vi hangs

[RavensFan]

Because the program is scary?

How large is your monitor?  When I opened it, it was so large I didn't see any window borders, and my taskbar which is always at the bottom of the screen disappeared!!!  I was able to get the taskbar to flash up and select maximize to get the window back within screen dimensions.

You were still missing some subVI's that were being searched for in the "VEP" subdirectory which did not exist in your zip.

You also have some broken wires towards the bottom of your VI where cluster types are being run into I32 and other clusters are mismatched.

You will need to clean up your VI some more if you expect any help.

[LVCoder]

Hi,

You saw the broken wires because you didnt open the correct VI.

As i mentioned in one of my previous posts you got to navigate to BERA-> Test-> BERA Test.vi .

BERA Main.vi which you were trying to open is not the main VI.

Pls open BERA Test.vi in the "Test" folder.

Ritesh 

[GerdW]

Hi ritesh,

"BERA Main.vi which you were trying to open is not the main VI." 

So much for self-explaining code

That's maybe one reason for so few people to help you. Give clear description, clenup vis before attaching, attach the whole/needed hierarchy...

[johnsold]

Ritesh,

While I cannot see an immediate explanation for your "hanging VIs," I see some things which might contribute.

1. Use of local and global variables and Value property nodes are slower than wiring the data directly and may lead to race conditions and other problems.

2. The consumer loop and the two loops at the top have infinite timeouts.  It nothing is queued by the producer loop, nothing will happen.  If the value of H/W is false and Bytes at Port never exceeds 64, the program could cycle through the timeout case indefinitely without putting anything into the queue.

Have you tried execution highlighting during the freeze to see what is happening?

Lynn 

[LVCoder]

Ok!
I am extremely Sorry for putting up such confused VIs. I have cleaned up my folder and now you can open BERA main to run the program.
 
The program might look big because there are 4 loops running parallely  and i have put them in vertical order.
 
There is some preprocessing stuff(reading settings file) that is done before the loops start executing.  When ran, it'll open i Vi called "Ask for H/W data.vi" which will keep writing a string to the H/W after every 100 ms. When Stim button(3rd from right) is set to TRUE, the program will stop  "Ask for H/W data.vi" and will start "Ask for Wave data.vi".
 
I hope you dont get any irritating error after this.

[LVCoder]

---

johnsold wrote:

 1. Use of local and global variables and Value property nodes are slower than wiring the data directly and may lead to race conditions and other problems.

---

I know and i am only using Globals where i want to communicate with other VIs which are called dynamically.

And, presently i dont know of any method of passing data to a VI which is called dynamically. Please let me know if there is a better workaround.

---

2. The consumer loop and the two loops at the top have infinite timeouts.  It nothing is queued by the producer loop, nothing will happen.  If the value of H/W is false and Bytes at Port never exceeds 64, the program could cycle through the timeout case indefinitely without putting anything into the queue.

---

Yes, they do have infinite timeouts. and nothing will happen if nothing is queued. That is why i have used Error Out from Deque function to terminate the loop. After the Producer loop is terminated by pressing the Exit Button, all the references to the queues are closed which will force other loops to terminate as well.

 If the value of H/W is false, there wont be any data at the port as when the value of H/W changes to false, it will abort both the VI's asking H/W for data. 

This is the case in my program:

 The H/W on its own wont send any data to the port. Only when the program writes something to the H/W, it'll send data according to the command it recieves from the program. So when the H/W value changes to false, both the VIs(Ask for H/W data and Ask for Wave data) are aborted and the queue and the serial port is flushed.

[johnsold]

Ritesh,

Try the Method: Control Value: Set on your Invoke node.  I rarely use dynamically called VIs so I am not familiar with the limitations of the method.  A quick glance at the help files found it.

The reason I asked about the infinite timeout was that I wondered if this was what you were seeing when your program "hangs."  It may just be waiting for something to happen.

Try putting an indicator on the "i" terminal in each loop.  This will tell you which loops are running and how fast. Post what you see during the hangs.

Lynn 

[LVCoder]

Well i tried using "i" in each loop to keep track of how fast the loops are running.

and when the VI hangs, all the loops comes to hault. the "i" indicator i each loop stops increasing.

Another thing i noticed is when the VI hangs, the event that was to occur at that point didnt get triggered. i put a random number at the starting of the "stim:value change" event. and when the value of "stim" was changed, the VI hang without changin the value of the indicator of the random number. 

[johnsold]

Ritesh,

OK.  Since it will restart after some time, the whole program has not quit.  The only way I can see for all the loops to stop iterating is for the producer to not put anything into the queues and to not execute the timeout case.  Therefore, by elimination, the producer must be in one of the other event cases when the VI hangs.  Put some kind of indicator in each event case to see if you can identify where it goes when it hangs.

I looked through the cases and the only thing I saw was the Hardware is Not Responding dialog in the timeout case.  Is there any way that the dialog is somehow off the screen?

Lynn 

[altenbach]

---

ritesh024 wrote:

Well i tried using "i" in each loop to keep track of how fast the loops are running.

and when the VI hangs, all the loops comes to hault. the "i" indicator i each loop stops increasing.

---

You can only tell that the FP no longer updates, you cannot tell if the loops actually stop. DO the loop numbers jump up when the stall is over?

A quick code review would find many inconsistencies and troublespots, but I doubt most would cause a hang as observed. Still it would be a good idea to check some of these things.

• You have U16 data but carry it around as DBL. Why? That's 4x more memory.
• You have many overlapping controls on the front panel, causing redraw issues.
• Are any of your fancy buttons customized for the hover effect using unsupported features?
• A lot of your code is exceedingly complicated and could be done with near atomic operations, for example, have a look how you typecast inside "break into data...."(see image). For some reason you go to I32, so if you need that, you would add a "to_I32" conversion after the typecast.
• What's with all the value properties! Keep things in shift registers.
• Lots of "dead code". e.g. why is the STIM change queue wired into the lowe loop structure? It's not used there!
• For some reason, many subVIs reset a control to defaults near the end of the execution. Why? Next time it gets called, unwired controls well be at the default anyway and wired controls will get new data from the connector.
• You also have quite a few "reinit to defaults" property nodes scattered throughout the program. Make absolutely sure there are no events associated with them, because they will fire.

Message Edited by altenbach on 05-05-2009 02:10 PM