Modbus IO Server causes cRIO CPU to go to 100%

[JimMacD]

I have 2 Modbus IO servers set up on my cRIO 9022 System. I am using Modbus ethernet to communicate. Each server is targeted to a diffrent IP address for the Modbus device it talks to. The Modbus devices are configured with these IP addresses.

Under normal operation, the CPU of the cRIO is around 10% utilization. however, i am trying to build in error-correction to my VI. The issue I am having is that when one of the modbus devices is dissconnected, the CPU useage gets locked at 100%. I'm assuming this is because the IO server is attempting to re-establish connection and failing.

What would be the correct why of handeling this case to prevent the CPU from hanging at 100%?

[charris]

JimMacD:

When the connection fails, do you know which function is hanging/consuming the CPU? What happens if you run the VI interactively in highlight execution mode?

Do any of the functions return an error when this happens? What are the chances you could post a screen shot of the code?

[JimMacD]

Caleb,

It is not an issue with the VI, I have observed this behavior in the Distributed Systems Manager with no VI running on the cRIO. This leads me to believe that it is the IO Server itself causing the Error.

Using the Distributed Systems Manager, I can see that the piece of code causing the error is considered "Normal priority" (as apposed to High Priority, Timed Structures, etc...)

Also, I have noticed (in Dist. Sys. Manager) that when the CPU is locked on 100%, every 75 seconds the usage drops to 5% (normal operation), and then quickly returns to 100%. This seems like some sort of polling routine that stops and re-executes every 75 seconds (Perhaps related to the # of retry in the server setup screen?) **See attached picture**

[Elizabeth_K.]

JimMacD:

I have talked to the applications engineer who is working on this same issue with you over the phone.  I will help him troubleshoot this issue, and then once we solve the issue, we will post the result on the forum, so please continue to work through the phone request.

Elizabeth K.

National Instruments | Applications Engineer | www.ni.com/support 

[Ben_J1 · Accepted solution]

This is unexpected behavior which shows up also when any other I/O server tries to address the slave as well and I have filed a Corrective Action Request with R&D to help fix the issue in a future version of LabVIEW. One potential workaround for those with the DSC module is to programmatically enable/disable the I/O server with the Engine Control features available in the DSC palette.

[Ting1224]

Hi Ben,

I encountered the same issue too.

Is there any update or patch for this bug now?

Thanks

Ting

NITW AE

[Ting1224]

Hi Ben,

I have to emphasize the importance of this fix a little bit more.

The customer we are servicing here is using cRIO as a critical device in their system, when CPU locks at 100%, it jeopardize the security of the application.

Also, the customer is planning on mass deploying cRIOs in 2012, in the order of 200 cRIOs, very large opportunity, and this issue is hitting hard on the success of this case.

Could you estimate the delivery date of the fix or help us to rush it?

Thank you

Ting

NITW AE

[Roryriffic]

Ting1224,

Your request and situation has been relayed to R&D.  However, it is unknown at this time when the fix will be.