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.
Best posts made by infamous_panda
-
RE: Raster Gcode
Latest posts made by infamous_panda
-
RE: Updating firmware from 2 to 3 worhwhile?
So conditional programing and meta commands. What would a common use case for this be?
I am interested in input shaping.
-
Updating firmware from 2 to 3 worhwhile?
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.
-
RE: Raster Gcode
Awesome I have laser at home which I would love give Duet another go in the future.
-
RE: Raster Gcode
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.
-
RE: Raster Gcode
@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.
-
RE: Raster Gcode
@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
-
RE: Raster Gcode
@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
-
RE: Raster Gcode
@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.
-
RE: Raster Gcode
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.