Posts made by infamous_panda

So conditional programing and meta commands. What would a common use case for this be?

I am interested in input shaping.

It's been a while.

I have a Tevo little monster (fairly large Delta) upgraded with a Duet Maestro, and it's been reasonably well sorted as far as print quality and reliability for the past couple of years. I have Slic3r profiles and Macros setup that have made running this thing mostly painless.

I have looked but have not found any firmware features that would warrant the upgrade from Rerap 2.05 to the current version of 3. I understand there is quite a bit of work to make sure all the configurations carry over properly.

I'd be interested in features that would improve speed and quality.

@dc42 Thanks, I will have to give this another review

@dc42

Awesome I have laser at home which I would love give Duet another go in the future.

I received a Teensy 4.1 yesterday and using "stock" grbl-HAL was able to achieve a 9:21 time for our test file. I tweaked one setting in the firmware called BLOCK_BUFFER=250 in the planner.h file by increasing the value to 1024 and was able to achieve a stable 50,000 mm/minute etch resulting in a 1:20 time. I left my standard acceleration settings at 400 for both X and A axis.

I am not technical enough to state how this information can apply but it seems that Duet should be capable of this kind of performance. I much prefer working RRF and DWC over grbl but for now I think I have to just reserve it for 3D printing.

Just wanted to provide an update in case this helps in future RRF/Duet development for high speed laser engraving.

@dc42 said in Raster Gcode:

The movement queue has limited length (39 moves on the Duet WiFi)

Is there a useful improvement to this on the Duet 3? Or a way to change this limit?

I am wary of increasing the global acceleration and jerk to get the raster time down. We have other non raster operations and even just jogging which I think can be catastrophic if we tried to accelerate 30kg at the values you tested.

@dc42 said in Raster Gcode:

Your config.g file sets the maximum A speed to 4000 units/min in the M201 command

I thought M203 was max speed. Which we set at 80,000. I'll try setting M201 much higher tonight and test it again

@dc42 said in Raster Gcode:

I can only conclude that either GRBL is not honouring acceleration and jerk (or junction deviation) limits

This may be it. I'll do some digging

@dc42 I am sure you are right and I am failing to communicate some of these technical items to get the proper solution.

The config.g settings I provided are equivalent to our GRBL settings with exception to jerk which I am not sure there is a parameter for that, so I made it the same as acceleration. I actually do not understand the difference between the two.

This file produces real world physical parts in 4 minutes. Not simulation. Why it's different from other controllers/firmware I am trying my best to understand and get it faster.

Thank you so much for your feedback. The new test file is a worse case high density of the engraving we do.

If I understand your comments correctly.

The Duet is imposing some mechanical limitation based on jerk and acceleration settings and the way it interpreting the motion.

The best case would be 21 minutes.

Duet 3 would not improve this.

We run GRBL-LPC currently and this completes in approximately 4 minutes. I have been testing other 32 bit GRBL builds and the result is similar. Feedback from the various developers mention that it may be a bottleneck from the pc based streamer to the controller. I will be looking at a 600mhz arm version this week in hopes that I can get this file to run under two minutes or better.

I am hesitant to increase our jerk and acceleration values since the moving mass of our sled (x axis) and tubes (a axis) can be in excess of 30 kg.

The goal is to accelerate to a constant speed through the etch like a lathe.

I guess I have to put Reprap aside for now.

@dc42

Not sure if you had a chance to run the code we provided yet but if not attached is a different file we put together to "stress test" a few other boards and platforms. If your still willing can you test this file instead so we have an apples to apples comparison.

CONTROLLER SPEED TEST.gcode

@dc42 I accept that gratefully. Thanks!

@dc42 I very much appreciate this. Please see attached.

R001-00 - Copy.gcode

The code has a cut sequence at the beginning and end which seem to work fine. The high speed etching in the main body is what gives me trouble.

I left in M7 M8 M9 M3 M4 M5 commands. I know Reprap does not support all of these but they would be easy workarounds. What we would have difficulty in doing is changing the way our software generates the spiral etch.

For reference this file produces a 20mm diameter short 170mm long rod. We have files that produce 100mm diameter 2000mm long tubes.

