Laser application
20 Apr 2012 06:25 #19386
by Zig
Laser application was created by Zig
Disclaimer: Moderator please move to the correct forum if this is not the right area.
I presently generate a scanned image ( writing lines in Y direction and stepping to the next line in X direction) Gcode file.
I use this file to drive a laser with Z axis as modulating source for the laser. So far simple enough and great results.
My problem is the time factor. With the stop start motion inherent in this configuration it takes quite some time to image.
I understand this problem has been tackled and solved by Graster crew.
I have had a look at their sample ini and hal file and have some difficulty in comprehending what to do to fall into the monkey see monkey do category.
Has anyone here had the joy generating the the two file formats and successfully printed/scanned out an image?
Any hand holding will be appreciated..
I must also add I do not start with an image file but rather with a cad file and shade/fill in the areas to achieve scanned effect.
I presently generate a scanned image ( writing lines in Y direction and stepping to the next line in X direction) Gcode file.
I use this file to drive a laser with Z axis as modulating source for the laser. So far simple enough and great results.
My problem is the time factor. With the stop start motion inherent in this configuration it takes quite some time to image.
I understand this problem has been tackled and solved by Graster crew.
I have had a look at their sample ini and hal file and have some difficulty in comprehending what to do to fall into the monkey see monkey do category.
Has anyone here had the joy generating the the two file formats and successfully printed/scanned out an image?
Any hand holding will be appreciated..
I must also add I do not start with an image file but rather with a cad file and shade/fill in the areas to achieve scanned effect.
Please Log in or Create an account to join the conversation.
20 Apr 2012 09:00 #19389
by andypugh
Replied by andypugh on topic Re:Laser application
Zig wrote:
Not answering your actual question, but in the 2.5 release of LinuxCNC it should be possible to set laser intensity with M67. (analogue output synchronised with motion). This didn't work in the past, but has been fixed now. You might find that this allows your code to run faster as there are no arbitrary Z-move limits being applied.
I use this file to drive a laser with Z axis as modulating source for the laser.
Not answering your actual question, but in the 2.5 release of LinuxCNC it should be possible to set laser intensity with M67. (analogue output synchronised with motion). This didn't work in the past, but has been fixed now. You might find that this allows your code to run faster as there are no arbitrary Z-move limits being applied.
Please Log in or Create an account to join the conversation.
24 Apr 2012 01:33 #19475
by Zig
Replied by Zig on topic Re:Laser application
Andy,
While M67 may alleviate reliance on Z axis direction flag in my instance the X and Y axis movements are still coordinated and will cause the laser head to stop and start.
I was looking at Graster and it seems they rely on two files one with XY coordinates and the other with full width sacn movement ( G00,G01 ) instructions.
In other words one file gets the laser head to move full width of the scan area without the usual stop start motion while the other file with Xor Y coordinates is used to generate trigger points for laser head.
I can generate both kinds of file contents.
I think if I could access the current file and extract the laser modulation info from it then I might be able to resolve my problems.
Question however is
HOW TO READ IN THE COORDINATES INTO HAL AND SYNCH LASER TO FULL LINE LENGTH SCAN?
I shall generate sample files and post them shortly.
While M67 may alleviate reliance on Z axis direction flag in my instance the X and Y axis movements are still coordinated and will cause the laser head to stop and start.
I was looking at Graster and it seems they rely on two files one with XY coordinates and the other with full width sacn movement ( G00,G01 ) instructions.
In other words one file gets the laser head to move full width of the scan area without the usual stop start motion while the other file with Xor Y coordinates is used to generate trigger points for laser head.
I can generate both kinds of file contents.
I think if I could access the current file and extract the laser modulation info from it then I might be able to resolve my problems.
Question however is
HOW TO READ IN THE COORDINATES INTO HAL AND SYNCH LASER TO FULL LINE LENGTH SCAN?
I shall generate sample files and post them shortly.
Please Log in or Create an account to join the conversation.
24 Apr 2012 02:37 #19476
by Zig
Replied by Zig on topic Re:Laser application
OK.. Some sample NC files to demonstrate the issues.
Please Log in or Create an account to join the conversation.
24 Apr 2012 02:38 - 24 Apr 2012 02:39 #19477
by Zig
Replied by Zig on topic Re:Laser application
more of the same
Last edit: 24 Apr 2012 02:39 by Zig.
Please Log in or Create an account to join the conversation.
24 Apr 2012 02:41 #19478
by Zig
Replied by Zig on topic Re:Laser application
and another one and a DXF to come showing the original drawing
Please Log in or Create an account to join the conversation.
24 Apr 2012 02:42 - 24 Apr 2012 02:46 #19479
by Zig
Replied by Zig on topic Re:Laser application
final file
Last edit: 24 Apr 2012 02:46 by Zig. Reason: could not attach a .DXF file will try .dxf
Please Log in or Create an account to join the conversation.
24 Apr 2012 02:47 #19480
by Zig
Replied by Zig on topic Re:Laser application
this time for shure Rocky
Please Log in or Create an account to join the conversation.
24 Apr 2012 09:54 #19483
by andypugh
Replied by andypugh on topic Re:Laser application
Zig wrote:
It looks like you only turn the laser on and off, so perhaps M62 / M63 would work best?
"The actual change of the specified outputs will happen at the beginning of the next motion command. If there is no subsequent motion command, the queued output changes won’t happen. It’s best to always program a motion G code (G0, G1, etc) right after the M62/63."
However, the head really shouldn't stop and start with XY motions in a straight line. I would be curious to see what happens with G64 (and no P or Q) or if the Z moves are put on the same lines as the XY moves.
Reading wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser there is the statement "Actually, if you go from X0 to X100 to X200 to X300, EMC2 will stops at X100, then goes to X200 and stop then goes to X300 and stops" which isn't exactly true. EMC2 will always make sure that is can stop within the next movement block (often referred to as "one block lookahead"). Your G-code contains blocks like:That might well force a stop for the Z move, but evenis asking for a 0.17mm movement, and the prior motion will be limited such that the head can be stopped inside the velocity/acceleration limits inside that distance. You probably have even shorter moves elsewhere in the image.
I have had a look at the graster approach, and can't help thinking that it is going about things in the wrong way. A great deal of cleverness has gone in to finding a way to make G-code and Axis do imaging, but I think that might be a sub-optimal approach.
It ought to be possible to create a very simple GladeVCP interface and a HAL realtime component. The Glade Interface would have a file selector and stop/start buttons and X/Y scale/position boxes (and possibly an intensity slider) and the HAL component would generate the raster scan and read .BMP data directly from memory, modulating an output pin accordingly.
Darn it! I didn't need any more projects!
Actually you might want M68. I really do need to do the experiment to see what "Analogue output synchronised with motion" really means. It could mean that it takes the value at the start of the next motion, or it could mean that it changes smoothly to the set value during the next motion.While M67 may alleviate reliance on Z axis direction flag in my instance the X and Y axis movements are still coordinated and will cause the laser head to stop and start.
It looks like you only turn the laser on and off, so perhaps M62 / M63 would work best?
"The actual change of the specified outputs will happen at the beginning of the next motion command. If there is no subsequent motion command, the queued output changes won’t happen. It’s best to always program a motion G code (G0, G1, etc) right after the M62/63."
However, the head really shouldn't stop and start with XY motions in a straight line. I would be curious to see what happens with G64 (and no P or Q) or if the Z moves are put on the same lines as the XY moves.
HOW TO READ IN THE COORDINATES INTO HAL AND SYNCH LASER TO FULL LINE LENGTH SCAN?.
Reading wiki.linuxcnc.org/cgi-bin/wiki.pl?Rastering_With_A_Laser there is the statement "Actually, if you go from X0 to X100 to X200 to X300, EMC2 will stops at X100, then goes to X200 and stop then goes to X300 and stops" which isn't exactly true. EMC2 will always make sure that is can stop within the next movement block (often referred to as "one block lookahead"). Your G-code contains blocks like:
F6100 G01 X301.0395 Y218.5995
G00 Z0.005
G00 X301.2095 Y218.5995F6100G01 X301.0395 Y218.5995
G00 Z0.005 X301.2095 Y218.5995I have had a look at the graster approach, and can't help thinking that it is going about things in the wrong way. A great deal of cleverness has gone in to finding a way to make G-code and Axis do imaging, but I think that might be a sub-optimal approach.
It ought to be possible to create a very simple GladeVCP interface and a HAL realtime component. The Glade Interface would have a file selector and stop/start buttons and X/Y scale/position boxes (and possibly an intensity slider) and the HAL component would generate the raster scan and read .BMP data directly from memory, modulating an output pin accordingly.
Darn it! I didn't need any more projects!
Please Log in or Create an account to join the conversation.
25 Apr 2012 00:07 #19510
by Zig
Replied by Zig on topic Re:Laser application
A small explanation
Z axis moves are 0.005 mm moves which is minimum step of the Z axis stepper motor ( notionally as there is no stepper motor) . This is used to toggle the Z axis direction flag. Z axis direction flag is used to gate the laser on off.
Laser output is is derived from OR ing X axis and Y axis encoder pulse trains. This train is processed by a monostable the output of whihc then in conjunction with gating signal drives the laser to deliver constant energy irrespective of head speed .
All in all a neat and tidy solution for my needs but for stop start movement of the head.
I have experimented with G61 exact stop start versus blended motion and have settled for a blended motion equivalent to 1/4 of laser spot size.
This gives me acceptable outcome but the jerkiness of motion is still very much apparent.
If You inspect the G code file You will note feed is set to 6000 and 6100 respectively. I actually set the feed rate to 150% and drive the machine at 9000 plus.
A few days back I went through retuning the servo loops and am happy to say there is measurable improvement not so much in speed of operation by precision with which the machine is now working.
The working platen is an aluminium plate approximately 500 * 600 *40 mm. The forcer which drives the platen is now producing a much tighter change and the small deviations at the sharp transitions are now almost imperceptible.
On the question of Glade interface... DOHHH??? I am yet to understand how to spell Glade. ( and You thought you didnt need yet another project)
Z axis moves are 0.005 mm moves which is minimum step of the Z axis stepper motor ( notionally as there is no stepper motor) . This is used to toggle the Z axis direction flag. Z axis direction flag is used to gate the laser on off.
Laser output is is derived from OR ing X axis and Y axis encoder pulse trains. This train is processed by a monostable the output of whihc then in conjunction with gating signal drives the laser to deliver constant energy irrespective of head speed .
All in all a neat and tidy solution for my needs but for stop start movement of the head.
I have experimented with G61 exact stop start versus blended motion and have settled for a blended motion equivalent to 1/4 of laser spot size.
This gives me acceptable outcome but the jerkiness of motion is still very much apparent.
If You inspect the G code file You will note feed is set to 6000 and 6100 respectively. I actually set the feed rate to 150% and drive the machine at 9000 plus.
A few days back I went through retuning the servo loops and am happy to say there is measurable improvement not so much in speed of operation by precision with which the machine is now working.
The working platen is an aluminium plate approximately 500 * 600 *40 mm. The forcer which drives the platen is now producing a much tighter change and the small deviations at the sharp transitions are now almost imperceptible.
On the question of Glade interface... DOHHH??? I am yet to understand how to spell Glade. ( and You thought you didnt need yet another project)
Please Log in or Create an account to join the conversation.
Time to create page: 0.117 seconds