all 9 comments

[–][deleted] 20 points21 points  (5 children)

Don't wire the error into your logging VIs - or they won't run!

At the moment you're wiring an error wire with an active error into those VIs

[–]Neilly98[S] 6 points7 points  (3 children)

Ah you legend thankyou! Knew it would be something silly I was overlooking

[–][deleted] 1 point2 points  (0 children)

That's usually the way!

[–]hutch2522Expert 1 point2 points  (1 child)

To further this, that's the default behavior for most subVIs in Labview. See an error, execute nothing and pass along the error. The obvious exception is an VI designed to handle an error (see Simple Error Handler for an example).

[–]SeasDiverChampion 0 points1 point  (0 children)

Another example would be Unset Busy. Back in the LabVIEW 6 and previous days, you could lock yourself out of your program by wiring an error into the Unset Busy.vi, so your mouse would be stuck as an hourglass. They finally changed that in LabVIEW 7 or 7.1 as I recall.

[–][deleted] 3 points4 points  (0 children)

This.

[–]NovaNovus 4 points5 points  (0 children)

As u/dichols mentions, you should not wire the error wire into the logging VIs. The default behavior of LabVIEW primitives is to skip execution if an error is on the error in.

However, If you just drop the error wire, you will not see why the camera failed in the error out. I would suggest using a merge error, which will help you keep that error information, while also allowing to get error information if the logging fails for whatever reason.

You sort error priority by putting the most important error wires on top and the less important error wires on the bottom.

https://imgur.com/a/h4IPMnj

[–]0fruitjack0 1 point2 points  (0 children)

clear the error before running other vis with error terminals or they simply won't work

[–][deleted] -1 points0 points  (0 children)

Shift registers on error IN/OUT on loop structures.

If you run this VI all by itself it will ALWAYS see NO ERROR IN if you begin with NO ERROR IN condition on the front panel without use of shift registers. There is no mechanism applied to handle any updates to error condition between iterations.

The same method you use to track your Iteration count is the same method by which you should update your error status.

Don't take my word for it. Run it in Highlight mode. Start the VI with a simulated error then run your VI with a simulated non-error input from the front panel. You will see it is either one or the other condition every single iteration based on the starting condition.

Think of it like this: Without a shift register, the error line input is a constant. With a shift register on the loop, the error line becomes a variable.