non-laser resin based printer
-
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.
-
Hi
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?
Thanks,
Tim -
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:
https://drive.google.com/file/d/0B8xCOdl2soS-UDQ1ckE3SEZvVnM/view
page 13 starts the discussion on M650 if it helps
Thanks
Tim -
@ 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... -
@Fasi said in non-laser resin based printer:
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
-
@Fasi said in non-laser resin based printer:
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.
-
@Fasi said in non-laser resin based printer:
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.
-
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 !!!
-
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.
https://www.nanodlp.com/download/#pcb
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.