LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Channel Wire read Only Abort

I'm experimenting with channel wires and real enjoy the additional clarity that they bring to the language.

 

Is there a way to read the aborted? status of a channel wire with abort without having to read or write items to it ?

0 Kudos
Message 1 of 5
(2,298 Views)

should know the answer, as I've been using Channel Wires since LabVIEW 2015 (when they were a "hidden feature"), but I've found the "vanilla" forms of Streams, Tags, and Messengers more than sufficient for my needs (I've got one routine that has >100 Channel Wires running simultaneously when all the Channels are enabled).

 

What are you trying to do?  What I would do if I wanted to know the answer would be to write a Test routine with a Writer and Reader and just try it out!  If you are not sure how to test this, explain your situation and I do the test for you (and learn something, myself, in the process).

 

OK, my curiousity got the best of me, so I just wrote a Demo for myself, and confirmed that (a) the Abort terminal for the Tag Channel does exactly what the Message that pops up when you select the Channel says it does, and (b) that if you use Tag with Abort, then all the Abort Inputs on all Readers and Writers must be wired (I didn't expect it was required, but would simply use the default "F" value if unwired.  I actually think this second point is curious, and possibly "wrong-headed", but I missed my chance to complain about it when Channels were being developed ...

 

So if you set Abort to True (which you can do at either the Reader or Writer, as it happens), then (a) the Channel shuts down immediately, not transmitting anything that might be present on the Writer to the Reader, and (b) all "Aborted?" terminals become True.  I've used Tags to get a Producer to shut down multiple Consumers (without using Abort, just having the Tag be a Boolean where True means Shutdown), but if you use Abort, you can send the signal "backwards" from the receiver to the sender, which might be useful in some situations.

 

I haven't tested other Channel Wire types, but suspect they work the same way.

 

Bob "Channel" Schor

0 Kudos
Message 2 of 5
(2,273 Views)

I realize that my longer response might not have directly answered your question.  The answer is that for a Tag Channel, wiring a True to the Abort Channel will shut down the Channel immediately, not transmitting any data, and setting all of the Aborted? indicators on all connected Endpoints to True.

 

Bob Schor

0 Kudos
Message 3 of 5
(2,265 Views)
if you use Abort, you can send the signal "backwards" from the receiver to the sender, which might be useful in some situations.

That is precisely what i'd like to do. My objective is to make an actor-like code template with channel wires.

 

I want to link multiples message producers to a single consumer with a many-to-one Message Channel Wire. this single Consumer has to be able to shutdown all producers. This does "flow" the opposite way the data does in the channel.

 

I cannot use a Read Channel on the producers, at it would capture messages destinated to the Consumer, and cannot use a Write Channel, as Producers does not continuously have data to transmit (a "Do Nothing" message would be quite inelegant, and possibly have a massive execution speed impact)

 

An additional Tag Channel can be used parallel to the Message Channel wire to transmit the consumer status, but this is quite the hassle : it double the connector pane usage and the visual clutter, and add quite a bit of complexity to the exit condition of all loops.

0 Kudos
Message 4 of 5
(2,262 Views)

Thanks for explaining your usage for this Feature.  Recall its name -- Abort, meaning "Forget about an Orderly Shutdown, Do It Now!".  I've always tried to have an "orderly Shutdown" -- a Consumer might see an Error Condition and want to notify the Producer, who could decide to terminate everything, but might also want to try to "fix" the Consumer.  Because Abort kills the Channel, this is not possible, so I would caution that another approach might be preferable ...

 

Bob Schor

0 Kudos
Message 5 of 5
(2,259 Views)