We have a new version of the SimpleFOC Studio app updated to work with SimpleFOC 2.1 thanks to @Antun_Skuric who took the previous version and pushed it to the next level
The main features are:
Plug and play with the SimpleFOClibrary version 2.1
Real-time tuning and configuration of the motors
Real-time plotting and monitoring of motor variables
Code generation for easier integration of the tuned parameters in your code
Built on PyQt5 and a standardized SimpleFOCConnector interface that can be used as a gateway form python to the SimpleFOClibrary device as it is shown in the simple example.
This is great, you can test out property changes really quick to see how they change performance.
I have a few ideas
Add a āJog Dialā, eg:
In velocity mode, it has preset speeds. In angle mode, it has preset positions.
Then you could just click the button and sends the command to go to that speed/position.
This would make it even faster to see the effect of changing settings.
Custom commands:
Where you could specify a Name, Command, Value and Response text.
Then we could extend the commander interface on the controller to do things like change register settings for SPI devices.
Help
Maybe a help button beside each setting where it links to the online docs explaining the setting, and what typical values might be.
That sounds awesome!
Iād be in to support any further development as well both in python and on the library side. There is still a lot to optimize for the efficient communication, we should probably introcude the Verbose:::studio or Verbose:::python ( or Verbose:::echo_command similar to what @malem already suggested an approach for that in the PR) mode in the commander as well and echo the command instead of a lot of text that we need to parse. The same is true for the monitoring.
This would allow tuning multiple motors a bit more easily and less overhead in communication.
Now Iād like to suggest to you guys and everyone else that feels interested to try to use the same python connector class for both applications.
What do you think of making the python connector a separate repo and even a pip package?
This way we can easier support all the library changes that might occur.
the bottleneck is more MCU-side.
I think it would be possible to prevent the monitoring from affecting the control loop.
The idea would be to setup a e.g. 10khz timer (like paul gould did) where the control loop happens and put readings in a FIFO buffer. Then buffer would then be emptied when the MCU idles, or interrupt based.
in the main loop() function, we could e.g. listen for commands
asyncio on the GUI side might be interesting for other reasons, although my impression is the GUI is very responsive despite the constant serial comms.
On the MCU side, I think there is a lot that could be done, but I think care should be taken to keep it separate from the āsimple and genericā interface we have now. Any Arduino has a Serial object, but not all of them have timers that work in the same way, etcā¦
I know you like SAMD - I think on SAMD it should be possible to drive the SERCON using DMA, with almost no overhead to the main loop. But this will hardly be portable to other MCUs. So I think a good approach here could also be to write alternative āmonitoring backendsā, which can be kept separate from the main code (not wasting space and confusing the people not using them). The āprosā that want DMA-based monitoring for their MCU can then select from the available backends, or code their own.
Iām sure some people have been thinking about other channels than Serial (UDP on ESP32 for example, or MQTT, etcā¦). There could be backends for that too!
In terms of the existing SimpleFOC implementation, I would keep it simple, and keep it on Serial. This will be what 90% of users want when first testing it out, and what the less advanced users can realistically manage.
A possible optimization might be a binary mode for monitoring.
At the moment we send a bunch of 32 bit floats as ASCII. This incurs a penalty both in terms of ASCII conversion of the data, and sending some extra bytes.
I think converting to a binary format might improve the performance somewhat.
The ASCII format could be default, and we could keep it for the commander, but the binary format could be used by the monitoring when called from the SimpleFOC Studioā¦
On the MCU side, I think there is a lot that could be done, but I think care should be taken to keep it separate from the āsimple and genericā interface we have now. Any Arduino has a Serial object, but not all of them have timers that work in the same way, etcā¦
Agreed, also with your backend idea. the default could be a backend that synchroneously write via the configured Stream. I think it would still be doable to keep the FIFO idea without losing generality.
I know you like SAMD - I think on SAMD it should be possible to drive the SERCON using DMA, with almost no overhead to the main loop. But this will hardly be portable to other MCUs. So I think a good approach here could also be to write alternative āmonitoring backendsā, which can be kept separate from the main code (not wasting space and confusing the people not using them). The āprosā that want DMA-based monitoring for their MCU can then select from the available backends, or code their own.
Well itās the dev board I have in stock, and my initial plan was to reproduce Paul Gouldās controller. Lots have happend since. Iām more and more interested with the SMT32G4. But yeah, I do want DMA-based/async monitoring. And I totally agree we should design a binary protocol. Another thing Iād like to see are timestamps which would become crucial it we go async
Just so you know, Iāve put quite a bit of effort on the data logging side. I chose to go separate way from the commander interface since I aim for real-time data logging performance, probably on a separate, outbound-only. data link. I wonāt be needing SimpleFOCStudioās connectors. I tried, but I then found a solution thatās both simpler and much, much higher performing. I should be ready for a little demo by monday or tuesday.
Beware, itās Pyside6-only (pyqt5 is GPL, btw), uses QtQML, and it parses C-code sunch as āArduino-FOC/src/common/foc_utils.hā to genrate parsers automatically. Itās going to be a bit nasty at first, but donāt worry, I hate nasty code.
for example, to send a struct from MCU, it becomes as simple as:
I had some time today and I have decided to implement your suggestion to add a Jogging control.
The fast reverse button reduces the current target by 2 times the specified increment, the reverse button reduces the current target by the specified increment ā¦ etc. Stop button, in angle control mode, sets the current angle as target angle and in velocity control sets the target to zero.
Just got time to implement your second suggestion os something similar. Each custom command has a name and a value as yoy can see at the bellow.
Once you have defied each custom command in rder to execute each of them you have to select it and once selected press the space key (āµ) or right arrow key (ā).
You are right, Itās a bit annoying having to add the custom commands every time yo execute the application. I will add the functionality of being able to save custom commands in the JSON file and also saving the āMā o whatever parameter of the engine. When I have it done I will let you know, it is a minimal change that adds quite value