Switch Executive with SCXI "an error occurred while attempting to access device"

[Now_With_Underscores]

Hey Crazy Chicken,

While our team is working on a solution, one possible workaround is to use another non-pxie-compatible NI device (M-series board, E series board, etc) to control the SCXI modules, and then route the triggers externally from the DMM's AUX connector to the switch(es, daisy chained).    Of course, this requires change, which isn't always acceptable, and it won't work unless you have another compatible controller in your system, but just a thought... thanks for bringing this issue to our attentions; we're working on understanding the issue.

[Mark_E]

John! (Previous Frank L, right? "We're #1.0000000", remember? . Look at my profile if you don't remember.)

We are in the process of re-writing our tests to not use NISE as we HAVE ordered new hardware, but it's not going to be here until mid-February. Believe me, we definitely want to upgrade hardware. It's just a slow process when employed by a government contractor.

Thanks!

[LoquitoPollo]

Oops. That wasn't so covert, was it? I was just testing my old login, but it still said I was LoquitoPollo. Oh well.

[Now_With_Underscores]

Hey Mark, long time no chat!  I know we're hard at work here looking into the issue.

Can you elaborate on why you're migrating away from NISE?  Have the design requirements changed (do you need triggering)?  If the new HW is IVI compliant, then you can keep using NISE.  Are you planning on migrating to NI-Switch, NI-DAQmx, or something else?  How much HW are you waiting on?  Do you have any open slots for an M/E Series controller?

[LoquitoPollo]

Moving away from NISE for now as it's what is not working (even though our hardware is IVI compliant). Our switching really isn't too complicated either, so it's the easiest decision we can make right no to get production going again. We ordered the AUX cable for the front of our PXI-4065, but it's t-daq for now as we have to use our PXI-4060 as the controller for the SCXI side of the chassis (as the PXI-4065's are PXI express and don't have the backplane connector).

[Frank-L]

Loquito,

For the Validation Issue:

This was a bug in NISE and only happens on Traditional DAQ devices. This is because when using NISE with NI products, T-DAQ and DAQmx devices use NI-SWITCH. This is done to allow extra functionality that NI-SWITCH has compared to a standard IVI-SWTCH driver. Unfortunately, NI-DAQmx devices and T-DAQ devices have different functionality and issues can come up.

Fortunately, that specific issue was fixed in NI Switch Executive 3.6. I verified that by upgrading to NISE 3.6, using the "1129/2-Wire Quad 4x16 Matrix" driver setup string, validate works without issues.

For the Driver Session, Driver Setup Issue:

In order for the T-DAQ driver to work in IVI SWTCH and NI-SWITCH the Driver Setup string must say "topology:1129/2-Wire Quad 4x16 Matrix;resourcetype:legacy" and the help documentation is correct. I verified this by running NI-SWITCH and IVI-SWTCH in LabVIEW with the 4060/1010/1129 combination.

With the correct "topology:1129/2-Wire Quad 4x16 Matrix;resourcetype:legacy" string for driver setup I was able to initialize, use and connect channels appropriately.

With the incorrect "1129/2-Wire Quad 4x16 Matrix" string for driver setup, initialize would fail in both NI-SWITCH and IVI-SWITCH.

I am unsure how you got this to work in IVI Swtch as you mentioned in a previous post, as I had installed the exact software on your machine.

This leads us to the question "Why did it fail to allow me to add a device in NISE". The answer to this question is that the parsing for TDAQ devices is incorrect in NI Switch Executive. As you see in the image below, using the same Driver Setup in DAQmx [blue] and TDAQ [red] produce very different topologies in the "Create New..." dialog box.

Because of this parsing error, when NI Switch Executive calls Initialize, the DAQmx Device calls init with the options "DriverSetup=Topology:1129/2-Wire Quad 4x16 Matrix" while the TDAQ device calls init with the options "DriverSetup=Topology:topology:1129/2-Wire Quad 4x16 Matrix", hence the resulting error. Again this difference is only for T-DAQ devices.

This issue has been put into a CAR [Corrective Action Request] for bug fix.

For the Documentation on 4060 Support Issue:

4060 support was originally documented in the "Getting Started Guide"  and did not get ported when the "Getting Started Guide" was split into SCXI and PXI versions. A CAR [bug fix] has been filed to address this issue as well as the help file limitations. Thanks for your understanding!

[LoquitoPollo]

Frank,

Thanks for the reply.

For the validation issue, it didn't appear that this bug we've found was one of the two bug fixes listed in the NISE 3.6 readme. Was this a bug fix that wasn't assigned a public CAR?

For the topology issue, I'm assuming you're filling out the driver setup string in the Driver Session section under IVI in MAX, right? I know there are some Initialize VIs that allow a configuration string input, but that's not on the IVI example from the example finder. That's why I figured we were talking about the same thing, but I just want to double-check. I tried it again by creating another IVI device with a different driver session with the whole "topology:<topology>;resource:legacy" string and NISE throws an invalid topology error when adding the switch. So strange that the behavior is opposite. I'm using Windows XP, but I can't imagine that would change on Windows 7.

Can you post the CAR #s for the two issues you've submitted? That way I can see when they're fixed.

Thanks again!

[Frank-L]

Loquito,

Was this a bug fix that wasn't assigned a public CAR?

This bug was found during validation testing for 3.6. A specific attribute was being requested by NISE during validation that does not apply to T-DAQ devices.

I'm assuming you're filling out the driver setup string in the Driver Session section under IVI in MAX, right?

Yes

I know there are some Initialize VIs that allow a configuration string input, but that's not on the IVI example from the example finder. That's why I figured we were talking about the same thing, but I just want to double-check. I tried it again by creating another IVI device with a different driver session with the whole "topology:<topology>;resource:legacy" string and NISE throws an invalid topology error when adding the switch. So strange that the behavior is opposite. I'm using Windows XP, but I can't imagine that would change on Windows 7.

I also was using Windows XP.

I was using the standard IVISWTCH [as well as a NI-SWITCH] initialize function within labview. This is the function that takes in four inputs [Device, ID Query, Reset, and Error] without additional options. This would then pull the driver setup that was configured in MAX. These initialize functions only worked for me using devices that were configured in MAX with "topology:<topology>;resource:legacy". Any other Driver Setup I tried would not work.

When working in NISE the "topology:<topology>;resource:legacy" failed with invalid topology error because of the bug in the parser discussed above. The bug in the parser caused the low level driver to call "Topology:topology:<topology>;resource:legacy" as the driver setup. The driver then looked for a topology called "topology:<topology>" and could not find one.

CARs are as follows:

Help Document: 387074

Getting Started Guide:387072

NISE Topology Issue: 387062

[LoquitoPollo]

Frank,

Thanks again for clarifying the issue. I'm still perplexed by the topolgy "driver setup" string being the complete opposite. I got our PXI-4065 with the SCXI-135x adapter kit for the SCXI portion so I'm moving on with those for now. I'll try those VIs again with the new hardware, but if they're the ones listed in the example programs I used, then we were using the same VIs with different behavior on the driver setup string. Weird!

Thanks!