How can I roll back to Build 300? I'm using FluidNC. I realize that you are official supporting it but Build 301 just broke it. At a minimum, I'd like to stay on Build 300 if Build 301 and future version are incompatible.
Looking at the serial raw log, it looks like Commander is sending "$#" and then "[ESP400]". The "[ESP400]" is dumping my TinyBee's EEPROM and it looks like Commander never fully recovers from that (or my controller doesn't). It takes multiple tens of seconds for the EEPROM dumping to end.
I can press the disconnect button and still command FluidNC via FluidTerm directly, so I believe my controller is at least not locked up. Commander never gets an update to the machine or the work position. If I manually send from Commander a "?", it will refresh the positions but doesn't do so automatically.
Attached is a capture of the serial comm showing my issue.
Thank you for access to the older builds. That did help. With this data, I've come to the conclusion that Build 301 update was not the issue. I don't have root cause yet, but access to Build 300 let me confirm that this is not a Commander issue (although Commander could allow for a longer timeout to receive all the $ESP400 data that FluidNC is sending). Thanks again for the older builds.
Thanks for sharing this. FluidNC is not fully supported in Commander as it doesn't conform with standard GRBL.
We try to offer the best possible solutions we can but we can't always make a suitable solution for every 3rd party controller available.
If using FluidNC, we would not recommend the use of Commander for it's control if it is causing issues for you.
Regarding your specific issue, there are a series of Commands that are sent at initial connect for Commander to populate it's values. During this time, Commander does not poll the controller so it reduces the chances of it asking the controller to do any unnecessary work during the start up data process.
Once this process completes, polling is enabled so that Commander can return the current positioning and other diagnostic information about the controller.
If this process takes too long or fails, it may never enable atuomatic polling to occur.
In general, if there is a Command for doing something, i.e: [ESP400], it would be an expectation that the function would complete as expected because it is a valid command within the controller itself.
If there are hold ups or delays in processing this data it may indicate that there is an issue with the controllers eeprom itself and an eeprom reset may be required.
Looking at the data you have posted here, there is a LOT of additional data that [ESP400] is returning compared to a standard GRBL ESP32 controller. A lot of this is not needed by Commander but, the controller itself is returning all of it when a standard [ESP400] command is sent.
This is one of the reasons why we do not support FluidNC, there is simply too many changes to existing established commands, this is not good practice from a development standpoint.
It would have been wiser keep the existing [ESP400] command the same output as it always has been since production releases were made and if needed, created a [ESP401] command that did a more advanced EEPROM dump.
This of course is in the hands of the FluidNC development team.
I hope this helps.
After this post was made, we have setup a repo of previous Commander builds here. You are welcome to try them to compare your results: