No explicit path exists between the two channels

[StevoP80]

Hello,

I am developing an automated harness tester for automotive applications. We had a working program using one switch card, but capability needed expanding and a second card was added. Previously our program had LabView modules written using NISWITCH blocks, but when the second switch was added I had to recreate these modules using SWITCH EXECUTIVE blocks to properly handle using a virtual device containing both switches. When running the test after these changes, everything seemed to be working well, until I get to a certain point.

During the test I receive the error "No explicit path exists between the two channels". This happens, repeatedly, when I try to connect r1 to c65,c66,c67,...,.... This happens a few dozen loops into the test, so it seems as if the overall architecture is working, just not past this point.

In TestStand, the error is reported as coming from niSE Find Route.vi, stating No explicit path exists between the two channels. Path Capability is returning as (1) which looks to be "Path is available", so I am confused why this error is coming up, and how to correct it.

I am able to set a route r1->c65 in MAX and MAX says the route configuration is valid.

I have made a standalone LV program to manually check and connect routes. I am able to create a DMM measurement route ([positive post] r0->c1 and [negative post] r1->c2, to take a resistance value between c1 and c2, for example) that contains the leg r1->c65, and the route is able to connect and take the measurement, leading to more confusion why I am seeing this error in TestStand.

Any ideas?

I have attached the configuration for the virtual device in question.

[StevoP80]

A little more information.

This program uses LV modules to import a nets list from an excel file. TestStand then loops through connecting, measuring, and disconnecting these routes, indexing the array of connections to make as it goes. With this automation looping in place, and the nets list imported from excel, I get the error when trying to connect to anything higher than C65. I thought perhaps the topology of the switch was getting lost, but appears as if the 4x128 topology is still present.

I made a copy of the sequence and removed the steps importing the nets list from excel, removed the automation loops, and set constants for my row and column on my connect steps. In this manner I am able to connect to C65, or any channels greater than C65. So this seems to be an issue between the LV modules, and TestStand. The LV modules run fine standalone.

[PezDeSpencer]

My initial thoughts are that it is weird/most likely not a coincidence that the error is happening exactly at the transition from 64 to 65. 

One guess is that the issue is stemming from your LabVIEW scripting code. Could you post that?

Could you also comment on your hardware setup? Are you using multiple cards to achieve 128 columns, and is that transition at 64 to 65 where a second card is needed? It could be a resource error, where the LabVIEW code doesn't look to the correct resource. 

Also, are you using a sequential model in TestStand?

Spencer R | NI

[StevoP80]

Thanks for the reply PezDeSpencer,

Actually each card in this system is 4x128, for a total of 256 channels. So this error popping up at channel 65 is happening in the middle of the cards range.

Here is a list of the hardware in the system:

(1) PXIe 1073 chassis

(2) PXIe 2532B 512 crosspoint matrix

(2) TB2640B terminal block 4x128

(2) SCB264X breakout board

(1) PXI 4071 DMM

Virtual device config is attached to the first post.

I am attaching some files here.

1. The TestStand sequence file I am using.

2. A folder named Harness_Test_Importer - These are the LV files that read the excel file and build the arrays of routes for TS to use.

3. A folder called Combined CMSM - These are the LV files I re-created using NI Switch Executive blocks (opposed to the originals using NI Switch) so we could use 2 cards in a single virtual device. There is a library containing all of the sub vi's, as well as the main vi named Test_with_SEblocks. The main vi was made to ensure the niSE blocks were working as intended and not the cause of the TS error. This vi can connect to channels 65 and greater with no issues.

All LV modules work independently of TS with no issues. TS sequence worked fine including and above channel 65 when the LV files used NI Switch, but could only access one of the physical cards, hence the switch to Switch Executive and a virtual device to use both cards. This is when TS no longer will connect to channel 65 and greater.

Last bit of info. The PC I am using for development has TS 2014, and LV 2015 installed.

Hope this helps, as I am still stuck.

[StevoP80]

Lastly, attached is a sample excel netslist file used during troubleshooting.

[StevoP80]

Update: 

I created a netslist starting with channel 60, through channel 128.

The TS program was able to connect to channel 65 in this instance. The error occurred on the 65th iteration of the automation loop, so in this case channel 124.

This leads me to believe the issue is in TestStand, specifically with the automation loops. This worked previously however, when the LV sub-vi's used NI Switch, instead of niSE. Still confused about the true cause.

[PezDeSpencer]

Thank you for all the information and troubleshooting. It appears as though we might be able to narrow this down to the TestStand API or the SE API. 

One thing I am still unclear of is if you are able to run the LabVIEW VI's independent of TS and loop through all 128 channels? I may have missed this info, but think it’s important to clarify.

Does this issue only occur when running through TS?

The test going from 60-124 is very telling, because I am assuming that spans two of your switch cards, so we can rule out the hardware aspect of the switches. Thank you.

Spencer R | NI

[StevoP80]

Thanks again for the reply PezDeSpencer.

Sorry for the delay, I was out of the office Sat-Mon, just returning today.

I have completed some additional testing. I set the LV program up to loop making the same connection 1,000 times with no issue. This was a loop opening the session, connecting positive post of DMM to Channel A, then negative post of DMM to channel B, taking a measurement, and closing the session. No issues for 1,000 loops.

I then set up a test where the positive DMM post stays connected to channel A, then negative DMM post connects to channels B, C, D, etc, for a total of 100 loops. Channel A was on the first card, Channels B, C, etc were all on the second card. No issues for 100 loops. Again this was opening session, connecting route A, connecting route B, C, D, etc, taking a measurement, closing the session.

In conclusion, LV program is able to cycle through at least 1,000 loops of the same connection with no issues. Also tested up to 100 loops with different unique connections (for negative DMM channel) across both switches, again no issues.

So it seems the issue is only occurring when trying to use the automation loops in TS with the LV blocks using niSE. This issue did not occur in TS when LV modules used NISwitch.

[StevoP80]

I have realized there is one more key difference between the way TS executes the steps for the test, and the way my standalone LV program executes the steps of the test. In the TS program, a session to the hardware is opened at the beginning, and this session is kept alive through all of the automation loops connecting, measuring, and disconnecting the routes, and finally the session is closed at the end of the test. In my LV program, a session is opened and closed between each loop iteration.

I will modify my LV program to only open a session once, and keep it alive for the duration of the test. I will update with any findings. Curious to see if this throws an error after a certain number of loops like TS is doing.

[StevoP80]

Update to my previous reply.

I modified my LV program to open the session with the virtual device only once, and keep this session alive for the duration of the test. I then ran it through 100 loops, connecting channels between switch 1 and switch 2, incremented by 1 each loop (C1->C130, C2->C131, C3->C132, etc). 100 loops completed with no issues.

I then modified the program to run 200 loops, at which point in the middle of the test it would encounter channels that did not exist (C200->C300 for example, where channel 300 does not exist in our 256 channel system). When the test encountered the channels that do not exist, it returned an error that the route contained "unrecognized characters" which makes sense since these channels do not exist and have no alias that matches. This was not the error returned in TestStand.

All things still seem to point to this being an issue in TS.