NI Switch Executive 3.0 routes in route groups

[GR LV]

The NI Switch Executive 3.0 interface in MAX needs some improvements.

When adding a route to a route group, MAX appears to automatically alphabetize the route list in the GUI "child routes and groups"..

This is NOT the desired end state, particularly since when the results are read from the route group programatically, they are retrieved in the order they were added to the group. They also appear in the excel export file in the order they were added. The GUI needs to leave them in the same order (the order they are added) and add buttons to move the routes up or down in the list.

The order of routes in the route group are important to many applications.

I create groups of routes that can have a switching "function" applied to them.

For example, define a group of routes that act as a virtual MUX, or assign a binary value to a group of routes to activate the specifed child routes.

In what order does Switch Executive connect or disconnect the routes in a Group? (I doubt it's alphabetically)

Also, with LV 2009 SP1 and 13 switch cards containing both routes and route groups, the amount of time it takes to load the virtual device into MAX is almost unacceptable.. Actually, LV 2009 startup time is also slow.. And I have dual quad core processors.

[Mr.F]

Hi GR,

That’s strange, is this causing a problem in your code? Can you post your code? I’d like to get a better look at how you’re assigning values to that virtual mux. Have a nice day.

[Now_With_Underscores]

The best way to guarantee routes are executed in a certain order is to create and call unique route groups.  SwitchExecutive is going to connect all routes in a particular group as fast as possible.

[GR LV]

Here are a few snippets to show what I am doing.
There is not enough of the code here for it to be functional, but a quick analysis should show what I am doing.

Basically, I am using Switch Executive to create/configure route groups and apply a switching function to that route group, such as Mux or Binary switching. The order of the routes in such an application is important to know. This does not necesarily cause a problem for the application because we know they are programatically retrieved from MAX using the "niseCfg Get Objects" set for "Child Routes" in the order they are created, which is also the order they appear in the Excel export. The issue is that when viewing the route group in MAX the routes in a group are visually displayed in alphabetical order. This makes it difficult for a user to understand what is going on and will lead to extensive use of excel in order
to prevent the confusion.

I realize the supplied NISE fuctions do not care about order because the functions are limited to performing the same action to all child elements.
ie) connecting or disconecting all routes in a group.
However there is an inconsistency in your product. They are visually displayed in an order inconsistent with the order they are programatically retrieved and the order they appear in an export. Displaying them alphabetically adds no value to the product either.

In the snippets supplied:
"NISE Group Switch.vi" determines how to call "Switch.vi" based on the switching function.
"Switch.vi" configures the MUX or binary function on the group.
"driver_interface_NISESwitch.vi" performs the actual switching using basic NISE connect/disconnect.
"driver_interface_NISEswitch_init.vi" and "get route properties.vi" pull the necessary information from the NISE configuration in MAX.

[Now_With_Underscores]

To make the data consistent, you could write a VI that reads the current values from NISE virtual device into an array, sorts the values alphabetically, and then writes the values to either a different virtual device, or removes and then readds the alphabetized values to SwitchExecutive.

If the above recommendation proves tedious, I would recommend a prefix system of your choosing, such as:

"AA___________"

"AB___________"

"AC___________"

"AD___________"

etc

We definitely value your feedback and are always looking to improve our products according to specific customer use cases. 

I don't recall any prior requests to disable alphabetical sorting, but I can see why this is desired in your application.  Displaying the values alphabetically prevents SwitchExecutive users from having to scan all entries for the desired entry.

Can you elaborate on how specifically you plan on using Switch Executive?

[GR LV]

At the moment, we're using it as a nifty configuration tool to create routes and groups.

This saves us from having to create, learn, and document switch specific configuration data files.

Yours already does what we want and more as far as housing the configuration and it's nicely documented.

Actually, we're re-engineering a currently functional system that utilized custom ini files.

The basic NISE use cases on the groups will be utilized as is.. (connect/disconnect)..when that is all the developer needs. (this is a re-usable code base that is installed on numerous testers)

We're adding on top of that, additional functionality to apply different actions to the groups, such as the "virtual mux" of a route group as descibed earlier and indicated in the code. We've used these switching functions extensively in previous applications and are simply re-applying them in a new way.

It would be wonderful if you could take your product to the next level and add that to the product for us 🙂 🙂

We also like the IVI compliance. We recently we ran into a situation where we will have to replace a bucnh of NI Switch cards with pickering cards. Our old architecture would require a new driver to be developed to implement the driver layer functions for the pickering card in the defined VIT format. Using NISE functions we can more easily swap cards without touching the code or creating custom drivers because of the inherent IVI compliance. Of course, pickering provides IVI drivers for the cards we will be using.

Did I answer the question?

[Now_With_Underscores]

Definitely!  Thanks for the additional use case information.

May I ask what has you replacing NI Switch modules with Pickering modules?