Difference between restarting a cRIO and repowering a cRIO

[Thoric]

I have a deployed application on a cRIO 9030 (Linux RealTime with Display).

If I use the LabVIEW IDE "Restart" function to cause the remote cRIO to reboot, my RT application starts up without a problem.

But if I pull the power from the cRIO, wait, reapply power and let it boot up that way, my application encounters a problem.

The issue is related to the use of Ctrl Val: Set invoke nodes for setting the values of controls on a dynamically called VI front panel. LabVIEW fails to actually set the values, and although it doesn't return an error code from the invoke node itself, the control values are not being set.

I have the cRIO set to auto-power up when power is applied (BIOS settings) in order to allow this unit to recover from power outages and work autonomously within a production environment. The dynamically called VIs are Tests the cRIO performs on product.

My question is: why does pulling the power versus calling a reboot of the cRIO make a difference to the deployed code when it gets to the stage of trying use Ctrl Val: Set ?

Does a programmatic reboot clean up something on the way out? Can anyone throw some details on this internal process?

Additional info: This invoke node is quite a way into the software, it's not at the beginning, so the code runs a lot of other stuff first, quite OK, before it gets to this stage. This includes firing up a dozen or so actors, interacting with a database, reading local configuration files. So the application is largely working, it's only falling over when the Ctrl Val: Set invoke is called.

I also show the Front Panel before I call the invoke node.

[Thoric]

Update: the issue with Ctrl Val.Set has become more prevalent and is now occurring on any type of reboot, whether programmatic or through a power cycle.

I'm not seeing any errors from the invoke node and yet the control values are not updating. I'm still investigating, but hope someone else has encountered this and might be able to comment.

[Thoric]

I've got to the bottom of it. There appears to be a bug in Linux RealTime.

After using Ctrl Val.Set to write a new value to a front panel control, you must wait at least 20ms before Running the VI otherwise the values are lost.

I discovered this with the following test code which allowed me to play with delays between nodes until I could get reliable behaviour. There appears to be an underlying issue whereby the target VI doesn't honour the front panel control values when written using CtrlVal.Set if execution occurs immediately afterwards. But pausing after writing the value and before running (Pause 2 below) worked around the issue.

[Thoric]

Hmm. It appears the 20ms delay isn't the solution. No matter how long you wait after writing the value, sometimes the control value is empty when you invoke Run VI.

Am I missing something here?

[AJost]

Hi Thoric,

I agree, this looks indeed like a bug on the LinuxRT as on Windows this works perfectly fine.
I build a little project to reproduce it on my 9030 and I see a very similar behavior.

A delay of 11ms before the Run VI and before the second CTRL VAL.get worked perfectly on my system, but the VI I am calling is very small, so it might be different for large VIs which take longer to load. I didn't make a full sweep of all combinations of waiting times, but this seemed very reliable.

However, if the VI is finished running or not seems to make no difference.

In terms of possible workarounds:

- Are asynchronous calls an option for you?

- alternatively we could create a piece of code which checks using the .Get if the control has been updated and waits until it shows the same value as the .Set input

I will also create a bug report of this issue, so we can tackle is in a future version of LabVIEW.

Andreas Jost

Applications Engineer

National Instruments

[Thoric]

---

@AJost wrote:

Hi Thoric,

I agree, this looks indeed like a bug on the LinuxRT as on Windows this works perfectly fine.
I build a little project to reproduce it on my 9030 and I see a very similar behavior.

A delay of 11ms before the Run VI and before the second CTRL VAL.get worked perfectly on my system, but the VI I am calling is very small, so it might be different for large VIs which take longer to load. I didn't make a full sweep of all combinations of waiting times, but this seemed very reliable.

However, if the VI is finished running or not seems to make no difference.

In terms of possible workarounds:

- Are asynchronous calls an option for you?

- alternatively we could create a piece of code which checks using the .Get if the control has been updated and waits until it shows the same value as the .Set input

I will also create a bug report of this issue, so we can tackle is in a future version of LabVIEW.

Andreas Jost

Applications Engineer

National Instruments

---

Hi Andreas,

I've had to abandon the CtrlVal.Set property because sometimes a delay of 1000ms wasn't enough! I'm writing class objects into my controls, which may be a part of the complication (but shouldn't be a problem nonetheless).

Regarding your possible workaround:

1. Asynchronous - I don't see how this would help?

2. Check using CtrlVal.Get - I already do this, it lies.

Richard

[AJost]

Hi Thoric,

Yes, I would expect that VIs using classes would require much longer to load. It still should work, but I think this explains the much longer delays you experience.

Assynchronous Calls are just a different methods of running a VI dynamically and passing the data with it. It is certainly not a 1:1 replacement of what you are doing, but it can deliver a similar functionality in most cases.

I am not sure what you mean by CtrlVal.Get is lying. My proposal was to set the control with the CtrlVal.Get and then calling CtrlVal.Get in a while loop until it matches the input of the CtrlVal.Set. This should assure that the control is properly updated before continuing. Is this not the case?

[JÞB]

Hair brained idea.  Try a pair of defer FP updates methods true then false after the control valve set to force transfer buffers to flush.

I said it was a hair brained idea.. but it might work.

[Ben]

This thread reminds me of a problem Mike Porter ran into when dynamically launching VIs to insert in a sub-panel. he found that the VI was not fully loaded when the Open VI ref returned. I believe he had to code in a delay to get it to work. But that was back in LV 8 or so running under windows.

I have not read about if you have tried the "GetControlIndexByName" invoke node followed by a "Set Control Values by Index" node.

Since the "Get" has to wait for a value to come back... it may help out.

Just trying to help,

Ben

[Thoric]

---

@AJost wrote:

I am not sure what you mean by CtrlVal.Get is lying. My proposal was to set the control with the CtrlVal.Get and then calling CtrlVal.Get in a while loop until it matches the input of the CtrlVal.Set. This should assure that the control is properly updated before continuing. Is this not the case?

---

It is not the case. Using CtrlVal.Set followed by Get reports that the value has been written. But is hasn't. Which is a bug!

I understand the principal of asynchronous calls, and by providing a strict reference I can wire my data to the call by reference function. However, I cannot limit all my test VIs to the same terminal arrangement, as would be required here.

---

@AJost wrote:

Yes, I would expect that VIs using classes would require much longer to load. It still should work, but I think this explains the much longer delays you experience.

---

It's not a load time issue. I can preload the VI and set the class data in the control, then wait a whole 1000ms, check with CtrlVal.Get that the value has indeed been written, get a thumbs up from the check, then run that VI and find the control is empty (see above suggestion that this is a bug). Besides, I'm currently using statically referenced VIs so these are already preloaded when the main VI launches.

@JÞB wrote:

Hair brained idea.  Try a pair of defer FP updates methods true then false after the control valve set to force transfer buffers to flush.

I said it was a hair brained idea.. but it might work.

Jeff - perhaps worth a try, I like your thinking. However I've already moved on to using an FGV to pass my data around. Issues like this stop me progressing and I'm on the clock 😉

@Ben wrote:

... if you have tried the "GetControlIndexByName" invoke node followed by a "Set Control Values by Index" node.

Since the "Get" has to wait for a value to come back... it may help out. 

Ben

Ben, I've not used this new(ish) function before, although I remember reading of its introduction a few years back. I suspect under the hood CtrlVal.Set uses the same two functions, and perhaps these two exact methods have been exposed to reduce operation times when we want to write multiple times to the controls, allowing us to just call the second one. Could be worth a try, but I won't hold my breath! 😉