Problems with cRIO 9025

[Sicitronic]

Hello,

I have some problems with cRIO 9025. I will start explaining the system. We hava a batteries control system developed with a cRIO 9025. We aren't the developers of this system, but the manufacturer doesn't have the competences to solve the problems becouse the original developer is a third party. Because of we have enough knowledge about LabVIEW we will try to solve the problem by our own. However, we haven't experience with real time hardware systems.

The problem is the following. The Leds of the modules of the chassis (CAN BUS and DI/O modules) doesn't work, although the power Led of the cRIO is turned on, so we suspect that it could be in sleep mode ¿How can I awake it? There is a manufacturer application (LabVIEW .exe app) to monitoring the system through the PC, but it doesn't work too. It's evident that something isn't work.

We have tried to explore the state of the system through a LabVIEW project, but when we add the cRIO appears this message:

We think that we have the correct NI-RIO driver installed, so we don't know what happens.

In the Ditributed System Manager we can see the shared variables but the communication isn't good (no known values) and we can't view the device as a cRIO:

Exploring the systems through MAX I have realized that a common error is logged:

Another question. I know that there are some ways to reboot the cRIO (cycling power, resset button, with a reboot from labview proyect or MAX and programatically). We want to reboot the cRIO at distance, for example with the restart option from MAX, but we must to be sure that the FPGA or the internal real time code is not deleted. I have read in some forums somthing about this topic, but it doesn't clear. This point is very important becouse we haven't the program code to be able to deploy again the code.

I have read in forums some similar problems, but the solution is redeploy the software, and that isn't possible in our stuation.

I would be glad if someone can help me. Thanks in advance,

Miguel Ángel

[AndyClegg]

Do you know if the cRIO application is designed to work in a headless mode - i.e. without a PC connected ? If so it should be set to always start when the power is turned on. Or if it works in interactive mode (i.e. with a development PC connected) then you'll need the source code for the cRIO and LV on your PC and deploy/run to start it running. The former option relates to the last question you ask - about how to preserve the RT code and FPGA code at a power cycle / remote reboot - it is possible if you use the "Run at Start-up" option when deploying the code.

There is a DIP swicth on front called "NO APP" which if turned ON will prevent any application software from starting on power up. You can also check CPU usage to see if something running and it is so heavily loaded that it is unresponsive (incl. network dropouts) or if it is quiet. When you power on the flashing of LEDs at start-up provides some information - see the operating guide for the specific cRIO.

If it is networking that is causing problem - there is a lot of ways they can have a problematic connection (e.g. static vs dynamic IP - covered in other discussions)

The PC monitoring applicaton - as a .exe - implies that it is a compiled application, so you'll need the appropriate LV Run Time Engine installed - to match the version the .exe was built in.

Is the cRIO new, or had it been working with this application in the past ? It may need LV core software installed on it (NI-RIO) - and it has to be of the right version for the application you have.

BTW - I would expect the "SB-RIO" referred to is a single board RIO device, and not your cRIO, I think ?

The original developers should have documented all this stuff - but I guess if they had you wouldn't be asking these questions.

[Sicitronic]

I reply in your message:

Do you know if the cRIO application is designed to work in a headless mode - i.e. without a PC connected ? If so it should be set to always start when the power is turned on. Or if it works in interactive mode (i.e. with a development PC connected) then you'll need the source code for the cRIO and LV on your PC and deploy/run to start it running. The former option relates to the last question you ask - about how to preserve the RT code and FPGA code at a power cycle / remote reboot - it is possible if you use the "Run at Start-up" option when deploying the code.

I think that it works in headless mode and that it is set to start when the power is turned on because the manufacturer provides a stand alone app (LabVIEW .exe app) in which if I didn't have LabVIEW it should work although it is possible that the app deploys the program. I'm sure that the code is preserved if I turn off the system because sometimes it has work after that. So is it the same cycling power as reboot at distance or with the reset button?

There is a DIP swicth on front called "NO APP" which if turned ON will prevent any application software from starting on power up. You can also check CPU usage to see if something running and it is so heavily loaded that it is unresponsive (incl. network dropouts) or if it is quiet. When you power on the flashing of LEDs at start-up provides some information - see the operating guide for the specific cRIO.

All switches are turned OFF.  When I power on the system, the STATUS LED is turned ON one or two seconds and then it turn OFF, the POWER LED is turned ON and it remains in that state. I think that it is normal and so malfunction is not diagnosticated.

If it is networking that is causing problem - there is a lot of ways they can have a problematic connection (e.g. static vs dynamic IP - covered in other discussions)

It could be something related with this point. But the modules (CAN and DI/O) should turn on and they don't ¿Don't you? I think that the IP is configured as dynamic but I'm not sure.

The PC monitoring applicaton - as a .exe - implies that it is a compiled application, so you'll need the appropriate LV Run Time Engine installed - to match the version the .exe was built in.

Is the cRIO new, or had it been working with this application in the past ? It may need LV core software installed on it (NI-RIO) - and it has to be of the right version for the application you have.

It has been working yet, so run time engine and software should be installed.

