conditional gcode - are these bugs?



  • Re: Invitation to share your conditional GCode scripts

    Hi, really quick couple of questions...

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

    T{ state.previousTool } P0
    

    Also, when I query the mac address of the interface the returned value is not a string, and so it fails evaluation in an if statement like so

    if network.interfaces[0].mac == "a5:a5:a5:a5:a5:a5"
    

    or is the output from this used elsewhere so the "type" must be retained??


  • administrators

    @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
    

    That's not supported, because expression evaluation is not supported when evaluating the command number following the command letter G, M or T. I can see that it could be useful after T, so I will consider implementing it

    Also, when I query the mac address of the interface the returned value is not a string, and so it fails evaluation in an if statement like so

    if network.interfaces[0].mac == "a5:a5:a5:a5:a5:a5"
    

    That doesn't work because MAC addresses (like IP addresses) have a special type that cannot be directly compared with strings. But this or similar should work:

    if network.interfaces[0].mac ^ "Q" == "a5:a5:a5:a5:a5:a5Q"
    

    By concatenating the MAC address with a string (in this example, "Q") you force it to be converted to a string.



  • @dc42 Wow that was fast!
    Thanks, I tried many combinations to force the type to be cast, not sure how I missed that one, sorry.


  • administrators

    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.



  • 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?



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



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


  • administrators

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

  • administrators

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



  • @dc42 Excellent! Thanks very much!


  • administrators

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



  • @dc42 you're on a roll today 😁


  • administrators

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


Log in to reply