Freeze Windows

[Robert.Bedford]

I don’t normally ask for others to problem-solve a VI for me, but I have hit an impasse on this relatively simple VI. Seemingly randomly, the program, while running, will cause Windows to freeze. There is no reaction from the keyboard, the mouse, CTRL-ALT-DEL, etc. I must do a hard-reboot in order to do anything.

Moreover, due to the nature of the “crash,” I have a difficult time using highlight execution, etc to find the problem. I therefore ask that if anyone has a few minutes, if you could look over the block diagram to see if there is anything that might cause a memory allocation error or something that would be powerful enough to cause Windows to freeze.  I know there are others who have had somewhat similar troubles, but they don't seem to be quite the same thing.

A few stats:

• I am running Labview 8.2, upgraded from 7.1 (actually, 7.1 was fully uninstalled and 8.2 was subsequently installed)
  
• This VI was originally made in 7.1 and I never experienced this crash, HOWEVER-> Once I upgraded to 8.2, I did some VI upgrading, particularly using queues instead of arrays.
• This is running on Windows XP with Service Pack1
• This is an unnetworked computer and there is no screensaver or any power saving functions on
• The problem occurs when running the VI as well as running a compiled .exe of the same program.
• The VI always will crash in the second frame of the flat sequence (though this shouldn’t be surprising because it spends the vast majority of its time in this frame).
• I have never had problem with the subvi (Det Current.vi) in any other VI I have used, so while I am not sure, I don’t believe the trouble to be in the subvi.
• The communication is GPIB over 488.2 using a PCI-GPIB card.
• I think I get the following chain of events logged in the event viewer when it crashes, but am having trouble interpreting them.
  First, there is an error caused by the “eventsystem”:
  Event Type: Warning
Event Source: EventSystem
Event Category: (54)
Event ID: 4353
Date: 1/10/2007
Time: 8:54:23 AM
User: N/A
Computer: RSNDZZ062003188
Description:
The COM+ Event System attempted to fire the EventObjectChange::ChangedSubscription event but received a bad return code. HRESULT w s 80040201.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp
  
  This is followed quickly by an error with the “NI Variable Engine” with the following log (dont look at the relative time, they are usually within a second or two from eachother. This case I took examples from different freezes):
  Event Type: Information
