CNC CO2 Laser - Delay after "M" and "S" Commands

[jtronics]

Hello, I'm using the TinyG hardware with my 40W co2 laser cutter (made in china :-) ). For toggling the Laser I tried to use the "M3" and "M5" and for PWM the "S" commands.

It looks like: M5 G0 Xxxxx Yyyyy M3 G1 Xxxxxx Yyyyyy ....

or

M3 S0 G0 Xxxxx Yyyyy S100 G1 Xxxxxx Yyyyyy S0 G0 Xxxxx Yyyyy ... M5

The problem is, TinyG stops at every of these commands. That means, the laser decelerate to zero, than executes the M or S command and than accelerate again.

Is it possible, to modify TinyG, so that the controller executs the M or S commands without changing the speed?

There is also a video on youtube. http://youtu.be/-CjDW2fq-C0

best regards Martin

[wballard]

I'm looking to connect a similar thing, can you share your PWM parameters and a pocture of how you connected to your laser power supply?

[ril3y]

Guys, I made a laser writer project http://www.instructables.com/id/Laser-Glow-Writer-Introduction/ as of late and while is not the same thing as you are doing I did have to tweak my jerk settings to get the decel to go away. So just do this.

Turn up the jerk by setting the $xjm=200 then see if your problems start to go away. I think the default is like 20? So increment this until you get the results that you are after. On my epilog laser there is virtually 0 delay when changing directions in a raster job so the jerk (i assume they are using something like our setup) must be very high on laser cutters where the delay would dump more thermal energy into the material.

Oh and if it was not obvious. Change the $yjm value as well :) However I suspect that it would be much less of an issue on Y vs X. Keep me updated and post back your settings that worked for you (if it does!)

Hope that helps.

On Mon, Dec 29, 2014 at 7:57 AM, Will Ballard [email protected] wrote:

I'm looking to connect a similar thing, can you share your PWM parameters and a pocture of how you connected to your laser power supply?

Reply to this email directly or view it on GitHub https://github.com/synthetos/TinyG/issues/114#issuecomment-68255199.

[jtronics]

Hi, my laser runs with the maximum speed (like your tests with the makerbot). It seems, that the "M" and "S" commands are specialized handled. Before such a command the controller turns the speed to zero, executes the command and then accelerates again. If you use the controller in a milling machine, it doesn't matter, but if you use it for a laser cutter, the resulting delay (in cause of decelerating and accelerating) is very bad.

Is it possible to change the stepping algorithm, to execute the commands, without changing the speed.

PS.: If I remove the laser command ("M" and "S") the controller runs without problems and in the expected speed.

[aldenhart]

@jtronics - Thanks. This will be changed to work as you suggest. I do not have a time frame yet, so I will leave this issue open.

[ZackSchilling]

I am glad to see this is on the list of requested features. I am currently building an automated CMM using the TinyG, a strobe light, and a camera. It would be great to be able to use the spindle or coolant signals to trigger the camera without having the machine come to a stop at each point.

[jtronics]

Hello aldenhart, is something planned for a new release? What do I have to change to add this feature?

[stg]

For G2 there is a TODO at plan_line.cpp:272 which I believe relates to this. I am also quite interested in finding a way to make this work and any hints to what is necessary would be much appreciated.

[kingjamez]

Did this issue get resolved? I too would like to use a G2 to control a co2 laser.

-Jim

[interstellarspace]

Anyone tried the smoothieboard? I wonder if it has the same problem in engraving raster image

[kingjamez]

Hi interstellarspace: Yes, because of this issue, I used a smoothieboard instead of my G2 setup. I love the motion of the G2, but the smoothie won because of the laser module. The laser module is specifically built to rapidly change the laser intensity. I use Pic Engrave Pro to convert images to GCode and the smoothie will raster wonderfully and very quickly. I hear a native raster functionality is coming to smoothie soon.

On a side note. I wish the smoothie team and the TinyG team would collaborate with their open source code to get the best of both worlds. A hybrid of the two would be a-maze-ing.

-Jim

[interstellarspace]

Thanks for the info Jim. Where did you order it? I read some people complaining about Uberclock.

[troisiemetype]

Hi there!

Is there something new on this issue? I'm planning to buy/built a laser cutter, and would really like to use TinyG on it. Or, can you point out where to look in the code to change this behavior? After having spent a few hours reading the code, it seems that there is some part of the work done (with moveType in planner.h), but this seems to be not implemented yet. Looking at the code, I believe that a new "mp_queue_command" function should be made that set the MOVE_TYPE_SPINDLE_SPEED instead of the MOVE_TYPE_COMMAND. And if I understand well, the stepper.c should have a way to handle this type of action by letting it in the buffer to process it right in time, but without taking into account for the move planner. After having understod all that by myself I'm stuck: even if I understand more or less how the planner buffer works, when looking precisely I don't find where this modification should be made...

