LabVIEW Channel Wires
Channel Wires Entering and Leaving a Structure
@sth, Did any of the previous mockups try for an even MORE 3D effect like this?
I do understand the "excessive noise" problem mentioned by Jeff, but this WOULD enable distinguishing between a psudo-tunnel and a channel wire that runs underneath a structure.
Not forking, if I understand correctly what you are calling forking. Two independent sources, call then #1 and #2 both are fed different data. Loop A has these two writers. Loop B has one reader. Loop C has another reader.
Is this somehow syntactically wrong. I don't get a broken arrow until I try to run it.
There is no fork in your picture. A fork is just like any other wire forking. You can have as many independent wires between two loops as you want -- although I strongly recommend you never have more than one, just like I strongly recommend that you never use more than one refnum for communication [special case for Events because they all go into the same event queue] between two loops. Any time you have multiple communication paths between two loops, your probability of having a race condition somewhere in your code shoots up to near certainty -- I've been actively tracking that assertion for years in user code. It's why the Actor Framework documentation strongly recommends that you have no communication (notifiers, events, functional globals, globals, shared variables, etc) between two actors other than the actor's Enqueuer reference.
Here's a screen shot from the tutorial I've been working on for LV 2016.
AristosQueue wrote:
There is no fork in your picture. A fork is just like any other wire forking. You can have as many independent wires between two loops as you want -- although I strongly recommend you never have more than one, just like I strongly recommend that you never use more than one refnum for communication [special case for Events because they all go into the same event queue] between two loops. Any time you have multiple communication paths between two loops, your probability of having a race condition somewhere in your code shoots up to near certainty -- I've been actively tracking that assertion for years in user code.
Agreed there is no fork. That was why I was thinking it should be legitimate. In this case, I can make the diagram and the run arrow is "not broken". As soon as I click the run button it changes to broken and tells me a compiler error. Glad it is fixed in 2016!
Now on this multiple loop question. I sort of like an architecture where I have a single data collection loop and then parse data out to other loops for processing, decision making, archiving, displaying, etc. This is a producer - multiple consumer loops. I think this avoids race conditions inherently as long as I have a single channel between the producer and each consumer. Would that be a fair statement?
I suppose I could do this with a single channel that has all the data and forks to multiple consumers, each consumer can use the data it needs and discard the rest? It seems to be a less intuitive architecture where I parcel out the data specific to each loop.
Parenthetically, in looking at the example code, is the "Stream Channel" a 2016 thing or is it another added channel like the AQ Favorite.
Jeff, thanks. As long as it was on someones radar. But you guys are way ahead and already fixed it. The debugging switch works. Thanks.
