LAOS Laser

Fork: https://github.com/peteruithoven/Firmware

Hi Peter,

If you turn off your laser immediately after a file has been cut, you can take out the SD card and the file that has just been cut will be on it. If the problem exists inside that file, it must have been caused by Visicut or by the TFTP upload. If the
file looks correct but it makes cutting mistakes anyway, the problem must be in the LaosMotion part of the firmware.

I was thinking it might have something to do with the bedHeight, since my hpc doesn't have this issue, so I changed the y.home and y.rest and in VisiCut I changed the laserbed height to 200. Doesn't help.

Using my debug prints I'm getting something interesting.
First job:

Parsing file: 
>7
>100
>9000
> speed: 45
>7
>101
>4000
> power: 4000
>7
>100
>10000
> speed: 50
>7
>101
>5000
> power: 5000
>0
>10160
>19865
> ACTION type: 0 target: (x:10.160000 y:19.865000 f:3000.000000) power: 5000
>1
>19812
>19865
> ACTION type: 1 target: (x:19.812000 y:19.865000 f:3000.000000) power: 5000
>1
>19812
>10213
> ACTION type: 1 target: (x:19.812000 y:10.213000 f:3000.000000) power: 5000
>1
>10160
>10213
> ACTION type: 1 target: (x:10.160000 y:10.213000 f:3000.000000) power: 5000
>1
>10160
>19865
> ACTION type: 1 target: (x:10.160000 y:19.865000 f:3000.000000) power: 5000
>1
>10160
>19865
> ACTION type: 1 target: (x:10.160000 y:19.865000 f:3000.000000) power: 5000
>0
File parsed 
> ACTION type: 0 target: (x:0.000000 y:330.000000 f:3000.000000) power: 5000

Parsing file: 
>7
>100
> ACTION type: 1 target: (x:0.007000 y:0.100000 f:3000.000000) power: 5000
>9000
>7
>101
>4000
>7
>100
>10000
> speed: 50
>7
>101
>5000
> power: 5000
>0
>10160
>19865
> ACTION type: 0 target: (x:10.160000 y:19.865000 f:3000.000000) power: 5000
>1
>19812
>19865
> ACTION type: 1 target: (x:19.812000 y:19.865000 f:3000.000000) power: 5000
>1
>19812
>10213
> ACTION type: 1 target: (x:19.812000 y:10.213000 f:3000.000000) power: 5000
>1
>10160
>10213
> ACTION type: 1 target: (x:10.160000 y:10.213000 f:3000.000000) power: 5000
>1
>10160
>19865
> ACTION type: 1 target: (x:10.160000 y:19.865000 f:3000.000000) power: 5000
>1
>10160
>19865
> ACTION type: 1 target: (x:10.160000 y:19.865000 f:3000.000000) power: 5000
>0
File parsed 
> ACTION type: 0 target: (x:0.000000 y:330.000000 f:3000.000000) power: 5000

So parsing the second file, parsing the settings, there is suddenly a action buffered to move it close to 0,0.

I looked at the files you uploaded. I see some strange things:

1: rect2.lgc and rect3.lgc are identical, but both of them contain 5 cutted lines. Last time I checked, a rectangle has only for sides!

2. p2.lgc and p3.lgc are different files. Did you resize/change the P?

Your debug output of the second job proves that the first line of the second job, " 7 100 9000" is read as a move(with laser on) command by the firmware parser instead of a power command". Also the second line "7 101 4000" is not properly read. Looks like the parser is not properly reset after the previous file...

jaap wrote:

I looked at the files you uploaded. I see some strange things:

1: rect2.lgc and rect3.lgc are identical, but both of them contain 5 cutted lines. Last time I checked, a rectangle has only for sides!

That's probably a VisiCut issue, but good to keep an eye on.

2. p2.lgc and p3.lgc are different files. Did you resize/change the P?

Ah sorry, I moved the second one 10mm to the right. Besides that I didn't see any difference.

Interesting, I'm going to look into the parser.

Alright, so now I'm calling the reset function before I start parsing again, which should reset the step and command to 0. Because the problem was that they weren't.
But this didn't help, so I also printed what the value was of command and step at the end of the reset function, the weird thing is that on the second job they where both 1. So I now reset step and command again to 0 just before the print and this fixes the problem. Could there be some interrupt that changes one of the variables (xtep etc) and cause the step and command to be filled with his value? I didn't find any other places that change step or command so that can't be it.

void LaosMotion::reset()
{
  #ifdef READ_FILE_DEBUG
    printf("LaosMotion::reset()\n");
  #endif
  step = command = xstep = xdir = ystep = ydir = zstep = zdir = 0;
  ofsx = ofsy = ofsz = 0;
  *laser = LASEROFF;
  enable = cfg->enable;
  cover.mode(PullUp);

  step = command = 0; //following prints command and step on 1 sometimes, so lets redo it.
  #ifdef READ_FILE_DEBUG_VERBOSE
    printf("  (command: %i, step: %i)\n",command,step);
  #endif
}

Weird, but problem solved.

Alright, it also works to move step and command to the end of the line:

void LaosMotion::reset()
{
  #ifdef READ_FILE_DEBUG
    printf("LaosMotion::reset()\n");
  #endif
  xstep = xdir = ystep = ydir = zstep = zdir = step = command = 0;
  ofsx = ofsy = ofsz = 0;
  *laser = LASEROFF;
  enable = cfg->enable;
  cover.mode(PullUp);

  #ifdef READ_FILE_DEBUG_VERBOSE
    printf("  (command: %i, step: %i)\n",command,step);
  #endif
}

That really makes me think one of the other variables was changed somewhere in between by a interrupt.
I also removed my extra reset call, putting a print in there revealed that it was already called.

No clue why this happens on the Morntech one and not on the HPC.

B.t.w. this also solves the problem that the power and speed sometimes weren't set properly.

Let me get this straight...

You changed this line:

step = command = xstep = xdir = ystep = ydir = zstep = zdir = 0;

xstep = xdir = ystep = ydir = zstep = zdir = step = command = 0;

Maybe I'm a sloppy programmer, but is there any logic here, or is this one of those things that has to do with waving the foxtail in the full moon?
(not that I'm not happy to accept any code that works, of course)

Yep, it's that weird... And yes that's basically all I changed functionally.