LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

cRIO-9067 Real-time unexpected error restart (Hex 0x661)

Yes I am using the STM library in my software.

I don't know wich version I am currently using in this software.

I am making use of the CVT"s to communicate with the cRIO system.

 

 

________________________________________________________________________
Problems will keep comming... Lets hope the answers do that to.
Never give up without a fight...
0 Kudos
Message 21 of 32
(3,144 Views)

Hi Bigmack,

 

Wow, I didn't suspect that: I did a lot of debugging on the RT side: disabled to closing of the TCP connection over there to see if a crash didn't occur: it still did. The fact that the RT system crashed didn't point me to the GUI side (maybe it should have). Thank you so much, protecting the exit from data read did the trick. Attached is what I did: with every read of data I lock my semaphore on the receiver side so that at that moment the connection can't be closed at the data sender side. Only the exit state of the data sender is looking to the semaphore (not needed to do the other sending states). For now I implemented it quick and dirty, because this is definitely a work around. Now I don't have to re deploy everything if I stop the GUI.

However: the compact RIO will be used in tests which can last for weeks, when the test will interrupt we can consider the test as failed, and this will definitely ruin somebody's day (which will have an affect on my day as well). In my opinion an unsuspected network interrupt (computer crash, glitch in the network) can still crash the crio system (depending on the state in transmitting / receiving). With this in mind I'm very curious about the fix which will happen hopefully in the near future. Do you have a Corrective Action Request (CAR) number for me? Please keep us posted when a fix is available.

Further I want point out that in a previous project the same mechanism was used (I basically modified the code for this project), I didn't see this behaviour in LabVIEW 2013. Here I tested also the mechanism by deliberately unplug the network cable to see how the system responded.

 

Again we are very happy with the work around, thanks!

0 Kudos
Message 22 of 32
(3,127 Views)

All, 

We're not sure if this relates specifically to TCP/IP calls on the Linux target, but I have filed a CAR (#523471) on the issue for further investigation. 

 

J.Willems - If you are using the STM library, I would ensure that you are allowing all reads/writes to complete before closing out the connection. It's possible that we're dealing with separate issues here, but it's hard to tell without a consistently reproducible case. 

 

MichaelBalzer - Have you been able to identify any specific sequence of events that causes the crash semi-regularly? It seems like the answer is no, but if you could document these cases that would be helpful. 

 

My recommendation would be to disable portions of your code until you are able to locate the source of the crash if you are unable to simplify the code to a easily reproducible case. 

 

You indicate that the crash occurs during development periodically. Do you see any consistent warnings or other strange behavior prio to the crash and the hex error report? 

 

Will M.
Applications Engineer
National Instruments
0 Kudos
Message 23 of 32
(3,096 Views)

I haven't noticed anything specific relating to the crash. The only constant seems to be running the RT code from source. Although I'm also running the DSM to monitor the system state, I'm not sure I had the DSM open all the time. The only strange behaviour I've seen is failure to deploy VIs (e.g. a VI is 'broken'), or LabVIEW itself crashing frequently when developing for RT (to the point where LV crashed, corrupted a class in my project, and loading the corrupted class always crashes LabVIEW. Thank goodness for backups).

 

I'll experiment a bit more to try get the 9067 to crash reliably.




Certified LabVIEW Architect
Unless otherwise stated, all code snippets and examples provided
by me are "as is", and are free to use and modify without attribution.
0 Kudos
Message 24 of 32
(3,076 Views)

MichaelBalzer,

 

Just to clarify, the crash only occurs when you run the code in development/interactive mode?

 

What happens if you deploy the code to the controller and run the program as an executable? Are you able to communicate back and forth to the host successfully?

 

This is a bit of an aside, but it might be relevant to this discussion depending on your answer.  

Do you dereference any null pointers in your application?

 

I know you have quite a large program, but have you attempted clearing the LabVIEW object cache or mass recompiling your project?

Having a simplified reproducible case will make troubleshooting this much easier, so please do post something if you are able to find a more specific and reliable source of the crash.

 

LabVIEW crashes can be caused by a lot of different factors (as I’m sure you’re aware). Troubleshooting will be much more efficient if you can create a service request through our support portal. http://www.ni.com/support/ 

 

Will M.
Applications Engineer
National Instruments
0 Kudos
Message 25 of 32
(3,051 Views)

Hello there BIGMACK,

 

I just checked the read and write function and these are on the client side. I assume a wait of 500 msec is enough to get the sending done before closing the connection when I am closing the HMI.
I am using the CCC to communicate with the cRIO.

We had a new crash on monday. I am gathering some more info about when and how the crashes happen.

But it looks to me that usually the system is running stand alone and after some time it apparently crahses and reboots itself.

________________________________________________________________________
Problems will keep comming... Lets hope the answers do that to.
Never give up without a fight...
0 Kudos
Message 26 of 32
(3,031 Views)

Hello Joris,

 

At the moment you are running stand alone: you mean you aren't communicating through the STM library? My  state machine on the RT side goes to a sort of port listening mode, is this for you also the case?

WHen initializing my RT VI I also log a time stamp to a text file on the controller. This gives me insight in when the system reboots and the application starts as a result of the reboot. Maybe this is also a good idea to give you an idea when a reboot occurs (to see if there is any (time / action) consistency in it). If the problem is the same as the problem I had, maybe the use of semaphores is a more proper solution. I think with timing you reduce the chance a crash occurse because you are closing the connection, but there is still achance. With semaphores you are sure the reading is blocked when closing the connection, or the other way arround.

 

Best regards,

0 Kudos
Message 27 of 32
(3,046 Views)

Hello Will M.,

we have Crio 9039 RT Crashing Periodically problem, can you help us to find out the problem? Following is the link.

https://forums.ni.com/t5/LabVIEW/Crio-9039-RT-Crashing-Periodically-problem/m-p/3753451#M1056969

 

 

 

0 Kudos
Message 28 of 32
(1,825 Views)

hello J.Willems,

have you resolved the crash problem? we also have crash problem in crio 9039

https://forums.ni.com/t5/LabVIEW/Crio-9039-RT-Crashing-Periodically-problem/m-p/3753451#M1056969

 

0 Kudos
Message 29 of 32
(1,823 Views)

Hey Wang_Liming,

 

Since this thread is a bit old, I would recommend making a new post so that it can get more visibility than it might in this thread.

Applications Engineering
National Instruments
0 Kudos
Message 30 of 32
(1,814 Views)