Laser power varies within job
The HPC laser cutter in my workshop (JCW's laser) sometimes varies laser power within a job. 20-25mA seems to correlate with full power (100% duty cycle), under 5mA to no power (0% duty cycle).
I've checked the lgc file and it sets power, speed and frequency once in the file.
7 101 10000 7 100 1900 7 102 1500
#1 Updated by david over 5 years ago
(I had to split this in parts because redmine forced me to leave the page for some unknown reason)
Some lines are cut with very low power. It seems the duty cycle is zero or close to zero. Most of the lines are cut okay. There is no command to change the power in the lgc file. Manually changing the lgc file to re-specify the power every time before turning on the laser doesn't change anything.
#2 Updated by peter over 5 years ago
It is possible to set the MIN and MAX pwm in the config file.
The laser will be modulated between these values.
Also: the transfer function between PWM and power may be non-linear. There is no provision to compensate for that at the moment. You may however change the PWM frequency, that may alter the transfer function.
#3 Updated by david over 5 years ago
The weird thing is, the PWM duty cycle isn't supposed to change within this job. There are no instructions in the file that tell the laser to change duty cycle.
Do the min and max values limit the duty cycle? I.e. if I set the power to 100% while max duty is set to 90, will the actual output power be at 100% or 90%?
#4 Updated by KalleP over 5 years ago
Intuitively I would think that the PWM output signal will swing between the min and max PWM values over the 0% to 100% command values.
If you can put a simple resistor-capacitor filter on the PWM pin and monitor this with a DVM at the same time as monitoring the PSU output (tube) current meter you may be able to determine if the laser PSU is responsible.
If the PWM value drops for no reason then you can suspect the firmware, an occasional fault like this is unlikely to be in the processor silicon but could be the result of unexpected interaction in the code that depends on a specific set of data that triggers some register corruption or hardware control register reset.
A debug output that was to write the current 'line' to the LCD that could be kept an eye on might be able to localise the position in the data file that triggers the problem (if it is in the same place).
Of some help here might be a display of the current and max PWM values on the LCD to see if they are being altered somehow.
There is a need to localize the point of error so the mechanism can be investigated further.
#5 Updated by peter over 5 years ago
The laserpower is always modulated, based on the actual speed of the laser (with respect to the set speed).
The correct equation should be Pset = (actual_speed/set_speed) * set_power
So in the sharp corners of lines, the speed is reduced. There may still be a bug in the implementation of this algorithm (there was one in the original code, an overflow of a variable). That is triggered by a combination of a low set_speed and high set_power.
Have to check the code.
Also, in the config file you can set min and max PWM. The response to the laser is most likely not linear for 0..100% PWM, so you have to offset it (lets say, starting at 10 or 20%). For most lasers the response is also inverted (that is 0% PWM, is 100% power).
Hope this helps in the diagnosis.
#6 Updated by Daid over 5 years ago
The patch I made a while back for the PWM (removing the integer calculations and doing it all in doubles) seems to stabilize the lazer power. (I don't know if a release has been made with this patch, or even if the patch has made it into source control)
However, I see that the power level never reaches the set point. I was trying to cut at 100% power yesterday, but it stayed around 15mA, while 100% is around 24mA (pressing the "laser on" button puts out 100% power)
#7 Updated by lennart over 5 years ago
I have noticed the same behavior as mentioned by David.
The problem is not that the power is variable within a job - that is to to be expected in corners as Peter explained. The problem is that certain vectors are entirely cut with much lower power than set for the job.
I have attached a picture of the result that show certain vectors that are cut through (100% power, as set for the job) and some that received considerably less power. This result is repeatable and it is not something in the source file. I'm using Visicut.
In the end, it made me disable PWM altogether (with burnt corners as a result :-(. A fix would be highly appreciated.
@Daid: could you point out what you changed exactly in which file? Thanks!
#8 Updated by Daid over 5 years ago
That's exactly the bug that I attempted to fix.
I've changed this line:
p = to_double(pwmofs + mul_f( pwmscale, ((power>>6) * c_min) / ((10000>>6)*cycles) ) );
p = to_double(pwmofs) * to_double(pwmscale) * ((to_double(power) * to_double(c_min)) / (to_double(10000) * to_double(cycles)));
Which made the PWM stable, but I think it is too low now on our machine. I'm thinking about just fixing the PWM to a fixed level without the "variable by speed" option, just so it outputs enough power. It will make the corners uglier, but I currently cannot cut 4mm triplex any faster then 2mm/s which is a shame. As with full power it can go quite a bit faster (tested by holding down the "laser ON" button)
#9 Updated by lennart over 5 years ago
@Daid: thanks, it sounds like that is exactly the fix that I'm looking for! BTW I've noticed that without PWM and with power set to 100%, the current starts above 20mA, but it gradually drops down to 16mA on long jobs. Are you sure you are not seeing something similar?
@Peter: could you incorporate this fix in a new version of the firmware?
#11 Updated by lennart over 5 years ago
@Daid: I think you are referring to this file?
I just checked and it still has the incorrect integer calculations.
#13 Updated by Anonymous over 5 years ago
I just tried compiling with Daid's change, but foolishly decided to update the mbed library to the latest version (rev 42) - and now it doesn't compile anymore on my login. Grrr... mbed.org ... grrr.
At least that's what I think happened - first serious error is 'identifier "namespace" is undefined', FileHandle.h line 18.
#18 Updated by lennart over 5 years ago
No, it's not yet in github, and probably also not in the 09-09 firmware that's available from github...
Meanwhile, I've been playing a bit with the new firmware containing the fix. Although my previous problem - unwanted variation within a job - seems to be solved, I now have the problem of always running at 100% power, no matter what's in the lgc file. It seems PWM is not working for me.
Looking at the github code, I see the following:
LaosMotion.cpp, line 220:
static int x,y,z,power=10000;
The power is initialized at 100%. However, it seems that this value gets used for every simplecode "type 2" command (move with laser on) in line 242:
action.param = power;
Although a "type 7" command with parameter 101 (set power) does change the power variable in line 295, it doesn't seem to get stored permanently. It just seems to change the local variable, which gets reinitialized to 100% next time around in this method on line 220, i.e. when processing the next command.
Any thoughts on this?
#20 Updated by t-oster about 5 years ago
I can confirm the problem: My power is reduced very much on some small curves (seems random to me). This makes the whole thing unusable, because I can not cut. The posted firmware image just sets the power fix to 100%, which is the same as just bridging the pwm and using the hardware-power-knob.
In my opinion, this bug should get a high priority and as long as the algorithm does not work correctly, it would be better to use speed-invariant power until it is fixed.
Please upload a firmware which just uses the power of the last "7 101" command.
Also: I think I noticed, that the order of the "7 100", "7 101" and "7 102" commands is important, otherwise it happened to me, that a set-speed command had no effect.
#24 Updated by Topy44 about 5 years ago
We are about to switch our DIY laser to LAOS, and since it does not have any secondary means to control laser power this issue could make it completely useless. Any updates on this?
Modulating laser power through actual movement speed is a very good thing, its one of the reasons we want to switch to LAOS in the first place. But it needs to work properly. I would suggest specifying a minimum value at which the laser can be considered "on" in the config file, and then figure out a curve on how to map 1-100% "power" in a way that produces a more or less linear increase in actual laser power between the specified min value and full on. Then, another function can map movement speed to laser power. So in effect, the actual PWM value becomes a function of:
- Laser power percentage in job
- Minimum "on" setting in config file
- Linearisation curve
- Actual speed (affected by acceleration/deceleration ramps) in relation to the job's cutting speed setting
#25 Updated by peter about 5 years ago
The problem is twofold:
- An error in the calculation (that caused an overflow in the PWM setting, effectively reducing the power)
- The signifant non linearity of the PWM to power curve and power to cutting speed curve.
(the first one is constant, the second one is a function of the material)
In the latest (expirimental) firmware there is an option to disable the speed dependent PWM, and have a fixed PWM based
on the job power setting only.
We need a linearisation curve. It will most likely be material dependent. But if you have a fixed minimum (never go to zero percent)
this should be a compromise between burned edges and not cut through completely straight lines.
Note: RF lasers exhibit much better performance than the typical low cost glass tubes. The glass tube could exhibit other non-linearity (increasing spot size at higher power, effectively decreasing the peak intensity). So: YMMV.
Working on the issue (the calculation error should be fixed now).
#27 Updated by david about 5 years ago
I don't see how having the power setting fixed and varying laser intensity with the current potentiometer is any different from non-speed-based PWM. I'd say add fixed PWM to the stable firmware as soon as possible so we can at least go back to cutting without constantly adjusting the potentiometer.
@peter: is the linearisation curve something we can figure out easily? Would that involve making a file that tests different power levels on one material at a set speed?
#30 Updated by Topy44 about 5 years ago
- Due date changed from 2013-12-01 to 2012-12-01
- Priority changed from Normal to Urgent
(Just fixing the priority and date)
I am pretty sure that an exact, measured linearisation curve is unnecessary. A simple curve that can be tweaked by one or two values in the config file, valid for all materials (but differing from machine to machine) should probably be enough.
#32 Updated by peter about 5 years ago
- File laoslaser-5-12-2012.bin added
- Status changed from New to In Progress
Verified to work, when you connect your PWM to the laser power supply according to this drawing:
and set this in the config file:
laser.pwm.min 0 ; minimum pwm value [%]
laser.pwm.max 100 ; maximum pwm value [%]
laser.pwm.freq 20000 ; pwm frequency [Hz]
This makes a 20Khz PWM signal, from 0 to 100% dutycycle on the "IN" pen of the laser power supply.
Use latest firmware (attached).
#34 Updated by peter almost 5 years ago
Still seems to be a problem.
I nailed it down to the speed data coming into my ISR. It is sometimes not sampled at the correct moment, so it calculates the PWM relative to
the HIGH (move) speed and not the ACTUAL (cut) speed. So the lower the cut speed, the lower the PWM.
For the time beeing, I disabled velocity scaling in the 8-12-2012 firmware. Fixed PWM, independent of actual speed, but only depending on set power.
#36 Updated by peter almost 5 years ago
Hi Tomas, Can you attach your config file and a drawing of the connection?
The connection should not have changed (all boards use the same output, only the legend on the PCB has changed).
Could it be the PWM min/max are incorrectly defined? (see http://redmine.laoslaser.org/projects/laos/wiki/LAOS_configuration_file)
Depending on the connection 0% PWM could be 100% power (and v.v.)