05-14-2015 06:22 AM
i have a program in which i have to aquire / send data from serial port which is time critical ie 10 ms , my quension is that what are my options, can i use threads or use asynctimer (that can have 16 independent threads). i understand how to use asyncronus timer but my question is that are there anyother ways of creating threads in labwindows and are they as effective as asyncronous timer, please guide me in detail.
thanks in advance
regards ahsan
05-14-2015 08:19 AM
CVI can handle multithreading both with asynchronous timer and with multithreading functions included in Utility library. I tend to say the lultithreading functions are more flexible than multimedia timers, for example you can set priority and sleep policy for thread functions.
I suggest you to study Creating Multithreaded Applications topic in the Programmer Reference in the help: multithreading programming requires a bit of attention to protect program and system resources data from unwanted concurrent access. There are also some examples installed in CVI that you can looking at to begin understanding all technical issues in this technique.
05-14-2015 12:40 PM
I have already read the document that you reffered me but i feel i haven't clearly explained my question ,,, plz understand there are three requirements from my project and i want you to guide me the simpler and most efficient method by which i can not loose my data at serial port.
three requirments from my project
1)use joystick which i successfully have used .
2) acquire data at one serial post after every 10 mili second (for long time)
3) send data at other (2nd) serial port after every 10 mili second (for long time)
and i can not afford to loose any data (i mean to say data missing) so i want you guidance on this topic in detail i really appriciate your previous help secondly why labwindows have asyncronous timer when threading is also possible.
i want to know better of the two from all aspects i mean to say "thread vs asyncronous timer" which is better ?? which is simpler ?? which is more reliable ?? which will not loose data at sending and acquiring???
thanks in advance
ahsan
05-14-2015 04:54 PM
Well, async timers are an implementation of multithreading that rely on Windows multimedia timers for scheduling events; you may consider it as an application of multithreading. It's intended to give users an easy instrument to begin programming in multithreading without much effort: you can develop and debug your app using a UI timer and then switch it to async timer to execute it in a multithreaded environment without even changing the callback definition!
At the same time, this paradigm includes some constraints that may be not optimal in search for an optimized application.
Having said this, you must consider that maintaining a 10 ms regular pace with no-missing-codes requirement over a long time is *really* a difficult task, if not impossible on Windows: there are so many underlying tasks in this OS that you are never guaranteed that none of them will interrupt you at some moment. Trying to achieve this goal will imply a lot of work aimed to:
- make your app highly efficient
- tailor the OS to close or reduce time consuming activities that may interfere with your app (antivirus; automatic updates; scheduled tasks; unnecessary services; including some from NI...)
Frankly speaking, the 10ms constraint would claim for a real time environment, not for a Windows program!
05-14-2015 05:39 PM
Some additional note on the framework you depicted.
In such a fast application, and considering that RS232 can be considered a slow channel, transmission time is not a negligible aspect to consider: part of your 10ms time slice is spent simply on data transmission; how much depend on com speed and amount of data transmitted.
Consider that at 9600 baud you receive roughly a character per millisecond, at 115200 more or less 12: if you need to receive 20 bytes at 115200, almost 1.5 msec are spent waiting for messages to complete; if you are using a polling paradigm, you must add request time and the time spend by remote device to generate an answer.
That is to say: you may have very few time to interpret device messages!