John, Jeff, If synchronized I/O can be implemented, that would sure seem to be the way to go, recognizing where Jeff indicates it likely still doesn't or won't work, at least in the current form.
Alternatively, could I not do something like?: G1 X1 Move to X=1 with the laser off G1 X1.00001 Z30 Raise to 30% power over very short distance G1 X2 Move X at 30% power G1 X2.00001 Z60 Raise to 60% power over very short distance G1 X3 Move X at 60% power Basically if the distance is less than can be traversed in 4-5ms, then that is less than the response time of the laser anyway. I have to check with my CAM guy, but I believe the post-processor for the laser CAM package could do this. I will be sure to check in on IRC on Sunday, or let me know if it will be at another time. Regards, Eric > The problem with using another axis is that the change in > laser intensity will be spread over the entire move. For > example, assume you are using Z for the laser intensity: > > G0 X0 Y0 Z0 initial position, laser power zero > G1 X1 Y0 Z1 moves to (1,0), while ramping laser from 0 to 1 > G1 X2 Y0 Z2 moves to (2,0), while ramping laser from 1 to 2 > > If you want the laser power to be constant during the moves, > you would need to do: > > G0 X0 Y0 Z0 initial position, laser power zero > G0 Z1 raise laser power to 1 as quickly as possible > G1 X1 Y0 move to (1,0), laser power remains at 1 > G0 Z2 raise laser power to 2 as quickly as possible > G1 X2 Y0 move to (2,0), laser power remains at 2 > > If you are willing to write that kind of g-code, this > approach is quite feasable. However, you still won't get > step changes in the laser power level - the rate of change > will be controlled by the Z axis velocity limits. In > essence, you are turning your two-dimensional part program > into a three dimensional one, with the third dimension being > laser power. In addition, the program above will _still_ > stop the X axis while the Z axis (laser power) changes. (The > first program does _not_ stop X, but the Z axis change is > spread out over the entire X move, instead of happening > quickly when the X value passes 1.0. > > It sounds like what you really want is motion synchronized I/O. > That means analog and/or digital outputs that are controlled > by G (or M) codes, and change in sync with the motion. Such > I/O has been planned for years, and was partly implemented in > EMC1 (other parts of it were commented out years ago and > never worked). > > At the moment I can't even find out what G or M-codes were > intended to be used for synchronized I/O. (I'm away from my > Linux box and don't have the ability to quickly search thru > the source code.) > > This should probably be moved to the emc-developers list. It > may be possible to implement synchronized I/O in time for the > version 2.1 release. ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
