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