erratic slowdowns on Win 7 machines

[dacad]

I don't change visibility but do change the enabled state of a couple controls at the very beginning and very end of the sequence.  The glitch usually seems to occur early in the sequence though not at the very beginning.

Can't rule out a race condition though seems like that would have affected earlier versions as well.  Was just reading another thread about the use of global variables and trend seems to be that they are great for write once / read many situations.   I actually use a couple for write many / read once (actually read repeatedly in once location via the top vi 'while loop') values to update the front panel to current part of sequence being executed, current load point and updated table of full sequence results. Again, has worked without any issues up to this point on other computers / LV versions.

Behavior has changed a little since I have been tweaking display code.   Display will still stop updating while all other functions continue working.  Actual sequence time is now staying normal but it takes another 30 seconds to couple minutes before the screen updates to display the end of sequence information and that it is ready for another sequence.  All results are recorded and saved to file as expected.

As has been the case, when the glitch occurs, the current time that I show on the front panel stops updating along with everything else or it updates just every 20-30 seconds or so.  It's as if that loop is getting stuck.  Perhaps something in my code eating up all the processor threads (or what ever it's called. a little outside my  expertise)

All my subs are defaulted to Same as Caller for execution.

Thoughts ???

[dacad]

A new clue.

Have been watching this thing run all day (booooooring) looking for clues and trying new things.   As per earlier post, I think I have things rearranged a bit so that it no longer causes an actual delay in the sequence, but rather only in the display update (and options presented thereof)

Watching the last sequence that diplayed the glitch, the time display stopped at 2:49:46  (h:mm:ss).   It started back at around 2:50:42 or so and promptly stopped again at 2:50:46.  It then did not update again until 2:51:46.   The display stoped in one minute increments.  It may or may not start back before the next minute increment but then stopped again at the next full minute increment.

Too weird.

And it only does this once out of every 10-20 sequences.

Once the sequence is done and the display catches back up, the time display updates normaly, counting off the seconds and the next sequence will (almost all of the time) run normally.

This cannot be a coincidence.   But what is it telling me...........

[Yamaeda]

So what is happening in these sequences? As mentioned earlier, are you opening alot of visa, activex or .net connections? Are you closing them? Do you have some memory leak or arrays that grows that cause memory thrashing after 3h? If those globals do get a race condition, could it get stuck in some loop? Do you have no-wait polling loops that could cause slowdowns? Can you post some code? 

/Y

[Tortu]

Greetings dadcad

You mentioned your application uses some event structures. Could it be that the "Lock front panel (defer processing of user actions) until this event case completes" option is checked?

[dacad]

Yea, time to post a little code I guess.  Do have one thing I am in the process of trying to see if it has any effect. Am getting rid of two of the global variables and switching to queue's to update the screen instead.  This based on a thread I read about alternatives to global variables.  I'm a bit skeptical that it will help but am needing to get this thing going and if it works, I won't argue with the results.

Will post code in a short while.  Have to sanitize a few visible identifiers due to corporate mandates and such.

To be continued .....

[dacad]

Have posted code here.  This is last iteration I have been running before making a copy to try the queue approach for screen updates.

This version appears to not cause the actual sequence to pause as it was earlier but still causes the front panel to not update for periods of time (still odd, the one minute increments)

The main change that seems to have stopped the actual sequence from slowing down is that I moved the update for the current test global variable (in the Loki - Test Sequence.vi) from being inside each case to one instance in the loop.  The 'Test Control States' Strings property node was also originally inside each case and I moved it to outside the loop since it really only needs to generate the string list once (yea, I was in a rush first time around).

The Loki - Test Sequence.vi is where all the action is.  The two globals, Current Test and Test Results are the main screen updates.  There is also a global for the current load that updated via a global whenever the Loki - Read PT.vi is called.

Other than that, it is pretty much unchanged.  I am sure there are other aspects of the code that will be horrifying to look at but I learn as I go.

Thanks for taking the time to look at it

Doug

[dacad]

So have done some testing with using a queue to transfer the info to my front panel.  Seems to be working ok though updating cluster elements worked a bit different than I was expecting.  If you only update one element going into the enqueue vi, it blanks out the other element(s).  Was able to work around that.

Added an additional while loop in top level vi to dequeue every little bit to keep the front end updated.

Still using one global var to track load point and this is deeper down so a queue is less practical for that.

Time will tell if this resolves the glitch completely.  Still troubling is why the previous method was causing the glitch.

What I replaced was the two instances shown below where I write to the two seen global variables.  I have not changed any of the supporting structure that feeds the info, just how it gets transferred to the front end.  I really don't see why this would cause an issue unless I am just flat missing something.

On a side note, I was doing a sequence with highlight execution turnd on in the same lower level sequence vi (before changing to queue) and there was an incredibly long pause (even for the slowed highlight execution mode) when the flow got to the In Range and Coerce function shown below.  Not sure what that was all about.

For my manager, all that counts is that the system is up and going.  For me, I want to know why it does the weird things it does so I have the ability to know what not to do in the future.

Any thoughts are appreciated.....

Doug

[dacad]

Buggers. 

After cleaning up code from changes, first run displayed glitch.  Again, the one minute increments on front panel updates. Affected items fed by remaining global variable AND items fed by queue. This even though the gv's and queue's are updated in different top level loops with different wait times.

Beginning to think more and more that LV is not the culprit here.  If the sequence continues to execute while the display becomes static, this I would believe would have to be a system issue.

I'm just completely stymied at this point.

[Tortu]

Greetings dadcad

Did you confirm that the event structures are configured so that they don't freeze the Front Panel?

Have you tried using the Task Managers tool to verify this is a system issue? (Spikes of processor or memory usage?)

Let us know. Have a good day.

[dacad]

For the event structure ...  freeze front panel, is this the checkbox you are referring too? (the one just to the right of the Remove button)

This is checked, by default I guess since I have never made it a point to change that setting.   The event however is only to enqueue an element and write a global variable (true case that initiates the sequence under scrutiny here).  Thing is, the sequence will start and the display will update for some period before it goes limp.

I have been running the resource monitor while testing all morning but as luck would have it, the glitch has not shown up yet so will continue to monitor that while I run during the day.

Open to any suggestions on what else to try here.....

Thanks

Doug