Speed changes in gcode happening only half of the time

So I’m doing some tinkering with the Onefinity, and attaching a wood burner to the Z to do some pyrography like the pyroprinter does. How the pyroprinter works, is that it changes the speed to affect how much it burns to create a grayscale image. The slower it moves, the darker the image, the faster, the lighter.

However, with the Onefinity and the Buildbotics controller, it is only periodically reading the F lines in the g-code. So with my test image, which is just a white to black bitmap with 8 shades of gray in between for 10 values total, it is only doing half of them. So with an actual image, it is just a blurry mess as it will not change speeds when called to, it just keeps going until a certain distance and then decides to follow the next F speed. There’s no G64 to do any smoothing, jerk is already set at 10k, firmware is 1.2.1. I’m not sure what other G command would make it refuse to change the speed when it is on a line that says to change speed. Below is a sample of the g code. It also does a double wipe at the end of each line to remove any soot on the burner, that’s the 5 and -5 parts.

%
T1

G17G94G21G40G49

G0 Z15
G0 X0.000 Y0.000 M03 S16000

M3
M0(MSG, Click ‘Continue’)

G90G0X0
Y0

Z0.000

G90G0X0
Y0
G91G1F1000X-12.5
;M0
S255M3
X12.5
G90G0Y0.085
X60.96
G91G1F350X-6.604
F908X-7.112
F1373X-5.757
F1931X-5.758
F2489X-5.418
F2954X-5.758
F3512X-5.757
F4070X-5.419
F4535X-7.281
F10000X-6.096
G90G0Y0.254
G91G1F1000X-12.5
;M0
F5000X-5
X5
X-5
X5
;M0
F1000X12.5
G90G0X60.96
G91G1F350X-6.604
F908X-7.112
F1373X-5.757
F1931X-5.758
F2489X-5.418
F2954X-5.758
F3512X-5.757
F4070X-5.419
F4535X-7.281
F10000X-6.096
G90G0Y0.423
G91G1F1000X-12.5
;M0
F5000X-5
X5
X-5
X5

(repeated code removed here)

M5
G0Z15

M2

Hey Chad,

I have no experience with such a wood burner nor any software that does this, but G61 and G61.1 should be supported, at least according to Buildbotics 1.0 manual. G64 too.

So I would add G61 to the current list of commands G17G94G21G40G49 at the start, and then G64 at the end of the program? I was assuming G64 just did path blending. Now I’m seeing that I could actually add a value to it, like G64 P0.015.

I’ll first try G61 and then G64 with the value and see if I get different results.

Unfortunately G61 causes it to do a quick stop at every line, burning the image wherever there’s a new line. G64 P0.01 seems to blend XYZ, but not F. There’s also a Q that can be added onto the end of the G64 command, but I’m not seeing any examples on how to use it, or if it would even do anything.

Hey Chad,

  1. I have difficulties to imagine what the result looks like. Could you show the original bitmap and the result?

  2. What ‘tool-type’ are you using in the TOOL page, and what are your settings for ‘rapid-auto-off’ and ‘dynamic-power’?

I hope this image explains it better. I have a nichrome wire wood burner attached to the Z axis. The power is always the same, well, I adjust it on the wood burner power station, it isn’t controlled by the g-code other than to turn it on and then off at the end. The input image is 10 values from white to black. The default settings and G4 with P set to any value, gives the same result. G61, stops at each change in the feed rate, but as a consequence, it burns a little spot at each new line. The sample image shows what I would normally input into this software to generate the g-code. And the bottom half of it you can see how it is optimizing the feed rate or something, so the feed rate that should be changing all of the time is currently done not often at all. I can even set the top and low feed rate to be very low, or very high, it will still burn the same.

Everything on the controller is default from when I received it, other than jerk. Tool-Type = disabled. Since that is disabled, there’s no rapid-auto-off or dynamic-power set. Would that even do anything if the wood burner isn’t being controlled by the controller, other than to turn it on in the beginning, and off at the end. It’s using the same IOT Relay that I use to power on/off the Makita. Unless it changes how it updates the feed rate?

Here’s a YouTube clip of how pyrography CNC machines work.

Hey Chad,

thanks for the in-detail explanation and the good illustration.

Have you considered this:

A G Code program can never be fully obeyed. For example, imagine you specify as a single-line program the following move:

G1 X1 F10   (G1 is linear move, X1 is the destination, F10 is the speed)

In reality, the whole move can’t be made at F10, since the machine must accelerate from a stop, move toward X=1, and then decelerate to stop again. Sometimes part of the move is done at F10, but for many moves, especially short ones, the specified feed rate is never reached at all. Having short moves in your G Code can cause your machine to slow down and speed up for the longer moves if the naive cam detector is not employed with G64 Pn.
[…]

1.2. Path Following

A less straightforward problem is that of path following. When you program a corner in G Code, the trajectory planner can do several things, all of which are right in some cases: it can decelerate to a stop exactly at the coordinates of the corner, and then accelerate in the new direction. It can also do what is called blending, which is to keep the feed rate up while going through the corner, making it necessary to round the corner off in order to obey machine constraints. You can see that there is a trade off here: you can slow down to get better path following, or keep the speed up and have worse path following. Depending on the particular cut, the material, the tooling, etc., the programmer may want to compromise differently.

