Uninterrupted connection required?


I am a little confused about the required connection to the printer mainboard, and hope someone can clarify the functionality. 
The project is to add an Raspberry Pi with Repetier Server to an Duet 2 WiFi board, as an direct display input. 

Now I wonder what happens if I start a print on the display. I thought that the gcode-model-file is uploaded to the Duet 2 and than started by issuing the correct command. Therefore an uninterrupted connection should not be required.?.!
However I read on the website that if the server shuts down the print will stop.
For example if the Raspberry Pi gets stuck, I would like that the printer just keeps going.

Can someone tell me how it works, and if it really stops, why?



  • The server has full of a print so it knows where it is executing commands, can pause and continue and also insert extra commands if required and the gcode can be spiced with server commands. That means we send them line by line and not the complete file at once. So yes, an interruption causes at least a pause on print. Server will try to reconnect and if it succeeds within 10 seconds it will continue the print. But we are talking about wifi so that is not the most stable connection method and you should be aware that it can happen. Better would be to connect pi via usb to duet and the use wifi on pi instead. Here file is cached on pi and if you loose wifi to pi print would continue uninterrupted and usb does not depend on wireless signals not getting disturbed.
  • Thanks for the fast answer.

    This is not how I imagined it works. And this way of handling command execution is not reliable enough for me. 
    It is really unfortunate that I will loose the extended features that the repetier server would provide. 
  • Currently we are writing a connection method to DCS when duet is running in SBC mode and communicates via SPI directly (just like sd card uses spi). Does not work on all boards and is work in progress. But you can not have both advantages. 
  • If I understand this correctly there would still be a continuous connection to the SBC.  This will not solve the reliability concerns. 
    Just to illustrate why I do view this so critical: 

    using Raspberry Pi & Duet:
    - Model-Gcode-File sits on the SD card of the RP. Therefore it has to share bandwidth with the operating system. And is also more trafficated because it has to load the entire system.
    - Raspberry Pi does not run an Real-Time-Operating-System, Timing issues can result from that.
    - unreliable mirco-USB connection to the Duet board.

    using "entirely buffered" model-file, --> stand alone duet:
    - SD-card only hosts config files and web interface. therefore to usage on the card is reduced and bandwidth is freed up for the important G-commands. 
Sign In or Register to comment.