Request - support galvanometer control for SLA
-
I will put a scope on my machine tonight and get back to you but since it is a standard component I suspect the answer is yes. With a 50um spot size and a 130x130mm build platform, I think we would want at least a 12 bit DAC. The laser scans a lot faster than a stepper so speed is also a concern.
-
OK. I probed both the + and - signals and the - didn't move. Only the + moved from 0 to 5V. So it appears my printer may only be using half the available control range. Probably a cost reductions technique since most microcontrollers can output 0-5V natively.
What do you think about a daughter board that plugs into the stepper sockets. Accumulating step&direction and feeding that to the DAC? Then we would just have to add some sort of transform in the X & Y coordinates of the existing firmware to correct for gain, offset, curvature, & rotation.
-
Came here to post this exact suggestion.
Could be HUGE for the duet, as Arduino lacks the tech to drive a galvo currently and a lot of people are looking to drive galvos in 3dp -
It doesn't make sense to take the stepper motor outputs and convert them to DAC signals. What I think we should do is one of the following:
1. Use the two 12-bit DACs in the processor. Problem: the pin that one of them uses is not available, because it is used in another essential subsystem.
2. Use an external DAC. We need to determine whether a DAC with SPI interface will be fast enough for this. What scan rates (degrees/sec) and resolution (degrees) are required?
-
It doesn't make sense to take the stepper motor outputs and convert them to DAC signals.
What part doesn't make sense? I'm not talking about the actual stepper coil signals - just take step&direction going into the stepper controller. The Home function can be used to reset the accumulator at the start of each job by simply making sure the accumulator has rollover protection.
-
I thought you meant connect to the stepper motor outputs. Yes, you could feed the step and dir signals from the expansion connector or from CONN_LCD to another board, which would convert them to analog signals. The ATSAM4S4B processor that I use on PanelDue could be used on that board, because it has dual 12-bit DAC outputs. The output range is limited to 1/6 - 5/6 of Vcc so the actual resolution over the usable range, about 1 in 2730 rather than 1 in 4096. Would that be sufficient resolution? If not then an external 16-bit SPI DAC could be used instead.
-
I would be so excited if you found a way to make this work. Right now SLA is taking off and the field of printers is so small mostly because of the difficulty of driving a galvo/the fact that arduino boards can't do it at proper resolution. All the solutions are proprietary and expensive. If you can get a duet and a duet branded DAC on the market that could drive a galvo they would sell like hotcakes.
-
Can you tell me more about how laser SLA printers are driven? Do you need an RPi or similar Linux-based SBC to process the sections of the model? If so then some parts of the Duet would be redundant, e.g. the network interface, probably the SD card, and most of the stepper drivers. In which case, this would best be done using a less expensive board, based on e.g. a SAM4S microcontroller and a single TMC2208 stepper driver (or perhaps TMC2660 for larger SLA printers). It could run a cut-down version of RepRapFirmware.
-
Hi everyone,
I am new to this forum and would like to introduce myself.
My name is Radek and I am from Poland. For a year I have been collecting parts and knowledge needed to build a laser cutting plotter and engraving equipment. At the moment I have several lasers and accessories for them. I also have steppers for the plotter and Raylase head for engraving.
I already have a bit of knowledge about cutting plotter. So, I will buy a DuetWIFI or I will make a simple controller for two steppers on TMC2660. If I make my own controller, the Control will be implemented from Beaglebone Black (BBB) along with a fast BeagleG code. But I think it can be cheaper to make it by myself. Because I do not need as many as five steppers and only two. Unless I get a discount from creators for example for helping with SLA
As for your conversation about SLA. I have a similar problem with my engraving head. It supports the industrial standard for XY2-100 lasers. I gathered some useful information. This is actually the fastest type of control for galvanometers. I have information about the protocol itself and the electronics needed to build. You can build in two ways: the first one is using the mentioned Beaglebone or using the Sitara processor itself, in your own solution. The Sitara processor used in the BBB but also in the Green and Blue versions has two very fast and independent from the main processor PRU executive units. They are enough to control galvanometers - even they are two times faster than we need in this case and only one PRU is needed. That's how colleagues from HALaser did. In turn, BBB for PRU was used for steppers in Replicape and other solutions. I do not mean here to advertise other solutions, because in my opinion the Duet is fantastic and priced okay. I am just referring to the SLA topic and looking for solutions for the processor that is fast enough to run galvanometers.
The second solution is using a different processor in the solution I found in the work of Chinese engineers, they used the STM32F107 processor. But probably we could do it on one DAC from the processor used in Duet. You only need to use one of the many RS-422 controllers to the electrical interface layer. The total cost of parts should be comparable, and maybe even lower than in the case of Duet.
@dc42: If you would be interested, I will send materials to priv or email. I would be also happy to cooperate in building this. What's true, my free time is terribly poor because I work as an IT security engineer in T-Mobile, but maybe some time I would find, because I really want to start the Raylase head, and I do not have too much to pay for a ready solution which is extremely expensive. HALaser which 270 to 500 Euros for richest version, is the cheapest I found.
There is one more solution - ILDA. They are used to control galvanometers at laser shows. There are quite a few open source solutions for electronics and software. However, it seems to me that the protocol used in ILDA is not suitable for 3D printing. The image from the laser is displayed all the time, is not scanning once to expose the resin liquid as in the XY2-100 protocol.
Sorry for my english
Regards -
Can you tell me more about how laser SLA printers are driven? Do you need an RPi or similar Linux-based SBC to process the sections of the model? If so then some parts of the Duet would be redundant, e.g. the network interface, probably the SD card, and most of the stepper drivers. In which case, this would best be done using a less expensive board, based on e.g. a SAM4S microcontroller and a single TMC2208 stepper driver (or perhaps TMC2660 for larger SLA printers). It could run a cut-down version of RepRapFirmware.
On my SLA printer (Peopoly MOAI - a phenomenal printer for the $$$, BTW), I generate gcode using Cura. The slicer appears to work very similarly to an FDM slicer - just finer resolution. It slices into perimeters and infill. Laser power is kept constant and curing time modulated by the speed that it is scanned. So I think the Duet could be used as-is if we could convert the step&direction to 0-5V analog voltages with about 12bit resolution. The easiest is to have one board which is placed twice - once for X and again for Y. We would have to added a calibration and a transform into the software, though, with this option, to correct for curvature, rotation, gain & offset. If we wanted to minimize the impact to that, a more elegant solution would be a single board which accumulates step&dir for both X & Y, and does the transform there before sending out to dual DACs. Would not need any significant compute power - the challenge is getting a rail to rail 12bit DAC. I have not found and PIC or AVR that can do that. Most are only 10bit and their output drivers can only get to around VDD-1 reliably so I think we are looking at a dedicated DAC.
-
The more I look at this, the more I think that a dedicated design based on a SAM4S processor would be best, if the almost 12 bit resolution of the built-in DACs is sufficient. That avoids the speed issues involved if the control word has to be sent over SPI.
You might even be able to hack a PanelDue control board to do it.
What is the maximum scan speed required, in terms of how many times per second the DAC output needs to change?
-
That does look almost there. A couple things stand out, though. Output range is only 1/6 to 5/6 of the Vref so we lose a third of the useful range (almost all uC I've looked at have this limitation). Also, the DNL is not exactly stellar at +/- 2.5 DNL. I think for this application DNL is particularly important as it will result in visible distortion in faces. So I've been thinking a smaller uC - maybe even 8bit (it doesn't have much to do anyway) and use dedicated DACs such at MCP4921. These DACs have built in near-rail buffers so can probably drive the galvo controller directly.
-
Yes you lose a third of the DAC range initially; but you will need op amps to get the drive voltage range you need anyway, so you can get the range back at the expense of a slight loss of resolution (that's why I described the resolution as "almost 12 bits").
You didn't answer the question in my previous post. The answer to it is critical in determining whether an external DAC is a viable solution and what speed microcontroller you need to drive it.
-
From the research I have done, it seems that 12bit DACs will not work, and you need to use 16bit DACs. Someone in the Marlin development has already started created code to drive Galvos:
https://github.com/MarlinFirmware/Marlin/issues/6001
And from what I seen it is not to difficult to hook up the DACs to the Arduino, or atleast so it seems.
And here is a discussion on SLA with some good info.
http://forums.reprap.org/read.php?13,197775
closed [FR] Software correction for laser SLA distortion #6001