Rapid moves also obey the current trajectory control. With moves long enough to reach maximum velocity on a machine with low acceleration and no path tolerance specified, you can get a fairly round corner.

1.3. Programming the Planner

The trajectory control commands are as follows:

  • G61 - (Exact Path Mode) visits the programmed point exactly, even though that means it might temporarily come to a complete stop in order to change direction to the next programmed point.
  • G61.1 - (Exact Stop Mode) tells the planner to come to an exact stop at every segment’s end.
  • G64 - (Blend Without Tolerance Mode) G64 is the default setting when you start LinuxCNC. G64 is just blending and the naive cam detector is not enabled. G64 and G64 P0 tell the planner to sacrifice path following accuracy in order to keep the feed rate up. This is necessary for some types of material or tooling where exact stops are harmful, and can work great as long as the programmer is careful to keep in mind that the tool’s path will be somewhat more curvy than the program specifies. When using G0 (rapid) moves with G64 use caution on clearance moves and allow enough distance to clear obstacles based on the acceleration capabilities of your machine.
  • G64 P- Q- - (Blend With Tolerance Mode) This enables the naive cam detector and enables blending with a tolerance. If you program G64 P0.05, you tell the planner that you want continuous feed, but at programmed corners you want it to slow down enough so that the tool path can stay within 0.05 user units of the programmed path. The exact amount of slowdown depends on the geometry of the programmed corner and the machine constraints, but the only thing the programmer needs to worry about is the tolerance. This gives the programmer complete control over the path following compromise. The blend tolerance can be changed throughout the program as necessary. Beware that a specification of G64 P0 has the same effect as G64 alone (above), which is necessary for backward compatibility for old G Code programs. See the G64 section of the G code chapter.
  • Blending without tolerance - The controlled point will touch each specified movement at at least one point. The machine will never move at such a speed that it cannot come to an exact stop at the end of the current movement (or next movement, if you pause when blending has already started). The distance from the end point of the move is as large as it needs to be to keep up the best contouring feed.
  • Naive Cam Detector - Successive G1 moves that involve only the XYZ axes that deviate less than Q- from a straight line are merged into a single straight line. This merged movement replaces the individual G1 movements for the purposes of blending with tolerance. Between successive movements, the controlled point will pass no more than P- from the actual endpoints of the movements. The controlled point will touch at least one point on each movement. The machine will never move at such a speed that it cannot come to an exact stop at the end of the current movement (or next movement, if you pause when blending has already started) On G2/3 moves in the G17 (XY) plane when the maximum deviation of an arc from a straight line is less than the G64 Q- tolerance the arc is broken into two lines (from start of arc to midpoint, and from midpoint to end). those lines are then subject to the naive cam algorithm for lines. Thus, line-arc, arc-arc, and arc-line cases as well as line-line benefit from the naive cam detector. This improves contouring performance by simplifying the path.

In the following figure the blue line represents the actual machine velocity. The red lines are the acceleration capability of the machine. The horizontal lines below each plot is the planned move. The upper plot shows how the trajectory planner will slow the machine down when short moves are encountered to stay within the limits of the machines acceleration setting to be able to come to an exact stop at the end of the next move. The bottom plot shows the effect of the Naive Cam Detector to combine the moves and do a better job of keeping the velocity as planned.

Figure 1. Naive Cam Detector

1.4. Planning Moves

Make sure moves are long enough to suit your machine/material. Principally because of the rule that the machine will never move at such a speed that it cannot come to a complete stop at the end of the current movement, there is a minimum movement length that will allow the machine to keep up a requested feed rate with a given acceleration setting.

– Source: 1. Trajectory Control – LinuxCNC Documentation

So far for the definitions. The Buildbotics CNC Controller (Source), of which Onefinity Controller is a software and hardware fork, is patterned after the LinuxCNC implementation of the G-code Standard (see also: Differences between LinuxCNC and RS274/NGC), and G61, G61.1 and G64 are said to be supported.

Unfortunately I have not yet explored how tweaking these values influence the results and also never used a wood burner as tool (very interesting though) also I have no machine assembled here, just the Onefinity Controller in the lab so I can help you only with a reference to this information.

As each grey value of your wanted result image does depend on a specific real speed, and the feed rate is only indirectly translating to speed, If I were in your situation, I’d make another test (or series of tests) to specifically see how to you can achieve that speed is held constantly the best way.

Have you thought of using lifting Z a minimal amount as a “switch” to turn burning on and off?

What do you think of making the individual grey scale values of the image one after the other, each with a constant feedrate for the entire object, e.g. the entire object with color 00, then all color 01 occurences, and using lifting Z by a minimal amount to switch burning on and off?

The definitions are here:

‘rapid-auto-off’ - Checking the ‘rapid-off’ checkbox causes the cutting head to be turned off during rapid moves. This should only be used if the cutting head can be turned off and on instantaneously. This field is mainly used for laser cutters and engravers.

