Using variables with M584 doesn't work

CarlosR

@chrishamm I declare 3 variables and assign them 3 different values (integers):
var driverZero = 20
var driverOne = 21
var driverTwo = 22

Tried:

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:

chrishamm

@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.

CarlosR

@chrishamm

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.

chrishamm

@carlosr No, it does not.

Marcossf

@chrishamm @dc42

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?

chrishamm

@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.

Marcossf

@chrishamm Thank you very much. We'll wait anxiously for version 3.4 b2

dc42

@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}

CarlosR

@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.

dc42

@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.

CarlosR

@dc42 It sounds great. Thank you!

Marcossf

@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.

CarlosR

@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

@carlosr

 M584 E{20.0, 21.0,22.0}

didn't work either

dc42

@carlosr have you verified using M115 that you really are running firmware 3.4beta2?

Marcossf

@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.

dc42

@carlosr we have confirmed that this is a problem. It will be fixed in the next 3.4beta release.

Marcossf

@dc42 said in Using variables with M584 doesn't work:

@carlosr we have confirmed that this is a problem. It will be fixed in the next 3.4beta release.

Do you have an estimated date when version 3.4 will be released? We had to stop the project due to the problem of the use of variables with 3.4.0b2 and SBC.

dc42

@marcossf said in Using variables with M584 doesn't work:

@dc42 said in Using variables with M584 doesn't work:

@carlosr we have confirmed that this is a problem. It will be fixed in the next 3.4beta release.

Do you have an estimated date when version 3.4 will be released? We had to stop the project due to the problem of the use of variables with 3.4.0b2 and SBC.

I can provide you with a preview build if you like. Which Duet are you using?

Marcossf

@dc42 We are using Duets 6HC, 1LC and 1XD boards, as shown in the versions above, in SBC mode.

If you can anticipate the new beta release, @CarlosR can continue developing the configuration for this machine. So, we will also see other possible problems that we will undoubtedly find after that step.

Obviously it will be delivered to the client when it is at least a stable version, hopefully 3.4 soon.

Thanks!