I have also tried changing all the G0 moves to G1 with no effect.

Hi @dc42

"M3 M4 M5 or spindle speed Sxxx is altered"

My gcode changes the S parameter in this case to full on and full off at every dot. M3 turns on the laser initially. I am trying to explain sort out why the my movement is starting and stopping throughout the etch. This happens regardless even if I slow down the program so theoretically it's not the processing power that's the issue.

Just a quick question before I give up on this.

Default GRBL

Every time a spindle state M3 M4 M5 or spindle speed Sxxx is altered, Grbl would come to a stop, allow the spindle to change, and then continue.

Grbl's laser mode

1. Prevents unnecessary stops whenever possible

2. Adds a new dynamic laser power mode that automagically scales power based on current speed related to programmed rate.

In Reprap laser mode seems to apply only item #2. Which is why I and some others I have found in my search are experiencing a stutter in our movements. One example below.
https://forum.duet3d.com/topic/12785/duet-2-wifi-performance-for-laser-raster-printing/6

https://www.youtube.com/watch?v=ePAcdSWWiTc&feature=youtu.be&ab_channel=PawelSwitalski

Would it be possible or make a difference at all if I were to somehow map the laser firing to the extruder motors pins?

@Phaedrux

Yes sorry I was not very specific. 3.2 beta 3 just release 4 days ago. I assumed RRF would not be as optimized for this as GRBL but hoping that the faster Duet 3 could make up for it. But likely not since this is looking like a firmware issue.

@Phaedrux said in Raster Gcode:

@infamous_panda said in Raster Gcode:

Increased the speed in the Gcode from F100,000 to F100,000.

Those are the same numbers. Did you also increase the limit in the config.g file? You mentioned increasing jerk and accel, but did you also raise the speed limit?

M203 X4000.00 A80000 ; set maximum speeds (mm/min)

If the limit here is set lower than what you request in the gcode file you won't be able to obtain what you request in the gcode file. So set the M203 limit very high so that you can actually control the feed rate in your gcode file.

I multiplied the jerk and acceleration to 3600

This is still fairly low. Many 3D printers are using accel of greater than 6000 already.

Yes sorry I meant to type F1,000,000

I did try increasing the both the X and A max speed to 100,000 in the config without any benefit. The way our programs move the X axis actually moves very slowly.

I will try higher jerk and accel, however I do not think this is the issue since even at lower speeds (F1000) the motion duet produces seems to purposely start and stop at each "dot" when the intent is to keep the movement constant.

Another issue with increasing these values is that the moving parts of our setup is in excess of 30kg or so. That's why our x moves slowly and we ramp up our speed on the A axis and need to keep it constant throughout the etch.

I have tried a few other things with no improvement

Increased the speed in the Gcode from F100,000 to F100,000. Decreasing it to F1,000 is noticeably slower and still stops at each "dot" position.

Changed all the moves to G0 or G1 so there is no on/off switching for the laser (which is not physically connected anyway).

Turned off laser mode M452

Video below of the test bench.

https://photos.app.goo.gl/SiFXnkDEzYDFqumC9

Video of the GRBL-LPC setup. The rotary is driven by the same motor as in the bench only it's geared 5:1 (the steps/deg is identical for both setups)

https://photos.app.goo.gl/eEXaKqseQXFwaiLj6

Sample of our etch pattern

I assume this is just the way reprap is processing the file that it pauses the motion at each dot? We are moving this machine to a new facility and thought I would take the opportunity to upgrade the controller to Duet 3 hoping that we could push it even faster.

@dc42 said in Raster Gcode:

The speed of Gcode processing has been improved in firmware 3.2beta3 and beta 3.2. We have work planned to support sending data for several pixels in a single GCode command.

David,

Seems like the motion is pausing at every dot to be engraved. Is this just the nature of reprap at the moment. Smoothie and Grbl seem to keep the motion steady regardless if the laser is firing or not.

Maybe it's just the way my code is formatted?

Is the intent in the future to implement single line like smoothie "cluster". I think this would not work with the way our software generates the code.