Another TinyG question

Sorry for tinyg questions, I’m trying to upgrade from 8bit Grbl to 32 bit. Everything seems to be working well, I have to save the gcode from Lightburn and run it on a gcode sender. The issue is at every G1 line the motion planning will decelerate and accelerate even if the motion is going in the same direction. It is definitely an issue of jerk. I hope this makes sense, my question is does anyone know of a way to turn off jerk motion planning for linear movements until the direction is reversed? Refer to this video to see a simulation of my problem. https://youtu.be/mYWdnNp3O-c

This is what I’m trying to engrave, where it slows down then speeds back up is at every point the laser fires which is because a new G1 line is in the code. So at every G1 line no matter what the machine will slow down then speed up. I hope this is clear enough to understand.

Is it remedied by using a different g command?

No, even with G0 it still does it

What version of the tinyg do you have? And have you tried messing with LightBurn’s scanning offsets?

EDIT: And what firmware version are you running on that?

LightBurn version is 9.04. I am out of town for work now so I won’t be able to get my TinyG version until tomorrow. It’s not just the LightBurn gcode though, all of the raster engraving gcodes I’ve loaded do the same thing when the laser turns on, it creates a new line of “G1” which causes TinyG to slow down then speed up.

If you send several G1 lines in a row does it do it? Like this:

G1 X0 Y50 F6000
G1 X100 Y50 F6000
G1 X200 Y50 F6000
G1 X300 Y50 F6000

If it slows down for those, that’s bad. It could be that TinyG is set in “exact stop” mode or similar. On the other hand, if the stop happens when the spindle speed changes, it’s probably that TinyG is waiting for the spindle speed to catch up to the new setting. GRBL has a laser mode specifically to prevent this.

This code would illustrate that problem:
G1 X0 Y50 F6000 S0
G1 X100 Y50 F6000 S100
G1 X200 Y50 F6000 S0
G1 X300 Y50 F6000 S100

Oz, that sounds like a very logical explanation. I’m away for work but tomorrow I will give that a try. It seems like that is the reason just thinking about it now but I will know for sure tomorrow. Thanks for the help so far, purchasing LightBurn was worth it just for the support alone.

My TinyG version is :
[fb] firmware build 87.01
[fv] firmware version 0.98
[cv] configuration version 7.00
[hp] hardware platform 3.00
[hv] hardware version 0.00
[id] TinyG ID 0213-0215-0545

As you guessed, the motion is smooth when S-values are not present. Do you happen to know a work around? I tried changing the G Code path control in the TinyG settings but all three of them do the same thing.

You would need to contact the TinyG developers to see if there is any setting or mode to handle laser use and allow for continuous moves. I don’t know TinyG at all.

What do you recommend for a 32+bit controller compatible with your software?

One option that works very well with LightBurn is the Cohesion3D LaserBoard that I make.

2 Likes

How many axis’s do you need to control, will you be using a rotary attachment, and what size are your stepper motors? Answers to these questions will go a long way to being able to recommend a solution for you.

Right, I only need x and y axes. I use NEMA 17s at ~2A per motor. I only want to improve the laser quality which is why I’m looking at getting a better controller. The Cohesion 3D looks like a fine option though that Ray recommended.

The C3D laserboard is indeed a great choice. It will handle your needs, and give you room for expansion.

2 Likes

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.