Jump to content

Passing Data with LV 2 Style (Functional Globals) between different loops from separate VIs on an RT Target


Recommended Posts

I have a RT project on a cRIO that will be using a Class. In this class are several VIs that are Loops (only end when the RT shuts down). Each loop gets its own branch/instance of the LV Class. My idea was to pass some lossy data between some of the loops. I don't really need a producer/consumer and there are several consumers anyways such as the UI loop and a control loop.  I am okay with the inherent jitter that using FGV globals would cause. However during testing I noticed some weird behavior which makes me question the architecture. How sound is the method of passing data in an EXE from separate VI Loops with Classes.   I can create RT FIFOs for every producer/consumer combo if FGVs arent the way to go but it would greatly increase the complexity.  A colleague questione the idea of even passing data via FGV with dynamically launched VIs but I tested on my test computer.  However, Development namespace and EXE namespace are different. LabVIEW dev will load everything into memory.

The specific behavior is that sometimes the VI wouldn't update but then when I started to debug the RT system like loaded the FGV and watching it, it started working. Sometimes breakpointing would make it start to work. I simplified the structure in a Test VI and got the same behavior sometimes it worked and sometimes not. If I placed the FGV in the same VI removing the subVIs that it seemed to always pass the data

Link to comment

It should work. It doesn't matter if you're passing class or cluster or whatever else. Some generic questions, as troubleshooting this deeper would require actual code:

1. Is your FGV VI non-reentrant?

2. Are you using this FGV in different timed loops with different priorities? Are you sure all of those loops are running (i.e. one high-priority, high-rate loop might starve the others).

3. Can you use Global Variable instead od FGV? (yes, it's a genuine question :) )

 

Quote

A colleague questione the idea of even passing data via FGV with dynamically launched VIs but I tested on my test computer.

I'm not sure why adding a ton of complexity to the problem would solve it ;)

 

Link to comment
On 7/27/2022 at 10:54 PM, Buddy Curtis said:

The specific behavior is that sometimes the VI wouldn't update but then when I started to debug the RT system like loaded the FGV and watching it, it started working.

That is a typical symptom of a race condition.

I would suggest taking a look at "LabVIEW <version>\examples\lvoop\SingletonPattern". It is much simpler and easier to understand than GOOP examples which have a lot of infrastructure included.

Link to comment
10 hours ago, ShaunR said:

That is a typical symptom of a race condition.

I would suggest taking a look at "LabVIEW <version>\examples\lvoop\SingletonPattern". It is much simpler and easier to understand than GOOP examples which have a lot of infrastructure included.

I couldn't actually find that example there. Is there a package I need? Or maybe it was moved or renamed in a different version of LV

Edited by infinitenothing
Link to comment
12 hours ago, infinitenothing said:

I couldn't actually find that example there. Is there a package I need? Or maybe it was moved or renamed in a different version of LV

Ah. sorry. Looks like they renamed it.

LabVIEW <version>\examples\Object-Oriented Programming\Reference Object

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.