Reconnect to ethRIO - error -63040

[PiDi]

I have ethernet RIO 9146. It is connected to Windows PC by ethernet cable. My PC application is communicating with RIO and it works fine the time I run the whole system. I want to make my application more robust and allow it to reconnect to RIO after connection is lost. I'm performing simple "unplug ethernet cable from RIO and then connect it again" test, but cannot figure out any way to make my application reconnect to RIO.

So, the here's the state machine of what I'm trying to archieve:

And there is project in attachment.

Some more info:

- When I unplug ethernet cable, the FPGA application is still working (it has blinking LED), it is also still working when I connect cable again.

- When I press Reset button on RIO, it does not reset FPGA (LED is blinking). The same whe I try to make software reset from MAX or from Restart.vi from System Configuration pallete (which are equivalent I think).

- I can probably use System Configuration to get to the hardware and reset FPGA (I'll try it), but this takes a long time.

- On rare occasions, the reconnection actually works. I also haven't yet determined why I sometimes get error -63040, and sometimes -63044.

It sounds like a very typical use case - what am I missing?

[dborzi]

Hello there!

After you call the Reset and Download invoke nodes, you should wait some time before you call Run, because it might happen, that those actions are not yet completed before you try to run your not-yet-downloaded application, so it will cause problems in your application. 

For handling network connections I recommend using network streams.  It's a powerful way of handling network communications. You will find a property node to check if the connection is ok or not.

Hope this will help you develop your application.

Daniel.

[PiDi]

---

@dbCu wrote:

After you call the Reset and Download invoke nodes, you should wait some time before you call Run, because it might happen, that those actions are not yet completed before you try to run your not-yet-downloaded application, so it will cause problems in your application.

For handling network connections I recommend using network streams.  It's a powerful way of handling network communications. You will find a property node to check if the connection is ok or not.

---

1. I've always thought that Reset and Download are blocking and atomic operations - they're done after the flow goes past them. Now that I'm looking at it, there is no clear information about that in documentation (or anywhere else). Should I treat your post as some kind of revelation? 😉

2. Is there any way to actually reconnect to working FPGA application? Let's say I have RIO which controls Very-Important-And-Fragile-Process and somehow I lost connection to it from my PC. I want to reconnect to this RIO but I don't want to reset it, because my Very-Important-And-Fragile-Process wouldn't be very happy of that.

If I had cRIO with real-time OS, this would be no problem (yes, the network streams are one of the possible solutions here). I'm also completely aware that this is exactly the use case for cRIO. But what about ethRIO?

So, the whole topic in one simple question: Is there a way to connect/reconnect to working FPGA application on ethRIO (or actually to any working FPGA)? By "reconnect" I mean without reseting anything.

[ZX81]

Typically, I avoid the problem by using network-shared-variables to share data from an Ethernet-cRIO to a host computer.  But that makes for 3 layers:  FPGA, RT-CPU, and computer.  The advantages are that NI takes care of all the connections (and re-connections), and that I can sometimes run the host application on more than one computer.

A co-worker here typically uses FIFOs instead.  With them, NI takes care of connections (and re-connections), too.  They can go direct from the FPGA to the host, and don't skip values.

I haven't worked with streams a lot, but I think they have the same advantages as FIFOs and NSVs put together.  

But I suspect you have something more to the story, so FIFOs and NSVs aren't a good option.  You didn't describe (unless I'm going blind; very possible) what you use to connect; can you go into that a little?

I see that you followed the NI programming model very closely, and pass your error cluster around everywhere.  That's great in some cases, but once you get an error, it tends to prevent anything else from trying to run.  It can really hurt error-recovery.  Since you know the error codes are -63040 and -63044, you could ignore the error if it is one of those two.  Or you could drop all errors when you try to open a new connection.  This goes for the FPGA code and the host code.

Re: not resetting.  Is it possible the FPGA is really resetting, but faster than you can see?  Once the application is loaded in the FPGA, it may be able to reset in <1us.

Re:  -63044 vs. -63040.  One is an error locating the FPGA; the other opening a link.  The difference is probably in timing, and you could treat them as the same thing.

Re: download & run.  I've always had good luck with downloading to the FPGA then running immediately.  I've never tried programmatically downloading to a RT-CPU, though.  I'll file this away in things to look for if things look goofy, though.  Adding the delay sounds like good advice, and does help in a lot of cases.

Re:  avoiding reset.  I almost always avoid resetting the FPGA.  There is a setting for 'run when loaded to FPGA' you should check to avoid the invoke(Run), and 'set as default build specification' which I see is checked, in the build specification.  I've always included an RT-CPU application that ensures the FPGA is running, so don't have great advice for you on checking whether it needs to be downloaded.  I think once you've downloaded the .vi, it will automatically start it up on a power cycle or reset after that (but am not certain).