Real time application and timing with RS485 and Modbus RTU

[ardahatunoglu]

Hi everyone,

I am trying to set up a labview interphase for a test bench in which two electric motors are connected with a shaft where one would be acting like the drive motor in a vehicle and the second one imitating the braking forces (aerodynamic, rolling res, etc.)

I need to send my data points with a certain frequency which did by using a while loop with certain wait times (100ms for now). When I measure what is happening with a chronometer this 10hz process is taking way longer time. Time the data points are not send with 100ms but with a longer period even if the wait time is 100ms where it does not correspond to what I want to do in real time. 

How do you send data points at a certain frequency and make your software stick to it?

Attached you can find my vi and also the data setpoint file.

Arda

[LucianM]

Make sure you attach all the subVIs not only the main VI. Try to measure the execution time of the TRUE case inside your big while loop which includes your code for what I assume is writing and/or reading over serial interface.

[ardahatunoglu]

I didn't bother attaching them all because I assumed you guys won't be able to run anyways it since you need the same serial interface(they are mostly serial reads and writes inside them). Thing that you suggested seems where you measure the execution time and try to give a wait time according to it(that's what I understood at least) wouldn't be ideal  because the situation on my computer+serial interface will not be always the same.

can you elaborate what you are exactly suggesting? thanks anyways!

[GerdW]

Hi arda,

---

@ardahatunoglu wrote:

I didn't bother attaching them all because I assumed you guys won't be able to run anyways it since you need the same serial interface(they are mostly serial reads and writes inside them).

---

But so we can only guess what's happening in this huge while loop…

---

@ardahatunoglu wrote:

Thing that you suggested seems where you measure the execution time and try to give a wait time according to it(that's what I understood at least) wouldn't be ideal  because the situation on my computer+serial interface will not be always the same.

---

Right now you are doing (atleast) 8 serial read requests inside this case structure at a baudrate of 19.2kbaud: are you sure your device is fast enough to handle those requests within 100ms? The serial communication takes its time (~0.5ms/byte!) and the device itself will also take some time to process your requests and provide an answer message…

You also should cleanup your block diagram, right now it's to huge and improves a lot by applying AutoCleanup.

Do you really need to flush the VISA buffer(s) so often? This hints to a "not as expected" implementation of the device communication!

Btw. this is not a "Realtime application", so I changed the subject line…

[LucianM]

The complete code would have been useful to check all subVIs, maybe we can find a reason for your problem. I suggested to measure the time it takes for your code inside the case structure to be executed. This could be done using two Tick Count (ms) functions like it is shown here. After you have this information, you can check where the big delays are by placing the Tick Count accordingly. Maybe you are measuring incorrectly or, like GerdW mentioned, you try to handle too much data for that time interval.

[ardahatunoglu]

ok, so I understood that system timing wouldn't work like this since the read requests and everything inside the main loop takes time so it takes more then 100ms not like the setpoints.

yes clean buffer can be omitted but if I can find a way to execute my main loop every 100ms(including the requests in the loop), it would not matter. anyways flush buffer can be omitted for sure.

yeah I need serious clean up before I continue you are right!

I just want to run my loop every with somewhere in between 1-10Hz including the requests inside(sticking to my setpoint timing), how can I do that?

[pincpanter]

Assuming that your query vi's are already optimized (you may attach one of them), you can't do much.

What's the time cycle by now? If it's acceptable, you may simply change the delay to a time slightly greater than the maximum expected time, to assure that data are collected in a regular way.

[RavensFan]

Can you set the device to a faster baud rate?

Serial is slow relative to most things a computer can do.  There is only so much you can do in a given amount of time so unless you can speed up the serial communication, there is nothing you can do.

It would be like being asked to type up an encyclopedia book within a day when you can only type 40 words per minute.  Just not going to happen.

[RTSLVU]

I also have to say that One Big Loop is never a proper program architecture.

A simple state machine would probably work better, scale better, and be easier to troubleshoot.

Without seeing ALL of your code that's all the advice I can give you.