BTW - I would expect the "SB-RIO" referred to is a single board RIO device, and not your cRIO, I think ?

It refers to cRIO.

The original developers should have documented all this stuff - but I guess if they had you wouldn't be asking these questions.

You are right.

Thank you so much. Any idea?

[Sicitronic]

I have done some advances.

I have put the IP as static and according with the PC IP. I know before that the TCP/IP configuration was not the problem, but now I'm sure that it won't be.

I attach the report about the setting of the cRIO, you can check it (download and extract the "cRIO report.zip" file and then open the .html).

I have attached the logging of the frequent error too (lvrt_err_log.txt) related with /c/ni-rt/system/lvrt.out. I think that the problem comes from something related with this. I remind that  the chassis isn't recognized.

[AndyClegg]

I presume the labview.exe file is a PC application. What do you have on the cRIO - an .exe installed on the cRIO or the full source code which you can deploy ? If you don't have the soure code I wonder how far you can fix or debug it. Note there are two ways in which FPGA bitfile gets deployed within an RT application and important to understand which you have as it will change what you have to do to get things working - this explains it http://www.ni.com/white-paper/9640/en/.

When you say the labview.exe does work - can you be more specific.

I think a remote reboot and a reboot from swicth on front should be the same - a power on/off cycle may be different since it affects everything (IO modules, external devices, etc).

You'd be better looking at the operating instructions for each card with respect to the LEDs and if they should come on on power up.  Are you sure they are supposed to light up - I wonder if everything is fine and it is just waiting for some user input or some signal from somewhere else before it does anything. If it worked previously, it may be something simple (once you find it).

There is a serial port on the cRIO which can be used to provide some diagnostic information - e.g. messages as the system boots up - through something called CONSOLE OUT. See the cRIO operating instructions for detaials.

[Sicitronic]

Yes, the .exe is a PC application. I am not the developper of the system, only user, so I presume that the cRIO has a .exe installed and I don't necessarily have to deploy the full source code, which I don't have. The system had ocasionally worked therefore I suppose It is configured as satand-alone application. Is it possible that the labview.exe PC application deploys the FPGA libraries each time that it conects with cRIO?

When I try to start the application, it is displayed an error: "Failed to establish TCP connection. Check the Ethernet cable and then restart." It is a custom message, so I am not sure if it is generated becouse the program check all variables including those related to the DI/O signals of the modules and due to they aren't recognized it is shown that error.

I have checked the ethernet cable and it is OK, and the connection too. In MAX I can connect with the cRIO without any problem. However,  neither the modules nor FPGA are recognized. In the .exe application folder I have found a .aliases file. The alias for the cRIO joins with its actual IP, and the alias for the PC host is "localhost". There is a third alias for My Computer that has another specific IP, but I suppose that it is designed for developing targets.

In regard to the reboot ways, I agree.

My hypothesys now is that the cRIO chassis is broken.

[AndyClegg]

I doubt the PC application will install the FPGA code - it will be either installed as a separate (pre-compiled) bitfile which is downloaded separate from the RT application to the cRIO. Or the RT application on the cRIO can include the bitfile and download it to the FPGA whenever it boots up.

Given the error message you are seeing - it may be the network settings programmed into your PC application don't match the network settings you have right now (on either PC or cRIO), even though they do allow MAX to see it. When we are building systems it is very useful to have exactly the same network configuration on PCs/cRIOs under development/test as they will have when deployed.

You should be able to see the IO modules on the connected PC without the application software in Distributed System Manager (I think it is this, rather than MAX). If you can't see them, then you may be right about something being broken.

Have you checked that everything you need is installed on the cRIO (even though it should be the same) - in MAX expand the cRIO device in the navigation pane, right click on software and select Add/Remove, and it will show you what versions of the core software is currently installed on the cRIO. It may be that this core software has somehow become corrupt. I am not sure if reinstalling things will wipe you original RT application on the cRIO. It woudl be a good idea to make sure you have those application files backed up from the cRIO.

[Sicitronic]

I have done a test with the Digital Input module. According to the manual, each chanel has an LED that turns on and off to indicate the state of that chanel. LEDs have to turn on if the input level is higher than 11V. I applied a voltage of 24V, but the Leds haven't turn on. The manual says: "The LEDs are disabled when he chassis is in sleep mode." I have started the cRIO with the microswitch NO APP turned on so as to prevent that any program runs and active the sleep mode. Under my point of view either the chassis is broken or it is blocked and it is needed to format it (I discard this option until I don't have support of the developer, to prevent delete any file inside).

What is your opinion?

[Sicitronic]

[AndyClegg]

It seems that might indicate a faulty chassis or IO module - I assume you connected the COM when doing the test, and made sure the current draw wasn't too high for the module.

I am not sure if the NOAPP only disables the RT application or the FPGA as well. If the FPGA code is still running, it could be where the chassis is put into sleep mode.

Just to go back a couple of points - you say the status LED comes on and then off - if you look in cRIO manual it will tell you what that means - but in cRIOs I have used, this means there is no core software (NI-RIO) installed on cRIO. I'm not sure how the IO module will respond without the NI software - it may just default to sleep.