ESP3D
ESP3D copied to clipboard
luc-github
more wiki update
@luc-github
- This link seems to be dead or with limited access : http://smoothieware.org/supported-g-codes should we find an alternative link or let this one http://smoothieware.github.io/Webif-pack/documentation/web/html/supported-g-codes.html ?
- What do you think about having commands doc in markdown format instead txt ?
- should the commands be hosted directly by wiki or stay as now as part of code ?
next and last step will be to rework Readme (To explain/show what the repo does and redirect to the wiki for all questions/explanations)
Mention #737
seems the domain is locked - may be they forget to renew subscription ? The alternate link looks good - good catch
What do you think about having commands doc in markdown format instead txt
I am ok for Markdown
should the commands be hosted directly by wiki or stay as now as part of code
Well I think released version can be in wiki - for dev version (3.0) remove it from wiki and let it in dev branch (3.0) until it is released as it will be modified often, that would be best approach I think
@luc-github a remark about 3.0, maybe it would be more convenient tu move to linux command format ? removing the [] around ESPxxx commands. it would be more convenient for the help formatting (using [] for optional args) see https://stackoverflow.com/questions/9725675/is-there-a-standard-format-for-command-line-shell-help-text and http://docopt.org/
Also you command line Interpreter could have a help commend (optional with a define to spare code space)
the simple [ESPXXX] xxxx\n format allows to have fast sorting of commands to isolate them form GCODE / comments instead of bridging them and so not overload MCU - the ESP capability is limited and command analysis should not take mcu time
Impemententing a complex command interpreter will take memory / code size and mcu time - I do not think it is good idea
Additionnally - ESP commands are not mean to be typed (exactly like GCODE) but mostly executed from a sender / a program / a webui so make them beautiful / human readable is a non-sense IMHO
the simple
[ESPXXX] xxxx\nformat allows to have fast sorting of commands to isolate them form GCODE / comments instead of bridging them and so not overload MCU - the ESP capability is limited and command analysis should not take mcu time Impemententing a complex command interpreter will take memory / code size and mcu time - I do not think it is good idea
No need for a complex interpreter. But searching for ESPxxx yyyyyyyy\n instead [ESPxxx] yyyyyyyy\n. I think it's basically the same but you use a more standard syntax.
See this is how the help should look like [ESP100] [SSID] [pwd=<admin password>] but it's misleading because first [ ] is part of the command and doesn't mean "optional arg"
I choose on purpose [ ] because these characters are not in GCODE
about help that is why I use brace
[ESP0]
[List of ESP3D commands]
[ESP] (id) - display this help
[ESP100](SSID) - display/set STA SSID
[ESP101](Password) - set STA password
[ESP102](Mode) - display/set STA IP mode (DHCP/STATIC)
[ESP103](IP=xxxx MSK=xxxx GW=xxxx) - display/set STA IP/Mask/GW
[ESP104](State) - display/set sta fallback mode which can be BT, SETUP, OFF
[ESP105](SSID) - display/set AP SSID
[ESP106](Password) - set AP password
[ESP107](IP) - display/set AP IP
[ESP108](Chanel) - display/set AP chanel
[ESP110](State) - display/set radio state which can be BT, WIFI-STA, WIFI-AP, WIFI-SETUP, ETH-STA, OFF
[ESP111](header)display current IP
[ESP112](Hostname) - display/set Hostname
[ESP114](State) - display/set boot Network state which can be ON, OFF
[ESP115](State) - display/set immediate Network state which can be ON, OFF
[ESP120](State) - display/set HTTP state which can be ON, OFF
[ESP121](Port) - display/set HTTP port
[ESP130](State) - display/set Telnet state which can be ON, OFF
[ESP131](Port) - display/set Telnet port
[ESP140](SYNC) (srv1=xxxx) (srv2=xxxx) (srv3=xxxx) (zone=xxx) (dst=YES/NO) (time=YYYY-MM-DD#H24:MM:SS) (SYNC) (NOW)- sync/display/set current time/time servers
[ESP150](delay=time) (verbose=ON/OFF)- display/set boot delay in ms / Verbose boot
[ESP200] (json) (RELEASE) (REFRESH)- display/set SD Card Status
[ESP201](P=xxx) (V=xxx) (PULLUP=YES RAW=YES ANALOG=NO ANALOG_RANGE=255) - read / set pin value
[ESP202] SPEED=(factor) - display / set SD Card SD card Speed factor (1 2 4 6 8 16 32)
[ESP220] - Show used pins
[ESP290](delay in ms) - do a pause
[ESP400] - display ESP3D settings in JSON
[ESP401]P=(position) T=(type) V=(value) - Set specific setting
[ESP410](plain) - display available AP list (limited to 30) in plain/JSON
[ESP420](plain) - display ESP3D current status in plain/JSON
[ESP444](Cmd) - set ESP3D state (RESET/RESTART)
[ESP600](message) - send notification
[ESP610]type=(NONE/PUSHOVER/EMAIL/LINE/TELEGRAM/IFTTT) (T1=xxx) (T2=xxx) (TS=xxx) - display/set Notification settings
[ESP620]URL=http://XXXXXX - send GET notification
[ESP700](filename) - read ESP Filesystem file
[ESP701]action=(PAUSE/RESUME/ABORT) - query and control ESP700 stream
[ESP710]FORMATFS - Format ESP Filesystem
[ESP715]FORMATSD - Format SD Filesystem
[ESP720](path) - List ESP Filesystem
[ESP730](Action)=(path) - rmdir / remove / mkdir / exists / create on ESP FileSystem (path)
[ESP740](path) - List SD Filesystem
[ESP750](Action)=(path) - rmdir / remove / mkdir / exists / create on SD (path)
[ESP800](plain)(time=YYYY-MM-DD-HH-MM-SS) - display FW Informations in plain/JSON
[ESP900](ENABLE/DISABLE) - display/set serial state
[ESP920](client)=(ON/OFF) - display/set SERIAL / SCREEN / REMOTE_SCREEN / WEBSOCKET / TELNET /BT / ALL client state if available
But I agree https://raw.githubusercontent.com/wiki/luc-github/ESP3D/docs/Commands3.txt
is not consistent at all - should not have
[ESP107]<IP> pwd=<admin password>
[ESP900]<ENABLE/DISABLE> [pwd=<admin/user password>]
the bracket should not be used for pwd=<admin/user password>
I choose on purpose
[]because these characters are not in GCODE about help that is why I use brace
Indeed they are not in Gcode and it's because they should be in no command line. Brace is not the "correct" choice but I understand the idea of the workaround.
ESPxxx is also in no Gcode so I don't really see the problem removing the braces.
Also pwd=<> should be --pwd=<> to be a standard interpreter. Again this changes nothing if code complexity.
Let's just wait a bit. I'm doing my best to rewrite file commands 2.0 then I will push and we will discuss based on it.
well ESPXXX can be a file name, a comment in config file, can be many things actually - ESPXXX alone was not reliable IMHO, that is why I added [``]
Please look here https://github.com/luc-github/ESP3D/blob/301b40ca9957da7d2f8750acada165de215272e6/wiki/Command-line-2_0.md it's not 100% finished but I find it much clearer as used to standard command line helps. i listed the deviations, we can keep or remove from final wiki version.
well ESPXXX can be a file name, a comment in config file, can be many things actually - ESPXXX alone was not reliable IMHO, that is why I added [``]
I understand why you did it. Nevertheless, 3.0 is the occasion the change things in API and this is why it's the good moment to discuss about it.
IMHO ESPxxx is not really less reliable because no Gcode line will start with ESPxxx.
I'm unsure if it's allowed to have several gcode commands on same line. If it is not, this alone saves us from any problem by searching for ESPxxx only at start of line.
Moreover, while [ESP]xxx can not be a file name, it could still be a comment in a config file so [] doens't add much robustness.
I need to leave, take you time to think about it. And as always you are the boss for final decision. I might have a look to how parser is coded later to see if [] really adds robustness.
Hi @luc-github I had a quick look at command.cpp. Well i think it works but maintain what I said about format and now I have a concern about maintainability as a 1000+lines switch is not exactly best practice . It's pretty clean and I coded like this and I understand the update cost so please take not personal offence. That being said, once I finish update of wiki, IF I rewrite the parser and IF I change the commands to remove the [] + other remarks I made and IF it's still lightweight would you do a 4.x.x with it ?
I am never against improvement - that why I did rewrite of ESP3D 3.0 and rewrite of webUI 3.0 (twice) I am always listening suggestions and I welcome discussion as I know I do not pretend to know everything and I am far from being great programmer, in code there is always area in improvement, so I won't be offended, and to be honest I did not expected I will get so many commands, features pop and came one after one
For 3.0 there are already a lot features that are still missing and need attention, that is why currently I do not try fix something that is not broken, I keep it for later when time will be right.
That said without seeing your proposal, I cannot says it can be integrated in 3.0, 3.5 or 4.0, so it is ok, take your time
about the [] removal in ESPXXX commands:
- in 3.X it won't happen for sure because it will break too many things
- for later I am open to proposal, but need same level of reliability (e.g: if file name is a weight of reliability = +1, the comments in config files, even you do not consider them, I still consider it as better +0.5, so ESPXXX vs [ESPXXX] , weight is +1.5 in favor of
[]) also it need same level sorting simplicity because ESP3D is a bridge (telnet -> printer, printer -> telnet) and time to block or bridge a command is key for such small system, so if reliability / mcu time is not same it won't happen - because usage is more important than cosmetic IMHO FYI currently ESP3D already cannot handle all available features if you enable them at once, it slow down the system too much.
In all case I really thank you for all suggestions / discussions, it is always refreshing/stimulating to have another point of view, it bring challenge for improvement
I currently do not have a wide enough view to decide anything. Just improving commands.c could be a good step for me.
Could you elaborate on all possible ways ESP3D can get/send a command (when you have some time) ? I currently only use the serial line and webUI in a very basic way so I do not see the interlock.
Also thinking about POSIX command format it should be like git commands should be like ESP <100> [args]. But Gcode is mode like ESP100 [args] so I'm still wondering and thinking about it.
ESP commands can be sent from any external app by websocket / serial / Telnet, [ESPxxx]yyy commands can be sent even from printer FW using some command like M118 (Repetier/Marlin), in that case the ESP command is sent like usual [ESPxxx]yyyy (marlin/M118 P0 or repetier/ M118 ), or (smoothieware/ echo) in that case the command has an append in output echo: [ESPxxx]yyyy, these commands can be in FW itelf (e.g: M600 script in Marlin) or reading from SD GCode file, added manually by user or slicer start/end gcode
a lot of text can be bridged by ESP3D streamef from serial (Printer) or sending to Serial, and soon Serial 1 to Serial 2:
- GCODE commands(all Firmware)
- config file content (smoothieware)
- file list (all Firmware)
- configuration settings (all Firmware)
- commands using M118/echo (all Firmware)
- script from ESP3D FS for autorun / macro
so these commands should not be blocked but bridged as fast as possible, several people, even I do not recommend it due to network latency, do GCODE streaming, and in that case adding processing time could affect the print quality/ job even if network latency is low because ESP3D become the bottleneck. during latency the printer filament melt, generating blobs, overextrusion, on CNC a laser may burn too much waiting next command.
Active [ESPxxx]yyy commands - from another point of view, must be detected and not forwarded to avoid to mess up external application/webUI or printer Firmware with unknow command or misleading command behavior
I may miss some edge case but globally I think I covered all - I hope it clarify the scope
Sorry for delay. This might be my last contribution for long time as I have not much time for personal development now.
Side note about your alpha releases : please try to follow https://semver.org/ 3.0.0-alpha1 instead 3.0-alpha1 for futur releases
No problem - thank you for your help - I will review this and merge it - thank you for your time
https://github.com/all-contributors please add @atsju for documentation update