Topics created by robotsneversleep

@robotsneversleep as @gloomyandy says, one of the major overheads is access to the SD card. The FatFs filesystem used by RRF doesn't include a cache, just a single sector buffer per SD card. I have it on my list to implement a cache (see https://github.com/Duet3D/RepRapFirmware/issues/688) but this isn't high priority, and any improvement on Duet 2 is likely to be marginal because of lack of RAM.

Meanwhile you can keep the overhead to a minimum by:

Not calling macros more than you need to (every M98 command executed has to open the file) Not using loops more than you need to (every 'while' command needs to re-read part of the file when an iteration finishes).

For example, your script contains this:

while iterations < 1 M98 P"statusled/effects/fade.g" D"I" C{global.STATUSLED_RED} M98 P"statusled/effects/fade.g" D"O" C{global.STATUSLED_RED}

You can speed it up by removing the redundant while-clause and by expanding those two M98 calls to fade.g.

T3P3 created this issue in Duet3D/RepRapFirmware open Add LRU caching to FatFS #688

@robotsneversleep Thanks for reporting this, I'm going to fix it in v3.5.2.

@robotsneversleep in the M950 command to declare an LED strip you need to specify whether it is RGB or RGBW because RRF has to drive them differently. Assuming you get that right, if you provide a W parameter but the strip was configured as RGB then that parameter will be ignored.