Strange Real time target desktop reboots??

[soeren]

Hi

I have recently been using Labview Real Time 9.0 on a couple of Real Time Desktop targets. I have two different systems running 24hr operation each with their own project sharing a couple of variables via TCP/IP. Sometimes I have had some random faults on either of the systems, where I could read on the RT target screen that the system has rebooted due to system error. Another more mysterious error is when one of the targets writes : "70. connector : close h33, no handler" Any ideas what this means? Is there an error log somewhere I can consult to track down these faults?

Any fast responses to what could be the problem?

best regards

soeren

[soeren]

More strange errors. This time "57: Connector::close h 42, no handler". I wonder what the RT is trying to tell me??

The system is running 24 hr operation, with a couple of PCI cards, and some timed loops. This particular error appeared after 2 weeks of operation. It seems like it is stille running. Maybe it's getting tired and needs a reboot?

Any suggestions?

/soeren 

[soeren]

Hi

My two RT systems have been running smoothly after a reboot a while back. They seem to be working fine, but one system is has prompted the the line: "78: Connector::close h 17, no handler" and the other "58: Connector::close h54, no handler"

The systems are two different RT Desktop systems, both with two CPUs, and showing similar "mysterious" commands when left running for longer periods.

Should I worry about this? What does it mean? Someone must have programmed them to do this for some reason. The systems are connected to some potentially dangerous setups, and it's fairly important that I can rely on their operation. I'm just interested in the story behind these strange commands.

best regards

soeren

[soeren]

Since no one from NI has any idea of what's going on with their RT systems, I'll just keep this thread as my own log on what is happening with my RT systems. One of my systems now has 3 lines of strange code written in the prompt:

78: Connector::close h 17, no handler

78: Connector::close h 40, no handler

78: Connector::close h 17, no handler

The system is still running but I recently had a problem loosing connection to the RT system, but it is my experience that this sometimes happends when the systems are left idling for loooooong periods.

[soeren]

Hi again ppl

The fun continues, RT system now says:

"

Welcome to LabVIEW Real-Time 9.0

78: Connector::close h 17, no handler

78: Connector::close h 40, no handler

78: Connector::close h 17, no handler

78: Connector::close h 53, no handler

"

How about that!.........I wonder what it is trying to tell me. It is still running, working fine, maybe I shouldn't worry so much. 

[soeren]

Still no one apperently knows what the RT is trying to tell me. I lost connection to the system today, I think I'll restart the system and see when the error starts appearing.

[Riconquistiamola]

soeren,

The message is a warning message from the Adaptive Communication Environment (ACE) portable communication software library.  I do not know of any modules within NI that use the ACE architecture for network communication, as they most all use proprietary NI interfaces.

The particular error message you're seeing is being output because ACE is finding an inconsistency in the data structures for the connection being closed - ACE is attempting to cancel/close all services registered with an outstanding (socket) connection that ACE is trying to clean up, but a service that is using the connection does not appear to have the correct shutdown handlers registered to cancel/close the service.

Do you use the ACE libraries in your code? If so, you may need to debug your source. Cheers.

[soeren]

Hi, thanks for your response.

What you suggest sounds plausible, although I have not knowingly added any ACE communcation library. Maybe it is something that is integrated in some of the Real Time communication protocols, or in the Shared Variable environment. I'll go do some digging and see what I can come up with. It is annoying not knowing if I should care or not.

Thanks for you response.

/soeren

[JP205]

Did you ever find a way to resolve ths? I'm seeing the same error.

Thanks,

JP

[soeren]

Hi I have still not really solved the problem and the systems have been running for many years now. I have 3-4 systems that I bother to check for this error once in a while, which all continuously are running for months at a time. I make sure to reboot once every 3-6 months if it possible. I have seen the "error" one many different brand machines with different chipsets, and both on single, duo and quad core desktop machines. The VI I use are using standard labview code, nothing exotic except a couple of "Control Toolbox" sub VIs. Perhaps it is hardware realted, what sort of NI hardware are you using on your RT target? Best regards soeren