Random moves during raster

Hi,

I'm not sure if this is the best place to post this so please let me know if it isn't. I got given a "broken" Chinese 40w laser that I successfully got working by using a RAMPS board to drive it. (no LCD panel or anything, just the board) I've used this modified reprap firmware and this inkscape exporter plugin. I've successfully used it for vector cutting, it works great. However, raster has an annoying little "glitch" that seems to happen occasionally. The laser cutter will seem to just "take off" in a random direction halfway through the job, return to where it took off from, then continue. You can see this in the picture (the random diagonal and horizontal lines), the laser stays on the whole time so ignore the couple of spots I turned it off manually. Another thing I noted is that every time it did it, the speed wasn't necessarily the same as you can see two are darker/thicker than others.

I've attached my gcode and pdf file it was generated from. The PDF is a PCB I designed in Fritzing, and I inverted the black/white in Photoshop so it would etch correctly. I used Repetier Host to send the gcode to the laser and I couldn't see any of these anomalies when in the gcode previewer. Does anyone have any ideas of what may be causing these anomalies?

Gcode generated: out.g_BWfix_128.gcode
Original pdf file: CarCompanionSchematic2_etch_copper_top_negative.pdf
Problem seen in picture:

... this could be communication errors -- so either buffer overflow or dropped bytes, so some XY-coordinates gets wrong values

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Quote
Turnkey @ github
11-April-2015 - Added back in raster optimising, it's not perfect but it's mostly there. Only a little slow parsing white vertical space now. Found that raster optimisation code seems to be changing the pixel data at the end of the line somewhere. I'm not sure how since it's meant to just be cutting part of the data line out not changing it. will need to investigate further. Added option to the menu for users to disable raster optimisations.

There seems to be a bug in the raster code. Don't know if it's related to your problem...
-Olaf

Quote
VDX
... this could be communication errors -- so either buffer overflow or dropped bytes, so some XY-coordinates gets wrong values

Thanks for your response, is there any easy to way to test either of those theories?

Quote
o_lampe
There seems to be a bug in the raster code. Don't know if it's related to your problem...

Thanks for that suggestion but I don't think that is the cause. The gcode that has been generated appears OK to me, as I can't see the anomalous moves in the Repetier Host gcode viewer.

Thanks to VDX I now suspect it's a communication (or maybe firmware) issue. But seeing as no other users have reported this problem, I'm tending to lean towards the former.

... you can try with other (faster) baudrates or another PC ...

---

Viktor
--------
Aufruf zum Projekt "Müll-freie Meere" - [reprap.org] -- Deutsche Facebook-Gruppe - [www.facebook.com]

Call for the project "garbage-free seas" - [reprap.org]

Did you solve this?

Sorry, I've been really busy with Christmas and moving house.

Unfortunately my 3D printer RAMPS board died and it's more important so I had to swap it over. When my new one arrives I will try again with other computers and baud rates. However, it was already running at the max speed. (250,000 bps)

I havê a similar behavior but i am only at the first steps of troubleshooting. I have yet to confirm if the gcode is good. Think I will run yours ( gcode) and see how that works.

Also running from repetier on ramps and my error lines are parallel like yours

I use the same firmware and plugin, well with a few slight mods.
So far I have not encountered this problem, but I use Pronterface instead of repetier.
Some of my changes include adding the spped settings to every move as otherwise often the (wrong) defaults are used throughout the print.
In the gcode from the first posting there is no speed defined for the G0 moves, so the firmware defaults are used instead.

Keep in mind that raster engravings are base64 encoded to save on the required commands.
That means you need to have a suitable buffer size available as otherwise the machine gets a "hickup".
While the buffer is running low on certain commands it attempts to fill it up again and if there is a com problem even the base64 code can be compromised on the way.
Although it is claimed to work with a little Uno I prefer the Mega with more space, buffer and higher clock speeds.

If you can get feedback from the machine during the print check if you see commands failing with the need to resend them or any oter errors that could indicate com issues.