Using variables with M584 doesn't work
-
@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.
-
@dc42 It sounds great. Thank you!
-
@dc42 We need SBC mode as premise, so as you said to @CarlosR if the variable format its right for us, we will wait for 3.4 version.
We will have a lot of printheads, which need to identify by their CAN ID and the position in their dock, to assign their specific variables (GPIOs, offsets, fans, thermal, leds, etc). Doing it without this variable array would be imposible.
I hope could been released soon.
-
@dc42 Hi, we are testing this with 3.4.0beta2 version, but doesn't work.
We tried:M584 E{var.driverZero+0.0,var.driverOne+0.0,var.driverTwo+0.0}; extruders drive mapping
Where var.driverZero, ..., are integer values (20,21,22)
And we also tried to store the float value itself in an aux variable manually to test if the command recognise the params:
var driverZeroF = 20.0 var driverOneF = 21.0 var driverTwoF = 22.0 E{var.driverZeroF,var.driverOneF,var.driverTwoF}; extruders drive mapping
None of them worked...
-
-
@carlosr have you verified using M115 that you really are running firmware 3.4beta2?
-
@dc42 @CarlosR I've checked the version for you. Hope it can be solved.
9/8/2021 10:15:09 m115 b22 Duet TOOL1LC firmware version 3.4.0beta2 (2021-08-03 10:00:09) 9/8/2021 10:15:06 m115 b21 Duet TOOL1LC firmware version 3.4.0beta2 (2021-08-03 10:00:09) 9/8/2021 10:15:04 m115 b20 Duet TOOL1LC firmware version 3.4.0beta2 (2021-08-03 10:00:09) 9/8/2021 10:15:01 m115 b45 Duet EXP1XD firmware version 3.4.0beta2 (2021-08-03 10:00:36) 9/8/2021 10:14:59 m115 b44 Duet EXP1XD firmware version 3.4.0beta2 (2021-08-03 10:00:36) 9/8/2021 10:14:58 m115 b43 Duet EXP1XD firmware version 3.4.0beta2 (2021-08-03 10:00:36) 9/8/2021 10:14:55 m115 b42 Duet EXP1XD firmware version 3.4.0beta2 (2021-08-03 10:00:36) 9/8/2021 10:14:53 m115 b41 Duet EXP1XD firmware version 3.4.0beta2 (2021-08-03 10:00:36) 9/8/2021 10:14:49 m115 b40 Duet EXP1XD firmware version 3.4.0beta2 (2021-08-03 10:00:36) 9/8/2021 10:14:39 m115 FIRMWARE_NAME: RepRapFirmware for Duet 3 MB6HC FIRMWARE_VERSION: 3.4.0beta2 ELECTRONICS: Duet 3 MB6HC v1.01 or later FIRMWARE_DATE: 2021-08-03 12:42:44
By the way, it's SBC mode.
-
@carlosr we have confirmed that this is a problem. It will be fixed in the next 3.4beta release.