Line by Line bidirectional vs. unidirectional

[Dpsspower]

I have a very cheap chinese engraver using belt drive for movement.
When engraving a picture line by line, I can only see it working bidirectional. This goes fast but is a problem with cheap machines.
The driving belts have a kind of slippage when changing from one to the opposite direction. This shifts the lines a bit and produce a kind of "interleave" image.
Is there a possibility to drive the lines unidirectional and then move back using a higher speed?
This would cost time but increase picture quality, specially when doing small sizes.
Another solution could be to add a slippage correction value which is added to even or odd lines in bidirectional mode, so you can "shift" them to match.

[arkypita]

Have already tried configuring the acceleration parameters $120, $121?

[arkypita]

and then move back using a higher speed?

do you mean lower speed?

[Dpsspower]

No I mean higher speed.
You drive the line while lasering the picture, lets say F=500. When end of line is reached, laser is switched off and travels back to beginning of next line with for example F=2000. This saves some time.

I don't want to lower accelearation parameter, because when it is to slow, I get burning at edges. Not only at pictures, also at outlines.

[arkypita]

No I mean higher speed. You drive the line while lasering the picture, lets say F=500. When end of line is reached, laser is switched off and travels back to beginning of next line with for example F=2000. This saves some time.

But if you have belt slippage while bidirectional engraving at F500 you will have more slippage going back at F2000 also if not engraving!

I don't want to lower accelearation parameter, because when it is to slow, I get burning at edges. Not only at pictures, also at outlines.

grbl v1.1 can compensate the more/less burning due to acceleration/deceleration by modulating laser power. please read https://github.com/gnea/grbl/wiki/Grbl-v1.1-Laser-Mode#laser-mode-operation and consider upgrade your firmware to grbl v1.1 to use M4 constant power mode.

IMHO if you have hardware slippage problem you must solve them by hardware, there is nothing that software can do. Shifting odd or even lines seem to be unsteady and result is not assured.

[Dpsspower]

You are right. Sorry I used the wrong word.
It is not slippage, it is backlash of the belt. because of strain.

[arkypita]

Ok, but it's the same: more speed, more strain, more problems.

[Dpsspower]

No it is not :-)
Let me explain:
The belt will become a bit longer when the motor starts moving the axis. Because of friction of the bearings and weight of the laser head, this elongation of the belt stays the same. It has nothing to do with speed. Naturally, at very high acceleration, the elongation will be more, but what I mean is the static elongation which is from the point when the motor starts turning to the point when the axis is moving. This value is nearly constant.
When you change movement direction, the force to the belt is changed to the other direction. So the former elongated side will "shrink" while the opposite side of the belt is elongated. The way the motor must go until the axis begins to move is a mechanical hysteresis or backlash.

When you have a very expensive machine using spindles, this probably is not a problem.
But I think most of the cheaper belt-driven machines do have this effect.

I did a test burning a simple line pattern. The lines are vertically arranged and I used the horizontal "line to line" movement with 0.5mm distance beween scanning lines. So you can see each single line clearly.
Then I editied the file manually. The upper half of the picture uses your "zickzag" driving, F=1000 in both directions. You can clearly see that the lines are shifted because of the belt drive.
The lower half is modified by me and goes like "drive and laser the line F=1000, Laser Off, Go back to start of next line F=3000, do next laser line F=1000" etc. etc.
You can see the lines match each other, even the speed of return was 3x speed of buring.
I used the M4 command with latest GRBL firmware 1.1.
The screen picture of your software with the file loaded shows that this is NOT a G-code mistake.
All coordinates are right and all lines seem to match on the computer screen.

An additional effect which is added to the belt backlash, is the delay time of the laser.
Cheap chinese lasers are slow in in response to on-off signals. You may have a delay of several milliseconds until the laser starts emission and burns.
So even if you have a high precision machine but maybe a slow laser, the effect will be similar.

