LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

vi hangs


johnsold wrote:

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. 


The only event that would still be executing when the VI hang would be timeout event. 

The queue in the loop at the top(Write to Instrument) does not recieve instruction from the Producer loop. the VIs "Ask for H/W data" and "Ask for Wave data" enqueues element in the Write to instrument queue. So, if you suspect that the Producer loop has stopped sending data to other queues, the loop at the top would still be running.

 

 


johnsold wrote:

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?


 

 No that is not the case. Bcz when the "Hardware is not Responding" dialog is called, in that structure it sets the H/W value to false. and when the VI hangs, the value of H/W is True.

0 Kudos
Message 21 of 29
(716 Views)

  • You have U16 data but carry it around as DBL. Why? That's 4x more memory.

Thats the careless way of coding i do. Well in the code somewhere i am doing the interpolation which converts the data to DBL. I have converted the output from the Interpolation VI from DBL to U16.

 


  • 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?

 


Well there's only on the top wheretwi clusters overlap on each other. i need to present them that way.

What are redrawing issues ?

 

The fancy buttons doesn't seem to be any problem. as i tried replacing them with simple LV buttons and still faced the same problem.

 


  • 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.

Gosh!! that was so simple ..Honestly i didnt know about this Tyupe cast function.. like how to use it and where to use it. thanks for pointing out.

Could you pls pick out some more areas in the code where you think the task would be achieved using minimal operations?

 


  • 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!
 

Ok! i have put them in the Shift register. butwould only help the reading cause, right? as i have to use property nodes to write value to the control.

 

yeah there's some dead code. i think i was to use the STIM change queue in the lower loop, but wasn't needed later.. i have cleaned it up.

 

 


  • 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.

well even i thought of this. But this doesn't happen to be the case. If the control was unwired i was getting the previous value that was passed to the control and not the default.

 

Yes, i am using Reinitialize to Default invoke node in a lot of places in the code and none of the controls will fire any event.

 

 

 

0 Kudos
Message 22 of 29
(712 Views)

ritesh024 wrote:

But this doesn't happen to be the case. If the control was unwired i was getting the previous value that was passed to the control and not the default.


That is absolutely not true. Can you give an example that demonstrates this?

 

 

Here's the proof for the opposite:

 the subVI is just wire across from input to output. As you can see, the second instance (where the input is not wired) will return the default value for the control. If you were right, both outputs would be 20. 😉

 

 

 

Message Edited by altenbach on 05-05-2009 05:57 PM
Message 23 of 29
(701 Views)

Hi Guys,

I think i have finally cracked the problem.

The Problem it seems was in the Stim:Value change event, where i was writing a valur to a queue which aborts the runninv VI and Run another VI. 

By Adding a wait in that event solved the problem.

 

@altenbach

Yes, you are absolutely right. I dont know what occured to put the "Reinitialize to default" node at the end. i was probably thinking that if no value is passed to the variable, it'll retain its preious value. Which is totally False.

 

And, if possible could pls have a relook at the Vi and let me know where can i shorten my Block diagram.

There is a VI in the Action Engine VI which performs the averaging of Even and Odd waveforms. that VI is a little bit messed up. it would be great to know if there's a more efficient way to perform that operation.

 

 

Thanks,

Ritesh

0 Kudos
Message 24 of 29
(656 Views)

ritesh024 wrote:

And, if possible could pls have a relook at the Vi and let me know where can i shorten my Block diagram.


I only see a picture of parts of a diagram. Please attach the actual VIs.

0 Kudos
Message 25 of 29
(652 Views)

I am attaching my whole project.

BERA Main.vi is the main VI. and you can navigate to other VIs through the main VI.

 

 

Ritesh

0 Kudos
Message 26 of 29
(650 Views)

Hi altenbach,

are you finding it difficult to navigate through the VIs.

 

"average main.vi" and "average data.vi" are the 2 specific VIs which i really findi difficult dealing with and think that the operation done by those VIs can be done in a simpler way.

 I would really appreciate any Help from your side .

 

 

0 Kudos
Message 27 of 29
(625 Views)
Sorry, I haven't had a chance to look at them because I am pretty busy at the moment. I'll look at them as soon as my time allows. 😉
0 Kudos
Message 28 of 29
(619 Views)
Ok. Not a problem.:smileyhappy:
0 Kudos
Message 29 of 29
(614 Views)