Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Orange Pi's and Octoprint are not so successful #1252

Closed
MatthewCroughan opened this issue Sep 18, 2019 · 9 comments

Comments

@MatthewCroughan
Copy link

commented Sep 18, 2019

Continuation of general Octoprint discussion from #1065.

@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 18, 2019

I've set up the two Ender 3's with Octoprint, I'm demoing a format to advertise that the machines support Octoprint, and to encourage usage.

image
image

@amcewen

This comment has been minimized.

Copy link
Member

commented Sep 18, 2019

How will we know when this issue can be closed? I mean, arguably you've done some evaluating of Octoprint, so we can close it right now... but I'm assuming there's more you're thinking of?

@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 18, 2019

@amcewen Once we have some sort of system set up for dealing with Octoprint like we're getting to with MQTT. Just trying things out.

@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

I keep having an annoying serial issue with octoprint that I thought I should log here since it's pertinent to the usability of octoprint in the space.

Orange Pi Zeros seem particularly sensitive to noise when powered over USB, this is unfortunate because of their price point at £10 and adequacy at running these processes. So, all the advertised 5V 3A psus in the space seem fine at powering the thing, but inexplicably serial errors will occur in Octoprint.

I've even observed spooky things like a print stopping when devices are added and removed from same electrical socket. Some noise must be getting coupled to the DC side. I'm going to try ferrite beads around the USB cable, and a few other things including a more expensive and suitable PSU. If all of this fails, I've had past experiences like this with the orange pi go away by powering the board directly via the 5v GPIO power pins.

This should also be noted as a potential risk to Pi 3's, since even though they clearly have better design in this regard, there's no reason it couldn't happen to them since the 3d printers are pretty clustered now, and there's a lot of noise, my opinion is that this is all a factor in the longer term stability of the 3d printing infrastructure, proper power management.

Since I lack any ferrite loops, I've put a 2.4A aukey multi device PSU which probably has better internals into the loop in order to see if that mitigates the problem even a tiny bit, if it does then we can safely say that this is more to do with noise than power requirements since 2.4A is lower than what I've attempted to give it before, and below spec.

@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 20, 2019

Okay. I've made an interesting discovery. I can trigger these serial errors:

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:2739Please see https://faq.octoprint.org/serialerror for possible reasons of this.Changing monitoring state from "Printing" to "Offline (Error: SerialException: 'device reports readiness to read but returned no data (device disconnected or multiple access on port?)' @ comm.py:_readline:2739)"

simply by unplugging the usb on a separate pi, or by plugging and unplugging things on the same extension lead.

However.. If I move the Pi over to a separate circuit network and take it off the same extension lead, the same thing still happens.

It is not until I move both the printer and the pi to a separate outlet that these issues are resolved. So I'm confused as to what the biggest part of the problem is. Is the printer noisy? Or is the orange pi really just that bad at handling noise?

@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 21, 2019

Alex noted that both prints on the Ender 3's which are running Orange Pi Zero's had failed when the laser cutter was powered on. I have some plans in order to attempt to mitigate this, one includes using buck converters to power the Pi's directly from the PSU of the printer.

@amcewen

This comment has been minimized.

Copy link
Member

commented Sep 23, 2019

I've moved your temporary power cabling so it's powered from the CNC room rather than the laser room. That means there's no longer a trip hazard in the laser room, and we can close the door to that room to keep the noise down in the main room

@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 23, 2019

@amcewen That's entirely fine, I only intended to use it for that hour that I put it up which I think I noted on the sticker "Can move once print finished" or something. Thanks for taking care of that for me, apologies that I wasn't in to do it myself.

@MatthewCroughan MatthewCroughan changed the title Evaluate Octoprint Orange Pi's and Octoprint are not so successful Sep 30, 2019
@MatthewCroughan

This comment has been minimized.

Copy link
Author

commented Sep 30, 2019

@amcewen I think you're right about the issue title, so I've changed it to be relevant to the discussion that went on inside, and I think we can resolve this now, since now we are not using Orange Pi's for the Octoprint setup, but instead Raspberry Pi's generally.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.