LAOS Laser

Hi hpux735,

While I appreciate you sharing your experience so thoroughly, it would be nice if you could summarize the issue. I added a screenshot of a engraving that went wrong.

Could you share a file that went wrong? I would love to try it on other lasercutters. Preferably also the visicut (plf) file, because that includes some settings.

You could also try to view it with the webviewer:
http://webviewer.laoslaser.org/

Although it doesn't properly show engraving yet, see:
http://redmine.laoslaser.org/boards/3/topics/640?r=651#message-651

Sure,

To summarize, when engraving, the x-axis will sometimes "walk" back and forth (but usually to the right) as it scans across. Some files are worse than others. I just played around with the simplefile visualizers, and it seems that it's rendering fine. It seems that, at a minimum, it absolves inkscape and visicut.

I added the a file that I've been having problems with in SVG, PLF and simple code format.

Thanks again.

Looking at one of your experiments it looks like some rows (usually a couple) are more to the left or right than rows earlier. (Not sure what that tells us).
The lasercutter doesn't make any strange noise when this walk / shift happens right?

I tried your file once (I'm assuming it always goes wrong with the same file), it seems to go okay:
http://fablabamersfoort.nl/fotos/index.php/17-Mar-2015/IMG_0102
I'm using laoslaser-2015-02-23.bin. The changelog I started doesn't indicate a change since your version that can explain this issue.
http://redmine.laoslaser.org/boards/3/topics/880

I agree with your assessment. Tonight (if I have any free time, I have a toddler) I'll try the new firmware, but as you say, the changelog doesn't have any entries that give me much hope.

I suppose that I should find a reliably failing file (preferably one that fails early) and put a logic analyzer on the stepper driver. I'll have to write some code to visualize the output from the step and direction pins.

Another avenue of investigation could be that I order some new (known genuine) pololu modules and replace the existing ones.

Please ALWAYS try the latest firmware first. Asking questions about ancient releases is wasting valuable developer (volunteers) time!

I didn't think that one release back would be considered "ancient."

One release back is not ancient (especially since the last to are both still quite new) but trying the last one can remove differences in the setups between you and the others debugging. I cannot assist with testing at the moment but can offer a couple of ideas for you to try out.

1: Redraw the shape with a surplus line outside the work area, in effect defeating the optimisation algorithm.
2: Test the stepper currents, the raster runs the motors quite fast and the motors may skip at their limits.
3: I vaguely recall there were problems with a scan buffer over flowing in some raster code a while back but that may not have been the LAOS project, it never concerned me so did not pay much attention.
4: Also note that InkScape has some known issues with translating text that is part of a grouped object that causes it to generate incorrect SVG output.
5: Try and verify that the failure is at the exact same point each time (after a cold boot).
6: I also think there may have been some discussion about the fact that the raster mode does not use all the file pre-sets for speed correctly and might be running too fast, again here I may be remembering something else altogether so confirmation is suggested.
7: I lean towards buffer overflow or calculation overflow if firmware or something with the mechanics that stress the drivers capability.

That is all I can think of now but it might trigger an aha moment for you.

Kalle

Thanks so much! I'll try those out.

I did notice a weird thing that I had previously not paid too much attention to, but I'd be interested in other's opinions:

Because I'm using a lab power supply to power the motors and logic, I have a current indication at all times. When the motors are idle (but enabled, like when it's sitting at home) the combined (X+Y) motor current at the motor rail is near 2 amps (1.8). At this setting the X motor gets quite hot. When it's engraving, however, the motor current at the rail is more like 700mA. For some reason, during motion, the pololus are drawing half the current!? Is this normal? Has anyone seen a similar effect? I'm tempted to buy some new modules directly from pololu (not amazon) and replacing them with known genuine modules. I'm also tempted to go whole-hog and replace them with some professional stepper drivers, like Geckos.

With version 2014-11-14 the engrave speed setting and Laser misfiring should have been fixed.
http://redmine.laoslaser.org/boards/3/topics/841?r=847
http://redmine.laoslaser.org/boards/1/topics/747
https://github.com/LaosLaser/Firmware/blob/master/CHANGELOG

Things I've tried:

1: Redraw the shape with a surplus line outside the work area, in effect defeating the optimisation algorithm.

Didn't help

2: Test the stepper currents, the raster runs the motors quite fast and the motors may skip at their limits.

Checked. Also, I swapped the X and Y pololu's, hoping that one might be bad. No change.

3: I vaguely recall there were problems with a scan buffer over flowing in some raster code a while back but that may not have been the LAOS project, it never concerned me so did not pay much attention.

I read about that. Doesn't seem related.

4: Also note that InkScape has some known issues with translating text that is part of a grouped object that causes it to generate incorrect SVG output.

I'm using bitmaps only.

5: Try and verify that the failure is at the exact same point each time (after a cold boot).

It is very repeatable (the problem in general, especially with a few files) but the failure happens at slightly different points.

6: I also think there may have been some discussion about the fact that the raster mode does not use all the file pre-sets for speed correctly and might be running too fast, again here I may be remembering something else altogether so confirmation is suggested.

The speed seems right. I had reduced the engrave speed from 50 to 30, still happened.

7: I lean towards buffer overflow or calculation overflow if firmware or something with the mechanics that stress the drivers capability.

Yah. Probably.

I also tried turning off the laser power supply. Using the non-optimized engrave path (with the lines outside the image) I could tell by listening when the head skipped. It still does with the laser power off. It's clearly not interference related.

At this point, I owe an apology to Jaap. The new firmware seems like it has fixed the issue. Starting with the laser power off, no optimization, slow engrave, and verified currents I etched with the new firmware. When it sounded like it wasn't skipping, I turned the laser on and it still seemed good. Then, I started a new engrave with optimization and higher speed and it was still good. I've only tried one etch so far (it was getting late) but it is the one that always broke before. I'm cautiously optimistic that the problem has been solved.