Re: [lasersaur] Not etching complete image when rastering - SOLVED

[Stefan Hechenberger]

Hi ej, bugfix is in. See my other message for the latest release.

The issue was related to a rounding calculation. Depending on the image
width and pxsize setting this problem would be latent or very
pronounced. That's why I didn't notice it with my test image. Tricky!

Let me know if you find any persistent issues.


On 2017-01-12 22:44, e...@toolinc.com wrote:
> Hello,
>
> Our lasersaur is finally up and running but I am encountering an issue
> when etching images with the raster mode.
>
> It appears as if the lasersaur is not etching the last 1/4" or so of
> the image along the right edge of the image. This happens despite the
> file and positioning on the bed.
>
> we have not noticed any issues when doing vector cutting, only with
> the raster mode.
>
> attached is an image of cut I just made. The image is supposed to be
> symmetrical with the four squares being the same, but as you can see
> the two on the right are cut off.
>
> This clipping happens with every file and feed rate I have tried. Does
> anyone have any idea why this could be happening?
>
> Thanks in advance.
>
> --
> You received this message because you are subscribed to the Google
> Groups "lasersaur" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to lasersaur+...@googlegroups.com.
> To post to this group, send email to lase...@googlegroups.com.
> Visit this group at https://groups.google.com/group/lasersaur.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/lasersaur/7db96763-a53d-4e9f-904d-bc5e46f96cc1%40googlegroups.com
> [1].
> For more options, visit https://groups.google.com/d/optout.
>
>
> Links:
> ------
> [1]
> https://groups.google.com/d/msgid/lasersaur/7db96763-a53d-4e9f-904d-bc5e46f96cc1%40googlegroups.com?utm_medium=email&utm_source=footer
---
Stefan Hechenberger
work: http://nortd.com
project: http://lasersaur.com
twitter: @stefanix
instagram: @stefavon

[Scott (Strataforma.com)]

