NI-XNET session wired through TestStand causes Error Hex 0xBFF6309C

[Bluegraf]

Hi,

I'm trying to access a LIN Controller via PXI-8516, NI-XNET and LabView (2012) code from TestStand (2012).

Up to the point where with "XNET create session" I created two sessions (one for writing, one for reading) everything runs within LabView and without errors. Then I put those sessions to an Indicator and up into TestStand. There the sessions are stored in locals and put into the next call where I ty to send a frame.

The result always is a 0xBFF6309C aka -1074384740.

A test program which keeps everything within a Labview state machine behaves as expected and sends the frame without problems.

The error text to me sounds to me a bit as if the sessions don't particularily like to be passed through TestStand.

Anyone experienced similar problems?

Best regards,

Sören

[TinchoL]

Hi Sören,

have you tried to save the Session into a Global Variable?

It looks like this is a know problem with how the drivers interact within TestStand.

I am looking into finding a workaround for this issue. Once I have more information, I will let you know

Best Regards,

Martin L.

NIG AE

[Bluegraf]

Hi Martin,

thanks for your reply!

At the moment we use the workaround of creating a session for every single set of frames. Sometimes even for just one single frame.

It works but it is an as nice solution as using GOTOs in programming...

Unfortunately we are in the situation to have to make the machine run "yesterday". Therefore I expect to be only able to apply any fix I can build with the information gathered here at the next machine. 😞

I tried to create a functional global earlier but LabView didn't let me save it for some odd reason (Maybe it has to do with TestStand where I started LV from?). So I gave in.

I'll have to have another go (tomorrow) I think.

But even if that works it feels to me like a rather ugly workaround. TS is supposed to hold those sessions.

As each VI I call from TS is stopped completely (rather than being kept in that third state like inactive sub-VIs during their top-level VI is running) I'd expect each dependant global to be garbage collected after the VI stops.

What I'm not completely aware of is how the XNET session variables behave like. Obviously not like ActiveX or .NET references. They are behaving nicely exactly as I'd expect: Drop them into a variable in e.g. StationGlobals and they will live and can be retrieved till you set them to "nothing".

Gruß,

Sören

[Bluegraf · Accepted solution]

Solved!

Obviously XNET doesn't like it at all if the VIs using XNET are not kept in the reserved state. This is an LabView Adaptor setting in TestStand.

To avoid bad surprises and days of error searching when porting software to a different TS-machine you can also set the adapter setting by a line of code:

RunState.Engine.GetAdapterByKeyName(FlexLVAdapterKeyName).AsAdapter.ReserveVIs = True

I still consider this behaviour if not a bug then at least an issue. If keeping the session under these circumstances is not possible at least TestStand should provide a better error message pointing out what happened.

[vikkenie]

Hi Guys

        We use two NI USB 8502 to communicate with 2 DUT in a project.After Run about 10 times, there will be an error 0xBFF63001 Error, the CAN communicate fails,and the NI USB 8502 will loose communication in MAX.Attached error pictures and the VIs. Is there someone met this error before. please help, thanks

     Regards

     Vikke

[vikkenie]

Hi Guys

        We use two NI USB 8502 to communicate with 2 DUT in a project.After Run about 10 times, there will be an error 0xBFF63001 Error, the CAN communicate fails,and the NI USB 8502 will loose communication in MAX.Attached error pictures and the VIs. Is there someone met this error before. please help, thanks

     Regards

     Vikke

[JefeL]

The original thread is 5 years old and at first glance I don't see how it is related to your issue. In the future I would recommend creating a new thread to get better visibility from the community.

That being said, the errors in the error log indicate that the OS is throwing USB errors that the XNET driver simply bubbles up to the user. There any number of reasons the host OS could throw a USB error:

• Devices plugged in or unplugged simultaneously. Typically a secondary problem when the root is a under-powered USB port. Especially common in laptops with power management features. Are the USB port(s) on a hub and is that hub powered? 
• USB compatibility. Sometimes issues arise when a USB 2.0 device like the 8502 are plugged into USB 3.0 ports. Are we plugging the device into USB 2.0 ports? Have you tried using different ports?

Create a new post describing your physical setup, details about the ports/hubs in use, and general information about the system such as desktop/laptop ect.

You can link to this post in your new one to reference the information you have already posted.

[vikkenie]

Hi Jeff

    Thank you very much for the replay.

    I pop a new topic of this issue.

    i try different USB port and also use an extral USB HUB with power, still failed.

https://forums.ni.com/t5/Automotive-and-Embedded-Networks/NI-USB-8502-XNET-interface-loose-communica...

regards

Vikke