Hmmmm… that’s one for @JorgeMaker 
I’ve had SimpleFOC Studio connected to different MCUs for very long times… I think there a few issues with the way it handles data because it can get kind of laggy in some situations, but I haven’t had any issues with buffer overflows.
What platform do you run it on?
Laggy, yeah that´s the thing… Have to disconnect and then re-conect to get real time data.
Maybe its a view setting thing. Anyways. I have noticed a disturbance in the motor when serial connected.
The monitoring definitely changes the speed of the FOC loop, also in my experience it has an impact on performance… but you also have to get data on what’s going on, right? Serial is a convenient way to do it… on dual core MCUs like the ESP32 and RP2040 there should be some things you can do with multithreading to optimise this.
I believe it would help to Call the foc loop in between sending USB chars. When the receiver g’ets a new-line, that’s the end of transmission.
i know this is getting offtopic but how is this different than simply using spi with dma to read the control values sent by any external device?
Me too on OS X… I’m super-happy with it, even if it has some rough edges
1 Like
you mean like with a raspberry pi? I was thinking about getting the values to a PC (e.g. SimpleFOC Studio) - I guess the best way to measure a lot of things is with the oscilloscope and/or logic analyser, but when it comes to introspecting the calculated values within SimpleFOC you have to send them out somehow…
If you can set up DMA to SPI then you’re a long way forward on the MCU side, but you still have to interpret the SPI on the receiving side - serial (esp. via USB) is one or few steps easier to read on a Mac or PC than SPI would be.
But for sure there are many possible solutions here, depending on your MCU and preferred comms…
Both send and receive? also on the receiving side (say Windows), why would it be a problem, since the client would be grossly overpowered, any CPU peripherals would overrun any MCU peripherals as far as data bandwidth is concerned. Do I understand the problem or I’m thinking of something else?
I think there is a misconception about the SAMD51 USB peripheral. You don’t really need to set a baud rate, since its a virtual thing. SPI and USB are two distinct protocols. Its no different then sending G codes to a stepper controller. How are the commands parsed? I will assume DMA is set up with how the USB hardware works …
In sFoCStudio, we set up the connection as it was in fact a serial connection, which it is not. It is a full speed USB connection.
For the fast comms, its really just receive by the PC - at least normally I don’t think you want to command nearly as much as you want to read telemetry data. Sending a few commands, even if you do it at 500Hz, won’t take much bandwidth, and since the hardware always has a few bytes buffer it happens more or less without delays on the MCU side.
But sending data, esp. at the rate the FOC loop is (or should be) executing, is more of a challenge for the MCUs.
1 Like
Ok, I see the USB message is broken down into separate chars. Each USB package has just one character. That is a lot of packages to send.
[Edit] In order to send larger messages, you have to first assemble the message from the various variables plus the right termination. You basically need a hardware specific file for simpleFoCstudio commander.
It is definitely not the connection, rather its how the commander sends out the variables.
Hey, that’s actually a good find and very interesting… I assume there’s stuff you can do depending on which Serial implementation you use, and maybe with build flags, depending on architecture.
But it doesn’t look like it would be hard to account for it in the commander code. I’ll put it on our list!
char buff0[10];
char buff1[10];
char buff2[10];
char buff3[10];
// #include <avr/dtostrf.h>
long currentMillis = micros();
loops++;
if(currentMillis - lastMillis2 > 500){
dtostrf(motor.target, 4, 4, buff0);
dtostrf(motor.voltage.q, 4, 4, buff1);
dtostrf(motor.shaft_velocity, 4, 4, buff2);
dtostrf(motor.shaft_angle, 4, 4, buff3);
// stringOne += "test string : ";
// stringOne += " ";
stringOne += (buff0);
stringOne += " ";
stringOne += (buff1);
stringOne += " ";
stringOne += (buff2);
stringOne += " ";
stringOne += (buff3);
Serial.println(stringOne);
//Serial.println("\n");
stringOne = "";
lastMillis2 = currentMillis;
// PS Be aware of RAM leaks and strings
}
//motor.monitor();
[Edit] Updated code to use micros();
I can confirm, writing a string to simpleFoCStudio does not work… Cant test properly at this moment, but i can see the data coming through in one single packet.
Edit: does not work… I cant tell how sFoCStudio parses the data?
@JorgeMaker
I just ran a test using the motor.monitor(); function vs. writing a string via USB to FoCStudio. Turns out the motor.monitor(); is significantly slower, compared to sending a string each 2 milliseconds. I think it has to do with the USB protocol doing excessive handshaking.
this is using motor.monitor();
This is sending a string each 2 millisecond’s
I see the void FOCMotor::monitor() function is not part of sFoCStudio. sFoCStudio pull´s the data when plotting the graphs. So running the motor.monitor(); while using sFoCStudio is a waste of serial bandwith?
IMO the best and fastest way, when using a MCU with a virtual USB port, is to print out the data without asking for it first, but with the possibility to change variables through commands. Using the full 64bit USB package. So there should be a command called bool stream_data. On the receiving side, the python code will split the message using comma-seperation. This will move the main “work” to the receiving side, which typically will be much faster then the sending side (MCU).
SimpleFOCStudio has no any effect on how motor.monitor(); works neither if USB is used to to send data.
SimpleFOCStudio is a Python application that runs on a computer that listens for data sent from a microcontroller through the serial port interface.
It is not within the scope of SimpleFOCStudio to affect the way the SimpleFOC library performs its task. We simply use the existing Commander interface to develop an application that can plot data and send configuration commands. That is all.
Regards