‘dynamic-power’ - Checking ‘dynamic-power’ automatically lowers the cutting head power during acceleration and deceleration. Once again, this setting is mainly used for laser cutters and engravers. With this setting enabled, the intensity of the laser is reduced until the full speed is reached. This prevents having excess energy deposited during acceleration and deceleration. Otherwise, the excess energy could result in over-exposed or burned areas in laser engraved images.

– Source: Buildbotics Controller Manual (v1.0)

I have found out the other day that when ‘dynamic-power’ is selected on TOOL page, during the G4 (Dwell) command, the ‘tool-enable’ pin gets inactive during dwell (and I don’t expect that since according to standard, G4 dwell should not affect spindle, coolant and any I/O).

Note that as of firmware 1.0.9, you can only choose ‘dynamic-power’ when the tool-type ‘pwm spindle’ is selected, but on the new tool-type ‘laser’, ‘dynamic-power’ is always (invisibly) on and on the new tool-type ‘router’, it is always (invisibly) off.

Rapid-auto-off and dynamic-power wouldn’t do anything unless it actually changes the feed rate, which from the descriptions doesn’t sound like it would.

I’ll do a test with those after lunch, but I’m assuming it will be the same result I get now.

The G64 commands have no effect on this, as it’s all straight lines, no arcs. G61 causes the stops and burn marks.

This morning I did another test, where I made a graphic that had both a linear gradient, and a posterized gradient with 10 steps. Then also one with some solid lines and a squiggly to see what would happen.

When I make it 5cm wide, it burns both gradients in 1cm chunks for the gradient, so 5 values.
When I make it 10cm wide, it burns the posterized gradient with all 10 values, but divides up the linear gradient into 11.5cm chunks.
When I make it 15cm wide, the posterized gradient is 10 values as it should be, the linear gradient is still dividing it up in what appears to be 11.5cm chunks, just more of them now that it is wider.

It is hard to see the rest of the values as my board had a slight dip in it, with less equal pressure it does burn different, so I marked them up with cyan lines. The adapter I made isn’t spring loaded yet so as to keep contact with the board when that happens. I was going to make that after successfully verifying that the controller could do this.

Feed rates set from 100 to 1000, or 500 to 5000, there is no difference. This has me thinking, does it know how big the tool diameter is if it is never specified? If it has a default diameter, would that have any effect on how the g-code is read and sent to the machine?

Doing them as separated passes would be very time consuming, and a tedious job to make sure each was setup with the correct feed rate. Not to mention there is actually 52 shades that this software is creating from bitmaps that are input, verified this by looking at the g-code as well. I know this works on homebuilt CNC machines, as others have done it and none had this issue, they were using Mach3 to control it though. The feed rate even works properly on 3D printers that people have tried it on. It seems that the Buildbotics is doing something behind the scenes where it combines feed into chunks that it shouldn’t. When modifying the g-code to G61, it proves that it’s reading the different feed rates, it just has the side effect of leaving dot burns at every new line of code. When loading the same exact code with G64, the controller loads it in a couple seconds. When you change G64 to G61, it takes about 10 seconds for it to load. I wish there was a way to see what it’s figuring out during that import process.

One kicker, is that the software on Buildbotics website, CAMotics, simulates the feed rate correctly. Not sure how accurate that is in simulating their hardware.

And as I was expecting, changing to rapid-auto-off and dynamic-power doesn’t do anything for feed rate.

Hey Chad,

And what if you lifted the Z minimally each time, as to simalute “on” and “off” of the burner, to avoid these dots?

That would require rewriting software that I didn’t code. It would also probably create dots, and extremely long burn times, as it would be doing this for every single new line in far more complex images that would normally be done, vs in these tests. Just sitting on a spot a split second longer when moving the z up or down would make it darker than then it’s supposed to be. For instance, the amount of time it took to create those dots in my test was a tiny fraction of a second. If it comes to a stop, to go up, there’s a dot. Comes back down before moving again on the X, another dot. Any time there’s a stop, there’s a dot. If it starts lifting before it stops, then it’s an incomplete burn and there would be light spots between every line.

Hey Chad,

I understand.

What I would do if I wanted this controller to work as expected in this application (you said other controllers do), I would write to the author of the code. The problem is, the controller firmware is issued by Onefinity, but Onefinity has not written it, just forked it, and I doubt they know the code in the required detail. And if you ask Joseph Coffland, who wrote the code of the Buildbotics controller, he possibly may tell you he’s not responsible for support for Onefinity firmware. You may however try. He’s the one who knows how the Buildbotics works internally.

I got in contact with Buildbotics, and corresponded with Doug Coffland (nice and helpful guy). It was just as I suspected, with the feed rate being optimized for speed. He even tested out my gcode and confirmed that it does what I said it would. It doesn’t sound like a fast fix either from what I gathered, but they sound pretty busy with upcoming updates on their list. So I guess my best option is to buy a cheap laser engraver frame and get a cheap Arduino CNC Shield or GRBL setup. I was hoping I could just use the Onefinity, but you can’t win them all. Thanks for your help.

Hey Chad,

I thank you very much for reporting this back!

1 Like