Real time timer based RS-232 communication using Labwindows CVI 2009

[mowgli]

Hi NI,

Q1> We at KPIT are trying to build a LabWindows timer based project as a "real-time" system that transmits a 80 byte RS-232  packet to an ECU every 10msec. With our current PC RS-232 communications port configuration (115200bps, 1Stop, No Parity, 8 Data Bits, No flow Control) we are facing difficulties in trying to send this packet with consistency. The timer mechanism set for 10msec does not always follow a 10msec timer callback function call. Is there a way, within the CVI 2009 framework, that we can get near 10msec periodicity(plus minus 1msec at the most)? (some times the periodicity is scary and my timer runs at 100msec instead of 10msec however this is observed intermittently, not continuously). My machine configuration is 2Ghz processor, 1GB Ram, Windows XP. Please adivse.

Q2> In the future we would like to update 4 stripcharts(with the reply from the ECU which is a 12 byte packet), one table which lists the 12 bytes one in each column and also write the received packet to a file on disk all in the remaining time between 10msec slots. Is this possible at all ?

Regards,

-Mowgli

[RobertoBozzolo]

A sustained 100 Hz rate is difficult to achieve on a Windows system, even more if you are using standard UI timers, which are subject to events in the main thread (the one that handles all user interaction with the application). Timers can stop if you click and hold on a window title and are subject to other events in the GUI thread (e.g. opening a FileSelectPopup will block the timer for an unpredictable amount of time, depending on system resources, complexity of the disk structure, other apps running and so on).

You could have better performances using an asyncronous timer instead of the UI timer: you need to load asynctmr.fp instrument and use its functions. Refer to the shipped documentation and to samples\toolbox\asyncdem example for a reference on this object. There are also several posts on the forum regarding async timers that you may want to look at.

Based on my experience, though, a spawned thread with an endless loop timed with syncwait () can give better performances in a timer+serial application, with the appropriate caveats and precautions needed when handling a multithreaded application.

Regarding your Q2, the amount of operations added is relevant, even more since they are *slow* operations (disk I/O and table access): it may be a real challenge to have that system working well.

[mowgli]

Hi NI,

We thank you for your prompt response.

We are analyzing the async timer demo as suggested. We are trying to capture some timing information by modifying a copy of the aynsc demo.

Please find attached an excel sheet for our timing analysis at different periodicity of the timer. Also please find attached the demo code used for timing related text file generation.

We would appreciate a comment on whether our timing analysis is as could be expected given machine configuration as 2.8Ghz, 1Gb RAM machine or are we off target.(The GetAsyncTimerResolution function gives us 0.001 second as an attainable resolution)

We have noticed a stable timer repetition rate at around 250msec.(plus minus one millsecond deviation)

Also would like to know if there is a list of known system or other processes(anti virus etc.) that can affect performance while using the timer.

Ours is a mission critical application and it would be nice if we didnt miss any packets.

Regards,

-Ashish

[RobertoBozzolo]

Hi Ashish,

when trying to otain a regular and fast execution rate all elements in the system are crucial, starting from code structure.

Better performances can be achieved by having the timed callback the fastest as possible and with the minimum access to system resources at all. That means trying to put away from the function all irrelevant instructions. In the example that you posted, opening the file inside the calback is the worst you can do! The quickest and dirtiest remedy is to open the file in the main and only write to it in the timer callback (in a few minutes test I had a very regular activity at 25 msec this way). The opimal solution is to transfer data out of the callbck with a TSQ and write data to file in another thread (by appropriately defining the queue lenght and installing a callback that empties it only when it is full you can reduce disk I/O).

Multithreading is working better on multicore machine, as those systems have effectively more power to spend on all system activities. Multicore machines are now almost a standard but you should at least make sure you are running on one box of them.

Now, given that async timers are built on top of windows multimedia timers, they should be the most regular process you can find in your machine. Nevertheless, it can be seen that song or video playing is interrupted sometimes due to other activities in the system, and this is something on which you have little to do: are you aware of **all** processes that are running on your system??!?

Processes that can seriously disturb system performances can be:

- Antivirus update

- Antivirus system scanning

- Windows update

- Periodic backup

- Other periodic activities you may have set up in your PC

- Network activities like mirroring a pc (some customers of mine do it every night)

- .... (who knows?)

I have installed a few years ago a wonderful screen saver in which a full 4-cylinder, 16-valves engine was building from scratch, complete with all accessories (alternator, starter, oil and gasoline pumps...): you could see every single screw come in place and rotate to fix its piece! A 120 mb software that was a full video and sound experience! I have lately uninstalled it due to the huge amount of resources it was using. This is onle a little example: you should carefully examine the target system to exclude all time-consuming activities but in my experience you never succeed in putting away all of them (and you will discover the last ones only after loosing some crucial data, Murphy's law ).

Really, if your application is mission-critical with no loss allowed you should seriously consider moving to another target (i.e. a real-time os)

[mowgli · Accepted solution]

Hi NI,

We at KPIT are grateful for the prompt and accurate response. We have edited our project based on your inputs. We are pleased to report that the timer is very well behaved for upto steps of 10msec (plus minus one msec jitter). We will now try to introduce a suitable periodicity for our GUI elements. Attached is our final excel and project for your reference. We hope this data helps other users should they come across a similar problem.

Regards,

-Ashish