Syntax Check for "and" vs && (SBC mode)

davidjryan

Pi 4, 4GB, latest DuetPi image of bookworm
6HC @ 3.5.4
SBC mode
CNC mode

When I run this code in a macro, bBool1 has to be true and bBool2 has to be false in order for function1.g to run:

set global.bBool1 = true
set global.bBool2 = false

if global.bBool1 && !global.bBool2
	M98 P"functions/function1.g"

When I make a typo by substituting "and" for && and run this code, only bBool1 has to be true in order for function1.g to run. Even if bBool2 is true, function1.g will run.

set global.bBool1 = true
set global.bBool2 = true

if global.bBool1 and !global.bBool2
	M98 P"functions/function1.g"

I'm guessing the interpreter is evaluating bBool1 and ignoring everything after the "and" because the "and" isn't a valid meta command/keyword. This code doesn't get flagged for the use of "and" instead of &&, the macro keeps running after this code.

Is it possible to add "and" to the syntax check when running and stop the macro from further executing like other syntax errors? Or at least flag it in the DWC console with a message "Hey Python nerd, you're trying to use and instead of &&. Switch to a real language like C++ will ya?!"

I would guess "or" instead of || would result in a similar issue.

Yes, in the end, it's operator error. It's just that this operator has some mental deficiencies that require automated assistance every now and then.

dc42

@davidjryan I just tested in standalone mode using firmware 3.6.0-beta.4 and it fails with an error message as expected. So either it's a bug in 3.5.x that is fixed in 3.6 or it's specific to SBC mode. I will investigate further.

davidjryan

@dc42 I tested the code in 3.6.0-beta4 and it did not flag the use of "and"

Pi 4, 4GB, latest DuetPi image of bookworm
6HC @ 3.6.0-beta4
SBC mode
CNC mode

testand.g

var bBool1 = true
var bBool2 = true
 
if var.bBool1 and !var.bBool2
	M98 P"function1.g"

function1.g

echo "function1"

results in:

Result is the same when using var or global

dc42

@davidjryan thanks, we've established that it's specific to SBC mode. We've implemented and tested a fix in RRF, which will be in the next public build. Thanks for reporting this.