Problem with reading from / writing to multiple serial ports in Simulink

Hi,

For my project I need to read from 3 sensors simultaneously and based on the input from the sensors I need to control the robotic end-effector. Individually all the sensors and end-effector are interfaced with simulink and I can read data accurately.

However, when I run simulink model with two or more sensors simultaneously, there is a problem of data loss and inconsistent data. Simply if we have two sensors in the model, simulink can read only one sensor data accurately and the data read/ written to other sensor isn't reliable.

I will appreciate your guidance. Thank you.

Answer 1

[shmulik e]

Hello

How did you manage to read from multi Serial ports without significant delay ?

Answer 2

[Walter Roberson]

Reading from multiple devices simultaneously requires multiple independent bus controllers, together with a hardware trigger technique to synchronize the reading requests, such as using genlock or a hardware trigger line. Note that the fact that you read from the the devices simultaneously does not mean that the data will be available simultaneously.

One of the more common ways of handling this kind of situation is to use a National Instruments CompaqDaq chassis with multiple data acquisition boards, and program the daq for a common trigger signal, and use the data acquisition toolbox to read the combined set of readings (perhaps splitting the buffer into pieces to deliver the readings to different blocks.)

You also need to consider that although you might be able to get measurements from multiple sources, that does not mean that they are current readings. In cases where actual simultaneous readings are important (rather than polling in sequence), it is more common than not that you need to know how long ago the readings were taken. Many of the CompaqDaq chassis are able to timestamp readings.

I will be blunt that the CompaqDaq series are expensive and not nearly the highest performance you can get for the money, and that using them for high performance in MATLAB can take a fair bit more effort than one would expect. Using Simulink Real Time with a speedgoat system can improve performance. High speed low latency simultaneous data collection is not easy with a general program such as MATLAB which is not designed for real time work.

[shmulik e]

Thank you for the answer.

I think the CompaqDaq is an overkill for what i need. I have 3 Teensy3.6 boards in my system:

• Two that read data from sensors and send there values though the serial to matlab.
• One another that receive serial data from MATLAB and control some motors.

The process time of the data in MATLAB is very low, its doing some minor calculation of the raw data and sends the right command to the third controller.

I dont need for the system to work faster that 80-100Hz.

If i read the data from each controller alone, the communication is fast enough for my need. The problem starts when i try to communicate with all three at the same time, i get a delay of about 10+ sec. I thought that because i have a very powerful PC this wont be a problem.

This is my connection scheme:

[Walter Roberson]

That configuration cannot achieve simultaneous readings. If you were to use NTP (Network Time Protocol) between the devices, you would perhaps get about 1 millisecond timestamp synchronization; for higher synchronization you would need PTP, which needs additional hardware.

USB is asynchronous by design and cannot be made synchronous. It uses a master/slave configuration. Only one device (including the controller) can talk at the same time per controller, so you would need three USB controllers.

According to https://www.pjrc.com/teensy/td_serial.html, the Teensy writes bytes directly into the USB buffer. It has an inactivity timeout of 3 ms on filling the buffer (that is, it does not send bytes immediately, expecting that there might be more to send) but Serial.send_now() can be called to schedule the buffer immediately. After that you have to wait for the host controller to poll, which is generally 1000 times per second.

So it appears to me that it should be practical to write code for the teensy side to transmit 100 samples per second. There might be a bit of jitter due to running NTP.

The nature of USB, and of MATLAB / Simulink not being real-time, makes it impractical for the MATLAB / Simulink side to be written to send "scan now" commands simultaneously to three USB devices. To get synchronization you would need the teensy side to be figuring out when to sample.

Note that each teensy is not going to be able to read from more than one sensor at a time. It should be able to read them in quick succession -- certainly in much less than the 1 millisecond that is the limit of your synchronization ability without additional hardware.

Now, whether you can get the MATLAB/Simulink side to receive at the needed rate, on multiple devices, is a different matter...

[shmulik e]

On the Teensy side i use

Serial.Write()

to send that data from the sensors, this is the fastest way to send data through the Serial. And i understand that the micro-controller cant read the data from the sensors simultaneously, it reads it 1-by-1 and that the way it sends them.

I am not bothered with the minor delay between the data from each sensor (~few millisecond).

I didn't understand yo final conclusion, What can i do about the delay of 10 sec when all the ports are working together?

Is there a better program that i can use for this purpose ? I thought writing my own code in C++ but, then i wont use the Simulink blocks that are very helpful.

[Walter Roberson]

After all of the Serial.Write() for one set of sensor readings, use Serial.send_now();

At the moment I do not have any ideas as to why you might be getting a 10 second delay.

To debug, I would suggest that you have your Teensy send along a timestamp and also a cycle counter (increment once per set of readings), and that when you receive the data on the Simulink side, you also timestamp it. That should permit you to study the progression of delays and also to study whether you are getting dropped readings.