Windows Media Player makes NI-Motion calls faster (revisited)

[chvogt]

About 2 years ago I posted a message on this forum about a condition where running Windows Media Player increased the rate that my Visual Basic 6 program was able to communicate with a PCI-7344 board using NI-Motion calls (original post). To summarize the post, my VB program would call NI-Motion functions at a reduced speed after the computer is booted and simply running Windows Media Player would allow my program to make NI-Motion calls faster. I created a demo program, posted it, and was able to reproduce the situation consistently using several different computers & PCI-7344 boards. However, no one at National Instruments could reproduce this; it appears the function calls always ran fast for them and never ran slow. I finally gave up and let the issue die and have been reluctantly telling our customers to just start WMP to increase the speed of the machine.

Now I am working on rewriting the software for the machine using VB.NET 2008 & Windows 7. My initial hope was that the problem had gone away with either the new VB or Windows 7 but that doesn't seem to be the case. When I was using Windows XP, I could get the increased function call rate just by running WMP. With Windows 7, I can't get the increased rate even after running WMP.

Today, I took two identical new computers and loaded Windows XP on one and Windows 7 on the other. I put a new PCI-7344 card in each computer. I then installed version 8.2 of NI-Motion on each. With the exception of Microsoft .NET 3.5 which is needed for my VB.NET test program, no other software was installed, not even Visual Basic. I booted each PC, ran my test program to determine the calls/sec, started Windows Media Player, and ran my test program again. Here are the results:

   Windows XP & VB 6 test program - 128 calls/sec before running WMP, 1024 calls/sec after running WMP

   Windows XP & VB.NET 2008 test program - 128 calls/sec before WMP, 1024 calls/sec after WMP

   Windows 7 & VB 6 test program - 256 calls/sec before running WMP, 256 calls/sec after running WMP

   Windows 7 & VB.NET test program - 256 calls/sec before running WMP, 256 calls/sec after running WMP

As you can see, WMP increased the NI-Motion function call rate on Windows XP but had no effect in Windows 7. Also, it didn't matter which version of Visual Basic was used.

My first question is: what determines the rate that a call to a NI-Motion function is made? It seems like the maximum rate is 1024 calls/sec, which is consistent with what I was seeing 2 years ago even on slower computers. I would have thought that a faster PC would mean the function calls could also be made faster but that doesn't seem to be the case. And, is there some significance to the 128, 256, & 1024 rates?

My next question is: has anyone else noticed faster or slower speeds using NI-Motion after switching to Windows 7?

The software I am working on controls a machine used on a production floor where cycle time is critical and even saving a fraction of a second can be important. With Windows XP, we were able to reduce the cycle time by 5 or 6 seconds just by running WMP. We would like to start using Windows 7 but we won't be able to if it means slower cycle times on our machines.

The VB 6 & VB.NET 2008 source code for the demo program is attached. This is the computer I used for testing today, but I have also been able to reproduce this on Dell, Nematron, Xycom and Allen-Bradley computers. I've also used several different versions of NI-Motion and WMP with the same results.

[iZACHdx]

Hello,

I ran your benchmarking code as well and cannot reproduce the issue. Before running WMP on Windows 7:

After running WMP on Windows 7:

I am running NI-Motion 8.1 on this machine. The computer is a Dell Precision 390 with 2GB of RAM and a Core 2 1.86GHz processor.

-Zach

[chvogt]

Thanks for your reply.

Does your computer have additional software loaded onto it and is it connected to the internet or a network? The condition that I am seeing is that the communication with the board is slow after the computer is booted until certain applications are executed. The machines that we use these computers on are not connected to a network or the internet and only have the necessary device drivers installed with no other software loaded.

It's also important to note that only calls to NI-Motion functions are affected. I've tested calls to NI-DAQmx functions also and they do not see the speed change when Windows Media Player is executed. I've also tried just running calculation loops to verify that the processor and/or Windows isn't running slower and there doesn't seem to be any affect.

[chvogt]

I did some more tests with this today and could only get the communication rate to increase in Windows 7 if I ran Microsoft Virtual PC. The rate would remain high as long as Virtual PC was open and would revert back to the slow speed once I closed Virtual PC. This behavior is different in Windows XP where I can use Windows Media Player, Internet Explorer, & even NI-MAX to increase the speed and the speed will remain higher even after closing the software.

I also spent some time using Windows Event Viewer to watch the Windows services & processes but didn't notice anything unusual when Virtual PC was started or closed.

I've attached some PDFs to illustrate the tests I did using Windows XP & Windows 7. Note that I used 2 different PCI-7344 boards and 2 different industrial PCs for the XP & Win 7 tests; however, the boards and PCs are all brand new (just received a week ago).

