Raster Gcode



  • Testing Duet 2 for laser engraving. Speed is slower than expected. So slow that I suspect it may just be a setting I am missing or the way Duet reads interprets the code vs GRBL-LPC.

    Below is a snip of what our code looks like. First part is a series of rotary cuts which runs as expected. The next is the the engraving of dots on the rotary and it just slows stutters to a crawl. Looks like the movement stops at each "dot" to be etched. Hoping someone can chime in with suggestions. Grbl-lpc runs this pretty smoothly

    Running the latest firmware with laser mode turned on.

    G92 X0 A0
    ; Air Assist
    ; Exhaust
    M3 ; Switch tool on
    G1 A -360 X-0.35 S0 F18000
    G1 A 0 X-0.35 S0 F18000
    G1 A 360 X-0.35 S750 F18000
    G1 A 720 X0.35 S0 F18000
    G1 A 1080 X0.35 S750 F18000
    G1 A 1440 X0 S0 F18000
    G1 A 2880 X0 S750 F18000
    G1 A 3960 X0 S0 F18000
    M5 ; Switch tool off
    G0 X6 ; 6mm Rod Cap Offset
    G92 X0 A0
    G21
    G90
    M3
    G0X0A0
    G1 F100000 S0
    G0 A1.0000 X0.0028 S0
    G1 A2.1459 X0.0028 S1000
    G0 A6.8065 X0.0190 S0
    G1 A7.9524 X0.0190 S1000
    G0 A12.6129 X0.0351 S0
    G1 A13.7588 X0.0351 S1000
    G0 A18.4194 X0.0513 S0
    G1 A19.5653 X0.0513 S1000
    G0 A24.2258 X0.0675 S0
    G1 A25.3717 X0.0675 S1000
    G0 A30.0323 X0.0836 S0
    G1 A31.1782 X0.0836 S1000
    G0 A35.8387 X0.0998 S0
    G1 A36.9846 X0.0998 S1000
    G0 A41.6452 X0.1160 S0
    G1 A42.7911 X0.1160 S1000
    G0 A47.4516 X0.1322 S0
    G1 A48.5975 X0.1322 S1000
    G0 A53.2581 X0.1483 S0
    G1 A54.4040 X0.1483 S1000
    G0 A59.0645 X0.1645 S0
    G1 A60.2104 X0.1645 S1000
    G0 A64.8710 X0.1807 S0
    G1 A66.0169 X0.1807 S1000
    G0 A70.6774 X0.1968 S0
    G1 A71.8233 X0.1968 S1000
    G0 A76.4839 X0.2130 S0
    G1 A77.6298 X0.2130 S1000
    G0 A82.2903 X0.2292 S0
    G1 A83.4362 X0.2292 S1000
    G0 A88.0968 X0.2454 S0
    G1 A89.2427 X0.2454 S1000
    G0 A93.9032 X0.2615 S0
    G1 A95.0491 X0.2615 S1000
    G0 A99.7097 X0.2777 S0
    G1 A100.8556 X0.2777 S1000
    G0 A105.5161 X0.2939 S0
    G1 A106.6620 X0.2939 S1000
    G0 A111.3226 X0.3100 S0
    G1 A112.4685 X0.3100 S1000
    G0 A117.1290 X0.3262 S0
    G1 A118.2749 X0.3262 S1000
    G0 A122.9355 X0.3424 S0



  • This post is deleted!


  • Config.g below

    ; Configuration file for Duet WiFi (firmware version 3)
    ; executed by the firmware on start-up
    ;
    ; generated by RepRapFirmware Configuration Tool v3.1.4 on Tue Jul 21 2020 12:06:50 GMT+0100 (British Summer Time)

    ; General preferences
    G90 ; send absolute coordinates...
    M83 ; ...but relative extruder moves
    M550 P"LSS LASER" ; set printer name

    ; Network
    M552 S1 ; enable network
    M586 P0 S1 ; enable HTTP
    M586 P1 S0 ; disable FTP
    M586 P2 S0 ; disable Telnet

    ; Drives
    M569 P0 S1 T0 ; physical drive 0 goes forwards

    M569 P5 S1 R1 T5 ; external A axis
    M569 P6 S1 R1 T5 ; external X axis

    ;M584 X0 A5
    M584 X6 A5 ; set drive mapping

    M350 X16 A16 I0 ; configure microstepping with interpolation

    M92 X125.980 A44.4444 ; set steps per mm
    M566 X400.00 A400 ; set maximum instantaneous speed changes (mm/min)
    M203 X4000.00 A80000 ; set maximum speeds (mm/min)
    M201 X400.00 A400 ; set accelerations (mm/s^2)
    M906 X400 I0 ; set motor currents (mA) and motor idle factor in per cent
    M84 S1 ; Set idle timeout

    ; Axis Limits
    ;M208 X-5 Y0 Z0 S1 ; set axis minima
    ;M208 X2000 Y205 Z200 S0 ; set axis maxima

    ; Endstops
    ;M574 X1 S1 P"xstop" ; configure active-high endstop for low end on X via pin xstop
    ;M574 Y2 S1 P"ystop" ; configure active-high endstop for low end on Y via pin ystop

    ; Laser Mode
    M452 C"bedheat" F5000 S1

    ;No home
    M564 H0
    M564 S0


  • Moderator

    @infamous_panda said in Raster Gcode:

    M566 X400.00 A400 ; set maximum instantaneous speed changes (mm/min)
    M203 X4000.00 A80000 ; set maximum speeds (mm/min)
    M201 X400.00 A400 ; set accelerations (mm/s^2)

    I'd say it's your low speed, jerk, and accel settings holding you back.

    @infamous_panda said in Raster Gcode:

    G1 F100000 S0

    Your gcode tries to set a very high feed rate, but your X axis is limited to 4000mm/min.

    I don't know what your kinematics are, so I can't venture what values you should use, but try doubling them and test and double again and test again if still too slow.

    You also only have an X and A axis, which I find a little odd, but I don't know what machine this is.

    You're also only setting a motor current for X but not A.


  • administrators

    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.



  • @Phaedrux said in Raster Gcode:

    @infamous_panda said in Raster Gcode:

    M566 X400.00 A400 ; set maximum instantaneous speed changes (mm/min)
    M203 X4000.00 A80000 ; set maximum speeds (mm/min)
    M201 X400.00 A400 ; set accelerations (mm/s^2)

    I'd say it's your low speed, jerk, and accel settings holding you back.

    @infamous_panda said in Raster Gcode:

    G1 F100000 S0

    Your gcode tries to set a very high feed rate, but your X axis is limited to 4000mm/min.

    I don't know what your kinematics are, so I can't venture what values you should use, but try doubling them and test and double again and test again if still too slow.

    You also only have an X and A axis, which I find a little odd, but I don't know what machine this is.

    You're also only setting a motor current for X but not A.

    Yes this is setup on a test bed . We have an industrial laser with that is a dedicated rotary for cutting and marking cylinders. The A axis is an external motor. I trying to vet alternate controllers before taking off grbl-lpc.

    The controller does not know the diameter of the workpiece so we have to enter very high speeds for small diameter rods to keep the same surface speed as larger diameter parts.

    I multiplied the jerk and acceleration to 3600 and it's a little better but the the main problem is that the machine seems to want to stop at every "pixel" instead of moving continuously.



  • @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.



  • 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

    2a897831-75d1-4d8b-bbc9-e252ad66d833-image.png

    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.


  • Moderator

    @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.



  • @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.


  • Moderator

    I understand. Hopefully the improvements mentioned by DC42 will help.

    I assume you're using RRF3 at the moment? It may be worth trying the new beta releases.



  • @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.



  • 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?


  • administrators

    @infamous_panda , the code you posted earlier did not include any M3 commands, except for the one at the beginning (which RRF does not need). Why then are you saying that coming to a stop when M3 is executed is a problem?

    Using the S parameter on G1 commands is the recommended way of driving a laser with RepRapFirmware. Changes in the S parameter do not cause the system to wait for movement to stop.



  • 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.



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


  • administrators

    @infamous_panda, send me a sample file and I will try it on one of my machines.



  • @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.


  • administrators

    Thanks for your file. It may be a few days before I get to try it as I have some other work to finish first.



  • @dc42 I accept that gratefully. Thanks!



  • @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


  • administrators

    OK, will do.


  • administrators

    In your speed test file, is A a rotary axes, and is the amount measured in degrees?

    Please post your config.g file. [EDIT: I just found that in your earlier post.]


  • administrators

    I have taken a look at your speed test file and config.g, and I can see some problems:

    1. RRF will not recognise the F100000 line. I suggest you change it to G1 F100000 as I did for my tests.
    2. X is alternately moving by a small amount and stationary. This means that the speed will be entirely dependent on the X axis jerk and acceleration settings. Your acceleration and jerk settings are low.
    3. The A speed is constantly changing, because you are alternately moving just A and then X and A. So the A acceleration and jerk matter too.

    My current internal build of RRF for Duet WiFi completes simulation of your file in 1 min 36 seconds, and predicts execution time of 2h 20min. This confirms that the Duet is processing the file quickly but your acceleration and jerk settings cause it to execute slowly.

    A few more data points:

    • Changing the jerk policy from 0 to 1 reduces the predicted execution time to 1h 1m
    • Then increasing the allowed X and A jerk to 1000, and increasing X and A acceleration to 3000 reduces the predicted time to 21min

    Your test file is not representative of the engraving you are trying to do. I suggest you generate up a test file that only moves X once per revolution of A.



  • 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.


Log in to reply