Not sure if. Printing over sd card bypasses information flow so you can not trust shown values like fan or position any more. Also printing time prediction becomes unavailable. Maximum possible is percent and prediction on passed time, which is completely different. These are the reasons we omitted sd card print.
I feel like it would be relatively easy to implement, and could come with a disclaimer popup that tracking and timing would not be accurate (much like printing larger than the defined bed size).
Pretty please? I'd pay extra for this feature alone.
Starting a sd print is easy so much is true. Making all our products and interfaces aware of this mod takes a lot of time I think. Guess one day it will come, but can not say when that day is.
I also think this is a great idea. Occasionally I get communication errors on my usb on through repetier server (cura, s3d, and octoprint all control it fine but not until I reboot repetier server will it work again
Having an option like sd print is a temporary way I can prnt
Not sure if. Printing over sd card bypasses information flow so you can not trust shown values like fan or position any more. Also printing time prediction becomes unavailable. Maximum possible is percent and prediction on passed time, which is completely different. These are the reasons we omitted sd card print.
That is enough. M105 and M27 (Marlin) is enough information we need as a business and as far as time prediction, fan speed, etc is unnecessary (can be helpful but not required for MVP) for our process and use case; especially since most slicers have to review the generated gcode via previews prior to committing a plate into the print queue. Time prediction specifically we offload that to the slicer's responsibility to properly slot in plates to be printing in the appropriate time slots via the program's estimations (which ours are within 10 mins for a 24 hr print). We're testing out Repetier Server as a solution for our farm management and the ability to simply fire up a print via SD Card remotely is a time saver than having someone walk over to start is a missing feature we'd like to see implemented.
Why do we print from SD Card? Mainly because we're avoiding adding yet another device as a point of failure. We're currently testing Repetier Server as a basic monitoring server only with capability to preheat, issue gcode commands during maintenance processes, and remote emergency stop when not physically present. In essence we want a Non-Interference operation. If repetier server crashes, we do not want the current print job compromised, stopped/paused, or stalled/stutter upon reconnect. We have repetier server services on our miniPCs on each rack set to manual for this reason after initial testing showed this would affect prints and the way we operate.
You can simply just have an alert or notification in the UI tell the user that some reporting will be missing due to limitations of firmware reporting if you're concerned.
I'm with psaccess, I'm more than happy to contribute as well as even buy the two pro licenses on top for the number of racks of printers we have even though my use case doesn't call for it.
I'd like to add to this request. After an 8 hour print, Repetier lost connection and my print head stopped, creating a nice burn through. The option to print from SD Card should be available. This may be too difficult to code, and if so my apologies!
It is not too difficult to code but very time intensive since we need to modify 3 softwares with it's guis and many internal parts, so would take maybe 2-3 month of work for that feature to get correctly working. Maybe we add a faster hack sometime so you can start it at the regular gui and others just have to watch out for it, will see. It is on the todo for new features.
Have you already selected to reconnect after a connection lost and continue print? Especially on raspberry pi this is a saver as it mainly disconnects there due to power problems. Was especially added for this.
Problem with sd card may be that we need to prevent reconnect when sd was running to prevent a reset. But that is solvable as well. I mean bette rnot connect with message because of sd print then a reset while sd printing.
Have you already selected to reconnect after a connection lost and continue print? Especially on raspberry pi this is a saver as it mainly disconnects there due to power problems. Was especially added for this.
Problem with sd card may be that we need to prevent reconnect when sd was running to prevent a reset. But that is solvable as well. I mean bette rnot connect with message because of sd print then a reset while sd printing.
We have the server running on Win 10 Mini PCs, one on each rack of printers, as we've found RPis to be fairly unreliable for 24/7 printing for various reasons. We have all reconnects turned off and if the mini PC happens to reboot regardless, the server service is set to manual as another measure. So far the boards we use for our printers don't reset upon reconnect but there is a brief stall that does happen.
Ideally, we don't want any auto-reconnection but still have the ability to force a reconnect manually in the event we need to send M112 remotely. As it stands now, it's working but we're only just a week and half in for longevity testing.
I'm glad to see this is on the roadmap for the future. My use case is that of a 24/7 printing operation with the ability for someone to VPN in and check on the printers via an external camera system and send remote commands as needed.
A Faster hack would be great to add. I would love to even get temps, print finish, print running and pause. Those three things are broadcast from most firmware streams coming off of the serial bus. That should not be that hard to implement? Would love to see this feature. I had to move to SD card printing because some of my printers were having serial communication issues and at one point something took down the USB bus. I lost about 8 prints.
Comments
Pretty please? I'd pay extra for this feature alone.
Even if most of the features of RS are not available at first, this is such an important feature request for some printer farm operators like me.
Having an option like sd print is a temporary way I can prnt
Why do we print from SD Card? Mainly because we're avoiding adding yet another device as a point of failure. We're currently testing Repetier Server as a basic monitoring server only with capability to preheat, issue gcode commands during maintenance processes, and remote emergency stop when not physically present. In essence we want a Non-Interference operation. If repetier server crashes, we do not want the current print job compromised, stopped/paused, or stalled/stutter upon reconnect. We have repetier server services on our miniPCs on each rack set to manual for this reason after initial testing showed this would affect prints and the way we operate.
You can simply just have an alert or notification in the UI tell the user that some reporting will be missing due to limitations of firmware reporting if you're concerned.
I'm with psaccess, I'm more than happy to contribute as well as even buy the two pro licenses on top for the number of racks of printers we have even though my use case doesn't call for it.
Have you already selected to reconnect after a connection lost and continue print? Especially on raspberry pi this is a saver as it mainly disconnects there due to power problems. Was especially added for this.
Problem with sd card may be that we need to prevent reconnect when sd was running to prevent a reset. But that is solvable as well. I mean bette rnot connect with message because of sd print then a reset while sd printing.
We have the server running on Win 10 Mini PCs, one on each rack of printers, as we've found RPis to be fairly unreliable for 24/7 printing for various reasons. We have all reconnects turned off and if the mini PC happens to reboot regardless, the server service is set to manual as another measure. So far the boards we use for our printers don't reset upon reconnect but there is a brief stall that does happen.
Ideally, we don't want any auto-reconnection but still have the ability to force a reconnect manually in the event we need to send M112 remotely. As it stands now, it's working but we're only just a week and half in for longevity testing.
I'm glad to see this is on the roadmap for the future. My use case is that of a 24/7 printing operation with the ability for someone to VPN in and check on the printers via an external camera system and send remote commands as needed.