LabVIEW Channel Wires

cancel
Showing results for 
Search instead for 
Did you mean: 

Channel Bus

Thank you sth, I'll read through those when I get some time.

I came up with a way of updating all of my objects without the need for an update message, here's a snippet of my implementation. It is similar to how I imagine a channel bus or "zip tie" to function in regards to tags only, no idea how it would be implemented for streams or the like.

Channel Bus Workaround.png

The command processor sets an occurrence every time it finishes executing a command (the only time it updates the object tag), the update loop will read the current tag value of all subsystems when it receives this occurrence, and build an array of each object and send that through another channel to the manager VI. I'll probably want to add a long time-out to the wait on occurrence, maybe a minute or something like that.


My original design of this VI snippet involved asynchronously launching the "Ctrl Loops" VI, and it would return to the calling code after doing so. However I was unable to provide any channel inputs to the controller so I changed my code around a bit such that this VI now runs in parallel to the rest of the code, and I no longer asynchronously launch the controller VI.

I haven't actually tested this implementation yet, but I feel pretty confident it will work. I'll know in a couple hours when I have access to the cRIO it's intended for...

0 Kudos
Message 11 of 15
(2,610 Views)

"no center terminal" -- I meant, literally, the center terminal of the Bundle and Bundle By Name nodes. It's meaningless to have that terminal for zip ties. The group of channels together isn't something you can dynamically modify because there is no point when the "value" of the group arrives at the bundle node.

0 Kudos
Message 12 of 15
(2,610 Views)

Ahh okay, I see what you're saying, but I fail to see why a zip tie can't have a center terminal. Continuing the cluster analogy, the center terminal (the single wire out representing the zip tie group) doesnt need to be something which can be dynamically modified, it just needs to behave as an accessor to a single channel within the group. All the "zip tie VI" would need to do is package the channels into a single async wire, preserve the data type of each channel (or maybe not), and provide a means of unpackaging a channel or channels later. And I say "all" with significant reservation because I'm aware that this is by no means simple and carries with it several challenges.

It seems to me like initially this could be implemented to simplify code rather than to introduce additional functionality. When you package then unpackage a channel downstream couldn't the compiler just treat it as if the channel was wired straight through without any of the bundling and unbundling that went on in between?

In any case, I'm excited to see how channels evolve with future versions of LabVIEW. As they are right now I'll almost certainly be including them with the majority of my programs. I discovered them at just the right time too, as I'm in the midst of refactoring code which was clogged up with global variables.

0 Kudos
Message 13 of 15
(2,610 Views)

The Bundle for a cluster replaces a value in the incoming value.

But any values that propagate on channel wires do so *before the VI even starts running*. There's no dataflow to order on to make any sort of substitution of the bundle.

Does that make sense? If not, let me know and I'll try to draw some pictures tomorrow.

0 Kudos
Message 14 of 15
(2,610 Views)

The difference between bundling a cluster and "bundling" a channel is clear. I'm not suggesting to just allow bundling of channels into a cluster, clearly that wouldn't work.

I think the only part of bundling a cluster which could carry over to "zip tying" would be the visual effect (a scalable number of inputs and one output). Obviously they would have to behave differently, otherwise the resulting wire wouldn't be a channel.

0 Kudos
Message 15 of 15
(2,610 Views)