underpass (subway) for data exchange between parallel loops

[donkdonk]

There are several methods to exchange data between parallel loops.

These methods however are (intrinsically) not following LabVIEW's dataflow-along-wire paradigm.

If you think in different layers, where several loops are running in parallel at the surface, you could have subsurface datatransfer.

You could add a new "tunnel mode" to the LabVIEW 2013 right mouse menu on the border of a loop.

There you could also specify whether you would like the data passing the boundary to be queued.

You would however think of something to visualize these settings at the loop boundary as well as having some error terminals in case of queues.

[Brian_Powell]

Would you really want to have an infinite timeout on the dequeue?  It seems like this would be a really easy, concise way for users to accidentally write applications that deadlock.

I think there's merit to the idea of wanting to express asynchronous dataflow.  There are probably some additional semantics we need to define to make this workable.

[DJed]

This sounds very similar to the asynchronous data flow wire concept.

[donkdonk]

Would you really want to have an infinite timeout on the dequeue?

No, and I admit I did not a full visual of what would be required in the right-click-border-underpass-menu, nor did I draw error clusters that -for example- could originate from the underpass and connected to the stop terminal.

There are probably some additional semantics we need to define to make this workable.

Agreed

This sounds very similar to the asynchronous data flow wire concept

I guess so; didn't know it already existed, albeit for one product only (PCI-55640R).

It's all about visualization. How to show data runs asynchronously.

I notice that the first intuitive step for those new to LabVIEW is to wire straight through loop boundaries and still expect parallel execution.

[SteenSchmidt]

Your first scenario is lossy data transfer, the second scenario is lossless. Since these two scenarios are very different when it comes to the parallel execution of your loops, I think it would be beneficial if you put a bit more detail in your images outlining the differences? Or, if you don't want there to be any difference, then maybe describe which case is your primary use case?

In the meantime you might take a look at our VI Registers toolset. This toolsets cover both situations, VI Registers can be lossy (current value register) and lossless (buffered or creating events), depending on your configuration:

Read more about this toolset here, where you can also download it: http://gpower.as/viregister.

Cheers,

Steen

[ToeCutter]

Agree the idea needs a bit of kicking about, but I like it in principle. Simplifies code and gives the compiler the power to optimise, e.g. property node vs local. Also agree there should be a differentiation between lossy and queued in terms of how it appears on the block diagram.

+1K

[johnsold]

Steen,

Any chance of getting a cross-platform version of VI Registers?

Lynn

[SteenSchmidt]

This should work on Mac and Linux as well, although I have no means of testing it. Is it VIPM that is a problem?

/Steen

[X.]

What happens if the producer loop runs 10 times faster than the consumer one? Or the opposite?

As others have said, there are ways of controlling what happens or not with the proper tools.

With a wire approach as suggested, I don't see how you can have the two loops independent and still communicate data in a consistent way.

In your A design, you could just as well loose data or read the same data over and over again until it is updated.

Considering this ambiguity (coming with simplicity), I don't think that is a workable idea.

[donkdonk]

In your A design, you could just as well loose data or read the same data over and over again until it is updated

Yes, just as you would using the local variables example (similar examples are used by NI).

My idea is just a replacement for existing techniques but IMHO much easier to read.

[RavensFan]

"you could just as well loose data"

Loose means not tight.

Lose means the opposite of find or keep