@DonStauffer I have now reproduced this and created https://github.com/Duet3D/RepRapFirmware/issues/1020 and https://github.com/Duet3D/RepRapFirmware/issues/1021.

dc42 created this issue in Duet3D/RepRapFirmware closed Incorrect processing of # operator when operand is an element of an array of arrays #1020 dc42 created this issue in Duet3D/RepRapFirmware closed Parsing error when using ternary operator #1021

@dc42 Both of these produce errors.

;exists(#var.x) ;exists(var.x[0]) var x = {1,2} var y = 3 ; Method 1 if exists(#var.x) ; expected an identifier echo "exists(#var.x)" else echo "! exists(#var.x)" if exists(#var.y) echo "exists(#var.y)" else echo "! exists(#var.y)" ; Method 2 if exists(var.x[0]) echo "exists(var.x[0])" else echo "! exists(var.x[0])" if exists(var.y[0]) ; Cannot index into variable or parameter 'y^' of non-array type echo "exists(var.y[0])" else echo "! exists(var.y[0])"

@dc42 Looks like the roto tool board was running an older version (3.5.0 rc1) of the firmware. After updating the firmware to the latest 3.5.2 everything works as expected.

@dc42 - Thanks for confirming Ian's response. I'm definitely going to add a segment to my tfree.g macros to adjust my tool Z offset by the baby steps amount and reset the baby steps to zero. This way my users will be able to fine tune each tool as it's first layer is printed. Of course, this give no help if a tool is not used on the first layer, but subsequent layers should be more forgiving of tiny errors.

@Makergal3D If you want to set the heaters individually, then ideally using M568 in your start gcode in place of M104 is the way to do this. I understand that support for this is not yet implemented in slicers, let alone a way to capture that a material ("filament") profile has more than one temperature specified.

Creating three extruders in the slicer, with a different profile for each heater and then basing the conditional start gcode around this:
https://forum.prusa3d.com/forum/prusaslicer/starting-gcode-for-multiple-extruders/#post-404908
might help? For example:

M568 R{first_layer_temperature[0] -50}:{first_layer_temperature[1] -50}:{first_layer_temperature[2] -50} S{first_layer_temperature[0]}:{first_layer_temperature[1]}:{first_layer_temperature[2]}

(note this is untested!)

Alternatively there may be a way to handle this using the built in "filaments" system in RRF:
https://docs.duet3d.com/en/User_manual/Reference/DWC_filaments

@gloomyandy - thanks for your thoughts on this topic. I would really like to understand the state changes in the system through the tpre and tpost execution steps. It's not clear (at least to me) in the documentation.

My advantage in putting all my operations into tpost is slight - simplification of the macros I need to maintain, and teach to others to maintain. And I'm one of those people that wants to understand why.

Reading the current documentation, it isn't clear that tpre operates with state.currentTool = -1, which I believe is required for moves to be in machine coordinates and not tool coordinates (hence my obtuse question about "selected"). As a result, in my tpre, I preface all moves with G53 to force machine coordinates to be used.

And about aborting tool changes and the system assuming tpre has completed - I currently have no abort logic, though I've been thinking about adding some inputs to detect successful tool capture. I'll need to think some more about what to do in an abort situation. These may be the good reason to use tpre.

@Duet_Science_Application said in Getting metadata commands to loop at different rates:

one loop designed to run at half a second, the other ideally over a full second.

Why not have a single loop that runs every half second, and within that have an if-command that executes its body on alternate iterations?

Just when I think I know the meta commands...

abort <opt-expression>

This causes all nested macros and the current print file (if any) to be terminated.

RTFM. Thanks @jay_s_uk

@dc42 That will be a great addition! Thanks for all your work.

@DonStauffer tools[].axes[] has a bitmap type in the OM, which is essentially a set of values all of which lie within a certain range. RRF meta GCode doesn't really support set types, but in order to allow you to delve into it, RRF lets you use the # operator on it (to ask how many bits are set) and to use the [] indexing operator to retrieve the bit numbers in ascending order.

@dc42 I got rid of about half my array elements by restructuring it, and for the first time, 100% of the reboots stopped. So fundamentally, it seems like I have between 1kB and 1.5kB of global space to play with total, or else I start getting a mess. In other words, I was running out of memory, but instead of sending a message, it slammed into a brick wall. So all the other stuff was probably just rearranging where and when the memory ran out.

@chrishamm said in Conditional Loops running slow after SBC addition:

M576 S0

That worked perfectly, thank you! I was afraid the issue might have had to do with how the SBC sends commands to the Duet. Startup script is running normally now.

@dc42 I was able to free up 112 integers from one of the global arrays by combining RGB values into single integers. The spontaneous rebooting stopped as far as I can tell. Through it all I've never again seen the array corruption, so I'm confident your fix solved that. Things are running fine now. Thanks for everything!

@droftarts said in manual/Tuning/Tool_changing:

@stuartofmt from the 3.5 release notes https://github.com/Duet3D/RepRapFirmware/wiki/Changelog-RRF-3.x :

When RRF needs to deploy a Z probe ...

Ian

I'll take another look as soon as I get the chance. This was not the behavior in one of the 3.5 rc's - hence the workaround. I've not checked for a while - will report back as soon as I can.

@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

Thank You! I updated both the toolboard and the mainboard and all problems disappeared.

@DonStauffer thanks for reporting this. It's not intended behaviour. I have created https://github.com/Duet3D/RepRapFirmware/issues/1003.

dc42 created this issue in Duet3D/RepRapFirmware closed Bug: can't create a variable with the same name as a parameter #1003

@droftarts , Yes I realize that now. I found feature request #959 and want to add my voice to the ones requesting this modification. I feel this change could add significant flexibility to M291 by opens up many different options regarding how a query is responded to, or not. Note that is my case I don't even need or want the extra cancel box, but I would live with it if I could get the cancel/timeout to work the way I want it to.

My reason for this request is that I want to reduce the amount of machine cycling as I call macros that contain activity that has already been done and has set flags as to have been completed. The idea is to go ahead and do the extra cycling if there is no response to the query, as a safety mechanism.

@T3P3Tony Thanks, Tony!
I have the longer form implemented and all works well.