Allow infinite acceleration/speed on one axis

Hey all,

I've more or less finished a relatively standard laser-cutter (2 physical axes, CO2 laser/flying optics) and I'm using the Z axis to control laser power, where a positition ranging from 0 to -1 applies no to full power (with saturation above 0/below -1). My power output is physically driven using the PWMGEN hal component. This works more or less well enough, but I find I'm limited by the acceleration limits of the Z axis.

I've set up the maximum joint speed and acceleration to values that allow movement from 0 to -1 in under one servo-thread period, but I find that the path planner commands a deceleration/acceleration ramp along the X/Y axes when approching a step in the Z axis. As there is no physical reason for the axes to slow down at all --- linuxcnc can simply directly switch from 0% duty cycle to 100% duty cycle --- this slows down the cycle time of a part as well as causing an uneven surface as I expose the material near the Z step to the beam for longer than the remaining material.

One possible (though inelegant) method of resolving this could be to change the scale of my mapping from 0 -- 1 to 0 -- x, where x is smaller than my path blending tolerance (as set by G64), but I'd prefer not to do this as this makes my CAM generation slightly more obtuse.

Does anyone know if there's some way to allow the trajectory planner to generate a path that's reasonable for my application? (IE approach a large step in Z, while X/Y are moving, and change the Z value instantaneously without slowing down X/Y motion).

Cheers!

Have you tried using S codes to set your power level?

(then you would also have Z free to use as an axis for focusing your beam, if you would like that .)

Hi!

I'm not sure if using the Z-axis is the right choice for your application. For my Foam-cutter I'm planning on using the spindle speed as input for the power. As for the laser cutter, the foam-cutter must maintain a constant speed in order to make nice cuts.

My plan was to use S0 - S100 to set the power. Spindle speed is normaly connected to a PWM output in the first place. So this would be an easy path to follow.

Cheers!
Bernie

Thanks for the ideas, however after testing I can't really say that I noticed much of a performance increase; it still seems like the trajectory planner doesn't read ahead far enough to generate smooth motion (despite there being no change in velocity on a changing S word). For example, running a program like;

G0 X0 Y0 S0
G1 X1
G1 X1.001 S100
G1 X2
G1 X2.001 S0
G1 X3
G1 Y1
G1 X2
G1 X1.999 S100
G1 X1
G1 X0.999 S0
G1 X0

generates significant slowdown when transitioning over S words. Could this be because the current trajectory planner only has a one-line lookahead?

Uh, that would be the 2.6 branch (assuming that's what's regarded/packaged as 'stable'/equivalent at the moment), which AFAICT has a one-line lookahead. A longer lookahead sounds great! Any idea as to when 2.7.x is going to be regarded as stable/pushed out to the repositories?

Looks like the S command is breaking the queue (I tested in 2.7v0.5).

Try it using M67 E(0,1,2,3) Q (float value)

E chooses which of the analog pins (00,01,02,03) the float value will be used in your hal file.
motion.analog-out-00

so for your example code it would be

I have experience with the same issue as the OP, and will describe my findings and thoughts here.

Initial setup:
I have a traditional 3-axis cnc mill, using horizontal plane movements for X & Y, and vertical movement on the Z-axis. I want to laser engrave an image onto a surface using a raster engraving process. I’m running LinuxCnC 2.7.8.

Expected Outcome:
I want to control an engraving laser using Linux to vary the output power of the laser. The laser output power is typically a 0-100% setting. The preferred outcome of this setup would allow me to engrave as fast as my machine can do so, theoretically allowing infinite speed of the laser power output control (as the OP is hoping to achieve as well).

Possibility #1:
Controlling the laser output via M3 SXXX and/or SXXX commands.

I found that this approach is interfering with the trajectory planner in some way, and as a result we get erratic movement of the laser because the X&Y axes (what is moving the laser) are constantly accelerating/decelerating each time an SXXX command is encountered. The larger changes in SXX, say from S01 to S99, result in the greatest deceleration. I’m not sure what is causing the delay, perhaps Linux pwm generator, maybe it is internally allowing some time for (what it thinks is a spindle) to adjust. After testing this approach it “works” but is not great; some reasons for this are:
#1: I want the laser to travel at a constant velocity any time it is engraving. If the X & Y axis speed varies then the engraving will be darker when the X/Y axis is slowing down, and lighter when it is moving at max speed. This gives an unwanted shading effect on the image.
#2: Raster engraving can be quite time cumbersome, and by not running at maximum velocity for the largest amount of time you increase your run time. This can be quite significant when you are engraving a large image and are constantly speeding up and slowing down vs running at maximum velocity for the extents of the image.
(These thoughts were pointed out in the discussion above, but noted here again for clarity.)

