Hello.
6 days ago I downloaded the latest/current DietPi and installed it successfully on an ODROID C2. Works really well. Then I installed octoprint (from apt) and mjpg-streamer. Both also work, except of some issues:
I have connected a USB Webcam and an Arduino Mega (RAMPS 1.4 board). Camera works, octoprint works.
But during printing I repeatedly get an “unexpected error” in octoprint and it closes the connection to the 3D printer. When stopping mjpg-streamer, printing works fine.
This makes me think this is related to excessive load on USB, caused by the high data volume caused by the camera.
So I had a close look on USB using ‘lsusb’:
My Odroid C2 shows only one bus:
BUS 001 … Root HUB and all USB devices appear on this bus.
My friend also has an Odroid C2 running a slightly older DietPi version, but also has a USB Camera and Arduino connected to the four USB-A connectors. (Nothing on the microUSB !)
His ‘lsusb’ surprisingly shows two busses:
BUS 001 … Here arduino is connected
BUS 002 … Here his USB Camera is connected)
I am pretty sure this is the secret why his Odroid works stable, while mine repeatedly looses the data communication between Arduino and octoprint (while /dev/ttyACM0 still exists!). Somehow the dataflow randomly stucks, and then octoprint disconnects the printer.
My only idea is that USB is so extremely loaded by the camera that responses from Marlin are lost.
Does anybody have an idea in this:
How can my friend’s C2 have two USB busses while mine has only one? As this are two identical devices, this only can be a configuration issue on my side.
How can I get this communications error solved? I cannot print anything because of this persistant risc that communication fails.
It will be very kind if somebody can help. I am lost.
The C2 has only one USB controller, so it’s correct what you are seeing .
The kernel probably handled it different in older versions, that’s why you friend is seeing two busses and you just one.
My first is that the USB connection is busy with the webcam.
Maybe you can try to lower the webcam bandwidth within mjpg Streamer and see how’s it going then.
Hi, Jappe,
and thank you for confirming. Though, it is still a massive problem because of the overloaded USB BUS (it leads into the communication problems between Arduino and ODROID C2.
gemini.google.com recommended me to use an OTG cable adapter on the microUSB connector. As I connected the +5V supply to GPIO port (more rugged supply), my microUSB connector is completely free. If there is really OTG available, this will not go into the USB-HUB Chip and still interfere with Marlin; instead it will go (if gemini is right) directly into the SoC and therefore result in another (independent) USB BUS.
This way the camera cannot impact the communication with the RAMPS 1.4 board.
I hope gemini was not telling me some fantasy stories as it often tends to do.
Would be great if somebody can confirm how and if it works.
I ordered an OTG cable today. I will receive it on Tue/Wed, then I will test it. If I am right, this should separate the extreme data flow from USB CAM from time critical but slow communication with Marlin and solve the problem.
If somebody is doing the same, I will be happy to participate on his/her experiences.
Hello.
I am fighting since monday to get the USB WEBCAM working with octoprint. I used mjpg-streamer for webcam.
My problem is:
When 3D printing, everything appears to work fine, until I get an “Error: Commection unexpectedly failed.”, and octopring closes the connection.
This is showing up in the octoprint LOG: Send: N5490 G0 F5400 X123.6 Y84.44176* Unexpected error while reading serial port, please consult octoprint.log for details: SerialException: ‘device reports readiness to read but returned no data (device disconnected or multiple access on port?)’ @ comm.py:_readline:4175 Please see Making sure you're not a bot! for possible reasons of this. Changing monitoring state from “Printing” to “Offline after error” Connection closed, closing down monitor
This is a nightmare, because without communication the hot nozzle stucks in the melted plastic, in worst case the entire weekend long.
What I permanently saw was a flickering image (approx. 3mm high stripe), where either something or the correct image appears.
With disabled mjpg-streamer printing works perfectly.
Now I give it a try with ffmpeg and a python script as web server. here the picture is stable.
Before changing to this, I wanted to run the USB camera on OTG to separate it from USB (used for Arduino), but whatever I tried, the camera did not appear in USB.
So my idea: Is OTG not working at the moment ?
My C2 is installed exactly on same place where I had a RPi 1B before. Also same USB Cables are used. The C2 is running latest DietPi 10.3 (Trixie).
Via USB following devices are connected:
Arduino AtMega 2560 (with RAMPS board), USB Cable of 10cm length.
USB Camera
The RPi very seldom froze when USB Camera was on. But this is definitly caused by the totally overloaded system (octoprint + mjpg-streamer).
So I replaced the RPi 1B by an ODROID C2 which is lots more powerful. (Though, needs are the same: 3D Printer + Camera.)
I was able to find out that ‘dmesg’ sometimes reports an (EMI?) Error, and that the USB-HUB turned off the Port of/to Arduino, then it re-initialized it.
Without mjpg-streamer running (but Camera still connected), this does NOT happen. So I am not really sure about this claim.
The C2 is connected to the power supply with its GPIO pins (2+4 = +5.1V, 6+9 = GND). So it has a very reliable connection. The PSU for all logic (including arduino and camera) comes from a 5V/3A PSU, so this PSU is far away from its physical limits.
The arduino is NOT supplied from RAMPS Shield. It gets its 5V only from C2 USB. The RAMPS board is connected to 24V/60V PSU for sufficient power for the steppers and printhead.
Does anybody have an idea why the C2 is running so unreliable while the RPi was running well for many years (until its SD died). I am close to revert back to RPi with boottime of 4-5 minutes, but running stable.
It would be great if the problems on C2 could be solved by configuration.