It's very frustrating that only our customers and myself are able to reproduce this problem but no one else has been able to so far. It would be nice to know if I'm doing something wrong here, but I can't imagine what I'm missing.

[iZACHdx]

Hello,

Yes my computer has additional software and is connected to the internet. I will see if there is any way I can try this on a computer that has less software and drivers installed

-Zach

[iZACHdx]

Hello,

Here is what we are thinking may be a possibility. Since your computers are stripped down to the bare minimum, this could be a dll that is getting loaded and unloaded with Motion each time it runs. During development of the driver, this could have been a low level dll that was always loaded into memory because of some other piece or software or other process on the computer. When you run WMP or Virtual PC Console, that particular dll may get loaded persistently which makes calls through that dll via Motion quicker. If you try running Process Explorer on your computers, we may be able to identify which ones are being used on your system and see if there is one getting loaded and unloaded when you get a low number of calls versus it always being loaded when you get improved performance.

-Zach

[Eric_R]

We have reproduced this on a system here, there should be a throttle in place to keep the board from being called at rates higher than 1 ms. At rates higher than 1 ms readings from the board are voided and can cause a potential hang on the board itself as the internal queue runs into difficulty handling the number of repeated requests. Most calls on the usually take longer than 5ms. In this application what is the end use of the boards in the application? If this is propriatary you can send me a private message and we can get in contact.

Right now, I am looking into this to see if any other calls in VB are affecting the throttle, my understanding is that this occurs on a bare bones system, after installing .net framework I noticed the system ran considerably faster but a reboot returned things to normal behavior (the 128 calls per second). I also need time for some more expirmentation to see if the issue is local to VB or also lies in C++ and LabVIEW. Have you tried any other languages?

[chvogt]

Thanks for your response.

I've spent a lot of time using Process Explorer and my test program in Windows XP but so far I haven't seen anything getting loaded & unloaded during or after running my test program. Running Windows Media Player also doesn't seem to affect the loaded DLLs.

The motion board is being used on custom built machines that run tests on seatbelt retractors on the production line. Immediately after a retractor is assembled it is installed on our machine and tested. The motion board controls 3 motors but is usually only moving 1 motor at a time. The digital I/O port on the motion board is connected to an opto I/O rack that is used for monitoring and controlling machine I/O. A typical process in my software might be commanding a motion and monitoring the motion complete status while also checking the I/O rack for machine fault conditions (light curtain obstructed, shop air fault, etc.) I have modified my software to limit the calls made to the NI-Motion driver and it has helped speed things up somewhat, but we only really see the speed increase after running Windows Media Player, at least on Windows XP machines.

What I don't understand is why the communication is slowed down on Windows XP machines so most calls to NI-Motion are taking about 8 ms (128 calls/sec) after booting. Running an application like Windows Media Player increases the speed to about 1 ms (1024 calls/sec). I assume the 'throttle' you are referring to is within the NI-Motion driver itself, and it does appear that it is limiting calls to no more than 1 ms, but only after running Windows Media Player. I have tried adding simple calculation loops & loops that call NI-DAQmx functions to my test program and these are not being affected. It appears that only calls to NI-Motion are affected.

I have been able to reproduce this on many different computers and even ones that have several different applications loaded. For the sake of testing this condition, I have been trying to only use stripped down PCs to remove as many variables as possible. I have only tried this using Visual Basic 6.0 and Visual Basic .NET 2008.

I hope this answers all of your questions and I appreciate the time you are spending trying to solve this problem for us. Please let me know if there is anymore information I can provide to you.

[chvogt]

I modified my test program to call 'flex_check_move_status' instead of 'flex_enable_limits' inside of the test loop since this is a more common function to be called repeatedly within a loop.

The timing was slightly different (128 loops/sec before WMP, 743 loops/sec after WMP) but the behavior was the same; running WMP increased the rate that the function could be called.

I suspect the results will be similar using other NI-Motion functions as well.

[Eric_R]

Hi Cvogt

I have finished testing with LabVIEW and C++ the issue appears to be specific to VB. Our C++ and LV testing showed just a little under 1000 calls per second. This is what I was expecting and matches with the expected behavior of the throttle. The interesting thing with VB is that it is so predictable the number of calls performed. This really points to this being an issue with how the sleep thread is being handled. You are also correct in that this behavior falls across most other calls similarly.

Since the issue deals with VB and not Motion as a whole, I believe we will need to look into a situational fix, we will not make changes to the motion dlls. If you can contact ni support and have them reference this forum post we can work on opening up some additional possibilities for you to code your own sleep thread and throttle. I would like to address this work around with you on a by case means, as we will need to work together to make sure everything is operating properly for the card after the work around is in place.

Hope to hear from you soon.