.Net Invoke-Node blocking Event Structure execution?

[Jens_S]

Hello!

I'm currently experiencing a behavior that I can't quite explain. In the attached VI snippet, I have an event loop that captures log messages from my .NET library and displays them in the front panel.

“Start Asynchronous Call” (true case) calls a method in my library that takes several minutes to complete. During this time, log messages are displayed in the front panel via the subscribed event. The linked VI (fw update.vi) does nothing other than call the .NET Invoke node, which can be seen in the false case.

 

Here’s my problem: Initially, I was running the code in the false case, and in that case, LabVIEW first executes the Invoke Node, and only after it’s finished are all log events processed in the while loop. I have to admit that I don’t understand the behavior at that point. In my opinion, shouldn’t the .NET Invoke Node and the while loop run independently of each other?

Using Labview 2026 64bit, the dll is a .Net8 library.

 

[Yamaeda]

I assume the .NET node runs in the UI thread and thus the Event structure (that runs in the same thread).

[ConnerP · Accepted solution]

Hard to say without seeing the VIs. When you attach a png, only that VI is attached, no dependencies. You should zip the project or at least the necessary files. 

Without being able to see details, I would guess some kind of ui/root loop thing is happening.
http://www.labviewcraftsmen.com/blog/the-root-loop

Otherwise, the compiler just might be messing up. Uncoupled things on the block diagram CAN run in parallel, but aren't necessarily guaranteed to. It breaks code sections up into "clumps" https://www.ni.com/en/support/documentation/supplemental/10/ni-labview-compiler--under-the-hood.html. One thing you can do to try and force the VI call into a separate clump is wrap it in a single-iteration while/for loop. This thread may go into it more: https://forums.ni.com/t5/LabVIEW/How-to-control-parallel-threads/td-p/3985557

[Jens_S]

Ah sorry, here is the new VI-Snippet. The async VI I call is just the "false case" wrapped in a VI, nothing else.

 

Your first link doesn't work for me. thanks for the third link, the for-loop around the Invoke Node actually does the trick... this is so weird.

[Yamaeda]

I've seen some discussions about similar things before. One (silly) solution that actually worked was to put the code in a 1 iteration for loop! It's worth a try. There was some advanced answer in how LV spawns threads for a loop.

[avogadro5]

You could try an experiment: instead of updating the display in the event structure just keep the string and timestamp in memory. If the timestamps are all from after the .NET node finishes it means the event structure is not receiving/processing the events until after. If the timestamps are spaced correctly it means your event structure is actually blocked because the UI thread is blocked preventing the indicator from being updated. User events by themselves should not be UI thread bound.

[Jens_S]

@Yamaeda
Yes, as mentioned in my post before, the one iteration for loop does the trick.

@avogadro5

Good idea... Tested it and as expected all the evens are handled within ~100ms so the entire while loop/ event handler is blocked/ not executed.
You can see this pretty good when using the execution highlighting.

[rolfk]

Execution highlighting is not a good indicator of what happens in normal execution. It can sort of indicate things going on in parallel, which makes the execution highlighting jump all over the place and making debugging of such diagrams a complete pitta, but it is not a 100% accurate representation of real execution since it deliberately tries to make things sequential since humans can not follow multiple things simultaneously.

[Jens_S]

Yes, good point.

[Yamaeda]

From previous links you can get to this thread which has a good discussion on the subject and explains it:

Parallel .NET nodes not actually running in parallel unless inside loops - NI Community