more wiki update - Githubissues

atsju commented 2 years ago

@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

luc-github commented 2 years ago

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

atsju commented 2 years ago

Link works again, so it was temporary. I will markdown the commands

atsju commented 2 years ago

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

luc-github commented 2 years ago

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

atsju commented 2 years ago

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

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.

atsju commented 2 years ago

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"

luc-github commented 2 years ago

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

luc-github commented 2 years ago

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>

atsju commented 2 years ago

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.

luc-github commented 2 years ago

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 [``]

atsju commented 2 years ago

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.

atsju commented 2 years ago

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 ?

luc-github commented 2 years ago

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

atsju commented 2 years ago

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.

luc-github commented 2 years ago

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

atsju commented 2 years ago

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

luc-github commented 2 years ago

No problem - thank you for your help - I will review this and merge it - thank you for your time

luc-github commented 1 year ago

https://github.com/all-contributors please add @atsju for documentation update

luc-github / ESP3D

more wiki update #779