LAOS Laser

(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.

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.

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%?

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.

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.

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)

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)

@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?

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)

@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.

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?

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.

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.

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.

I see there was a new dev firmware with this change, however, I do not see the change in github?

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?

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.

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

@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

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.

Are there any complications on this issue? Maybe we can think out loud and brainstorm in this issue?

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

Any thoughts?

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).

How can I disable the speed dependent PWM and where do I find the experimental firmware?

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?

I assume you mean the 1st of December of this year instead of 2013? ;)

Any progress on this? I am in quite desperate need of PWM on my laser.

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.

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.

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

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.)

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