LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

LabView 2020 Broke niSwitch

Solved!
Go to solution

When I upgraded to LabView 2020 on a PXI chassis the niSwitch device no longer works.  When I open the VI I created it searches for "niSwitch Initialize With Topologies" and "niSwitch Topologies" VIs.  The VI I created worked with the LabView 2010 that was installed previously.

I've already tried uninstalling and re-installing the niSwitch module from Package Manager.  That did not help.

 

Next step is a full uninstall of Labview 2020 and a reinstall.

 

Can anyone suggest a better method?

 

Thank you,

J!D2007

0 Kudos
Message 1 of 10
(669 Views)

I tried the following link to download a fresh niSwitch install:

https://www.ni.com/en-us/support/downloads/drivers/download.ni-switch.html#329036

that didn't work either.  Package Manager replied there was nothing to do.

0 Kudos
Message 2 of 10
(641 Views)

NIPM frustrates me.  You might have to uninstall/reinstall ni switch so that it becomes "LV 2020 aware".

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 3 of 10
(637 Views)

  Part of the problem was that I tried to install LabView 2020 64 bit on a 32 bit PXIe chassis.  I uninstalled the 64 bit and installed the 32 bit.  Most of the functionality seems to work. 

  It seems to be having problems creating Instrument Handles and Tasks for DAQmx like the a PXI2570 40 Relay board and the PXI6529 Iso Input board.  I created a test VI to test the 2 things mentioned above as well as a PXI6602 Timing IO board.  At one point, on the 32 bit PXIe chassis, I had to remove the tasks and local variables that had worked in the original VI and tunnel the tasks into the test program.  Moving the VI to a 64 bit PXIe chassis seems to have fixed some of that problem; at least on the 64 bit chassis.

  Now, using the test program on the 64 bit PXIe chassis, if I try to assign an instrument handle and local variable for the PXI2570 Relay board it breaks the tasks for both the timing IO board and the ISO Input board.  If I click through using the Continue button for each those errors one time it goes through and everything works.  If I use a tunnel for the Relay board everything seems to work.

  I'm at the point where my next step is to install these 3 boards in a PXIe chassis with a new processor module that has been updated to Win10 and LabView 2020.  Maybe this will work.

 

Thanks,

J!D2007

0 Kudos
Message 4 of 10
(569 Views)

  I installed Win10 and LV2020 on a fresh PXIe processor module in another chassis.  It has similar problems.

  The Test VI created to test the PXI6529 Iso board, PXI6602 Timing IO board, and PXI2570 Relay board works when using DAQmx tasks and local variables for the PXI6529 and PXI6602 as long as a tunnel is used for the PXI2570.  If I create an instrument handle and local variable for the NISwitch PXI2570 Relay board the DAQmx Read VIs for the PXI6529 and PXI6602 boards show an "invalid or do not exist" error for those tasks.  When those errors and clicked through one time with "Continue" the Test VI goes ahead and runs properly.

 

  We're never going to be able to click through all the DAQmx read VI occurrences in the actual test VIs.

 

Thanks,

J!D2007

0 Kudos
Message 5 of 10
(549 Views)

@J!D2007 wrote:

We're never going to be able to click through all the DAQmx read VI occurrences in the actual test VIs.

I have no idea how to solve the root cause of your issue (whatever the root cause it... it sounds rough.).

 

But from what you're now saying, it sounds like you're just using Automatic Error Handling, which is why each error pops up, one at a time. Have you looked at doing your own error handling?

(Maybe you do, but we can't see your VI, so I can only assume based on your description...which, to me, sounds like Automatic Error Handling.)

(To get started on doing your own error handling, try looking here and here.)

 

If you put in your own error handling, it could give you a workaround*:

If** you're confident that ignoring the error is OK in every case, could you wire out your error wires and suppress/clear the particular errors you're having to deal with? That way, if a different error pops up, you'll still catch it, but you can ignore the errors you're clicking "Continue" to get through.

Spoiler
*This is just a workaround, not a solution. The solution is to fix the problem and not have the errors. As I mentioned, I'm not sure how to help you there.
**This is a big If. Like, bigger than IF. Even  IF  doesn't do it justice. You should verify that every possible time these errors might arise, they are OK to clear. 😁

Hopefully someone who knows more about PXIs the niSwitch, and other DAQmx things will see this issue and know what is happening.

 

Regards,

joeorbob

 

 

0 Kudos
Message 6 of 10
(525 Views)

I fixed the problem on the Test VI.  It was written sloppily with the initialization done outside of a control loop or anything.  It just placed all the initialization defining the DAQmx devices out in the La-La land to the left of the loops.  I added a flat sequence to the Test VI and placed the INI stuff in the first frame.  I think I ran into the same problem a few years ago; but didn't remember.

That really doesn't apply to the actual Functional Test VI's already created that used to work.  I'll troubleshoot that more this afternoon.

 

Thanks,

J!D2007

0 Kudos
Message 7 of 10
(515 Views)

Give yourself a pat on the back - AND mark your own post as the solution!  That's the ONE time I would recommend using a sequence structure.  (Actually you could have had just one frame around the init stuff and pass out any wire (usually the error wire) and connect it to the loop to establish dataflow.  If it's something you don't really need in the loop, it doesn't have to go in.  It just has to connect to the loop.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 8 of 10
(508 Views)

It looks like the original equipment testing programs are still having problems. 

  The test VI I created to check the DAQ initialization VIs seem to work on all the PXIe chassis (5 of them) I've tested them on.  Now, when I try running the original equipment tests it seems to have trouble recognizing the 6529 Isolated Digital Input module.  The drop down I/O list comes up blank and pressing the Browse button pops up a blank window.  The DAQ testing program on the same 2 PXIe chassis recognizes the 6529 right away and the Browse button's drop down list populates.

  I'm at a loss trying to correct this problem.  As described in this thread a test VI to create the DAQ initializations works fine.  The equipment tests DAQ initialization VIs have been moved to a flat sequence outside of and over the rest of the VI showing the same problem. Trying to delete the DAQ initialization VIs and replacing them doesn't help.

 

Anyone have a suggestion,

J!D2007 

0 Kudos
Message 9 of 10
(468 Views)
Solution
Accepted by topic author J!D2007

Pretty sure I've solved the problem.  Instead of using Constants for the DAQmx initialization tasks I created controls.  I thought I had tried this before; but, it seems to work now. 

This will come in handy once the VIs are created as EXEs.  We'll be able to move the boards to PXIe chassis where the boards are in different slots allowing easier setup.

 

Thanks,

J!D2007

0 Kudos
Message 10 of 10
(435 Views)