sbrio 9607 - Times out on first execution, then needs about 5 reconnect attempts, then works flawlessly

[tobiy]

Hi, I have a strange communication problem with the sbrio 9607.

It is connected via ethernet directly to a development PC, using LV 2019.

When I re-power or reset it, I can see and communicate ok in MAX after some seconds. I can also connect in LV and deploy a project. However, it will always immediately time out and loose connection.

If I then re-power or reset the sbrio I come back to the beginning. I.e. this is a sure way that I can not work with this sbrio.

The only way to get the device to function normally is to:

1) not reset it

2) attempt to reconnect it in LV 2019, which will fail. It says that some ressources are in use. I sould mention, that the initial deployment ceased running long before. The whole workaround here works only, if on the first deployment try, I run something which will terminate without user LV user interaction. Otherwise, the next step will not work.

3) attempt connection several times more. Usually between 3 to 10 times (Honestly, I don't remember how I found out. Must have been very frustrated lol). Speaking in time, this is about 1 minute after the first failure. But also waiting longer, I still need to reconnect many times before it eventually works.

4) Eventually the sbrio connects fine and I can normally deploy, run stuff and interact fine.

If the device shows the same behaviour, I anticipate it will not work well in the field. Therefore I am looking for a way in which I get an immediate robust connection.

[MrJackHamilton]

Toby,

First, this is not normal sbRIO or cRIO behavior.

Check the following:

1. In MAX check the 'Halt on IP Failure' is = OFF - this could explain the 'N' attempts - the sbRIO is halting and/or detection an IP failure.

2. Put the sbRIO on a static IP and set the DNS Server. = 127.0.0.1. This will turn off the DCHP lookup when attempting a connection for the FIRST time - this lookup can take about 1 full minute to timeout - after which the sbRIO will then connect and action normal and responsive for the entire session.

3. Open the simple UDP example program, drop and deploy the UDP into the sbRIO, add some code to report the sbRIO IP address and the time or something. Run the UDP receive on the Host PC...

...As UDP is 'conectionless' you can receive the UDP message on your Host without 'knowing' the TCP Address...this will tell you at the lowest level - the TCP IP stack is running on the sbRIO...

4. Reintall the sbRIO software...if that fails and try again.

Try that and report what you get.

Regards

Jack

If

[tobiy]

Hey Jack, thanks for the reply,

I will try to go through the steps one by one. I have difficulties locating the first setting you mention. Can you point me to it ?

2) i will try static IP if need be, but this is not useful remedy for field deployment. Also, at the moment the DHCP IP is received quite quickly as I mentioned, and I can communicate with the device in MAX shortly after startup. The problem seems to be only with Labview.

3) You mention "the" UDP example program. Is there a prepared example somewhere in Labview that I can blob into the project ? If so, where ?

[SeniorArchitect]

Toby,

1. The simple UDP is in Examples folder here:

C:\Program Files (x86)\National Instruments\LabVIEW 2019\examples\Data Communication\Protocols\UDP\Simple UDP\Simple UDP.lvproj

2. The 'Halt on IP' *might* not be avaliable on all RIO implementations - I just looked at a cRIO system we have setup and it's not avaliable for it.

But here is a screenshot of what it looks like in MAX. Its on the 'Systems Settings' tab not the Network settings tab [Go Figure]

[nanocyte]

You can disable those previous deployments by checking the "Disable rt startup app" and "disable fpga startup app boxes in MAZ

It might help if you post an error code or message.

I agree with the UDP strategy.

[tobiy]

The halt on IP is not available.

I tried the two disable startup option, but they did not change the behavior.

I also noticed, that the timeout is not immediate on the first run, but only happens after the program runs alright for about 100 ms. I.e. I receive valid data in the host app from FPGA processing in this first short time window. Only after this very short time of normal operation do I get a reproducible timeout.

Here is the error message I get, when I try to reconnect in the Labview project manager after the timeout happens.

After retrying the connect, it eventually works and everything will be fine indefinitely, until i either rebuilt the FPGA project or repower/reset the sbrio.

The new fact, that the program initially deploys fine and runs alright for a fraction of a second and communicates well both with the RT host and with the Dev PC lead me to believe that there could be a buffer overflow issue somewhere in the communication. ?!

I will try the UDP example next.

[SeniorArchitect]

Toby,

I think there is code running in your sbRIO which is causing some issues. Also, the sbRIO takes about a full 45 seconds from power-up to actually start communicating.

At this point I would recommend in MAX you:

1. Check & Update the firmware on the sbRIO to the firmware version of your LV development version - this is done in MAX - the firmware bitfile is already in your system. Firmware version conflicts can cause this qwirky behavior.

2. Format and reinstall the software on the sbRIO. Use the recommended baseline installation. Although when you get more experienced - you only install what you need.

Pls report back...

Jack Hamilton

C6 Systems, Inc

www.C6systems.com

[nanocyte]

Your FPGA behavior is a good hint. The networking goes through the FPGA so when you deploy a FPGA program, it's normal to see a disconnect there. UDP should be able to "reconnect" much quicker so that was driving some of the interest there. I'm not totally sure about how the projects arbitrate who gets access to a target but it sounds like the remote target has to give up on the previous connection before it's willing to listen to your project. I'm not sure if that's normal behavior or not but if it wasn't I would expect there was some minor aspect of your configuration (what software you have installed vs what it has installed) or your project that's causing the arbitration problem. I would probably just live with the issue if it isn't causing other problems but the only other way to determine if there's an issue and to solve it probably involves a call to NI and a fair amount of formatting, re-installation, creating a new project, etc as suggested above.

Conflict Resolution

Unable to resolve from current dialog

Access denied: Another project is using this target. You must disconnect the existing project from the target or restart the target before establishing a new connection. Note: The existing project may be running on a different host computer.

[tobiy]

Hello again,

some time has passed and I got my hands on another sbRIO-9607.

The same issue appears on it. So, indeed it has got to do with my code.

Some more details:

The issue appears when:

• The sbRIO is rebooted
• The FPGA code is re-built and was never deployed before

The issue DOES NOT appear when:

• When the sbRIO is disconnected and reconnected (Ethernet)
• When the RT code is changed and re-deployed.

Does this help narrow down on the cause?

[nanocyte]

I think what I wrote is still applicable. To reiterate:

• I don't think it's your code. Any code that reconfigures the FPGA will have the same behavior.
• Its probably is not worth your time and effort to solve this problem.
• Otherwise, I'd create a support ticket and please follow up here with the resolution.