Moving quickly between widely spaces shapes

Suppose I have a workpiece with dimensions 400x700mm and there is a 20mm square cut near each corner. Nothing else.

Is there a parameter in LB or Firmware that controls the traversing speed used when travelling between the widely spaced shapes?

I have a cutting speed of 500mm/min which is pretty slow for traversing 700mm of empty space.
I have whitespace turned OFF because it causes issues with image quality during fill ops. Although, I have not done much testing with modest whitespace values. I usually run fills at around 6000mm/min and tried whitespace at like 15k and didn’t like the quality of the results. Maybe set whitespace at my max typical working speed (~6k)?

This is partially device type and implementation specific.

On typical GRBL machines traversal moves between shapes will be driven with G0 commands which run at rapid rates as defined by max speed ($110-112) in controller.

I believe for Marlin machines traversal speeds can be set with fast whitespace scan.

This assumes typical firmware implementations and may further have variances in behavior by vendor.

Not directly an answer - although you do have whitespeed off and that would be the way to do it - it overrides the rapids speed.

I find, however - when i feel my projects are wasteing too much time with laser moving about doing nothing jumping from point to point - some time on optimization is needed.

Tricky part is this.
Is it a 1 off project or is it a project you will do 100’s of times
if the first, the time spent optimizing isnt worth it. If its a serial job kind of project for sure it does.

Out of curiosity could you post a screenshot of your project so we can take a look?

I’m away from my computer, but I can try to remember to upload something in the morning (~12 hours from now).

The example would be dead simple. A couple small shapes in opposite corners of a large sheet.

I’m thinking in general terms at the moment, so essentially one-off. I do have some designs that I run over and a over. Those are densly nested and highly optimized. Like you said, I also prefer not to spend a lot of time optimizing one-off jobs. The extra couple minutes of job time is far less than the time needed to optimize.

I have noticed this slow traversing on multiple one-off jobs and just wondered if there was a setting or parameter I had overlooked.

PY,
My $110/111 is set at 30000/20000 and the machine most definitely does NOT traverse at those rates. It SEEMS to traverse at the layer cut speed. This machine (Ikier K1) uses non-standard firmware. See more here: Ikier K1 and Atezr L2 "modes". Anybody know what they affect? - #15 by cggorman

Here the risk of losing accuracy for the sake of a few seconds shaved of might be something you have to consider
Rapids motions are quite nasty at exacerbating any little slack of the frame.
Granted, for some jobs might not be that relevant.

I need to test it myself as i am going on memory, but I think GrblHal has a Rapids section that’s usually not exposed on the settings. I know about AlgoLaser firmware, for example - Hal based - you could set if rapids speeds per X and Y.
Will try to dig that up in the morning

Agreed again, Gil. I’m not interested in anything that degrades quality for the sake of speed. But, say, a 5000mm/min traversing speed should be quite safe and much faster in this instance.

I haven’t noticed this behavior on my Algo machine, but I also use it almost exclusively for image engraving, so very few traversals. The Ikier machine is mostly used for cutting, so lots of traversal moves.

1 Like

When you come up with the example scenario, can you save the gcode and post for review? Would like to verify that it’s in fact generating a G0 for those moves.

Will do, PY. In the morning (US time). Thanks to both you and Gil for your time!

1 Like

Sorry to step in.
Could you please do the following test:
.
_tranverse_move_test.lbrn2 (3.8 KB)

  • Before testing confirm the job preview looks like the below picture
  • .Run the above file with 6000mm/m speed and 0% power.
    .
    .
    *Then Run GCode the follwing file.
    image

_tranverse_move_test.gc (397 Bytes)
.

Tanks.

Here is a basic example. Just two layers. One is a tool layer assuming some random pre-fab blank that need four holes cut in the corners. Maybe a bottom side table shelf. It doesn’t matter.

I tried a few things I could think of.

  • It’s not traversing at the cutting speed. It’s a fixed traverse speed regardless of cut speed. Cut at 4000 and traverse is slower than cut speed. Cut at 600 and traverse is faster than cut speed.
  • It’s not traversing at the framing speed. I tried several from 2000-30000mm/min
  • It’s not traversing at whitespace speed. I tried it disabled and enabled with the same speed range as the framing speeds tested above.
  • It’s not traversing at home seek speed. I tried a few.
  • Maybe a few others …
    None of those had any effect whatsoever.

Note: I typically run in “standard” mode (see post linked in earlier reply) which has max rates of 30k(x) and 20k(y), X accel at 2000 and Y accel at 1000. Near as I can tell with a stopwatch, it’s traversing at around 2500mm/min in that mode.

Since I know Ikier is playing a little loose with grbl, I decided to see what happened when I changed to “fast” mode. This mode substantially increases max rate and X accel. Y accel is unchanged.

***In “Fast” mode, it FLIES around the bed. Far too fast, IMO. I adjusted the parameters for both fast mode and standard mode. Traverse did not change, so it’s not a simple multiple of the max rate. It seems to be a fixed speed determined by the mode selection.

I poked around the parameters and didn’t see anything obvious that would control rapid motion.

I tamed down the fast mode settings some and got it traversing in a range that seems reasonable but testing must be done to confirm no corner ringing has been introduced.

As PY requested:


slow traverse.gc (500 Bytes)

I can confirm that G0 is being used for the traversals.

Your findings corroborate that this is being firmware driven. My guess would be that it’s a fraction of the max speed. So if Fast mode attempts to run at full max speed then perhaps “Standard” is 10 or 20% of max.

Check to see if you have any non-standard GRBL parameters that could potentially represent a multiplier or percentage value.

Interesting no F value is given on the G0


So it defaults to the Layer C00 initial F600

Odd! now i am curiouse!

The only parameter I can’t identify is $34. Currently set to 10. I have been hesitant to try altering it but 10% does seem to jive.

Anybody think of any harm I could cause by trying, say $34=20 or $34=1?

That’s likely to be related to PWM values. It’s unlikely to cause harm to change it. Either or your choices would likely be fine.

Just revert back if it doesn’t end up working.

Tried both =1 and =20 with both fast and standard modes. No change anywhere I could see. I put it back to =10.

Try changing the max speed settings. If the rapid moves are derived from that it should function to also change those.

If that doesn’t work, it’s entirely possible that those speeds are hard-coded or hidden behind an undocumented setting. Doesn’t the machine use certain M-commands for autofocus and crosshair function?

Try your GCode file edited.
_EDITED_slow traverse.gc (509 Bytes)

I got busy and had to step away for a while.

I DID try changing max rates (from 30k to 50k) with no noticable effect.

Best guess is it’s driven by some fixed value, behind the scenes in the firmware.

Parsec, I’ll try to remember to test your g-code later this week when I get time. Weekdays are real busy for me.

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