case statment in while loop - hardware state

[jimmyinct3]

hello

I have a crio 9014.

Specific module in question 9263 analog output

okay, i have a while loop and embedded case statment in labview.

image of case statement - link

I would like to make the analog output (AO1) go high when i click enable button

There is also another analog output embedded, AO0, im not sure if it is wokring either but dont think it is.

I can go through in debug mode and see that the case in changing.

I can see when the case changes, AO1 is fed 5 for enable and 0 for false.

Yet, the output i get is only for the first iteration of the loop.

Ie, if the loop starts with the enable button true, then i get an output of 5.

If the loop start with enable as false, i get an output of 0

Yet, once the loop has started, the output will not change.

I dont understand this. 

[AdnanZ]

Simple answer to your question: Put a Wait function node in your while loop since that particular thread is starving the communication thread that is reponsible for communicating between your RT front panel (on your Windows machine) and the RT code (which is on your cRIO 9014).

Something to think about: You need to improve your design. You should always design your RT VI without a front panel. So, it shouldn't be having a 'On-Off', 'Enable' control or a 'Numeric' indicator. If you are interested in communicating with the RT application, you should design another Windows host VI that communicates with the RT application using a communication method that suits you. Examples of this can be found in the Example Finder (Help -> Find Examples..)

[jimmyinct3]

i appreciate your answer.

it turned out to be a rather odd solution... i think.

One of the the modules of the crio is for a 9237 strain bridge.

Thus, some of the wires we were given were cross over and some were straight.

So one of the wires for that module made itself into the crio network port and into the router path... and were not the right type.

where is gets confusing is that, the program was still reading the first loop correctley each time but it just couldnt be changed.

Had that first loop not read correctly when changed in initialization,  this would have been easier to debug.

needless to say, the crio is now functioning much faster too when interfacing with the pc 

Message Edited by jimmyinct3 on 06-04-2009 04:02 PM