Compact RIO ( cRIO )/ LabVIEW Event Handling Bug

[nathand]

I was thinking of this thread: http://forums.ni.com/t5/LabVIEW/Unsupported-VIs-for-the-cRIO-9030/td-p/3072333 but it looks like there was never a conclusion there about event structures, and there are conflicting links to NI documents (one says events on front panel objects are not supported, another does NOT mention event structures as not being supported).

[a_clucker · Accepted solution]

Hi,

After talking with R&D, I have filed CAR # 544225 for this issue.

Thanks, MF, for reporting it as such.

[MF]

Excellent news Andrew,

This situation has workarounds but cRIO or future NI products will rely more on LabVIEW being the sole source of Grapical User Interaction. Therefore the flaws should be reduced as much as possible. 

Cheers!

Michael

[natasftw]

So following up on this:

I suspect you're not using the Embedded UI.  Here's my test:

Hardware used: cRIO-9033, non-touchscreen monitor, and mouse

Software used: Both LabVIEW 2014 SP1 and LabVIEW 2015  (RIO 15.0, I'd hope this is obvious as I'm not interested enough to uninstall and reinstall older RIO drivers)

If I build the application and run it as startup, I can use my Embedded UI and everything triggers as you expect.  It triggers a single event for both the Test button and the enum change.  Both of these cases only trigger a single event.

If I connect to the cRIO via the project, it prompts me about running code on the cRIO and asks if I'm sure I want to stop it.  At this point, I can see the code stop on the Embedded UI and go back to the Powered by LabVIEW wallpaper.  I can run the VI in the project and see it appear on the Embedded UI.  I lack any control from the Embedded UI at this point.  I can click my mouse as much as I please but nothing registers.  If I click on something on my Host PC's Front Panel, it triggers the event twice from the Test button and only once from the Enum.

What does this tell us?

1) The way LabVIEW handles the cRIO-9035 and 9033 is different OR you're not using the Embedded UI and are pointing out the Host PC doesn't behave the same as it's not the embedded UI and follows traditional RT paradigms.

2) The documentation on this isn't clear.  Is the Embedded UI expected to behave the same as a Host?  If so, the documentation should be updated.  If not, the  behavior isn't a bug.  Based on the CAR being filed, I'd suspect they're leaning towards it being supported os the documentation should be updated to be more clear here.

3) It appears developing your application and running it headless are two different things here.  If you want to see how it behaves on your target, you should deploy it to the Embedded UI rather than run it on your Host.

Now, I'm curious.  How did YOU test this?  Did you actually use the Embedded UI or did you run it from your Host?  If you don't have a monitor hooked into the display port and a mouse or a keyboard plugged into the cRIO via USB, you're not using the Embedded UI.  Did your test use the Embedded UI or did you see the behavior you explained in development?  If you're seeing the same thing I'm seeing, Andrew should probably modify the CAR to suggest the Host behavior appears different than the Embedded UI would perform.

[a_clucker]

Based on the CAR being filed, I'd suspect they're leaning towards it being supported os the documentation should be updated to be more clear here.

This is probably the case. Thank you for your detailed post.