DWarn 0x9E32E6DF: FPObserver list is in a bad state: No Local Observer or Controlling Observer

[JKSH]

Hello,

My colleagues and I have developed an application for the cRIO-9030, making use of their embedded UI on a touchscreen. Here's a brief description of our architecture:

• The built RTEXE has 2 top-level VIs: One for business logic, and one for the GUI.
• The GUI and business logic VIs communicate exclusively via Network Shared Variables, hosted on the cRIO.
• The GUI is rather simplistic, consisting of one large tab control with many indicators and a few controls.
• The GUI uses an Event Structure to handle Value Change events.
• The GUI has ~200 bound Network Shared Variables on its front panel.

I've had some issues with the cRIO crashing (error 0x661, just like https://forums.ni.com/t5/LabVIEW/cRIO-9067-Real-time-unexpected-error-restart-Hex-0x661/td-p/3105450 ), so we're investigating the issue. During our investigation, we found this message in the RT Error Log which we download via NI MAX:

DWarn 0x9E32E6DF: FPObserver list is in a bad state:  No Local Observer or Controlling Observer

My questions are:

1. What does this warning mean?
2. What could we do to try to eliminate this warning?
3. Could this warning be related to the error 0x661 in any way?

[Reyquaza]

Hi JKSH,

I've seen another instance of the two messages occuring together, so I do believe they're related. The warning appears to be related to an error on something in the front panel, so it may be that you're setting a property of your Front Panel that's causing an error. Are you using any Property Nodes to set properties on your front panel?

[JKSH]

Hi Rey,

Thanks for sharing your experience.

Yes, I do have one property node: At startup, I set "FP:Run Transparently" to TRUE and "FP:Transparency" to 100, in an attempt to stop the business logic VI's front panel from showing up on the touchscreen. I didn't think that was the issue, because the property node is only called once (at startup), yet the cRIO appears to run fine for up to 24 hours without issues.

I'll remove that property node and see if things improve.

If the property node is indeed the cause of the error 0x661, is there a document available that lists what can and can't be used in a Linux RT embedded UI? This page implies that tproperty nodes are supported: http://zone.ni.com/reference/en-XX/help/370622M-01/lvrtconcepts/display_developing/

[JKSH]

I just remembered: The embedded UI VI also uses the following property nodes for controls/indicators:

• Visible
• Disabled
• Val(Sgnl)

Are any of these disallowed on Linux RT embedded UIs?

Note: We have encountered eError 0x661 at times when nobody was using the embedded UI, so property nodes weren't being activated then.

[Reyquaza]

Have you tried error handling or state logging to confirm where the crash is occuring? How often does the crash occur?

[JKSH]

---

@Reyquaza wrote:

Have you tried error handling or state logging to confirm where the crash is occuring?

---

How do I do that? Neither DWarn 0x9E32E6DF nor error 0x661 appear in LabVIEW error clusters.

They only get captured in the RT Error Log (see my original post).

---

@Reyquaza wrote:

How often does the crash occur?

---

Error 0x661 seems to occur once every 5 hours or so, even when the system is left in an "Idle" state where the core state machine doesn't do anything. However, background processes are still running when Idle (e.g. copying Modbus registers into shared variables, monitoring digital inputs for alarm conditions. etc.)

DWarn 0x9E32E6DF actually hasn't appeared for a few days now, even though I didn't change anything in the GUI since the last time the warning appeared.

Anyway, this thread is mainly about DWarn 0x9E32E6DF. What implications does this warning have? Do I need to worry about it, or is it safe to ignore?

Also, you commented that we should be careful with property nodes in Linux RT with embedded UI. Which ones should I look out for?

[Reyquaza]

I believe the DWarn is something LabVIEW can resolve, so I don't think you need to be worried about it.

[JVH8SLV]

Were you able to get to the bottom of this? Experiencing a similar problem, crashes the program sporadically.

[JKSH]

---

@JVH8SLV wrote:

Were you able to get to the bottom of this?

---

Unfortunately not.

This is an internal issue and we users have no feasible means to troubleshoot or study it.