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.

[X.]

Thi usuak typu.

[donkdonk]

@Steen "In the meantime you might take a look at our VI Registers toolset".

Thanks! You did a really really good job!

(at first I installed the old version which covers the lossy data transfer only; it took me some time that I had to let VIPM search for recent versions)

It is much less diagram wire clutter when compared to queues, and IMHO much more intuitive.

It took me some time to realize however that the viregister read does not timeout. Instead you have to monitor Register value read if you don't want to read the same value twice or more.

The documentation is also very well done, my compliments!! In the documentation you could mention this timeout issue, since you compare the VI Register toolset (also) to queues.

Steen: "Your first scenario is lossy data transfer, the second scenario is lossless [..]"

I am aware of that.

Steen: "[..]put a bit more detail in your images outlining the differences?"

With hindsight I realize I should have done so. Actually I thought of some double arches/curvatures at the loop boundary when "buffered" is selected from the right-click-menu at the loop boundary.

I just wanted to emphasize the idea of having some asynchronous wire and how you could visualize that without going into detail of where and how exactly you choose single or buffered behaviour. I left out all those things I considered detauils.

Perhaps naively I thought this would be understood by this community.

[SteenSchmidt]

@donkdonk: Thanks. You're right that we could mention in the help that you should monitor the "Register value read" output when you poll the buffered registers. We're about to release an update of this toolset, and I could maybe get an optional timeout input onto the VI Register read function. Such an input would mean you could elect to not poll, but instead do an idle wait on a value (as with a queue). As it is now you can only register events for unbuffered VI Registers, so that isn't an alternative.

Async intra-process data transfer has been discussed endlessly in these forums and in many other places, so it's not a new idea. Therefore the difference does indeed lie in the detail of implementation. Thus, to truly get attention for an idea like this you'd have to come up with the best concrete implementation. So if you let us all imagine our own specific implementation it doesn't bring anything new to the table, but your implementation details might be the ones that makes this idea interesting again. Without telling more we wouldn't know .

There are numerous drawbacks of async data transfer in LabVIEW, so there should be a fundamental benefit to your specific wire before it will even get considered. One particular drawback that an async wire would solve, will be that we're no longer dealing with references, as we basically are with queues et al. Not on the BD at least.

Cheers,

Steen

[donkdonk]

Steen: [..] and I could maybe get an optional timeout input onto the VI Register read function

Yes, yes, yes please.

(did I already mention that I'd love to also have a timeout option  ) 

[SteenSchmidt]

@donkdonk: Now VI Register has been updated on our website: www.gpower.as/viregister

Remember to grab the full download to include all dependencies, as the Error & Warning toolset has been updated as well. This update will be available on the LV Tools Network shortly as well.

Cheers,

Steen

[donkdonk]

Steen: [..] Now VI Register has been updated

Thanks for sharing!! And I noticed that v2012.1 has the timeout option, which is great!

(unfortunately we're running LV2011 at our lab, so I'll have to do the conversion at home where I run LV2013)

[donkdonk]

Seems the "channel wires" introduced in LabVIEW 2016 do what I proposed here.

I suggest my idea as being implemented in LabVIEW 2016.

(unfortunately at our company we do not have LV2016 installed yet, but I'd love to play with channel wires and I am looking forward to what solutions/use cases other people come up with)

[X.]

It used to be possible to download the preview of channels for LV 2015.

[crossrulz]

Still is possible.  See this document for more details: Getting Started With Channel Wires

[donkdonk]

Right after my post I found information on using channel wires in LabVIEW 2015. 

I already made my first example code.

X, crossrulz: Thanks anyway for pointing this out.