I am sure if you think about this problem, you could greatly increase the quality of the pictures.
There are 2 possibilities to compensate the effect:

1. offering an unidirectional movement with fast return, so set 2 different F-values.
2. using your existing process but add an optional offset value to even or odd lines as a correction value.
   Both option would be great because then everybody can use what is best for him.

I haven't tested this with diagonal movement, but I guess the effect will then be at both axis x and y.

[arkypita]

Maybe I have understand. You mean this effect:

[arkypita]

My engraver is a DIY 20x30cm machine, it is belt driven. I use a wooden frame cut with handsaw, belts were pulled manually and fastened in place with screws. The laser sled is quite heavy to move, but with a bit of sewing machine oil it move clean and quick.

http://lasergrbl.com/wp-content/uploads/2017/03/DSC_1454.jpg
http://lasergrbl.com/wp-content/uploads/2017/03/DSC_1444.jpg
http://lasergrbl.com/wp-content/uploads/2017/03/DSC_1457.jpg

I used it @ F3000 (and up to F6000) without loosing precision, as you can see in my video: https://youtu.be/conZiopJF3k?t=22s

So, what I mean... belts it is not always a problem/limit. They could be if not properly mounted.
I think you should work a bit to improve your engraver. Sometimes the spring of a cloth clamp is enough to tight the belt. You can bend it and put on the belt.

About your suggestion:

offering an unidirectional movement with fast return, so set 2 different F-values.

Could be a good idea, it favors the repetition of positioning in any case.

using your existing process but add an optional offset value to even or odd lines as a correction value.

Require manual trimming of the value, not so easy to implement and use, require more data to input (lasergrbl claim to be easy to use, with the minimum data required).

However both of them helps only in line2line process. No way to fix this hardware problem with vectorized images and externally loaded gcode, so here why I continue to suggest you to fix hw problem working on your hardware first.

[Dpsspower]

Okay, the belt of my machine is not sagging in that way you maybe could think now.
I stretched it as good as possible. But the machine has no ball guides like yours. It just uses rolls running on the aluminium profile. I guess the backlash factor of my machine is much higher than yours.
But if you want to compare, you can try my "backlash-testpattern" on your machine.
lines04_bi_uni_g4.nc.txt

However both of them helps only in line2line process. No way to fix this hardware problem with vectorized images and externally loaded gcode,

You are right. But your software seems to be specialized for engraving pictures. My idea was just to allow better results without investing too much programming effort.
Unfortunately, I don't program in CS, otherwise I could add this feature by myself :-)
Your software is really great, except of this feature, don't misunderstand me.
I checked out the demo version of "Picengrave" but that software is sooooo sloooow.

I first run the original chinese software with the machine. The software is real garbage in GUI. But quality of pictures is lightyears better because they offer the unidirectional line2line motion.

But I don't want to bug you any more. Thank you very much for your time.

[arkypita]

I did a test with your file, you convinced me.
I had never noticed this problem, probably because I never did such a specific test.

The unidirectional tracing sounds better for me: work for any speed (odd/even compensation require calibration on speed as you can see) and does not add "an error" specifically to the generated gcode, so the code is portable from machine to machine.

[arkypita]

I use a special laser-test cardboard that can engrave with 2W at this high speed

[Dpsspower]

Okay, very interesting :-)
I think this shift is a sum of switching delay of the laser and backlash of the axis and motor delay.
In your case I guess that the laser and motor delay is most part of the influence.
Backlash normally is the same at different speed.

But you see, there are many time delay elements in the system, causing quality problems.
It is not easy to see this at a lasered photograph with 10 lines /mm. It is just a bit blurred.
I think if you try the unidirectional movement, your demo picture will become knife-sharp ;-)

Yes, an additional unidirectional tracing with 2 F-speeds would be a great option.

[arkypita]

I have plan to rewrite the whole g-code generator of LaserGRBL, to clean-up the code.
I add this feature in roadmap, i'll add after the code cleanup.