Some Observations / Questions / Suggestions



  • First off - a big THANK YOU to @gtj0 for this great piece of work.

    I am working on creating a panel-like config specifically for Raspberry Pi with 7" TFT. Along the way I have encountered some possible "oddities". Of course - these may simply reflect my lack of knowledge / understanding. For clarity - I do not have any Dueui code on the Duet. It is all deployed in a separate http server (nginx).

    Observation 1 - Test Mode with Duet turned off
    In some cases - when in test mode with duet turned off, the desired output does not occur. For example: this value for a label label statement - does not display anything. But works fine otherwise.

    "value": "Bed Temp:  ${state.temps.bed.current.toFixed(1)}"
    

    Question 1 - Can this be fixed ? Maybe the Duet calls of this type returning "" if in test mode ?

    Observation 2 - Strict JSON Syntax
    I notice that the config.json (and maybe .js files) do not follow strict json syntax e.g. }, (i.e. comma after the last element in an array). I also see comments included in the config.json file.
    Question 2 - Is this by design ? Can we rely on this syntax going forward - or should it be avoided (e.g. if the json parser is changed at some future time)? Specifically - I like the idea of commenting my config.json file but do not want to go "all in" if I have to later go "all out" 😖

    Observation 3 - Use of cookies for settings.
    I (and I suspect others) like to clear out my browser after each session which means that the settings for Dueui are lost. Same thing if accessing Dueui from another browser.

    Suggestion 3 - Allow for a setting file that, if present, is used - instead of relying on the existence of a cookie.

    Observation 4 - It seems like calls to macros can time out or not complete
    This is a bit strange - in a "Home All" command, I called /sys/homeall.g. I have an Ender 5 with a BLTouch. When the bed is some way off the BLTouch - the home command fails as the bed is still being raised. BUT - if instead I issue a G28, it works as expected. This was repeatable - note that my homeall.g itself is three macro calls :

    M98 P"homex.g"
    M98 P"homey.g"
    M98 P"homez.g"
    

    Question 4 - Any idea why this is happening? Something to do with Dueui polling ? In any case it may be a useful "be aware".



  • @stuartofmt said in Some Observations / Questions / Suggestions:

    First off - a big THANK YOU to @gtj0 for this great piece of work.

    I am working on creating a panel-like config specifically for Raspberry Pi with 7" TFT. Along the way I have encountered some possible "oddities". Of course - these may simply reflect my lack of knowledge / understanding. For clarity - I do not have any Dueui code on the Duet. It is all deployed in a separate http server (nginx).

    You're running in standalone mode right? No SBC/DSF?

    Observation 1 - Test Mode with Duet turned off
    In some cases - when in test mode with duet turned off, the desired output does not occur. For example: this value for a label label statement - does not display anything. But works fine otherwise.

    "value": "Bed Temp:  ${state.temps.bed.current.toFixed(1)}"
    

    Question 1 - Can this be fixed ? Maybe the Duet calls of this type returning "" if in test mode ?

    So the label displays nothing, not even "Bed Temp:" without any value?
    Interesting. I'll check on this one.

    Observation 2 - Strict JSON Syntax
    I notice that the config.json (and maybe .js files) do not follow strict json syntax e.g. }, (i.e. comma after the last element in an array). I also see comments included in the config.json file.
    Question 2 - Is this by design ? Can we rely on this syntax going forward - or should it be avoided (e.g. if the json parser is changed at some future time)? Specifically - I like the idea of commenting my config.json file but do not want to go "all in" if I have to later go "all out" 😖

    Yes it's by design for several reasons, including the fact that you can't put comments in JSON. 🙂 Technically, it's not JSON anyway. You're actually writing Javascript code that just so happens to contain mostly object definitions. The file is parsed as Javascript so any legal Javascript can be included. Comments. Functions, etc. The sample even has some functions at the top of the file. The reason it has a .json file extension is so it can be retrieved using JSONP to get around cross-origin restrictions. It's NOT going to change. I like comments as well 🙂

    Observation 3 - Use of cookies for settings.
    I (and I suspect others) like to clear out my browser after each session which means that the settings for Dueui are lost. Same thing if accessing Dueui from another browser.

    Suggestion 3 - Allow for a setting file that, if present, is used - instead of relying on the existence of a cookie.

    Been thinking about this. I think I can do the following...

    I'd add options to the json file to allow you to specify standalone/dsf, duet host/ip, etc. so you don't need 2 files, one for settings and one for the actual config.

    How does that sound?

    Observation 4 - It seems like calls to macros can time out or not complete
    This is a bit strange - in a "Home All" command, I called /sys/homeall.g. I have an Ender 5 with a BLTouch. When the bed is some way off the BLTouch - the home command fails as the bed is still being raised. BUT - if instead I issue a G28, it works as expected. This was repeatable - note that my homeall.g itself is three macro calls :

    M98 P"homex.g"
    M98 P"homey.g"
    M98 P"homez.g"
    

    Question 4 - Any idea why this is happening? Something to do with Dueui polling ? In any case it may be a useful "be aware".

    There's no difference to DueUI. It just tells the Duet to run gcode M98 P"/sys/homeall.g" or gcode G28. Can you show me the "actions" you're using? What happens if you run M98 P"/sys/homeall.g" from the gcode console tab?



  • @stuartofmt

    Hi,

    Why would you call homeall.g directly rather than use G28 as intended?

    Frederick



  • @fcwilt --
    Just from an (internal to me) consistency point of view. I generally find a layer of abstraction to be a good thing). For example calling a macro from the slicer "before print" code rather than having the code in the slicer itself. In theory - it should not matter but obviously there is no difference between theory and practice (except in practice) 🙂
    Not something that I'm wed to but thought it worth mentioning as it resulted in some unexpected behavior.



  • @gtj0

    You're running in standalone mode right? No SBC/DSF?

    Yes - Stand Alone. I'm running a Duet2Wifi. The Pi is just sitting there providing a remote camera, nginx and serving up Dueui via Chromium.

    So the label displays nothing, not even "Bed Temp:" without any value?

    Correct.

    Technically, it's not JSON anyway. You're actually writing Javascript code .....

    Clearly I have exposed the very shallow depths of my javascript knowledge 🙂

    I like your options for avoiding cookies. Not sure you need all of them - perhaps the config file being specified in the url provides explicit flexibility (and easy to change when testing new config files)

    What happens if you run M98 P"/sys/homeall.g" from the gcode console tab?

    I will do some more testing - likely tomorrow - and report back.



  • @gtj0

    What happens if you run M98 P"/sys/homeall.g" from the gcode console tab?

    I cannot reproduce the behavior.
    I have tried different combinations and all work. I'm beginning to suspect there was some strange cache behavior or similar while I was in edit / test / edit / test ...... mode.

    What I had in the action line was

    "actions": [
    	{"type": "gcode", "gcode": 'M98 P"homeall.g"'}
    ]
    

    But even that is working now. In any case - I have left it as G28 🙂

    Again - thanks !



  • @stuartofmt No worries. Just FYI.. You can also use the "macro" action like so...
    actions": {"type": "macro", "file": "/sys/homexy.g"}

    I'm working on the other stuff. I should have something around the middle of next week.


Log in to reply