Execution Flow With Error Cluster

[lavalolo]

Hi,

this is my first post in this very interesting forum,

so HELLO to all of you.

And here's my first question:

=======================================================================

Recently i had a strange behaviour with one of my LabVIEW VI's concerning execution order

with respect to the "error cluster" flow.

Is it right and always the fact , if an active error (error status = true) arrives at an (error in) input

of a following Vi or property node, then the code in this Vi (or property node) will not be not executed ?

I know that i can control this in Vi's written by myself and that i also can find out this by debugging

the code in most cases.

But i wonder if there is a general rule from National Instruments concerning the flow and behaviour

of the error in and out wires.

=======================================================================

I'm looking forward to every reply concerning this topic !

Thanks in advance, Andreas

[Rolf Kalbermatter]

Hi,

this is my first post in this very interesting forum,

so HELLO to all of you.

And here's my first question:

=======================================================================

Recently i had a strange behaviour with one of my LabVIEW VI's concerning execution order

with respect to the "error cluster" flow.

Is it right and always the fact , if an active error (error status = true) arrives at an (error in) input 

of a following Vi or property node, then the code in this Vi (or property node) will not be not executed ?

I know that i can control this in Vi's written by myself and that i also can find out this by debugging

the code in most cases.

But i wonder if there is a general rule from National Instruments concerning the flow and behaviour

of the error in and out wires.

=======================================================================

I'm looking forward to every reply concerning this topic !

 

Thanks in advance, Andreas 

4998[/snapback]

Basically error in=TRUE means don't execute the diagram code at all. However there are a few "buts" here. Sometimes it is not smart to not do anything. Also if you have controls which correspond to indicators on the frontpanel it is usually a good idea to wire them together through the TRUE case of the error case structure.

And last but not least for closing resources I almost always create the VI in such a way that it attempts to close the resource independent of the incoming error. The only thing I then do is depending on "error in" either pass out the incoming error or the error from the close function.

But yes besides of the last mentioning about close functions (NI does it sometimes too in their functions but not always and not consistently) you should assume that the function does basically nothing except passing through the error cluster (and sometimes also passing input data to corresponding output data).

Rolf Kalbermatter

[pmaj]

Hello

I just want to add a little thing - sometimes if "error in" = TRUE (I mean ERROR STATUS = TRUE) - it can be a warning. In my case I just ignore it or ... do a simple vi which cancel the warning. If you have a warning - error cluster behaves just like there was an error - remember that.

I think you should always check what kind of an error can occur and be prepare.

[Rolf Kalbermatter]

Hello

I just want to add a little thing - sometimes if "error in" = TRUE (I mean ERROR STATUS = TRUE) - it can be a warning. In my case I just  ignore it or ... do a simple vi which cancel the warning. If you have a warning - error cluster behaves just like there was an error - remember that.

I think you should always check what kind of an error can occur and be prepare.

5029[/snapback]

This is a good advice but I wouldn't make some unrelated VI down the error stream depend on specific errors not being a real error. Instead whenever you call a function you know can create a particular error you don't want to treat as error, just create a small utility VI which looks at the error cluster and resets the error status if that particular error has been seen and hook it directly after the function which can create that error.

An example of such an error would be the timeout error of the TCP Read node. In most cases this is not a real error you want to bail out from but rather an indication that there hasn't been enough (any) data and that you should retry to read in a short moment.

My network communication usually works in such a way that I almost always clear the timeout error after a TCP Read. An extra indicator out on that utility VI gives me a True on timeout so that I can take apropriate action such as retrying after a short delay in the subVI or often passing it out of the subVI as extra indicator so that the higher level function can take appropriate actions (usually do some other stuff and retry later again.

Rolf Kalbermatter

[JackHamilton]

Don't wire the error cluster sometimes!

There are times where you do not want to input the error cluster. For example in state machines, we often put the error cluster in a shift-register - this allows an ERROR state to read that calling error state and handle it. You should then pass a NO ERROR cluster to the shift register - or else your other states will enter with an error and not execute.

Second, I don't wire error cluster into Queue messaging - as I don't want my messaging to collapse upon a hardware or other error in my code. This gives me a chance to see an error and send a "Initialize" message to the state maching to attempt to recover the hardware.

Some DAQ, IMAQ and other hardware initialization - should not have the error clusters wired between - as for instance cancelling/Aborting a DAQ operation in progress will generate an error - but who cares. Many times I will put a DAQ. IMAQ STOP or ABORT before a config call to assure that no operation is in progress when I attempt to configure the hardware. One would naturally want to wire the error cluster across the ABORT - INIT - CONFIG vi's but error from the ABORT will cause none of the init vis to execute.

I've even seen errors when I perform an abort - telling me no operation was in progress to abort! - again who cares.

If you want robust code sometimes the error cluster is not your friend.

Regards

Jack Hamilton

[i2dx]

be carefull !

Error=TRUE does not mean no execution in all cases.

it is true for the most system VIs,

but surely a self written sub-vi will execute when the error in = ERROR and handle the error in the way you programmed it, which can mean, if there is no error handling the next system VI (e.g. the yellow ones) will not execute at all ...

take a look at the example and you will hopefully see what i mean ...

cheerio

cb

Download File:post-885-1119734181.zip