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...
- Use local storage if it exists. If not...
- Use any config file specified in the URL like one of the following...
http://yourserver/dueui.html?configFileURL=/myconfig.json
http://yourserver/dueui.html?configFileURL=http://someotherserver/myconfig.json - If it's not specified in the URL, check
http://yourserver/dueui.html?configFileURL=/dueui_config.json - Finally, start with a blank settings page.
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 gcodeG28
. Can you show me the "actions" you're using? What happens if you runM98 P"/sys/homeall.g"
from the gcode console tab? -
-
@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. -
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.
-
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.