Thank you for you help, or answer, or anything else!

[hatchethand]

I am going to revive this thread, as well (troisiemetype referenced it in #156). I have verified that the addition of S commands halts G1 movement, regardless of positioning in the file. Both of the below scenarios produce jerky raster movements: G1X10Y20S30 and S30 G1X10Y20

I haven't actually checked to see if the same if true for M commands, as I'm only using M3 and M5 at the beginning and end of jobs, and S0 to turn the laser off during the job, but I see the above post from jtronics stating this to be the case for both M and S commands.

For reference, I generated my test gcode for rastering using LaserWeb.

Thanks, guys, for the awesome work!

[nickw89509]

Hi, I have made this mod for the grbl code base. I am planning to update the tinyg g2 using the same mod. Expect to have this forked for the g2 repository by mid October.

The reason this works this way is because when the planner encounters a spindle change previous GCode blocks may or may not be executing so processing of the planner que must stop so as not to change the spindle speed for previous G codes. What change involved is planning spindle changes in the same way that axes position is planned.

If you want to review the grbl modifications https://github.com/nickw89509/LaserInk

[patyork]

No movement on this, I see.

From what I can see, the M and S commands are implemented per the comment here - with entry/exit vmax of 0 (which is a quick/short stop).

Are there any large hurdles to changing this (more than likely, optionally via a config item) to maintain velocity?

[nickw89509]

Hi Pat, I have got sucked into a distressed project as a consultant and have been super busy for over 3 months and not able to complete this. There are two issues yes it should be easy to have the spindle command cause an instantaneous change without stopping motion. The problem is that the spindle command needs to act much like an additional axis. The Spindle speed needs to be planned just like an axis.
Consider G1 x1y1 S255 G1 x10y1 S225 G1 x20y1 S200 G1 x30y1 S175 G1 x40y1 S150 G1 x50y1 S125 G1 x60y1 S100 G1 x70y1 S75 G1 x80y1 S50

The planner accepts commands prior to there actual execution so if we allowed the spindle change to happen immediately then we could potentially override the desired laser intensity where the head is moving between x=10&x=20 with the power of "G1 x80y1 S50"

In the grbl code I needed to add the spindle velocity directly to the planning block when the GCode is read. As I process each block I then send the velocity out this guarantees that the position matches the desired laser intensity which is important for image processing.

This work quite will when velocity changes are very small between blocks or acceleration is very high. Edward has extended this algorithm to proportionally scale the laser intensity as the instrument accelerates to full speed. This prevents over-burn when cornering as in doing fonts.

You may be interested in checking out this video https://www.facebook.com/myobjectworks/videos/1746081008996566/ This using a streaming algorithm to send image data to a laser controlled with a custom derivative of grbl. In the video you will notice the large amount of data being sent as blocks in the software. In this video the laser is moving at about 3200 mm/min any more then that and the laser is not powerfull enough. I have tested the firmware by using it to run a CO2 laser and was able to see speeds at 15000mm/min. Note this is a totally different approach then scheduling spindle changes. I hope this helps I would love to see this in the TinyG controllers. Nick

[nickw89509]

replied inside of git, cheers

On Sat, Jan 28, 2017 at 5:54 PM, Pat York [email protected] wrote:

No movement on this, I see.

From what I can see, the M and S commands are implemented per the comment here https://github.com/patyork/TinyG/blob/master/firmware/tinyg/plan_line.c#L377-L379

• with entry/exit vmax of 0 (which is a quick/short stop).

Are there any large hurdles to changing this (more than likely, optionally via a config item) to maintain velocity?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/synthetos/TinyG/issues/114#issuecomment-275888234, or mute the thread https://github.com/notifications/unsubscribe-auth/ADFHvmWTeuMavWD3CyZwoPtF284QFmL5ks5rW_E9gaJpZM4DLkcY .

[patyork]

Hi Nick,

No worries.

I've only taken a cursory glance through the code, so I'm not sure if the following will make sense.

My thought was that the Spindle (or rather, laser - as the 2 should probably not be interchangeable in this delay regard), as you said, would act similarly to an axis. However, the "moves" on this axis would be considered to be of 0 length, and can handle a jerk/accel/velocity of infinity (or to have the same velocity as the machine is currently moving in). That is, the "S" commands in this scenario would still be synchronous, but no decel would need to occur (as the "axis" can handle anything instantaneously, and is fine to continue moving at the currently velocity).

Again, not sure that the above makes sense in practice. In theory it would be like the below:

G0 X0
G0 X10
S2000
G0 X20

Currently, the planner sees an "S" code, which requires a decel to 0. However, if you image that "S" being an axis "S" that moves instantaneously, there is no need to decel. Perhaps not the best analogy (as instantaneous is not something that tends to happen in the real world), but the idea of a synchronous command that planner can essentially ignore for movement planning is what I'm getting at.

Edit: Treating the PWM as an axis would be very good for changing the laser intensity as the machine decelerates/accelerates. However, I'm just looking for a basic ability to modify the spindle speed on the fly without delay (with a decent jerk rate, acceleration and deceleration times to target velocity should be small enough that the laser intensity does not necessarily need to be adjusted to prevent overburning). Especially given that the current workaround for many people on the tinyG is to set the jerk to 10,000 (x10^6) or as high as possible to get a smoother transition from those short stops, a high jerk to minimize acceleration/deceleration times (near corners) isn't a huge issue, IMO.

[aldenhart]

There is movement on this, it's just not ready for release. In the mean time the ideas you documented above can provide some work-arounds if you want to implement them.

[patyork]

I've tried to implement something, but without a programmer for debugging, I'm flying completely blind..

Any hints at all? Based on the comment that length, entry/exit_vmax are (or should be 0) for this type of move_type, I've tried manually changing those values before forward/backward planning, but I can't even tell if it's getting to the code block I'm expecting it to for an S command.

Edit: if this has been worked on but is not ready for release, is it in one of the dev branches?

[patyork]

Well, a dozen or so hours stepping through the Atmel simulator debugger, I've got a workable solution. A little iffy on the first move (since it's not replannable) but a dummy move to start off the gcode and it works as expected - no decelerating into/accelerating out of an S command.

