cpdude wrote:Dirk,
To comments...1) I think that 1000mm/min is probably way too fast for the Z axis. Just my 2 cents. 2) I'm not sure which motors you are using but most steppers--including the stock ones offered by Bart--are 200 steps/rev. I think that would make 1/2 micro-stepping equal 400 steps/rev.
Brian
bdring wrote:G-Code is vector only. There is no realistic way to provide image information along the move. I suppose you could program the move from pixel to pixel with power information, but most controllers like to accelerate and decelerate on each move and often pause while power levels change. You could write your own controller to fix that, but by then things are so custom, you might as well use a more appropriate method of sending image information to the controller.
BTW: Does the GRBL code do constant velocity moves? Controllers without it do pretty badly on things like ellipses where it is really a set of lines. Fonts could be rough too.
Also: A long time a go I wrote a G-Code commenting app, so you see what is going on in G-Code. It is also a good general reference for G-code by clicking the "show all codes" button. There are a lot of flavors of G-Code. It is leans towards a Mach3 type flavor.
http://www.buildlog.net/cnc_laser/cnc/g ... mment.html
bdring wrote:Good news on GRBL. I assumed that was the case
your proposed method....
That is basically how my XMOS controller and the Mach3 plug in works, but where is the image data coming from? You can either have it already in memory or you can stream it in, but I don't think it is realistic to get it in via G-Code. I decided to stream it in because the memory could not hold a big image. Telling the controller the general raster parameters is rather simple (speed, width, stepover, number of rows) so I did that upfront once, rather than telling it at each row.
If you are just doing an on/off per pixel you will find that the laser will probably react acceptably. Most images usually have a few on then a few off anyway and you just leave it in the previous state if the next state does not change it.
The nice thing about an XMOS controller is the multiple cores. The pulsing engine will never be affected by anything else like interrupts or communications issues. You might want to do as much pre-processing as possible before each row so that it runs smoothly.
Users browsing this forum: No registered users and 28 guests