Hi, I have the same problem with PREDATOR, I have two printers. When both were connected to pi and a Predator error occurred, both printers stopped working. The buzz the colleague wrote(multiple acces). When I placed the Predator behind an external powered HUB, only Predator, not CHIRON, dies in the error. Another thing that is interesting is that Predator is susceptible to glow bulbs of tube, but it's not entirely conditional. I have another question, and that is whether each instance of Octoprint can hardly allow only one serial port, as defined in 99-usb-serial.rules. Thanks.
Multiple instances on one Raspberry Pi is not officially supported. It works for some people, but if it doesn't work or behaves weirdly, you are on your own.
OctoPrint only supports a single serial port at a time because that's how it was designed: a single server connecting to a single printer.
Congratulations, you've discovered one of the best reasons not to put multiple printers on a single inexpensive single-board computer; a problem with one printer can take out multiple print jobs at once.
Of course, officially yes. But this is not a correct answer because a separately connected Predator is also sensitive to interference(in my case), so the second pi is not a solution. I plan to measure ground loops, I put ferrit cores on the cables, but this is the solution for higher frequencies. Flickering fluorescent lamps and their glowing discharges are moving on the order of kiloherz. Does anyone have experience with EMI filters? What type? Attenuation characteristic etc.
Oddly enough, I do have experience in this. I worked in the USAF and researched black/red data from secure devices. These are terms for unencrypted/encrypted data and referred to the ability of the Russians in gathering unencrypted communications using espionage. So we made sure that unencrypted traffic was shielded, in other words.
Each serial cable should have internal metallic shielding or a ferrite core, be as short as possible, not have additional inline adapters and should fit snugly at both ends. The Pi shouldn't sink 5V power over to the printer board. The printer board should be plugged in and turned on, preferably before the Pi has power. Under normal conditions the Pi will cheerfully power the printer's controller board by itself but fail to heat up the hotend/bed.
The typical daughter boards for RAMPS boards are very noisy, producing (EMF-dirty) square waves which just punch the electromagnetic field in the vicinity. Minus shielding, they are readily induced into any wire nearby and seen in any data-related signals, for example. Typical FCC-approved devices within the consumer space probably wouldn't allow this, for what it's worth. They say a picture is worth a thousand words; I wish that I had a screenshot of an oscilloscope view of this occurring.
I'm old enough to suggest this one: not all sites have 3-prong outlets with a good Earth ground. In some cases, a 2-prong power cable supplies power so the common ground is missing. Hopefully that's not the case here.
I can say from experience that I have put an oscilloscope lead on my skin and measured 60Hz from the lights in the room "punching" my skin 60 times per second. Turning off the light removed this completely from the output. So yes, fluorescent and incandescent lamps induce a cyclical noise to any unshield/unfiltered data lines. Arc sources are worse (Tesla coil input side like you might find in an old-school Radio Shack novelty lightning globe).
But also, solid 5V power to the Pi (and no sinking) is what's required for the data level threshold to be where it's supposed to be for proper serial communications.