Typically, yes, since they are run out of the same venv.
That depends on how your multi-instance setup was done. If they all use the same venv and just different service file configurations pointing to different basedir locations then yes, you would just have to restart the other instances for the plugin to be loaded. You could technically copy the config bits for the plugin from config.yaml into the other config.yaml files of the other basedir locations too once you get one setup.
Running into another issue. I have an Ender 3 Pro that I've had a lot of trouble with, so it's mostly just been sitting there for a few months until I had time to deal with it. My main printer is a Prusa i3 MK3S+. I set up both printers because my plan was to eventually be using both of them. I've been using two instances of OctoPrint on my Pi for a while now and I've had no problem with it controlling my Prusa. It's been a wonderful time saver. (For instance, my workshop is in our barn, a short walk from our house. I can now start a print from my study in the house and not have to go down and check on it until I'm ready to pick up my print.)
Looking back, I'm not sure I did anything with the Ender 3 Pro until today. I started a print and it messed up from the start. I was at the print table, so I used the control on the E3P to stop printing, but it wouldn't stop and by now it was trying to move the printhead too far in one direction. The E3P has a frustrating situation where, if you leave the USB connection plugged in, it still acts like it has power, even after you turn it off and even when you pull the AC plug, it still tries to keep going. (At least it did today.) So I pulled out the USB cable. I shut down the E3P 100%.
While troubleshooting the E3P, I started sending my print to my Prusa - but my E3P started acting like it was possessed. When I looked things over, I saw that instead of going to the Prusa, the print was going to my E3P! (I had made sure I was in the correct instance of OctoPrint before printing.) I stopped and rebooted. I set the hot end temp on my E3P to a higher temp (on the E3P control panel), then I went to the OctoPrint interface, picked Prusa, and specified /dev/ttyACM0 and went to the Temperature tab. It showed me the temp data for the E3P. So I went back in the settings and changed the Prusa instance to /dev/ttyUSB0. Same situation: It gave me the temperature data for the E3P again.
I tried the same with the 2nd instance of OctoPrint and got the same. (I didn't expect it to be different.) So whichever tty device I specified for a printer (ACM0 or USB0), OctoPrint only talked to or saw my E3P.
I ssh'ed in to the system and listed /dev, since it's been a while since I set this up. This is the related part of the listings:
I had forgotten I had set up direct links. I went back to OctoPrint and, in both instances, I added globs for listings, so I have the following (globs and devices OctoPrint lists are in the screenshot):
This gives me a list of the original devices OctoPrint lists (ACM0 and USB0) as well as the links I had created.
Once I did that, the problem changed - it's workable, but unpredictable for future situations. Now when I pick my Prusa instance, I'm getting the E3P temp data - no matter which device I select. If I pick the E3P instance, no matter what device I select, I get the Prusa temperature data displayed. (Each instance still displays the webcam for that instance, but that's an entirely different issue, so I'm just mentioning that as troubleshooting data.)
If I could count on this continuing reliably, I'd just swap the names and instances of OctoPrint, but I have no idea what's going on, or why I can pick different devices and still get data from the device I picked. This feels like the two separate OctoPrint instances are just picking the serial device they want no matter what I select.
I neglected to include that after I change from one device to another, in each profile, I do disconnect and connect, specifying the same port I specified in settings.
That can't and shouldn't happen if things are setup right.
Show us the udev rules you are using to create /dev/ttyPRUSA and /dev/ttyE3P
It took a while. It's happening - but I found that after reconnecting, I had to wait for the values to show up. I was looking at the chart and it took time for the changes to show up there. Once I got used to waiting, I experimented and found that even the immediate temp readings might take time to change.
Once I got used to the change being delayed, things worked okay.
Webcam parameters:
I want to add some configuration changes for mjpg_streamer and webcamd for my first instance of my webcam on my Pi.
When I first set up my multi-printer/multi-cam server, I used the instructions on this thread to set up both webcams. So I copied /boot/octopi.txt to /boot/octopi.conf.d/webcamd2.txt. My understanding is that gives me 2 config files, /boot/octopi.txt is the config for the first instance and /boot/octopi.conf.d/webcam2.txt is the config for the 2nd instance.
I also see, in /home/pi/webcamd, that if I want to add or edit options, to do so in /boot/octopi.txt.
I also note a webcamd and webcamd2 in /boot, but apparently I don't need to worry about those files.
I tried adding options to /boot/octopi.txt, then rebooting the Pi, but I'm not seeing any results.
Note: I'm testing with "-vf" as an option because it's a setting where I can quickly and easily see the results. I know, within OctoPi's web interface, I can check a config option to flip it vertically, but, again, this is my test option so I can be sure it works and add more later. (Also, my wife and I often use the direct link to the stream, like http://octopi/camprusa/?action=stream to see print status, so if I can flip the original stream, that'd be helpful - as well as using this one parameter as a test to know where to add other changes.
Not all parameters are supported by all cameras - especially the flip options. They might be in the config correctly, but unable to be applied.
The parameters in either octopi.txt or webcam2.txt will apply to those webcams individually respectively, not one set of parameters for both.
So it just might be that my cam won't flip. Okay, that's a good start for research. I can check on that and switch to another option to test.
Am I right that my changes on /boot/octopi.txt will apply to my 1st webcam and /boot/octopi.conf.d/webcam2.txt will apply to the 2nd webcam? (I'm paraphrasing what you're saying to be sure I understand it.)
Yeah, that's correct.
Another way you can adjust these parameters, in a more user-friendly way is with the 'Camera Settings' plugin.
I know that'll adjust it in OctoPrint, but it won't adjust the actual stream itself, right?
(Well, if I can't invert it, it looks like I'll have to drop using the raw stream anyway.)
The Camera settings plugin applies to the stream itself, not just in OctoPrint's UI.
1 Like
I did get in touch with tech support and they say the camera does support flipping the image and specifically suggested using '-fv' for mjpg_streamer. They also sent screenshots showing the video stream flipped. Granted, that could be a load of crap, but they did know which switch to use, so I'm inclined to believe it supports it.
Do you mean the camera settings I change in the config files or the ones I change in the OctoPrint UI, under the settings? I changed to flip the video in OctoPrint's settings and it does flip the stream in OctoPrint, but when I go straight to the streaming URL directly (http://octopi/camprusa/?action=stream in my case), it's still upside down.
Neither.
1 Like
Thanks!
That looks like it'll handle everything that can be done. If I weren't in the middle of a long print, I'd already be installing it.
Is there a relatively easy way to use a different theme for each instance of OctoPrint?
I started using the UI Customizer plugin and changed from the default theme for the web UI. I notice that whatever theme I use works for both instances. Is there a directory where I can put a theme for my 2nd instance?
It's not a "must do" kind of thing, but if it's easy, it does help me tell, at a glance, which printer I'm looking at.
That shouldn't happen. How did you setup the multiple instances? Each instance should have its own config.yaml file that contains the plugin information.
The actual plugin info, like the layout patterns, is per-instance. The theme is for both. My guess is that the theme is html and css files stored wherever OctoPrint keeps its normal HTML theme data.
It looks like it's saving to a base folder, which probably is getting interpreted to the octoprint files directly rather than in the individual instance's base folder.
I would probably recommend maybe changing the temperature graph image with my Custom Background plugin. Chris Riley mentioned that one in his multi-instance guide and I thought it was a good idea. There's also the Name in Appearance settings that you can use to change what shows on the title of the browser.
1 Like
@Laze not sure if you might want to consider changing that base path to be self.get_plugin_data_folder() or if it's a technical reason you can't reference the css files that way?
Never got around to it.. Will check ASAP