souske Posted April 11, 2008 Report Share Posted April 11, 2008 Hello, I'm trying to get loop speed and I've got result that I have not expected. I set "wait until next ms multiple" to values from 10ms to 0 ms and I want to check how fast the loop runs. Can anyone explain why when I set 1ms I get 2ms? Is there something wrong with the vi structure? I attach vi that I use (created in LV8.2). Download File:post-1959-1207817923.vi Quote Link to comment
gleichman Posted April 11, 2008 Report Share Posted April 11, 2008 I ran your test and I saw similar results. When the wait time was set to 1 ms, the average wait time was close to 2 ms. BUT, "wait until next millisecond multiple" vi is not made for critical timing. At 1 ms it is probably running up against a wall of how fast it can go back and forth between the OS. The wait until vi is like a sleep command that allows the OS to perform other tasks. If you are looking for better timing use the timed loop. I replaced the while loop with a timed loop in your example and I observed a measured time of 1.025ms for a setting of 1.0ms. Download File:post-151-1207831749.vi Quote Link to comment
crelf Posted April 11, 2008 Report Share Posted April 11, 2008 QUOTE (souske @ Apr 10 2008, 05:02 AM) I'm trying to get loop speed and I've got result that I have not expected. What OS are you using? Alan's comments are absolutely valid, but you might also want to consider http://forums.lavag.org/blog/crelfs_technology_articles/index.php?showentry=116' target="_blank">determinism. Quote Link to comment
souske Posted April 11, 2008 Author Report Share Posted April 11, 2008 Too much time with Windows, and I totally forgot that TimedLoops were made for RT targets. With TimedLoop on cRIO I also get nice 1.01 ms, but even cRIO can't squeeze 1ms from a standard "while" (with RT version of "wait until..." ). Thanks for the reminder! Quote Link to comment
crelf Posted April 11, 2008 Report Share Posted April 11, 2008 QUOTE (souske @ Apr 10 2008, 09:18 AM) Too much time with Windows, and I totally forgot that TimedLoops were made for RT targets. With TimedLoop on cRIO I also get nice 1.01 ms, but even cRIO can't squeeze 1ms from a standard "while" (with RT version of "wait until..." ). I don't know anything about your application, but have you considered doing your ultra-time-critical work in FPGA? Or maybe some of it and then stream data as needed to the RT host? Quote Link to comment
Mellroth Posted April 15, 2008 Report Share Posted April 15, 2008 QUOTE (souske @ Apr 10 2008, 03:18 PM) With TimedLoop on cRIO I also get nice 1.01 ms, but even cRIO can't squeeze 1ms from a standard "while" (with RT version of "wait until..." ). If you enable us support on the cRIO you can probably get closer to the 1ms target, by using the RT specific "Wait until next multiple" with 1000us as input. /J Quote Link to comment
souske Posted April 15, 2008 Author Report Share Posted April 15, 2008 QUOTE (crelf @ Apr 10 2008, 04:54 PM) I don't know anything about your application, but have you considered doing your ultra-time-critical work in FPGA? Or maybe some of it and then stream data as needed to the RT host? That's what I was planning to do. The thing is that right now I'm testing several different options and want to choose the best one for the system I am creating. I can see that with cRIO one has many possibilities to group the code according to its time priority. Not only by using loops with different priorities on the RT part but also by using the FPGA. QUOTE (JFM @ Apr 14 2008, 08:35 AM) If you enable us support on the cRIO you can probably get closer to the 1ms target, by using the RT specific "Wait until next multiple" with 1000us as input. /J I didn't know you can actually enable us support for cRIO. How do you do that? Quote Link to comment
Mellroth Posted April 15, 2008 Report Share Posted April 15, 2008 QUOTE (souske @ Apr 14 2008, 09:40 AM) I didn't know you can actually enable us support for cRIO. How do you do that? It might depend on the type of cRIO you are using, we had a cRIO-9012 controller where we used us timing without any problem (the actual resultion in the timed loop was more like 50~80us). To enable MHz support, have a look at these links on NI.com: http://digital.ni.com/public.nsf/allkb/0C0...6256F6700061790 http://digital.ni.com/public.nsf/allkb/5B1...13?OpenDocument Please note that enabling MHz support will also take a lot more CPU, and that is the reason that it is not enabled by default on some RT targets. /J Quote Link to comment
Ton Plomp Posted June 17, 2010 Report Share Posted June 17, 2010 This was narrowed as a bug inwindows XP/LabVIEW combination. Ton Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.