You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
David: 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
David: 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.
pbrier: 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.
David: 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%?
KalleP: 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.
pbrier: 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.
Daid: 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)
lennart: 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!
Daid: 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) ) );
To: 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)
lennart:@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?
Daid: Nope, I'm seeing a steady 15mA power output. But if I press the laser ON button, I get 24mA output.
I think this fix has been applied to SVN. And SVN also has a fix for the "laser ON on machine powerup" problem (but that fix is not in our machine yet)
David: I have tried the v0.3 binary from 12 aug 2012 and it doesn't solve the issue. Is there a fixed binary available somewhere?
Anoniem: 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.
Anoniem: Ok, re-import and added FatFileSystem, and it compiles again. Attached the build with Daid's one-line change.
David: Thanks, that seems to fix it. I've done just one job with this firmware so far, so let's not close the issue yet.
Daid: Most likely you'll see my issue now, where the laser won't reach "full power" anymore. But stable lower power is a bit more useful then unstable high power.
Daid: I see there was a new dev firmware with this change, however, I do not see the change in github?
lennart: 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?
pbrier: I do not think that is the problem (a local static variable only gets initialized once).
It is most likely related to bug #36. I'll look into this.
T-oster: Hi,
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.
cheers
T
Lennart:@peter: any update on this?
Issue 36 and 42 are really hurting the usefulness of the Laoslaser board. There's not really a point in - say - a v0.4 revision that fixes the header location of the PWM signal if the PWM signal doesn't work ;-).
Lennart
David: I'd like to give this a little bump as well. I'm using the hardware power knob to modulate power but that feels very primitive in comparison with space age computer controlled lasers.
peteruithoven: Are there any complications on this issue? Maybe we can think out loud and brainstorm in this issue?
Topy44: 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
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).
T-oster: How can I disable the speed dependent PWM and where do I find the experimental firmware?
David: 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?
pbrier: Highest prio. Make calculation work as intended.
David: I assume you mean the 1st of December of this year instead of 2013? ;)
Topy44: 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.
David: Any progress on this? I am in quite desperate need of PWM on my laser.
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).
Daid: Does that work on all speeds? The latest firmware I used in Amersfoort worked good at speeds between 10-100%, but slower is started to cause problems with the power levels where the power dropped as I went slower and slower.
pbrier: 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.
T-oster: I just tried the 8-12-2012 firmware. But my power seems to be 100%, no matter, what I send. Maybe I missed some changes on the PCB-PWM output? I remember seeing some Emails about that.
T
pbrier: 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.)
David: 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.
David: 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.
pbrier: 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.
David: 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%?
KalleP: 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.
pbrier: 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.
Daid: 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)
lennart: 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!
Daid: 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) ) );To:
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)
lennart: @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?
Daid: Nope, I'm seeing a steady 15mA power output. But if I press the laser ON button, I get 24mA output.
I think this fix has been applied to SVN. And SVN also has a fix for the "laser ON on machine powerup" problem (but that fix is not in our machine yet)
lennart: @daid: I think you are referring to this file?
https://tuxic.nl/laos/firmware/mbed/laoslaser/LaosMotion/grbl/stepper.c
I just checked and it still has the incorrect integer calculations.
David: I have tried the v0.3 binary from 12 aug 2012 and it doesn't solve the issue. Is there a fixed binary available somewhere?
Anoniem: 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.
Anoniem: Ok, re-import and added FatFileSystem, and it compiles again. Attached the build with Daid's one-line change.
David: Thanks, that seems to fix it. I've done just one job with this firmware so far, so let's not close the issue yet.
Daid: Most likely you'll see my issue now, where the laser won't reach "full power" anymore. But stable lower power is a bit more useful then unstable high power.
Daid: I see there was a new dev firmware with this change, however, I do not see the change in github?
lennart: 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?
pbrier: I do not think that is the problem (a local static variable only gets initialized once).
It is most likely related to bug #36. I'll look into this.
T-oster: Hi,
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.
cheers
T
Lennart: @peter: any update on this?
Issue 36 and 42 are really hurting the usefulness of the Laoslaser board. There's not really a point in - say - a v0.4 revision that fixes the header location of the PWM signal if the PWM signal doesn't work ;-).
Lennart
David: I'd like to give this a little bump as well. I'm using the hardware power knob to modulate power but that feels very primitive in comparison with space age computer controlled lasers.
peteruithoven: Are there any complications on this issue? Maybe we can think out loud and brainstorm in this issue?
Topy44: 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:
Any thoughts?
pbrier: The problem is twofold:
(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).
T-oster: How can I disable the speed dependent PWM and where do I find the experimental firmware?
David: 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?
pbrier: Highest prio. Make calculation work as intended.
David: I assume you mean the 1st of December of this year instead of 2013? ;)
Topy44: 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.
David: Any progress on this? I am in quite desperate need of PWM on my laser.
pbrier: Verified to work, when you connect your PWM to the laser power supply according to this drawing:
http://redmine.laoslaser.org/projects/laos/wiki/HPC_LS3020_connections_-_July_2012
and set this in the config file:
This makes a 20Khz PWM signal, from 0 to 100% dutycycle on the "IN" pen of the laser power supply.
Use latest firmware (attached).
Daid: Does that work on all speeds? The latest firmware I used in Amersfoort worked good at speeds between 10-100%, but slower is started to cause problems with the power levels where the power dropped as I went slower and slower.
pbrier: 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.
T-oster: I just tried the 8-12-2012 firmware. But my power seems to be 100%, no matter, what I send. Maybe I missed some changes on the PCB-PWM output? I remember seeing some Emails about that.
T
pbrier: 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.)
T-oster: Hi, It seems as if the PWM works correct, but only in the first Job I send.
Please see http://redmine.laoslaser.org/issues/63 [fixed]
Source: http://redmine.laoslaser.org/issues/36
The text was updated successfully, but these errors were encountered: