I was wondering if it's still a problem? Since the laser can move rather quickly I anticipate running into a similar bottleneck with many small (and quickly processed) gcode commands. If that is still an issue, is there a solution for that except using something like ArcWelder to mitigate it to some degree? The control board that Octoprint will communicate with is SKR 2.0 with Marlin.
I haven't found anything on this topic, but is it possible to let the controller print from it's own SD card while receiving the same feedback in Octoprint as if the print was started there?
Most SLA printers don't run on gcode the same way that FDM printers do. You've mentioned it will be using Marlin - I wasn't aware Marlin supported SLA printers?
@Charlie_Powell What do you mean by: they don't run on gcode the same way? Several SLA printers I know of use Slicers like Cura and allow you to transfer GCODE to the printer. Some do have a closed slicing software and proprietary formats (Lke Formlabs and 3dsystems for example).
You're right, Marlin does not support SLA yet. I am however working on a galvo controller and will be modifying Marlin to control the SLA printer. I could run the GCODE straight from the controller (using an LCD and encoder), but I would like to use a Raspberry with Octoprint to have a touchscreen and use internal camera(s). That's why I wonder if the throughput from Octoprint to the Controller is still an issue.
I thought most SLA printers worked by sending an image to the printer, which is displayed on their screen to cure the resin in that particular shape. Wasn't aware this could be done with gcode as well - still surprised, as it doesn't have the usual 3 axes that an FDM printer has.
The throughput of OctoPrint to the printer should not be an issue. For most, it has never been an issue, OctoPrint has 100s of thousands of monthly users, and some people have issues - it really depends on the hardware you choose as well.
32 bit boards and decent Raspberry Pis (not the Pi Zero (W)) mean the problem doesn't really exist anymore. Arc welder can be useful to convert lots of tiny lines into curves, which is the common problem.
I guess if your SLA printer runs with really fine resolutions you may run into issues - but I can't really help with that without knowing what the gcode commands would look like. Normal gcode for an FDM printer is not an issue.
Also, to quickly answer this question- no, you don't get the same feedback. All OctoPrint gets from the printer is progress updates really. Whereas when OP is sending the gcode, it is in full control and knows exactly what the printer is doing. Plugins can modify this gcode stream, they can't impact the SD card print at all.
The ones that receive images would be DLP (Projector based) or LCD (UV LED and LCD mask). I believe the term SLA 3d printer is mainly used for laser+galvo based systems.
Thanks for your response. I was hoping that it would be possible to get some feedback from SD printing, but I guess one can't have everything
I guess I'll just order the parts and hope that I won't run into such issue. I guess Bufferbuddy might also help me if some bottleneck appears (just found out about it)