Event Source: NI Variable Engine
Event Category: None
Event ID: 0
Date:1/9/2007
Time: 10:29:10 AM
User: NT AUTHORITY\SYSTEM
Computer: RSNDZZ062003188
Description:
The description for Event ID ( 0 ) in Source ( NI Variable Engine ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event:

NI Variable Engine started.
Executable: C:\Program Files\National Instruments\Shared\Tagger\tagsrv.exe
Plug In Path: C:\Program Files\National Instruments\Shared\Tagger\
Plug Ins: LogosRTServer, NI OPC Server Plugin., LogosRTClient.

There is no informaion on error 4353 on Microsoft's website (following the link above). I thank you for your eyes and your time, and look forward to any suggestions you might have to solve the problem.

/Robert

[johnsold]

Robert,

I have no idea whether Windows freezes because of this, but it is generally not a good idea to have multiple event structures in a VI, especially as you have used them, looking at the same events while executing in parallel loops. Read the help file on event structures.

Use a notifier or queue to tell the other loops that a "halt" event has occurred.

You also do not need the flat sequence structure. The dataflow of the error clusters and queue refnums will provide the same sequencing. The local variables can be replaced with wires (and maybe a shift register).

Lynn

[altenbach]

I don't have your VISA hardware, so I cannot test. Except for the scary color scheme, I cannot see anything "seriously" wrong on your diagram. 😉

Just curious, why is "Responsivity (A/W)" type EXT, causing all these coercions???

If you take all the VISA stuff out and substitute simulated data, do you still get the same problem?

[Joe_H]

I am not sure why it is "freezing up" but you have three event structures firing off of the same event (stop, restart, running samples) and they are all set to lock the front panel. This cannot be done. This will cause the program to hang the way that you have the code structured.

You should only have one event structure and use some type of producer consumer architecture. the way you have everything coded up now it will not be easy to maintain the code or perform general maintenance on it.

[altenbach]

---

@Jhoskins wrote:

I am not sure why it is "freezing up" but you have three event structures firing off of the same event (stop, restart, running samples) and they are all set to lock the front panel. This cannot be done. This will cause the program to hang the way that you have the code structured.

---

Of course it can be done! There should be no problem having multiple event structures as you did here. Even with lock front panel enabled. All you events are in seperate loops and all events do relatively simple short tasks. And all exit under the same condition.

One problem might be the upper loop, for example "if Read Detector Current" inside the subVI takes forever for some reason.

A few tips for the upper loop. You might want to handle errors, e.g. exit on error. Also, you should wire the error and Visa resource across in all event cases. Currently, the VISA resource is always invalid after exiting the upper inner loop, thus the VISA resource that you openend will never be closed! This might be the real problem.

(Sorry, I don't use VISA so others might have more specific recommendations).

[Joe_H]

Yes it can be done. but should you do it.

Also this VI may be corrupt. It seems that I cannot delete any of the controls or indicators without changing them to a constant first. Anyone else have this problem.

Wierd.

[johnsold]

I can delete from the panel, but not from the diagram. This may be because many of the controls/indicators are grouped. I don't think I ever tried to delete a control which was part of a group, so I don't know how it should work.

Lynn

[Joe_H]

sure enough when you ungroup them you can delete it. I never knew that. Well looks like I learned something new today after all.

[Robert.Bedford]

Sorry I have not responded.  Here is a quick wrapup of some things I have tried:

---

johnsold wrote:
Robert,

I have no idea whether Windows freezes because of this, but it is generally not a good idea to have multiple event structures in a VI, especially as you have used them, looking at the same events while executing in parallel loops. Read the help file on event structures.

Use a notifier or queue to tell the other loops that a "halt" event has occurred.

You also do not need the flat sequence structure. The dataflow of the error clusters and queue refnums will provide the same sequencing. The local variables can be replaced with wires (and maybe a shift register).

Lynn

---

I have reworked this such that only one event structure will check the stop/restart/valchange items and it will send a user-defined event to the other loops to stop if necessary.  However the windows continues to crash/freeze.  The flat sequence is more for my organization than anything else.

---

altenbach wrote:

I don't have your VISA hardware, so I cannot test. Except for the scary color scheme, I cannot see anything "seriously" wrong on your diagram. 😉

Just curious, why is "Responsivity (A/W)" type EXT, causing all these coercions???

If you take all the VISA stuff out and substitute simulated data, do you still get the same problem?

---

Good catch on the EXT.  I have reverted these back to DBL in both the subvi and the main vi but the crash/freeze still occurs.  I have substituted simulated data, but have not given it enough time to run to see if it crashes.  I will try to do this.

---

altenbach wrote:

---

Jhoskins wrote:

I am not sure why it is "freezing up" but you have three event structures firing off of the same event (stop, restart, running samples) and they are all set to lock the front panel. This cannot be done. This will cause the program to hang the way that you have the code structured.

---

Of course it can be done! There should be no problem having multiple event structures as you did here. Even with lock front panel enabled. All you events are in seperate loops and all events do relatively simple short tasks. And all exit under the same condition.

One problem might be the upper loop, for example "if Read Detector Current" inside the subVI takes forever for some reason.

A few tips for the upper loop. You might want to handle errors, e.g. exit on error. Also, you should wire the error and Visa resource across in all event cases. Currently, the VISA resource is always invalid after exiting the upper inner loop, thus the VISA resource that you openend will never be closed! This might be the real problem.

(Sorry, I don't use VISA so others might have more specific recommendations).

---

Thanks for this reply.  I was concerned that I was misinterpreting the help file on the events.  If there is no timeout on the Read Detector Current command, the VI could be stuck waiting for a reply from the equipment, however in my experience, that only causes the program itself to seemingly stop.  I would be able to stop the VI and fix the problem that way.  That has not (historically, for me) caused Windows to freeze/crash.  To be clear, I can not do anything once the freeze occurs (no mouse, no keyboard, no CTRL-ALT-DEL, etc). 

Also, I will fix the VISA session closing issue.  This is also a good catch  However, I can't forsee the VISA session not closing to be causing the freezing problem because it freezes while the program is running, before a VISA session would be closed.

I want to thank everyone for helping out.  More ideas are welcomed!

Robert

[altenbach]

Just in addition to everything else that has been said, don't rule out a real hardware problem with the PC.

Disk: scan for errors and defragment.

Memory: test all memory, e.g. using the microsoft tool: http://oca.microsoft.com/en/windiag.asp

Check the motherboard voltages.

Check CPU temperature and CPU fan rpm.

etc.

It could just be that something is borderline bad and heavy CPU use together with the GPIB use pushes the system over the edge after a while.