Laser Sintering Galvo Drivers

[Richard Ibbotson]

I just built a prototype of the galvo driver hardware for the laser sintering. At present just an arduino shield with 16 bit DACs and the drivers for the galvos.

Have tested with sketches, but now need to make the driver for Marlin, or better Smoothie.

Can anyone with knowledge of Marlin internals help ?

The DAC output will drive the deflection angle of the galvo, and I need to map to an XY image at the powder surface. Not sure how the flat field lens works in with this too.

Also I need to understand the dynamic case for the galvo mirror motions. I can experiment, but someone with more experience may be quicker.

[barnaby]

Not sure that starting with Marlin gains us anything. It is build
ground up around the concepts of driving steppers. For your sanity you
would have to leave the planner etc. all dealing with generating
DIR/STEP output. Then add a routine that simply took the DIR/STEP
signals and integrated them into the value for the DAC. I.e. in
stepper.cpp change all the WRITE(X_STEP_PIN, !INVERT_X_STEP_PIN); lines
to set a new value in the DAC instead.

Smoothie is a much better starting point. Whilst its current
modules/robot/Robot.cpp is stepper based you could drop in a new module
that was optimized for galvo's. Their planner etc all looks
well-structured enough to work well. However it doesn't run on
Arduino's, do we have other hardware as an option?

Alternatively I hacked a supper simple g-code evaluator together for
testing different driving options: https://zi.is/p/browser/microg
Obviously we don't want to reinvent the wheel and would need to switch
to Smoothie before going past basic testing. But the is something to be
said for starting with something that dose precisely what we tell it,
rather then trying to test our output code inside the advanced
acceleration planners.

As you say it is the dynamic stuff that we need a good understanding
off. Even the simplest question: how often do we need to update the DAC?
It may even be possible to use more analog stuff to smooth the output so
the MCU can output more in terms of: Move galvo from its current
position to XY over T seconds.

[Richard Ibbotson]

The DAC interface is SPI plus a couple of GPIO. The PCB version will not be
a shield, I just used one for prototype and testing. With Arduino, I get
updates to both the DACs about every 15us with the library I wrote. This is
above the galvo performance limits I think. A faster processor would mainly
limited by the 50MHz SPI speed giving an update every couple of us.

Smoothie boards do not seem to be available yet, but I do have mbed and also
the LPC4357 board. The LPC4357 has a spare 200MHz cortex M0, and serial I/O,
which I will investigate to offload the laser interpolation.

--
You received this message because you are subscribed to the Google Groups
"Reading Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an
email to reading-hacksp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Richard Ibbotson]

I do think it is right to go directly with Smoothie and 32bit.

So far I have tied myself in a few knots with the LPC4357 as most of the examples use Keil or IAR. The evaluation versions are too small, and the real version too expensive. I have used Rowley in the past, but struggling a bit to port the LPC4357 emWIn code across, especially the link files for the complex memory maps. Rowley is cheaper, but still not free.

I think we need to agree on a common toolchain without constarints. I am not very command line or Linux savvy, so something that I can use under Eclipse would be better for me.

[Alan Wood]

Smoothie would be much easier for you as it uses an event subscription to more loosely join its modular parts, that way you could keep things like the planner etc..

Couldn't you use something like an LPCXpresso board (there are several) either with it's CodeRed GCC, our your own manual GCC toolchain + Eclipse.

regards

Al

--

You received this message because you are subscribed to the Google Groups "Reading Hackspace" group.
To unsubscribe from this group and stop receiving emails from it, send an email to reading-hacksp...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--

regards

Al