LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Problems connecting an executable to cRIO

I have a problem that may be impossible to solve, but I thought I would present it to the experts to see if you  have any insight that might be helpful.

 

In 2008, we bought a chemical reaction system from a company. This was before my time, I inherited the system a few years after it was installed and running. The system uses a LabVIEW executable interfaced to a cRIO-9073 to control various stations and record data. The system has more or less run continuously (with only a few stoppages) since. Last month, I had to power down the system. When I turned the power back on, the system came back but the computer running it did not (still working with my IT on having the original computer fixed). 

 

I've reinstalled the executable on a new computer using the installation disc the company provided, but the executable won't connect to the cRIO. It starts up and operates correctly, but it is not reading any outputs from the cRIO nor controlling any of the components. I've done quite a bit of troubleshooting and am pretty sure it is an executable problem, not a computer communication issue. I am able to ping the cRIO, restart the cRIO using NI-MAX, and can even read temperature, analog, and digital outputs from the cRIO on my computer using NI Distributed System Manager (see image below). I can even see changes in the temperature readings if I heat/cool the thermocouples.

 

I do know that the installation disc from the company did not contain all of the drivers/modules I needed to run the executable or connect to the cRIO. I had to install a couple just to get to where I am. My working theory now is that either: 1) there is still a module or executable I need to install for  the executable to communicate with the cRIO, or 2) there is either a variable, file destination, or something else in the executable assigned to a specific location on the previous computer that is in a different location on the current computer.

 

Concerning my first hypothesis, I have basically installed every module/driver I can think of, and then some. At the bottom I have included both the software that I have installed on the computer and what is running on the cRIO (I have not modified or uploaded anything on the cRIO). I also have the hard drive from my old computer, and have all the same National Instrument program files installed on the new computer that were on the old computer. Maybe there is something else I need? 

 

Concerning my second hypothesis, this would be easy to troubleshoot if I had the original project file. Unfortunately, all I have is the executable file. The company that we purchased the instrument from is now dissolved. I have been in contact with a former employee, but not the LabVIEW specialist, who we can't contact. I don't think I'll be able to get the original project file, but I'm trying.

 

I realize that without the original project file, I may never be able to figure this out, but any advice/ideas you may have are appreciated. We really, really, need this system back up and running. Happy to share any other information. I have somewhere between a beginners/intermediate skill level with LabVIEW, but little knowledge of networks.

 

NI-DSM.jpg

cRIO_software.jpg

Comp_software.jpg

  

0 Kudos
Message 1 of 6
(1,544 Views)

Regarding your second theory about looking for a particular file in a specific location, it seems like you can verify this with procmon. I didn't build my test code into an executable, but I don't see why it wouldn't work the same way; just filter based on your application's executable name instead of LabVIEW.exe. You can see that attempting to open a file that doesn't exist still registers as an event in procmon.

 

file_access_test.png

0 Kudos
Message 2 of 6
(1,529 Views)

Shot in the dark but have you checked the firewall settings for the application that talks to the cRIO? You might need to explicitly give it access through the windows firewall security configuration.

0 Kudos
Message 3 of 6
(1,507 Views)

Thanks, this was a good thought. I made sure the executable had access but it still didn't work.

0 Kudos
Message 4 of 6
(1,458 Views)

Your right, it did work... there's a lot of files to get through, even if they are filtered by "Name Not Found"... Most of them are registries and .dll files. Seems strange to me that so many of these would apparently be missing... 

0 Kudos
Message 5 of 6
(1,444 Views)

Makes me wonder if the original application called some external libraries that were installed along with some kind of driver or third party program

0 Kudos
Message 6 of 6
(1,440 Views)