10-22-2013 09:12 AM
Have had to transfer a long existing test sytem to a new computer with Win 7 (was win xp) and upgraded to LV 2013 as well (was LV 2011)
While doing cleanup, an error has started showing up that has never occured before. Screen shot below.
So I have tracked this down to this sequence. Screen shot below.
I made notes of the control values that are fed into the vi (and corresponding calculations)
Anything in this look out of wack to anyone ?
Am attaching vi as well. The case causing problems is the "PWM (Timed)" case. The error specifically points to the Wait Until Done vi which I give a full second extra for the time out value.
Appreciate any thoughts on this.
10-22-2013 10:41 AM
OK, really bad math on that screen cap
Fs should be 2000 and
#s should be 6400 or 13600 dpeending on time in seconds (3.2 or 6.8)
I increaed my allowable timeout on the daqmx write and the daqmx wait until done but have still received the error on the wait until done vi.
If I interpret this error correctly, it tells me that it is taking longer to write the information to the daq device than it used to (when I never got error on old computer)
It does this intermitently which makes it harder to debug too.
I already added another second to the timeout input but will look to add another. Problem is, if it is taking that long to write to the daq, can I feel comfortable that the information being written is uncompromised ?
10-23-2013 05:43 PM
Hi Doug,
I'm assuming that you're using the same sampling rate/number of samples as the code on the old system, correct? It looks to be within the 200kS/s spec of the device so we can rule that out in that case. If you haven't changed any other code since then, I'm wondering if this might be due to a change in performance with our card and that OS + the newer DAQmx driver. Which version of DAQmx are you currently running?
I looked into changing the buffer size, but that wouldn't do much good since the issue is that you aren't able to fill the buffer fast enough. I know this wouldn't work for your application, but do you still see the error when you use a much lower sample size/rate (i.e. half)?
10-24-2013 07:02 AM
Funny thing.
The primary issue I had when I moved this app to the new computer was an erratic slowdown (covered in this thread http://forums.ni.com/t5/LabVIEW/erratic-slowdowns-on-Win-7-machines/td-p/2592587/highlight/false/pag... )
One of the clues there was that once I had made some changes, the screen updates would occur in 1 minute increments. This seemed too odd.
I made a discovery yesterday afternoon when looking way outside the box. I have always used a utility called Caffeine to stop the screen saver from engaging while the computer is on (corporate policy on blanking the screen and requiring password to get back to it after like 3 or 5 minutes of no activity)
Turns out, this utility keeps the screen active by performing an F15 keystroke every 59 seconds. So that COULD explain the screen update issue but, would it explain the daq write issue ?
Well, when I disabled the utility, all my issues seem to have gone away. Still need more testing to confirm all is well but with the utility off, the full sequence even runs a few seconds faster.
I have found another utility that serves the same purpose but does so by making a small mouse move every minute.
I had made a post inquiring about any link with the F15 key and labview but didn't get any hits. Or perhaps there is something that happens with the win 7 OS when that key stroke is sent ?
I am going to test the very original version of the code (vers that I have succesfully been using on a win xp box for many years) to see if it all realtes to that or if any of my code changes were actually required.
Most code chages were good changes so I am not going to get rid of them but I want to make sure I have a clear idea of the actual root cause for future work.
Will post if this really didn't solve the issue or something besides just the utility caused the issue.
Thanks.....