Using variables with M584 doesn't work
-
@owend said in Using variables with M584 doesn't work:
I don't have multiple extruders
The problem is the way multiple extruders are configured, i think DSF doesn't understand well the "M92 E--:-- " way of configuring them.
-
@cosmowave Yes, we have a 1LC v1 extension board.
-
@carlosr said in Using variables with M584 doesn't work:
@owend I think the problem is when using ":" to concatenate different extruder drives. The command only detects the first value. When using only one value, without the ":" character, it works.
Then you can write the commands in separate lines! Or not?
In the gcode-wiki is written:
In RRF3, M584 works the same way as in RRF2, with exception that on Duet 3 the driver on expansion boards are assigned with <board address>.<driver number>. -
@cosmowave said in Using variables with M584 doesn't work:
Then you can write the commands in separate lines! Or not?
No.
-
@cosmowave If you write the command in different lines, the first drive value is overwritten.
-
@ja ok... yes. M92 is not possible in single line.
-
@cosmowave Can it be that there is a problem of the format of your variable?
e.g. the variable is a string, but M92 needs a "float"... -
@cosmowave as @JA said, i think DSF doesn't understand well the "M92 E--:-- " syntax when using variables.
-
-
@carlosr Array expressions aren't yet supported by RRF in SBC mode but something like
M584 E{123:{myVar}}
should be already passed to RRF correctly. I'll discuss with dc42 how we can add support for this. -
@chrishamm I declare 3 variables and assign them 3 different values (integers):
var driverZero = 20
var driverOne = 21
var driverTwo = 22Tried:
- M584 E{var.driverZero}:{var.driverOne}:{var.driverTwo}
- M584 E{{var.driverZero}:{var.driverOne}:{var.driverTwo}}
- M584 E20:{var.driverOne}:{var.driverTwo}
And none of them worked. The following commands show this error message:
-
@carlosr As I said RRF does not support array expressions in SBC mode yet, although
M584 E{{var.bla}:..}
would be passed through correctly. Before this can work further improvements in RRF are required. -
I think I'm not understanding correctly (i'm not an english speaker).
Do you mean that M584 E{{var.bla}:..} should work right now (in 3.3 version)? Because it isn't.
-
@carlosr No, it does not.
-
When is the use of arrays expected to be implemented in SBC mode? In 3.4 version?
This is what we need to be able to fully operate our machine with the dynamic selection printheads.Why are there such differences in functionality between standalone and SBC with the same version?
@CarlosR tried to make it work with other methods but a lot of functionality is lost. (By the way, he's in our developing team).
Would the use of array variables work in version 3.3 in standalone mode, or would it not work either?
-
@marcossf The upcoming version v3.4-b2 will support array expressions in the form
M584 E{123,456,global.paramXYZ}
both in standalone and SBC mode. The reason this already worked in standalone is because RRF parses text-based G-codes whereas DSF in SBC mode reads them and then wraps them into binary format for performance reasons. -
@chrishamm Thank you very much. We'll wait anxiously for version 3.4 b2
-
@marcossf to be clear, in 3.3 standalone mode (but not SBC mode) you can do things like this:
M92 E{var1}:92:{var2}
i.e. any individual value can be replaced by an expression. In 3.4beta2 that will no longer be allowed, but in both standalone and SBC mode you will be able to use this:
M92 E{var1,92,var2}
-
@dc42 Last question about this topic from my side:
I think the critical command would be M584 since we are writing our drives as 20.0, 21.0, 22.0.
How would this be stored as variables?
We are thinking on storing only the integer value, and add the .0 board to each of them:M584 E{{var1}.0, {var2}.0, {var3}.0}
Thank you very much.
-
@carlosr said in Using variables with M584 doesn't work:
M584 E{{var1}.0, {var2}.0, {var3}.0}
I think this would work:
M584 E{var1+0.0, var2+0.0, var3+0.0}
The +0.0 converts the value from integer to float, and in 3.4 we allow a float that is close to an exact multiple of 0.1 to be converted to a driver ID.