Bug #85
closed
Lasering long vertical line at start of jobs after the first job
Added by peteruithoven almost 11 years ago. Updated almost 11 years ago.
0%
Description
I keep having some issues with my lasercutter, it starts by cutting a bit vertical line and sometimes the speed/power isn't used.
So I'd like a way to debug this and see exactly what comes in (unparsed simplecode) and what it tries to do with that. I understood from Jaap this can be tricky to debug since instructions are given by interrupts and you get other issues when you serial print in interrupts. So I went looking for ways to debug earlier in the process. I'm no c++ or mbed expert but I think the current system goes trough the simple and calls LaosMotion::write with every integer that is found.
So printing every integer that comes into this function would be a very blunt start.
A bit more specific would be to print the parameters and values it parsed when it found command 7 (case 7). Also the plan_buffer_line
Another interesting function would be plan_buffer_line from planner.cpp. this gets a parsed action (tActionRequest) as parameter.
Hopefully this will give me something useful and maybe this debug method is useful for someone else.
Files
| rect3.lgc (135 Bytes) rect3.lgc | peteruithoven, 2013-06-01 17:51 | ||
| p2.lgc (762 Bytes) p2.lgc | peteruithoven, 2013-06-01 17:51 | ||
| p3.lgc (764 Bytes) p3.lgc | peteruithoven, 2013-06-01 17:51 | ||
| rect2.lgc (135 Bytes) rect2.lgc | peteruithoven, 2013-06-01 17:51 | ||
| laoslaser-1-6-2013.bin (147 KB) laoslaser-1-6-2013.bin | peteruithoven, 2013-06-01 22:03 | ||
| laoslaser-2-6-2013.bin (147 KB) laoslaser-2-6-2013.bin | peteruithoven, 2013-06-02 14:38 |
Updated by peteruithoven almost 11 years ago
Updated by jaap almost 11 years ago
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.
Updated by peteruithoven almost 11 years ago
- File rect3.lgc rect3.lgc added
- File p2.lgc p2.lgc added
- File p3.lgc p3.lgc added
- File rect2.lgc rect2.lgc added
Thanks for that tip again Jaap.
I tried cutting the letter P twice, restarting and cutting a simple rectangle twice. Both times the lasercutter cut a big vertical line at the start of the second job.
I found 3 lgc files both times, a empty one (god knows why) and two that where the same. So this line isn't in the simplecode. The simplecode also looks the same as the debug files of Visicut.
I also noticed that it first goes strait down (to the 0,0 according to LAOS defaults) and then moves horizontally towards the actual job while moving up agian.
What's also interesting is that it's always the second job that is executed where I get the line. Even if I send a couple of files the first job that I execute on the lasercutter is started without the line.
Another thing that I tried was cutting a rectangle in the bottom left corner. This gives the same behavior. The first time it just moves directly to the rectangle and started cutting, the second time it moves to the 0,0 point first.
So yeah, I'm afraid there is something wrong in the LaosMotion.
Updated by peteruithoven almost 11 years ago
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.
Updated by peteruithoven almost 11 years ago
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
Second job:
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.
Updated by jaap almost 11 years ago
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?
Updated by jaap almost 11 years ago
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...
Updated by peteruithoven almost 11 years ago
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.
Updated by peteruithoven almost 11 years ago
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.
Updated by peteruithoven almost 11 years ago
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.
Updated by peteruithoven almost 11 years ago
- File laoslaser-1-6-2013.bin laoslaser-1-6-2013.bin added
- Status changed from New to Closed
- Assignee set to peteruithoven
Git seems to ignore .bin files, so I don't know how to commit my bin file, so here it is. I'll do a pull request for the code.
Updated by peteruithoven almost 11 years ago
B.t.w. this also solves the problem that the power and speed sometimes weren't set properly.
Updated by jaap almost 11 years ago
Let me get this straight...
You changed this line:
step = command = xstep = xdir = ystep = ydir = zstep = zdir = 0;
Into this:
xstep = xdir = ystep = ydir = zstep = zdir = step = command = 0;
and that solved the problem.
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)
Updated by peteruithoven almost 11 years ago
Yep, it's that weird... And yes that's basically all I changed functionally.
Updated by peteruithoven almost 11 years ago
- File laoslaser-2-6-2013.bin laoslaser-2-6-2013.bin added
.bin again, with DEBUG flags off.