From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Mute
- Printer Friendly Page
Ethernet Data Transfer Fails on Deployed RT Application
Solved!
billtrib
Member
08-04-2015 01:06 PM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
I have written a TCP/IP client that interacts with a custom TCP/IP server over a very local network (one cable). I've been developing this for a couple of months on LabVIEW 2014 (not SP1) targeting a cRIO9068 chassis.
Development went very smoothly, never any flaky Ethernet problems on the LabVIEW side. Once I got it all bulletproof I deployed and went out to the plant.
At the plant, Ethernet will connect but no data is transferred. Puzzled, I reconnected my LabVIEW development machine to the chassis, opened the project from which the application was deployed and ran it from inside the project. It works. I see this behavior on the original chassis too, so I have two chassis that work with the development environment but do not work when deployed.
What's up with this? Any ideas appreciated, I can find nothing on this subject in these forums or a general Google search.
Thanks,
Bill
Solved! Go to Solution.
Solution
Accepted by topic author billtrib
08-05-2015 09:34 AM
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report to a Moderator
The problem was caused by the Execution setting of the top-level VI being set to reentrant. I set it to non-reentrant.
The key was using
netstat -a
I saw that the application had multiple ESTABLISHED connections where only one should be possible.
Along the way I cleaned up my code a bit, but the root cause was multiple instances of the application running on the cRIO. If the startup vi is reentrant then you get an instance when the hardware starts or restarts, then you get another instance when you fire up the web-based front panel. Instead of the panel connecting to the running program another one is started.
When running from the development environment this does not happen. The development environment enforces single execution on the top-level vi.
A shout-out to the NI software people: A little warning: "Multiple instances of the program may run because the top-level VI is reentrant" when the build starts, plus adding to the panel documentation something like "Connecting a web-based remote panel to a reentrant top-level VI will invoke a second copy of the top-level VI" would have saved me a day...
Cheers,
Bill