Thanks for the help.

[nickw89509]

This is awesome any have you cloned the git. If so I would love to give this a try.

[patyork]

Yeah, I pushed it to master on my fork.

I cleaned up the code a bit, haven't retested, but it should still work. I left the version the same and pushed the .hex file as well, so you could just drop it on the board.

To add: like I said, the first move is planned to 0 exit velocity (since as far as the planner knows, it's the only move) and is sent directly to the runtime, so it's not replannable. You can get around this by moving away from and back towards your starting point in GCode beforehand (fine for my purposes). ~Also, now that I'm thinking about it, there may be some odd behavior at the last command, if it is an "S" command - machine may fly into it at cruise velocity and then stop short, but that I haven't tested.~ Acceleration and Deceleration are planned and executed correctly based on the jerk settings - this little workaround does nothing to adjust the PWM output automatically when acc/decelerating however, so that's something to keep in mind at corners/junctions (and also in general; make sure you don't starve the TinyG planner such that it stops unexpectedly while waiting for more moves).

[patyork]

@nickw89509 I've made a pretty sizable mistake somewhere; it works fine when moving in the positive direction along an axis, but not when moving in the negative direction. I had thought that the directional part of the velocity was handled elsewhere, but it appears not.

[nickw89509]

Hmm, haven't had a chance to look at this super busy with work. When I get a free moment this is on my to do list.

[patyork]

Made a quick update today - it was the directional vector causing issues (because the spindle speed change is stored within this directional vector, as a memory optimization I guess).

Video of it in action (apologies for the simplicity of the example - if you can't tell, this was exactly my 4th test image):

https://www.youtube.com/watch?v=mprc9WvEJ6s

[JonathanGoldnauVogt]

I'd like to see this feature added as well. Ran into this problem

[ghost]

As far as I understand there's still no solution in the original code, right? @patyork to use you firmware it's enough to update the hex file?

[ghost]

Ok, after flashing the @patyork's fork the behavior is slightly better, but there are still vibrations and I cannot find a suitable CAM to produce the expected paths.

I'm going to migrate to GRBL if there are no plan to add the "laser mode" to TinyG. By the way, neither G2 has this feature?

[patyork]

The firmware changes work well at about 2000 changes ("S" commands) per minute; this equates to my laser's abilities of a .2mm by .2mm approximate burn area at its focal point and an acceptable, if slow, machine rate of 400mm/min. The firmware begins to cause noticeable vibration (due to motors turning off for a few milliseconds on each S call) at around 5000 changes/minute, which is 1000mm/min on my machine. I've said before, but all of my CAM software is handwritten, though some person's have fiddled other CAMs to output S command-based gcode for lasers as well. null