conditional gcode - are these bugs?

[dc42]

The second issue has come up previously with IP addresses. I have it on my list to allow IP and MAC addresses to be compared directly with strings.

[zombiRon]

It appears that the WiFi module doesn't actually become active until config.g has been processed. Which means that I can't select config based on which duet device is running. I was hoping the MAC address being unique would be a good identifier.

Is there any other unique identifier I can query during config.g?

here is the example code I've been trying

; config.g - Configuration file for Duet WiFi
; executed by the firmware on start-up

; General preferences common to all machines
M81
M575 P1 S1 B115200
G90	
M98 P"startNetwork.g"
M400
while true
	if iterations == 30
		break
	G4 S1
	echo network.interfaces[0].mac
if { network.interfaces[0].mac ^ "M" } == { "a5:a5:a5:a5:a5:a5" ^ "M" }
	echo "Network device not enabled"
elif { network.interfaces[0].mac ^ "M" } == { "bc:00:00:00:00:00" ^ "M" }
	M98 P"MACHINES/3DPrinter.g"
elif { network.interfaces[0].mac ^ "M" } == { "b4:00:00:00:00:00" ^ "M" }
	M98 P"MACHINES/CNC.g"
else
	M552 S-1
	G4 S5
	M552 S0
	G4 S1
	M587
	echo "Please Configure WiFi Access Point with"
	echo "    M587 S""SSID"" P""p4ssW0rd"""
M501

startNetwork.g looks like this

M552 S1								; Enable network
M586 P0 S1							; Enable HTTP
M586 P1 S0							; Enable FTP
M586 P2 S1							; Enable Telnet

Originally the network start code was inline in config.g but I moved it into another file hoping it would allow the WiFi module to be triggered while it switched files.

You can see with the 30 second delay the WiFi module doesn't come alive until after no matter how long it waits, I've had it wait 5 minutes and still nothing.

Am I right in thinking the processing of config.g is before the main program loop and communication with the module happens after?

[A Former User]

The M552 command in config.g is defered until the end of the file by design.

But I'm sure we've seen people enabling it explicitly in config.g. Maybe you have to reset it with M552 S-1 before M552 S1 or maybe thats been changed in a recent version.

[zombiRon]

@bearer any idea why it's deferred? Only thing I could think of is to allow the firmware recovery of the WiFi module with M997, but then this is just a simple ordering of commands in the file. I could understand that if the config was not guaranteed to be processed in any order but we have commands used in config.g which must be in a particular order already. Add to that if files were processed out of order; 3D printing wouldn't be possible.

I noticed in another post M552 commands are deferred since you mentioned it, but in them posts they were interlaced with G4 wait commands, so how does it know to defer them too? This would lead to inconsistent behaviour.

If it's by design then it must have a reason; hardware implementation, some blocking I/O or a race condition?? I wonder if the WiFi module has direct access to the SDCard, this would make sense.

[A Former User]

dc42 would know, I can't say I recall any specific reason being given. (unless it boiled down to preventing M578 overriding the ssid setting on every boot and wearing out the flash)

on the other hand, I know I've bypassed the deferral in an older version of RRF, much in the same manor as you're trying, just without M98 and mulitiple files.

[dc42]

@zombiRon said in conditional gcode - are these bugs?:

Is there any other unique identifier I can query during config.g?

25/07/2020, 09:28:32 	echo boards[0].uniqueId
2X88B-BD6P9-F65J0-401F8-M603Z-ZLB9F

[zombiRon]

@dc42 great, thank you. I never looked in the boards section, assumed it was for expansion / tool boards.

Now I can leave out all of the logic and just include a config if it exists, which means I can have a single SD image for both machines.

M98 P{"MACHINES/" ^ boards[0].uniqueId ^ ".g"}

[dc42]

@zombiRon said in conditional gcode - are these bugs?:

Should I be able to do this? if not can it be implemented please?

T{ state.previousTool } P0

This is now supported. It will be live in 3.2beta.

[zombiRon]

@dc42 Excellent! Thanks very much!

[dc42]

@zombiRon, I've just fixed the comparison of Mac addresses and IP addresses with strings too.

[zombiRon]

@dc42 you're on a roll today

[dc42]

I finally found some time to work on the minor bug list.