11-24-2015 03:24 AM
Hello Frank-L,
its working now.
Removing the checkbox "Reserved for routing" didnt help but the hint with abus1 and com1 was good.
I didnt see these names before in the list as I thought that this would be done by the driver.
Now i created a group with two routes: "1001->slot1com1" and "abus1->slot1com1".
This is executing without error. 🙂
Another question:
1. What is now the typical way when using SwitchExec under TestStand?
Should i create prefined routegroups for all available channels? (2muxes x 20channels x 4 Abuses = 160 groups for voltage-measurements with only one abus + the same if i want to use 2 abuses for a 4wire-measurement?)
Or is more typical to just the "MyLogicalName/1001->slot1com1"-syntax with multiple comma-separated routes?
2. In Teststand i first have to select the VirtualDevice-name that is create in Switchexec. Now i have a Logical-name that links to a driver-session with 8 modules. Is it possible for a clearer view to create now 8 virtual devices and only create routes for this module inside of this virtual device? For example i could name the VirtualDevices "Slot1..Slot8" and would have faster access to the routes inside of this module. Is this a normal way? Or should i create all routes in only one virtual-device?
Thx
11-24-2015 10:11 AM
OnlyOne,
1. What is now the typical way when using SwitchExec under TestStand?
Should i create prefined routegroups for all available channels? (2muxes x 20channels x 4 Abuses = 160 groups for voltage-measurements with only one abus + the same if i want to use 2 abuses for a 4wire-measurement?)
Or is more typical to just the "MyLogicalName/1001->slot1com1"-syntax with multiple comma-separated routes?
I think it really depends on the needs of the system. I would say that in my opinion, MOST customers using TestStand would probably pre-define their route groups ahead of time. This makes configuring the TestStand steps easier, and reduces the likelyhood of syntactical and runtime errors. It also helps with self-documentation of code as you can reference an export of the configuration.
2. In Teststand i first have to select the VirtualDevice-name that is create in Switchexec. Now i have a Logical-name that links to a driver-session with 8 modules. Is it possible for a clearer view to create now 8 virtual devices and only create routes for this module inside of this virtual device? For example i could name the VirtualDevices "Slot1..Slot8" and would have faster access to the routes inside of this module. Is this a normal way? Or should i create all routes in only one virtual-device?
I am unaware of how the Ag34980 system works. It shoulds like you normally open an IVI session to the chassis itself that contains the 8 modules correct?
If this is correct than I think you would NOT be able to have multiple NI Switch Executive Virtual Devices in TestStand talking to the same chassis. This is because with TestStand, it assumes that you will continually be using the session to the VirtualDevice and does not close references until after the sequence completes. I have written a description of why it might NOT work.
I hope that this helps.
11-25-2015 02:25 AM - edited 11-25-2015 02:29 AM
Hi Frank-L,
yes it is one chasis with 8 modules inside.
i tested it with simulation-mode and there it opens a session for each virtualdevice after first start of testplan.
The session is closed when closing the execution-tab of teststand.
If the execution-tab remains open and i restart (F5) then the already opened session is used (no second OpenSession in I/O-Trace appears)
The only question is now: Does the OpenSession reset all 8 modules in the chasis?
I think this can only be clear if using real hardware.
Screenshot I/O-Trace
BR
11-25-2015 09:04 AM
OnlyOne,
Does the OpenSession reset all 8 modules in the chasis?
The function call "niSE_OpenSession" calls "IviSwtch_InitWithOptions" with the resetDevice parameter set to true. So assuming that the Ag34980 follows IviSwtch protocol it will reset the device (and presumably reset all modules, opening all connections).
11-25-2015 10:37 AM
Hi Frank-L,
I just tested it with real hardware and it is as you said.
As soon as the first call to the second VirtualDevice is executed the mainframe is reset and previously closed switches are opened.
http://up.picr.de/23805484gc.jpg
Lines 1..43 are the first switch (using VirtualDevice Tisch), the rest is the second switch (using VirtualDevice Tisch2).
Tisch and Tisch2 have the same DriverSession.
Too bad that i cannot use this way to create something like a filter.
Now i have to prefix all routes with Slot1..Slot8.
BR