I seem to be experiencing this bug all of the sudden. I thought it was because I was mucking around in the raster code (more improvements on my fork coming very shortly!), but I tried reverting back to the firmware/driveboardapp from the 18.07 release .exe (https://github.com/nortd/driveboardapp/releases), and the issue is persisting. Stefan / Martin it looks like you were the ones who fixed this the first time it was happening (https://github.com/nortd/driveboardapp/commit/39669fd8fa4c082f01613babb5e994fe5d3de691), any ideas why it could be popping back up?

Scott

> an email to lase...@googlegroups.com.

[Scott (Strataforma.com)]

To reproduce, here's the test file I'm running with. 4000 mm/min feed, 0.2 mm pxsize, and either one of the butterflies. The rightmost 7-8 mm gets chopped off.

https://drive.google.com/open?id=1hvRvMGLsLJKLfXCP4r9CEE60XZ27Zzsb

What's weirdest is that I've had rastering working just fine before. Not sure what this could be.

[Scott (Strataforma.com)]

I'm still working on this, and have ruled out the error being on the transmission side of things. By looking at the raw serial data being sent out I can see that the correct target coordinates for each raster pass are being sent, as are the correct number of raster points for the pixel size. So the issue is somewhere in the firmware. 

Some more tests have shown that it's not exactly chopping off the rightmost points. Instead, it's offsetting the left edge by about 3 mm, and stopping about 7 mm short from the right edge (so that the new right edge is inset about 4 mm from where it originally should have been). Below is a picture of a raster image of some text, with a vector bounding box, and how it comes out engraved. The image comes out at the right scale - it's not squished or stretched at all. I only see the issue with raster engraving, not fills. This is sufficiently weird behavior that I think it must be something tricky like a rounding error or an implicit type conversion. 

I'll keep digging into the issue since I need the raster engraving to work in order to make Xmas gifts for the year, but I'm a lot less comfortable hacking on the C firmware than on the python side of things. If anyone has any ideas of what might be causing this, can reproduce the issue, or can think of some workarounds (replace the Arduino?), I'd love any help I can get.

Cheers - 

Scott

[Scott (Strataforma.com)]

I don't know if this thread is helpful for anyone, but I figured I'd keep documenting my struggles here in case people run into this issue again in the future.

Frustrated with not being able to figure out where the error is in the software-serial-firmware loop, I decided to try digging out an old laptop that I have used to run the lasersaur software before. With the same firmware, driveboardapp executable, USB connection, raster file, and version of Firefox, my old laptop works and my current laptop give the same erroneous result. This is turning out to be a real gremlin.

There are two possibilities I can think of now. The first is that the Windows 1909 update changed something that is screwing with the information being sent to the machine. To test that I'll try updating my old laptop to the newest version of Windows and seeing if it still works. The second is that I recently installed something myself that changed something, in which case the begrudging fix will be to try to reinstall windows on my current machine, or ideally backtrace through some recent programs and take a guess at which one might have changed USB serial interfacing. I'm still shooting pretty blind here but slowly making some progress?

[Scott (Strataforma.com)]

Finally fixed this. 

I tried posting a thread over on the Arduino StackExchange (https://arduino.stackexchange.com/questions/70856/seeing-consistent-serial-data-loss-over-usb-have-ruled-out-hardware-and-rx-tx-s), and there was some good discussion, but nothing that ended up helping. I also tried buying a new Arduino to put into the machine, but that didn't change anything.

What finally worked was doing a Windows "Reset" of the PC, which reinstalls Windows while keeping files but resets settings and programs. After reinstalling and adding back in all the programs I originally had, the serial communication worked again. So I'm still totally in the dark as to what the original issue was, but at least it's working now. Maybe this is helpful for someone in the future? I don't know.

Cheers -

Scott

[Scott (Strataforma.com)]

The bug is dead! It applies to all versions of driveboardapp, and if you are running your own fork you probably will want to cherry pick my git commit with the fix. 

This resolves the "image raster cuts off some 5mm at the end" note that Stefan had put into the TODO, so it's definitely long-lingering.

Surprise surprise, my last fix above only lasted a few months before I saw the issue again, and this time doing a Windows refresh had no effect. I basically resigned myself to not being able to do rastering over the past year, until I got a spurt of inspiration in the lead-up to Christmas to try and make presents again. As it goes. It took 3 days this time around to figure out what was going on, but here's the cause of the bug:

The firmware calculates trapezoidal velocity profiles for each line it draws. As new lines get added to the queue, it calculates a smooth acceleration/deceleration between each successive pair of lines. This is why we have lead-in and lead-out distances for fills and rasters - so that you don't have to have an acceleration or deceleration region in your image, and can spend the full distance engraving at the 'plateau' velocity. 

For the last line in the queue, it assumes a ramp down to 0 velocity. If more lines get added, this calculation gets updated.

However, for raster data, the pixels are streamed over the serial connection during the engraving pass, blocking the lead-out line from getting transmitted until the pixel data has all been sent. What was happening was that the raster engraving was hitting the placeholder 'deceleration point' necessary to slow down 0 velocity. Once it did this, it saw that it isn't able to continue engraving at the target speed, begins its deceleration, and discards all following raster data. Once the raster data is cleared from the input buffer, it reads in the lead-out line, recalculates the deceleration profile, and ramps back up to the intended speed (meaning that there isn't a visual slowdown).

The fix was simply to assume that in the case of no additional lines in the queue, assume that a raster line will not decelerate at all. 

I am still confused as to:

a) why rastering ever worked making complete images at all

b) what the finicky discrepancy between versions of Windows on my laptop had to do with anything

I believe that the answer is something to do with the speed of serial interface buffer handling at a low level - if the feedrate is low enough or if data was transmitted to the arduino quickly enough then this issue doesn't occur. I must have been on the borderline with my setup.

Phew. That was one of the hardest bugs I've ever had to track down, and I'm glad it's dead.

Scott