conditional gcode - are these bugs?
-
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""" M501startNetwork.g looks like this
M552 S1 ; Enable network M586 P0 S1 ; Enable HTTP M586 P1 S0 ; Enable FTP M586 P2 S1 ; Enable TelnetOriginally 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?
-
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-1beforeM552 S1or maybe thats been changed in a recent version. -
@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.
-
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.
-
@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 -
@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"} -
@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 } P0This is now supported. It will be live in 3.2beta.
-
@dc42 Excellent! Thanks very much!
-
@zombiRon, I've just fixed the comparison of Mac addresses and IP addresses with strings too.
-
@dc42 you're on a roll today
-
I finally found some time to work on the minor bug list.