Wiring output tunnel of event structure to assertion raises error 1055 on Real Time target

[stagg54]

I have no idea if this is a LabVIEW bug or a Caraya bug. I figured I'd throw it here first and see if someone can reproduce it.

What I am trying to do is run some unit tests to test a DQMH Module running on a cRIO. I want to launch the module, send it a message and verify that it fires off the correct event as a response. To do that I have an event structure inside my test VI to catch the event.

I am running LV2017 (32bit 17.0.1.f4) on Windows 10. I am trying to run tests on a 9040 cRIO. I attached a screenshot of MAX showing the SW installed on the cRIO.

Here is the error I am getting:

Here is the simplest thing I could get to replicate it.

Everything is fine if you wire a constant to the assert. However, if you wire an output tunnel of the event structure to the Assert, then you get error 1055.

Running the same VI on Windows does not show this behavior.

[francois-normandin]

Hi Sam @stagg54 , Maybe you can put a single iteration while loop around the event structure to see if you still get the error? If not, then it's a LabVIEW bug... Otherwise it's still inconclusive but at least it would rule out the effect of the single case event structure.

I've seen 1055 error usually happening when a front panel reference is invalid and you try to close it via VI server... It's a suspicious coincidence that no front panels exist on some real-time targets, so I'm unwilling to rule out a wired interaction with Caraya yet, although from your report, it does not seem to be the most probable cause.

[kosist]

As I've understood from "Basic Test Manager\Process Container.vi" block diagram, it opens Caraya interactive interface. If error is occurred, then Caraya UI will immediately display error dialog window. And most probably VI server property node drops the error because of execution on the Real-Time side.

Of course, that does not explain the fact, that when there is constant wired directly to Assert function, then this error does not occur...

[francois-normandin]

I think Sam has the silent mode flag set though, so the process is not supposed to pop any panels opened. Maybe this node does need to be removed completely. I've never liked this behaviour of the jki state machine in the first place;-)

[kosist]

Yes, but that flag is read in Process.vi. So anyway Process.vi is executed, even if flag is set to False (Interactive=False).

[francois-normandin]

You're right, but the VI name function is compatible with RT targets. It's actions such as open/close/set cursor, menu or dialog boxes that error out. I think you have a valid point that this error handling node is a liability for the future, but it's not at fault here

[stagg54]

Hi Sam @stagg54 , Maybe you can put a single iteration while loop around the event structure to see if you still get the error? If not, then it's a LabVIEW bug... Otherwise it's still inconclusive but at least it would rule out the effect of the single case event structure.

I've seen 1055 error usually happening when a front panel reference is invalid and you try to close it via VI server... It's a suspicious coincidence that no front panels exist on some real-time targets, so I'm unwilling to rule out a wired interaction with Caraya yet, although from your report, it does not seem to be the most probable cause.

Someone else suggested the while loop and I tried it but still got the same error.

[stagg54]

I guess I will submit it to NI and see what they say.

[francois-normandin]

@stagg54 I have a sbRIO at home currently. Can you send me some test code? I think I could try reproducing it quickly. If it can't be uploaded here, send me a message on Slack...

[stagg54]

The snippet I posteda bove should work, but here is a link: https://www.dropbox.com/s/ix2qc6mrfkam7em/Caraya%20Bug.vi?dl=0 I also sent it to you on Slack.

[francois-normandin]

So, the error is in the Basic Test Manager.lvclass:Process.vi (UI: Update Counts frame). This frame is updating the number of failures and passes on the UI, which are unused in non-interactive mode. I don't know why it errors out when you pass through an event structure terminal and why it does not otherwise, but the fix is to skip the Update Counts frame in non-interactive mode.

I believe this is a LabVIEW bug, somehow, but it might be that this frame should always have errored out and it didn't.

The snippet below will fix it for you.

[stagg54]

I can confirm that disabling that did solve my problem. Thanks Francois!

[stagg54]

I filed a report with NI and they were able to reproduce it.

[stagg54]

Here is what I got back from NI:

Sam,

R&D and I have been doing some additional testing to try and determine the source of this bug, and believe it may not actually be due to the presence of the event structure we're using, but rather due to a race condition in Caraya introduced by the event structure's timeout/wait. I was able to get the same error to occur by removing the event structure and wiring a false constant directly to the Assert True VI, but adding a 1 second wait in between the Assert True VI and Define Test VI - I've attached a screenshot of the code I was using to this email.

I'm still waiting to hear from R&D regarding their thoughts on next steps, but I think the issue may actually lie with Caraya - feel free to try out the code I linked to this email and see if you get similar results.

[stagg54]

Here is the sample code he sent me. It does reproduce the issue.

[francois-normandin]

fixed in 1.1.0