erratic slowdowns on Win 7 machines

[Yamaeda]

I'll try to take a look at the code later, but from the pictures (which you say you've changed) i notice 2 things:

- Reading the Test control states through a property and writing to the global seems unnecessary. To convert a Enum to string it's more efficient with a Format into string with the enum. I'd also avoid the global fully and simply update the terminal, i assume there's one on the front panel you want to update.

- The same with the 2nd, if you're sending out the result array, why update a global?

/Y

[dacad]

I did get rid of both of the globals that I posted screen caps of and am now updating the front end using queue's.  The sequence performs thirteen different tests and the front end needs to be updated after each test (each in it's own case in the state machine) so the operator or technician can monitor the testing as needed.

Have never tried the format-into-string on an enum.  Will give that a try.  The property node method is something I had picked up from someone elses code.

The result array is formated into two versions.  One ergonomic set of data that goes to the front end and one raw data only that goes to the results data file.  I also eliminated the indicator for the display version in the sub-vi as it wasn't used there after initial development.

After having tested all morning, I can't get the glitch to show up.  I do have a new issues where my pressure transducer is now sending out the occasional NaN but I'm pretty sure that is unrelated.  Just weird as it has Never done that before.

Gremlins.   They must have gotten in over the weekend.

Thanks....

[Tortu]

Greetings dadcad

Yes, that is the option I was referring to. This is the default option but try unchecking it and see if there is any improvement. Make sure to do that in all the Event Structures of your code. Finally, I’m glad the bug is fading away. If it comes back, make sure to let us know if it is related to a processor or memory spike by running the task manager’s resource monitor along with your application at all times. Have a good day.

[Sam_Sharp]

A couple of things that I've seen cause issues with LV and Windows 7 are...

- Ensure that your hdd is not set to turn off after a period of inactivity - this is something that has absolutely caused us problems in the past if we've forgotten to turn it off - a problem where the time it took for the disk to spin up again was causing a function to lock up and things to stop working further down the line

- Consider if there are any background tasks that run that  (e.g. defrag? indexing service? virus scanner?)

- We have also seen a problem with front panels not updating which could be temporarily fixed my minimising and reopening the front panel to force a redraw - I can't remember what the proper fix is but I think it's Aero related

- There is also something about if you are running LV software on one PC and then remote into it from another PC and then you shut the other PC down without disconnecting first it will cause the LV software to hang

I put the first one in bold because when we've forgotten to disable the power saving on HDDs it has absolutely caused us problems in the past.

One possible thing that might help you debug the issue in your exe is to have an execution timer that sees how long it takes to execute the states of your program and if they take a long time (due to this issue) then log some debug info to disk or display it on-screen somewhere.

Also - 60 second timeouts I have seen before were due to TCP commands...possibly even VI Server issues! (I think we had an issue once where the application wouldn't start up for 60 seconds or so due to trying to do something via VI Server).

[dacad]

Will try the front panel lock / unlock option a bit later.  Went ahead and made the change on formating the enum.  Still learn something new every day.

For other stuff,   HDD was set to never turn off.  No remoting going on.   No tcp or vi server set up for this app.  

Still have not seen issue today though NaN on transducer is showing up more often.  Have been able to identify that as a non-read from the daq.  The vi doesn't get any values to process (array is empty) so some kind of com error which is weird since it is a pci daq (6014).

Will keep evaluating and posting if things reveal themselves.  Kills me to not have a specific thing I can point to that turns the glitch on and off.

Thanks for all the input and if any other thoughts come up, it is much appreciated.

[dacad]

Something new that may or may not be related to display glitch but is driving daq NaN error.  Set up error handler to troubleshoot NaN problem and got this.

This has never occured in probably 6-7 years of running this exact hardware set-up (sans computer, OS and vers of LV).   Is just today started showing up on this new system.   Going to IT to see what they might have done and not told anyone about.

This is a PCI-6014 so it is plugged straight into the bus.  I use a basic scsi cable to tie into a terminal card on the test system itself.

I have to blame this on something with the new computer, either the box itself or Win 7.  My task setup was imported from the previous system so my sample size & rate are unchanged.

Any thoughts ? 

[dacad]

So have been running resource monitor as had been suggested earlier while I debug this thing and made a very eye opening discovery.

I ran my original version first thing this morning and made note that the LabView process was consuming an average of around 4.5% of the CPU according to the resource monitor. (running in development environment)

Didn't think much of that until I switched over to the edited version and noticed it was only consuming about .25%.   That's point two five percent.   A reduction by a factor of 20.

This with the only changes made of eliminating two global variables and a property node and switching to a queue to transfer my data to the front panel at the same frequency.

I am completely astonished that it had that big of an impact.

No one in my building that I can tell that would be impressed so figured I would post it up here.

This is certainly going to make me re-think how I design some of the functions of my apps going forward.

Still doesn't give me the root cause of my original glitch but it is certainly nice to see the impact of something that I would have considered minor.

(Am going to create a new thread for the other error so as not to muddy up this one to much more.)

[Yamaeda]

---

@dacad wrote:

Something new that may or may not be related to display glitch but is driving daq NaN error.  Set up error handler to troubleshoot NaN problem and got this.

This has never occured in probably 6-7 years of running this exact hardware set-up (sans computer, OS and vers of LV).   Is just today started showing up on this new system.   Going to IT to see what they might have done and not told anyone about.

This is a PCI-6014 so it is plugged straight into the bus.  I use a basic scsi cable to tie into a terminal card on the test system itself.

I have to blame this on something with the new computer, either the box itself or Win 7.  My task setup was imported from the previous system so my sample size & rate are unchanged.

Any thoughts ? 

---

I got that last week actually! In my case it ended up being single reads looped too fast, while generating an analog out-signal. Changing to reading arrays at a slower rate solved the issue.

/Y

[dacad]

I actually started a new thread for the daqmx error    http://forums.ni.com/t5/LabVIEW/error-200016-Device-mem-underflow-with-pci-6014/td-p/2598053  

I increased my timeout by one second and so far that seems to be keeping the error from showing up though it doesn't explaing why after all these years it showed up in the first place.  If the new win 7 computer running LV 2013 is executing faster, seems like it could get away with a shorter timeout.     Just saying..........

[Yamaeda]

Ok, i've looked at the code, and in general i like it, but use the Variant! You have an excellent queue structure with command+variant, use that. E.g. in Initialize, place the Bottom loop init in the Import case and transfer the setup cluster. The same way you can skip the global loop completely, just place it in the timeout of the top loop. The PWM driver i can really recomment opening the com-port in the Init state (which should be added to the bottom loop) and then close it in the Close, and kept in a shift register in between. I'll attach my modified driver. The erratic slowdown could very well be the constant opening/closing of the com port, as mentioned in the earliest posts.

Also, if you transfer the information with the Variants, you can keep it in a shift register in that loop instead of those locals.

/Y