non-laser resin based printer
I am purchasing the various pieces that I need to build the printer detailed in the link below.
I have a spare Duet and I'd like to see if I could use it in this build.
Specifically, there is only 1 stepper which is the Z axis, and two limit switches, but I am wondering if the bed heating circuit could be used to control the UV lamp system. In reality it would need to be able to turn the lamp controller on for a duration of time, and then turn it off.
In the printer that I have linked to, an LCD panel with the backlight removed is used to display the layer image on the bottom surface of a vat containing resin. A cluster of UV LEDs is used to fuse the resin layer. The build plate is raised through each layer and the LCD displays the next sliced image which is then exposed to the UV light.
If I can't use the Duet, it's not a problem. A Raspberry Pi is used to drive the sliced image on the LCD, and general io pins are used to drive the stepper and light exposure. I have seen other designs using a Ramps board which is why I thought I might be able to use the Duet.
Yes it's possible to use a Duet talking to a RPi running nanoDLP. You need to be running firmware 2.02 to get that support. Send M555 P6 to put the Duet in nanoDLP-compatible mode (which causes RRF to execute every move individually, waiting for it to complete before processing the next command). Create macro peel-move.g to define what happens when the Duet receives the M651 command from nanoDLP.
AFAIR, nanoDLP uses a M106 or M42 command to turn the backlight on/off, and you can set up RRF to use that command to control the bed heater output.
Thank you so much for the quick reply. That is great news.!!!
Is there a wiring diagram anywhere and perhaps a setup guide?
I will look up the G-Codes you have listed and look for a peel-move.g sample
I have about a month for the parts to come in so I have time to understand what I have to do to make it work.
Any docs you can recommend?
No there is no documentation yet. The documentation for nanoDlp is rather poor too, it doesn't say anywhere what GCodes it sends or how it expects them to behave.
I have spent the morning searching for information that might be helpful. I have not found a specific list of which GCodes are supported by nanoDLP.
I have found a manual for a specific printer which is the mUVe DLP and the manual is all about setting up nanoDLP. There are certainly a number of specific GCode detailed examples.
I have a couple of Raspberry Pi 3 b+ units with Raspbian installed so I am going to download nanoDLP and see what I can discover by working with the software. I can easily set up a board with some LEDs to see what GIO pins are being used.
Is there anything specific that I can look into that would be of help to you in looking at this? Is the specific list of GCodes in the DuetWifi the list that would need to be supported assuming there may be some specific to dealing with the exposure time for the UV Lighting, etc.?
In theory would the goal be to replace the nanoDLP with the functional capabilities already built into the DuetWifi? I already have a DLP printer that I purchased from SparkMaker which includes the software used to slice the model before it gets written onto the memory card which it prints from. Would I not be able to obtain most of the GCodes needed by reading that GCode file?
I'm offering to do whatever research I can. Can you give me a list of the information you need?
It's not difficult to set up nanodlp. It lets you configure the GCodes that it uses for turning the backlight on/off and for several other things. So you can have it control a fan output with m106 for that, or a GPIO pin with M42. It doesn't let you configure the one for the peel move, it always sends M650 and M651. Neither does it say how it needs G1 moves to be treated. But I went through all of that and added nanoDLP compatibility to RRF 2.02, so you don't need to.
The GCodes are sent from the RPi to the Duet over USB. The SD card in the Duet is used only for running macros (homing macros, peel-move.g and so on).
Thanks. That would make implementation simpler by having the RPi manage sending the slices to the LCD panel and control the exposure time.
Any plan to put together a wiring diagram?
I meant to include the link for the mUVe:
page 13 starts the discussion on M650 if it helps
@ dc42 Hello do I understand correctly that RPI and Duet2 Wifi can be connected via USB? So RPI USB Port is only intended for power supply, or am I wrong? I have RPI3 and RPI4 here, which have different USB ports but the same function as far as I know. So do I need a cable that fits into Duet's USB port on one side and RPI3 / 4 on the other?
Sorry vor my English, i speek German, this is the Google translater...
bearer last edited by
So do I need a cable that fits into Duet's USB port on one side and RPI3 / 4 on the other?
Plain micro USB cable (that has data + power). While you can supply the Duet with 5V from the Pi via USB you'll need a 12-24v supply for the Duet to drive motors, which in turn can and by default will also provide the Duet with 5v.
@bearer I have the power supply for duet via 24V power supply. RPI also has its own power supply. Can I still use this micro USB cable to connect to the RPI to transfer the data from the NanoDLP?
@bearer oh, wait, when I connect RPI to Duet via USB, RPI no longer has its own power supply unit because it was connected via USB.
@bearer that would mean that I supply the RPI from the Duet with power, otherwise RPI has no power connection, except USB
bearer last edited by
otherwise RPI has no power connection, except USB
maybe you should make your own thread.
But as the Duet has a only micro USB connector, the cable should go to the Pi's full size USB A leaving the Pi's micro USB for supplying power to the Pi. You cannot power the Pi from the Duet's micro USB.
If you need to provide the Pi with 5V from the Duet you will need to use the GPIO pins on the Pi and a 5V pin on the Duet.
@bearer Sorry, but I didn't understand that. What do you mean with USB A? Standart USB Kable for PC in the Size A? Can you post a picture here to illustrate this? I will create my own thread later, I thought it would be better because the topic was already discussed here.
bearer last edited by bearer
Can you post a picture here to illustrate this?
There is only one way to connect such a cable between the Duet and the Pi. Micro B needs to go in the Duet and it will not flow power back to the Pi. (Because of the design in the Duet, nothing to do with the cable itself)
@bearer ok, and from where and via which port does RPI get power? The other side of the cable is then connected to the power supply? Sorry, I do not understand.
Danal last edited by Danal
Recent RPi has several USB ports. It has a micro USB that is an input for power only, no data moves through that port.
It has up to 4 USB A ports that act as "host" ports. They can power, and exchange data with, mice, keyboards, etc, etc. They are two-way data.
Therefore, you could power the Pi through its input only power Micro USB (cable comes FROM a power supply), and also connect a USB A out of the Pi to the Micro USB on the Duet. This will allow appropriate software on the Pi to control the Duet. The Duet will still need VIN (Screw Terminal) power for motors, heaters, etc.
@Danal Oh ok, now it's clear, sorry, I forgot the other USB ports. Alright !!!
Danal last edited by
And, having said all of that, it seems like massive overkill to use a Duet on one stepper and two limit switches. Especially when the NanoDLP software supports driving a "step stick" style stepper driver directly from the Pi.
While they show a circuit board, this looks simple enough to breadboard.
@Danal Yes, I've already read that, of course it's totally exaggerated with the Nanodlp on the Duet. I just wanted to have everything in one device, whether that's the best solution - I don't insist, but as a test.
Thank you for the clarification!!!
@Danal as I said, this is only intended as an additional option. My printer will otherwise have many useful options such as 4-fold extruder changer, endless z-axis (transfer belt), status LEDs, etc. One of the options is supposed to be LCD SLA printing, therefore the effort.