LabVIEW
How Do I tell if an array or a scalar are connected?
Solved!
@mcduff wrote:
Interestingly, this VIM works for string arrays BUT not for string scalars, whereas it works for both arrays and scalars of task refnums. What is the reason for that discrepancy? Of course you could make a normal VI with a variant input, like below, without Jay's improvement, but I am curious as to why the VIM does not work for a string scalar.
Hang on... that snippet works for scalar task refnums for you? I banged that out before lunch and didn't test it (which was dumb) and it doesn't actually work with scalar tasks for me. The problem is case 0 allows the wire to pass through, and the For loop doesn't force indexing, and then errors due to no iteration counts. The For loop needs to be inside the type specialization structure so the error causes that frame to fail.
@JÞB wrote:
Close Bert.
Now right-click that merge errors and select "Preserve all errors" then you will know how many tasks you tried to close didn't exist rather than that at least 1 didn't.
TIL that's an option. Apparently it was introduced in 2020... I hadn't heard of it until now. Thanks for enlightening me!
One other thing to mention. DAQmx Clear Task doesn't actually merge and retain upstream errors if it throws an error itself. If there's an upstream error, "DAQmx Fill In Error Info" just passes the upstream error through and doesn't keep its own error (it still closes the task). So, in order to retain both upstream errors AND all Clear Task errors... I have to try again:
The previous version worked with the exception of not keeping errors contained within DAQmx Clear, since I didn't know one error wire could contain multiple errors. This version combines all of them. The previous version is probably fine as I can't remember a time I've actually needed to know when a Close Task failed, but it's good to have.
@BertMcMahan wrote:
@mcduff wrote:
Interestingly, this VIM works for string arrays BUT not for string scalars, whereas it works for both arrays and scalars of task refnums. What is the reason for that discrepancy? Of course you could make a normal VI with a variant input, like below, without Jay's improvement, but I am curious as to why the VIM does not work for a string scalar.
Hang on... that snippet works for scalar task refnums for you? I banged that out before lunch and didn't test it (which was dumb) and it doesn't actually work with scalar tasks for me. The problem is case 0 allows the wire to pass through, and the For loop doesn't force indexing, and then errors due to no iteration counts. The For loop needs to be inside the type specialization structure so the error causes that frame to fail.
@JÞB wrote:
Close Bert.
Now right-click that merge errors and select "Preserve all errors" then you will know how many tasks you tried to close didn't exist rather than that at least 1 didn't.
TIL that's an option. Apparently it was introduced in 2020... I hadn't heard of it until now. Thanks for enlightening me!
One other thing to mention. DAQmx Clear Task doesn't actually merge and retain upstream errors if it throws an error itself. If there's an upstream error, "DAQmx Fill In Error Info" just passes the upstream error through and doesn't keep its own error (it still closes the task). So, in order to retain both upstream errors AND all Clear Task errors... I have to try again:
The previous version worked with the exception of not keeping errors contained within DAQmx Clear, since I didn't know one error wire could contain multiple errors. This version combines all of them. The previous version is probably fine as I can't remember a time I've actually needed to know when a Close Task failed, but it's good to have.
As a general rule, any reason DAQmx Close throws its own error would likely mean the Task never successfully opened and there is an upstream error from DAQmx Create or other reason so .... since merge errors historically only reported the first error the error out of Close was less informative. NOT USELESS but, less interesting than the upstream error. The changes introduced under the hood to 2020 error handling enable us to see a fuller picture.
Since you provided an excellent example where that new information could be useful, I took the opportunity to point it out. KUDOS.
Much appreciated, and thanks again for pointing out the new error handling stuff. Must've missed that announcement.
And I think I've remembered a time when I did need the Clear Task error code. I had some bug in my state machine's initialization or deinitialization where I cleared my Task refnum unintentionally. This led to the task being active even when the module closed, keeping the hardware reserved causing the NEXT call to the module to fail. Seeing that Clear Task failed due to "not a valid task" showed me I had a bug in my state handler.
