Enhancing Firmware Autodetection

[ghost]

Splitting off from #2 to encourage some more creative thinking without depending on firmware changes

[cprezzi]

Frontends that support multiple firmwares, would like to have a way to identify the firmware before sending commands that cause errors on some of the firmwares.

• One already existing solution is sending an idetification string when a connection is established. This works well with USB connections, but doesn't work with serial connections via UART.
• A better solution would be if all firmwares implement the same command (like $I, M115, version, what ever) to query their idetification string. The string doesn't need to have much information, just firmware name and eventually protocoll version (to identify protocol changes). After that, the host should use only valid commands for this firmware.

If someone has a better/different solution, please post it here and let us discuss pros and cons.

[ghost]

Doesnt solve for TinyG, but what about looking at the subtle formatting difference from the result of "?"
between grbl and Smoothie?

[ghost]

And from my other chair as electronics designer, would wiring autoreset between ESP and controller, be the real solution? Connecting to the ESP triggers a reset, just like the ftdi does via DTR for Grbl, and similar to the virtual behaviour in smoothieware?

[ghost]

My thoughts are that it is simple enough to select your firmware in the setup. Autodetect is 'nice' if it has to be continually used, but it only needs to be set once and then never touched again.

There should be a way to define a set of 'rules' adhered to by each of the firmwares. For instance, for GRBL abort = $X, Smoothie abort = $Y, TinyG abort = $Z etc.

The apply the rules appropriate to the selected firmware.

When eventually all the planets align and we have a universally accepted set of rules, then we end up with one set of rules and instantly will have autodetect.

[cprezzi]

We already have a universall set of commands: the lw.comm-server API. The frontend doesn't have to know details about firmware protocoll or specific commands, the server cares about that.

By the way: This issue is not about how we solve our actual problem, it's more about how a future solution could look like.

[cprezzi]

That's just my opinion ;)

[ghost]

Agreed, keep in mind discussions inside lw.comms-server always has to keep in mind Claudio wants to have comms server be the better alternative for anyone wanting to plug in any frontend. Any frontend. Any protocol (serial, wifi, telnet, ethernet) and Any firmware. Thats the dream, thats the vision. Most importantly, that's the legacy that makes the world a better place. As it gives to the machine control community an easy pluggable backend to use for many different projects. Which in turn encourages work on continually improving this as its reach spreads. To do that though, it needs a lot of autonomy. A lot of the discussion here is going to start picking up speed for #2018yearoftheglobaltakover lol What we have now is great but we have to keep pushing the envelope (esp32, pluggable apis, new ideas) - those are things that feed developer souls. Its not always aligned with Vendor duties but it is critical to work on the next level. Absolutely. One of the reasons we have a hard time now, is that those that came before us didnt work on 'tomorrow' - now tomorrow has become today and we need to battle firmware differences, protocol inefficiencies and other issues. Sons carry the consequences of fathers' sins... In the dev world that means we need to push the envelope now!

…

On Mar 1, 2017 11:10 AM, "Claudio Prezzi" ***@***.***> wrote: We already have a universall set of commands: the lw.comm-server API. The frontend doesn't have to know details about firmware protocoll or specific commands, the server cares about that. By the way: This issue is not about how we solve our actual problem, it's more about how a future solution could look like. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#11 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AHVr2xWQiur04521HvqyDhgt3UOasMeeks5rhTYMgaJpZM4MOhiT> .

[cprezzi]

@DarklyLabs Don't worry, the problem you had with ESP connect should be solved with 4.0.40. I just swapped the check order to smoothie first for the moment (as your users would probably be the major group using this feature).

[ghost]

@cprezzi Great. I will test it in the morning. Much appreciated.
(by the way, the double function 'abort' button is genius! Working really well for USB)

[ghost]

@cprezzi Looks like connecting and resetting alarms for WIFI is working correctly now.
Thank you.