errors and dataflow

[Tzench]

I need to read up on how error handling and dataflow works. Can somebody recommend something?

[Hillman]

Hi Tzench,

Thanks for the post and I hope your well today.

Regarding training the website has some free courses - including a six hour LabVIEW introduction course.

How Can I Learn LabVIEW?
Link: http://www.ni.com/academic/lv_training/how_learn_lv.htm

For dataflow I have found a Tutorial and an Exercise

Video:

http://decibel.ni.com/content/docs/DOC-1694

Exercise:

http://zone.ni.com/devzone/cda/tut/p/id/7538

Handling Errors

http://zone.ni.com/reference/en-XX/help/371361E-01/lvconcepts/error_checking_and_error_handling/

LabVIEW help file link.

Did you have any specific questions?  and maybe I can then help you out a bit more..

[Tzench]

Yes, I have some questions:

1. What are the proper objects with which to start and end the error thread in your main program? I suppose "error in" and "error out" are mostly intended for sub-VI:s.

2. In a sub-VI how do you appropriatly connect an error wire if there is nothing obvious for it to enter (like, for instance, a loop). Should the error wire simply run parallell to the actual program?

3. Are there any general guidelines for splitting and reuniting an error wire?

[Hillman]

Hi Tzench,

Thanks for the reply and I hope your well today.

Good questions - I'll do my best to answer them.

1. You can use the Error In and Error Out Cluster Controls/Indicators on the front panel. (found  under Modern>>Array, Matrix and Cluster>>Error In 3D.ctl). However, normally in the main VI there is no Input Error until the first subVI which is used. Some users do use the error cluster output on the front panel, but not always the most pretty of controls. Therefore most users place a Simple Error Handler VI found under Programming>>Dialog and User Interface. This will display any errors in a separate window to the front panel. 

2. If the subVI isn't using subVI, just functions such as add that do not have error clusters then most users will just wire straight through the error cluster, either in parallel or through the middle of the for loop. If using a while loop some users would also place a shift register so when the loop finishes if there were any errors in any of the iterations it will be passed out of the loop. 

I think the most common is to have a case structure in the subVI for Error True/False case. So if there is an error not to execute any code.. Because its a waste of time or may cause more errors etc. This can be done by just wiring the error cluster to the conditional terminal of the case structure. 

3. Guidelines such as what? You can use the unbundled function to get the information contained in an error cluster, and then use the bundle to restore/update the error cluster. The most common case of this when your handling errors. For example lets say we want to test for error 7. Then we could have some unbundled on the error cluster, test for an error (status = true) and then test the code (code = 7) and then if it is error 7 in the cluster, we just bundle a default (no error, status false, code 0 and blank string) into the error cluster, otherwise it wasn't error 7 and just wire the input error cluster straight through. 

 

I hope this helps, 

Message Edited by Hillman on 02-10-2009 12:44 PM

[Ben]

---

Tzench wrote:

Yes, I have some questions:

1. What are the proper objects with which to start and end the error thread in your main program? I suppose "error in" and "error out" are mostly intended for sub-VI:s.

2. In a sub-VI how do you appropriatly connect an error wire if there is nothing obvious for it to enter (like, for instance, a loop). Should the error wire simply run parallell to the actual program?

3. Are there any general guidelines for splitting and reuniting an error wire?

---

1)

THere is no need to create a erro cluster constant on the BD as the start of your data flow. The first node or sub-VI that has an erro cluster input will use its default od "no error".

2)

It depends. If the code can't throw an error (think hard before you decalare code guarentted error free) OR can operate properly regardless of precceeding errors, then just wiring the error cluster through. (But if you want to be technically correct create a case structure that senses the error cluster pass in and skip your code if an error was passed. I mention this just to cover "taking tests").

Loops that can enounter an error should use a shift register to make sure you don't loose an error on iteraction number 3 of 23. Pay attention to For loops since if they use an auto-indexing tunnel and they are passed an empty array, they may iterate zero times and with a SR you could loose your error info.

3) Branchine an error cluster wire is a good way to tell LV that the down-stream nodes can execute in parallel. There is a Vi called Merge Errors that will let let you splice together error cluster streams. You also may want to take a look at the code Mike Porter (Clertified LabVIEW Architect,  LabVIEW Champion, and one of my co-workers) posted in theis thread. It is called "Error Fork Stacker" for a more robust way of merging error clusters. Unlike the Merge Error VI the Error Fork Stacker will pack two errors together while the Merge VI will just report the first one it detects.

I hope that helps with your error cluster Q's!

Ben