erratic slowdowns on Win 7 machines

[dacad]

Thanks for the input on my code Yamaeda.  Am certainly going to look to incorporate what I can. 

The Serial pwr sply driver is an old legacy vi that I never did anything with.  I utilize the TQLP dll supplied by the mfg on newer systems and do exactly what you indicate.  Open a session and leave it open for the duration and close it when exiting the test app.

I also can see the logic in re-arranging how I move the data from the lower level vi(s) to the top level and using the variant as the vehicle for that.

Moving the stuff in my global loop to the timout in the event structure is one of those too obvious things I tend to overlook.  Makes sense though.

Once thing you mentioned in your previous post has me a little confused.  You said you went from single looped reads to a slower array read to fix an analog out error.   I'm not performing any reads while that task runs so am not sure what you were referring to.  When my error pops up, it is pointing specifically to the daqmx wait until done vi.   (in the "PWM (Timed)" case in the  Loki - Motor Control.vi)

What is buggering me on this one is that I supply a specific duration for the waveform that is fed into the task. I can't understand why a timeout that is 1 to 2 seconds longer (even 3 on my last try) for the timout period still allows an error to be generated. In the last iteration, I added a second to the wait until done vi making it one second longer than the timeout for the write task vi.  If the task didn't timeout, why would the wait until done timeout ?   I'm so confused.

I have to make sure the task is complete (the pulsed analog out is fully executed) before proceeding to the next steps to determine if the unit under test performed as required.

That is telling me that my task is taking much longer to execute than it should.   Or am I looking at it wrong ?

I think the actual analog pulse duration is accurate as I scoped it a couple times this morning to verify the true analog out time though used a different calling vi so it wasn't a true replication of the test sequence.

Appreciate very much the input and will tag the buttons when I get things wrapped up.

[Yamaeda]

---

@dacad wrote:

Once thing you mentioned in your previous post has me a little confused.  You said you went from single looped reads to a slower array read to fix an analog out error.   I'm not performing any reads while that task runs so am not sure what you were referring to.  When my error pops up, it is pointing specifically to the daqmx wait until done vi.   (in the "PWM (Timed)" case in the  Loki - Motor Control.vi)

---

Yes, it took me quite some time to figure out also, but in my case it was 2 separate tasks, not related, that caused problems for each other. That might not be the case here. One of the issues i got was buffer underflow, which i solved by usinga DAQmx property node and changing the buffer size as needed.

/Y

[dacad]

Funny thing.

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 (screen updates in 1 minute increments ?) 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 (Will kudos appropriately before I wrap this up) 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 the final outcome of this just in case someone else ever runs across trhe problem.

Am thinking I may look at making a tiny LV app that keeps the screen saver from kicking in (cause I don't know any other programming languages).  But that will be for a different day.

Thanks.....

[Yamaeda]

Disable screen saver

That should solve the last problem. 🙂 (ofc you might need some rights, in which case the mouse mover is an easier solution)

/Y

[Yamaeda]

Move mouse

/Y