LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Instrument handle through a shift register generates error code "-1073807346"

I get an error when I pass an instrument handle through a shift register but not if I pass it straight to the next subvi. I am using LabVIEW 2011, NI-Sync 3.3 and a PXI-6652 timing module. This vi worked fine previously in LabVIEW 7.1. Did something change that would cause the shift register to no longer work for instrument handles?

0 Kudos
Message 1 of 15
(2,791 Views)

I certainly hope not!

 

Please post images of your code for us to review.

 

The VI with the SR is not going idle is it?

 

Curious,

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 2 of 15
(2,788 Views)

Ben,

I have attached an image of the problem.

0 Kudos
Message 3 of 15
(2,783 Views)

If the two calles to the AE are made from the same running top level VI (the AE never goes idle) then there is something very strange happening.

 

Q:

 

If you replace the For loop with a While loop (with constant to stop while loop) does that change things?

 

 

The only time I have seen trouble with your code is when the VI went idle between the two calls.

 

As a sanity check you can put an indicator on the ref to make sure it does not change from the first call to the second.

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 4 of 15
(2,776 Views)

Both calls are made from the same top level VI. I have tried replacing the For loop with a while loop and have the same result. I added an indicator and did not see a change in the value between calls.

0 Kudos
Message 5 of 15
(2,774 Views)

You have both stumped and troubled (thank you!).

 

Last Q:

 

Is the action a type def and the constant used to select the action copies of that type def?

 

Ben

Retired Senior Automation Systems Architect with Data Science Automation LabVIEW Champion Knight of NI and Prepper LinkedIn Profile YouTube Channel
0 Kudos
Message 6 of 15
(2,770 Views)

There's got to be something fishy.  Two places to look:

 

Check and make sure you don't have tunnels overlapping in any of the cases (I've had it happen with a unwired tunnel set to use default if unwired with a wired tunnel to nowhere on top of it) a CTL+U usually exposes these.

 

Check and make sure you aren't accidentally calling a close case (probe and breakpoint on the mode control) 

 

A conditional probe on the output SR's input (after the case) set to suspend if invalid may help too


"Should be" isn't "Is" -Jay
Message 7 of 15
(2,763 Views)

Ben,

Yes, it is a typedef and the constant in the top-level vi is tied to it.

0 Kudos
Message 8 of 15
(2,743 Views)

Jeff,

I checked for overlapping tunnels and have none. There are no accidental calls to the close case.

 

This code worked previously in LV 7.1. I have made no changes to the code other than converting it to LV 2011.

0 Kudos
Message 9 of 15
(2,742 Views)

OK, something really odd then (possibly a bug, possibly a mix-n-match on NI-SYNC API )  We'll have to look at the code itself.. first thing Check the VI hierarchy show vi.llb and full paths - is the API mixed from two different LabVIEW versions?  If you can't find it that way send the working AE <save as- to new location-preserve Hierarchy-include VI.llb as a zip and same-same for the bad AE. 

 

But it almost has to be a mixed NI-Sync API at this point or the 2010 NI-sync got corrupted- we can compare the .zips to clean installs


"Should be" isn't "Is" -Jay
0 Kudos
Message 10 of 15
(2,737 Views)