Thoughts:
Ok, so SXXX is breaking the que, and we are losing speed. Let's try another solution...

Possibility #2:
Controlling the laser output via M67 E0 QXXX
I found that this approach is interfering with the trajectory planner in some way as well, and as a result we get erratic movement of the laser because the X&Y axes are constantly accelerating/decelerating each time an M67 command is encountered. The larger changes in QXX, say from Q01 to Q99, result in the greatest deceleration. I’m not sure what is causing the delay, perhaps Linux pwm generator? The results using this method seem slightly better than using M3 SXXX, but still not what I would consider ‘good’ results. This method will ‘work’, but I am still having the same accel/decel problem when trying to vary the intensity of the laser. I expected this solution to work better, but am unable to get good results from it either.

Let's try another solution...

Possibility #3:
Control the laser intensity directly using a (fake) axis movement. I did this by adding a new axis, we’ll call it axis A, so I went from an XYZ traditional 3-axis mill to an XYZA, where the A axis is a fake axis whose stepper signals we will use to control the laser. I know Linux pulses the axes wicked fast, so this should be a good approach. I set the A axis to have crazy high acceleration and velocity rates, as I'm not actually moving any axis, just controlling power being sent to the laser (note: I’m not actually powering the laser with the stepper motor signals, in this setup I’m reading the stepper pulses on the laser driver board and converting them to laser intensity).
I added the necessary lines of code into the Linux configuration files and ran some test engravings. This is where things got interesting, and I will try to be clear on what’s happening here:
1.) When processing the XYZ commands, the machine behaves as it normally does -> good, this is the expected outcome
2.) When processing the following A axis movement commands:
a. G0 A0
b. G0 A100
c. G0 A50
d. G0 A0
e. G0 A100
f. G0 A0
The A axis properly controls the laser, is adjusting the power correctly and is doing so really fast -> good, this is the expected outcome
3.) When processing XYA commands (now varying the laser during raster engraving) the A axis commands are causing my XY movements to slow down -> bad, this is not what I want to happen
I honestly do not know what is happening here, or how to fix this problem. My best explanation for this (gathered from watching my machine and observing what is physically happening, not looking into the source code) is that Linux is restricting the axis movement to consider the slowest axis which is currently moving, or about to be moving. In my case the limiting speed is my X&Y axes, as they are set as I normally have them, while the A axis has velocity and accel set to the point just before my machine trips the “axis following error”.
I did further testing on this, and the results are more or less linear in that linux ‘bogs down’ and can only maintain a constant speed of ~40% of the maximum XY velocity during engraving. In other words:
a.) X/Y axes velocity set at 100mm/min -> Linux can hold a constant speed when using G1 F40 commands. Using a velocity greater than F40 causes the velocity to drop to 40 at points of large laser power changes (say from 0 to 100%)
b.) X/Y axes velocity set at 1500mm/min -> Linux can hold a constant speed when using G1 F600 commands
c.) X/Y axes velocity set at 3000mm/min -> Linux can hold a constant speed when using G1 F1200 commands
I do not know why, but 40% seems to be the constant speed that Linux was able to sustain under all my velocity tests.
This possibility yielded the best results for me, with M67 performing 2nd best, and M3 giving the worst results.

My recommended solution:
If possible, control your laser power via step pulses and maintain your raster engraving at the highest speed you feel comfortable having your machine go. There are real world variables in play here, so I can’t recommend a speed for you other than to know your machine limits, as high velocity and/or accelerations have an effect on your hardware life. If you are comfortable running at 1000mm/min then set your G1 speed to F1000 and back-calculate your axis max velocity ( = 1000 / 0.4 = 2500 ) and set accordingly in your .ini file (***note -> I highly recommend you make sure and do not execute ***any*** G0 X/Y/Z commands if you do this, otherwise your machine might get damaged, as it'll be going 2,500mm/min rather than the 1,000mm/min you are comfortable with.)
If you don’t want to deal with stepper motor pulses, then controlling via M67 offered me 50-75% of the speed I could get using step pulses, so it’s not the end of the world.

Thoughts:
My preferred solution would be to tell Linux that my A axis is not actually an axis, and to decouple its commands from the XYZ commands. This would be similar to telling Linux that the A axis controls a separate machine, so the XYZ commands are entirely different from the A commands. That way the XYZ commands would follow their movement equations and the A axis would follow its own separate movement equation and be free to vary its laser intensity near instantly.

Requests for help:
If anyone see’s any flaw in my logic or thought process please let me know. I do not have further plans to test this, but only because I can’t think of any other approaches to try.