Ability to use real serial as default interface rather than USB.
-
Hello,
I am with Autodrop3d. We have been building 3d printers that use a raspbery pi to send gcode to the control board in a rostock max v4.
Currently use a raspberry pi to send gcode to the printer over USB. The gcode sender program requires an acknowledgement from the board for each line and currently works over the USB. Unfortunately we have some problems with EMI that knocks out the USB interface from time to time. It would be beneficial to allow for changing the default from using USB to using some serial pins. I understand that you can send gcode over the serial interface normally used for the display but the board dose not send acknowledgements.Pushing the GCODE over a wifi or Ethernet network connection is not an option in my use case.
-
@mmiscool said in Ability to use real serial as default interface rather than USB.:
Pushing the GCODE over a wifi or Ethernet network connection is not an option in my use case.
can you elaborate on that?
the duet supports telnet, which would be suited for what you are trying to do. -
you'll loose out on features if not printing from the SD card; is not feasible to upload the whole file over wifi/ethernet and then print either?
you could use the usb interface to write gcode to a file on the SD card, then print from the card after verifying the filesize or something?
the duet supports telnet, which would be suited for what you are trying to do.
Pushing the GCODE over a wifi or Ethernet network connection is not an option in my use case.
telnet with vitual serial port on the pi is still pushing gcode over wifi or ethernet so guess not?
-
that is why i asked for more information.
sometimes it makes sense to challenge a requirement, because that requirement was based on incomplete assumptions. -
In my particular use case we are making printers with automatic part ejection systems. It would be too much to ask the user to configure one printer to use 2 different networking tools to make it work. As to pushing the data to the sd card. This is not a viable option. If the usb connection drops out it will not be able to continue print autonomously.
-
what about using a duet 3 which uses a raspberry pi as the main interface?
btw if you configure the network statically you could connect a duet ethernet / maestro directly to the pi with a shielded cat cable. no switch/router involved.
not much different than connecting a usb cable. -
still not clear why plain networking isn't an option. tcp has checksums and retransmission built in, so uploading would either succeed or fail after retries letting the sender know to retry.
also not quite clear on why it would require two tools the customer would need to be concerned with, if you're using a Pi as part of the printer it would mask the inner workings from the customer presenting a single interface regardless of how many tools networking/slicing/storage/etc is used under the hood?
-
Work is scheduled for RepRapFirmware 3 to extend the M575 command to configure the serial port to be used in that mode.
Meanwhile, your USB issues may be the result of a USB ground loop. See https://duet3d.dozuki.com/Wiki/USB_ground_loops.
-
@bearer using a network connection in my use case would not be practical. The board is being consumed in to a product that the user should not have to do a bunch of janky network set up. The raspberry pi in this use case is intergrated in to the end product and is the sole network connection the user has to set up. The way the system is written gcode is not pushed to the machine from a central server but rather fetched by the raspberry pi and sent line by line to the printer. Shooting the gcode file over to the duet sd is not desired as the raspberry pi is being used to control other parts of the printer directly as the pi and associated extra hardware are designed to be universal and work with a variety of printer control boards.
-
@Veti
I was really hoping to not have to do hardware changes on the base printers we are getting from SeeMeCNC. They come stock with duet wifi boards and we take the machines and add automatic ejection hardware and cloud print management software before reselling the machines. -
@mmiscool said in Ability to use real serial as default interface rather than USB.:
that knocks out the USB interface from time to time.
I hunted USB problems between a Pi and a different controller board (Planet CNC) for weeks. Manifested as a USB disconnect that would occur every 5 to 20 hours when cutting. Everybody thought it was EMI. Near the end of the debugging, had just the Pi and the PCNC board in a cage. Still happened.
Tried all kinds of things. Including 3 different Pi 3B+ boards. Really, lots of hardware changes. Excellent support from the PCNC people; many suggestions.
Turned out the Pi 3B+ has known USB issues. Very hard to pin this fact down with Google searches... (hard to separate Pi versions, and a huge signal/noise ratio with many posts that blur the 3B+ issue). If you read very carefully it becomes apparent.
In my case, switched to a Pi4 and USB became completely stable. Tested for 30 and 40 hours at a time in the cage. Put the setup back in a CNC router that uses 70V Nema 23s. Perfect. Several 20 and 30 hour cuts. Many, many, shorter cuts since then.
I have read that perhaps Pi2 and Pi3B (not plus) are also USB stable but have no direct experience either way.
Summary: Pi3B+ will disconnect USB every few hours; Pi4 is USB stable.
