Multi Extrusion "Intelligence" in RRF

raykholo

S3D (I'm on 4.0) has a few pitfalls in multi extrusion such as putting the toolchange script in extra places (like right below the first T0 at the beginning of a print) and doing the prime pillar in the wrong order.

Because of this, I switched to using a Duet on my Y splitter machine, because RRF handles its own toolchange scripts and the firmware actually knows which tool is active at any given time, hence no unneeded toolchanges are executed.

I would like to add a purge bucket to my machine so that the prime pillar is no longer needed, and while I could hardcode the following, it would be nice if RRF could have a little more internal intelligence:

Purging: I currently print a prime pillar - for some colors, 30mm of purge is enough, for others, 50+ is needed. Can I put a gcode comment for a variable that can be referenced in the scripts (maybe also in macros, as macros can be called to run during a job, but macros can also be called to run while idle or someone can not put a variable definition in their gcode, so maybe when I call my gcode there should be a defined value, and a default value as backup.

Example
I put into the start script in S3D
;purge_amount 45

I currently have G1 E45 F300 in my tpost, now I could have G1 E[purge_amount] F300
or with the fallback value the structure would have IFDEF purge_amount, purge_amount, else, 50 with any syntactic characters omitted for clarity

Which brings me to my next point:
Conditional statements in the scripts.

Let's say I want to purge all my active toolheads, but only for the ones that are enabled at this time/ for this print.
This would be a twofold one, because first I need a variable such as tool#_enabled (enabled meaning that a G10 P# R# S# line has been called) and then, borrowing from S3D syntax, I would do something in my start script like:

G0 X230 F600 ;go to dump area
{IF TOOL0ENABLED}T0 G1 E10 F300
{IF TOOL1ENABLED}T1 G1 E10 F300

and so on, with support for other variables…

Very much aware of exactly how much can go wrong with introducing these variables (no pun intended) in the mix (more puns?), and that any other firmware maker would dismiss this outright and say "the board just takes gCode, you need to do all this in your slicer/ start scripts there", but figured I'd bring it up and see if anyone else wants this or has any thoughts on the idea.

dc42

Currently there is no support for variables in GCode commands, or conditional commands or looping; but adding all of these is under consideration.

BMMal

@dc42:

Currently there is no support for variables in GCode commands, or conditional commands or looping; but adding all of these is under consideration.

This is interesting to me. I think it could aid in keeping machines more Gcode agnostic. As part of a response to a question about getting the machine to wipe the tool head off, I detailed how I currently go about getting Kisslicer and RRF to work together so that I don't have to remember nearly as many details about settings: https://www.duet3d.com/forum/thread.php?id=3121#