National Instruments LabVIEW Remote Panel Bug
Although we use many different technologies and software packages at DMC, we have a great amount of experience with National Instruments LabVIEW. We currently have four Certified Architects and another seven Certified Developers.
Lately, we've had several customers with applications that require distributed systems using cRIOs and RT PXI chassis. Both for development and for later interaction, we often use LabVIEW Remote Front panels. Remote Front Panels allow us to peek in and check on VIs as well as give our clients a simple, economical interface.
I was recently developing an application for a cRIO-9073 that would monitor the safety conditions of several laboratories by checking various sensors and sending safety status to our RT test nodes over LAN. This is a perfect fit for an embedded remote panel since it allows users to check the status of the system from any networked computer simply by pointing their browser at the appropriate cRIO for the zone they are interested in.
An interesting thing happened while testing the remote panel. I accidentally opened a second browser window also pointing to the cRIO. Right now, the cRIOs all have a single connection license. The expected behavior in this situation would be to reject the second connection and leave the original connection open. Instead, both connections were closed with a message that the max number of connections had exceeded the license.
At this point I tried shutting down my browsers windows and reconnecting. No luck. Then I tried the native LabVIEW remote panel dialog. No luck again. Eventually, after a few other troubleshooting attempts I rebooted the cRIO. I spoke with NI and they tested and confirmed the issues. My best guess as to what is happening is that the when the second connection is requested, the RT system sends a message to close all connections to the connecting IP. This terminates both embedded browser connections. Unfortunately, the RT system still thinks the original connection is alive and refuses all future connections. With a system handling laboratory safety, even a very infrequent reboot could interrupt month long tests and is therefore not an option.
Currently, I have no real work around that doesn't change the functionality drastically. My best advice is to create an executable that will act as a remote panel client and avoid the embedded web interface altogether.
Learn more about DMC's LabVIEW programming services.
There are currently no comments, be the first to post one.