topic Error 1055 when Creating One Element Stream Channel Read with Abort in LabVIEW

Error 1055 when Creating One Element Stream Channel Read with Abort

cous — Thu, 10 May 2018 20:11:22 GMT

I'm trying to add a one element stream channel with abort for a Boolean. I can create the write with abort, but whenever I try to create the read with abort, I get an error 1055 as shown in the screenshot. I can create a regular one element stream channel write and read, and the regular stream with abort works fine.

I've tried with multiple data types on the one element with abort, but get the same error.

I've tried on another computer with LV 2017 32-bit, but get the same error.

I've tried deleting the channel instances in C:\Users\<me>\Documents\LabVIEW Data\2017(32-bit)\ExtraVILib\ChannelInstances, but I still get the error.

I'm starting to wonder if the one element stream with abort is not a valid channel type...

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

Bob_Schor — Fri, 11 May 2018 00:44:44 GMT

I use Channel Wires a lot -- my latest Project has over 100 running simultaneously (and very happily). I must confess that until I build a little test VI in reference to your post, I'd never used the Abort inputs. I do use the Last Element and Valid? inputs (very handy in orderly shutdown of Producer/Consumer patterns). The Abort of either Reader or Writer will cause the Stream to shut down, with both Reader and Writer showing their Aborted? outputs True (so you could also use this signal to stop a loop, but it seems clumsy, to me).

Bob Schor

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

cous — Fri, 11 May 2018 15:21:16 GMT

Yes, I agree that abort isn't necessarily the best way. I've been using a combination of last element, valid, and abort to synchronize loops. I mainly use the abort for an emergency shutdown of the equipment that is running where I care less about neatly shutting down everything and more about putting equipment in a safe state and shutting down as quickly as possible.

I'd be curious to know if anyone else is able to create a one element stream with abort channel reader. Takes <2min to try out 🙂

Also, I should note that this error hasn't prevented me from getting code running. I've been able to use the stream with abort without any problems. Still, it's disconcerting to have this error with the one element stream with abort.

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

lgc102 — Sun, 28 Jul 2019 15:18:54 GMT

I also am unable to create One Element Stream, Reader With Abort - same error 1055.

Thought this was just that it was my first project using channels, but found this forum post.

I guess it's just broken in 17.0.0. Not seeing it in bugs.

Old thread, but is there a workaround that friendly for channel newbies? You said you could get code running...

I'd be curious to know if anyone else is able to create a one element stream with abort channel reader. Takes <2min to try out 🙂

Also, I should note that this error hasn't prevented me from getting code running. I've been able to use the stream with abort without any problems. Still, it's disconcerting to have this error with the one element stream with abort.

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

Bob_Schor — Sun, 28 Jul 2019 19:55:59 GMT

Wow -- a Channel Wire bug that I didn't find (I've found several, but haven't tried all of the "corner cases"). I can verify that this bug is present in all versions of LabVIEW that support Channel Wires as a "full" feature, namely LabVIEW 2016, 2017, 2018, and 2019.

So having said that, I'll ask the question "Why do that?". I think I would argue that a single element Stream does not need an Abort, as Last Element? will do the same thing, namely immediately shutting down the Channel when the Reader next accesses the Channel.

Consider the reason for the Stream -- point-to-point asynchronous transfer of element from Writer to Reader. Streams are usually used for Producer/Consumer designs, where the rate of producing elements may be different from the rate of processing ("consuming") them, and you don't want anything to "block" the rate of Production (typically because this is a time-critical step that needs to run at a known, fixed rate). So you make the Producer do "as little work as possible" (i.e. just "produce" the element, don't try to process it) and run it at the "rate of Production", while the Consumer, you hope, runs (on average) at a rate comparable to the Producer. If it runs slower, data will accumulate in the Stream, which can be OK for the short run.

Now suppose you have a Producer/Consumer Stream pair, and you want to stop everything. The "normal" way for the "normal" Stream is to set "Last Element?" to True on the Writer (and set "Element Valid?" as appropriate). This stops the Reader when that "last element" is processed. If the Consumer has gotten behind in its work, with many elements still to process, this method allows all of the elements to be processed before the Consumer shuts down. Note that this has no effect on the Producer.

But what if you need a "Panic Stop", to stop everything as fast as possible? Then you want a signal that says "Stop, no matter if you have data remaining to process or not". That's where Abort comes in -- Abort means "Stop now and throw away any unprocessed Elements".

So what about a One-Element Stream? The "normal" Stream never blocks the Writer, but the One-Element Stream will block if the Reader hasn't processed its data. Consider a Producer that runs at 1 kHz and sends 10 elements to a Consumer that runs at 1 Hz. It sends the first Element, and the Consumer removes it to process it. It sends the second Element, which is accepted by the Reader. However, the Consumer still has 999 ms to go before it can loop around and access the Reader, meaning that the Producer now is blocked by the Consumer! This is something you generally do not want -- the Producer is, in general, the time-critical loop, and here we are forcing an unexpected "stall" into the loop. The Consumer has now effectively forced the Producer to run at 1 Hz, as this is the rate that the Producer can write to the One-Element Stream.

In the paragraph before the one above, I said that Abort differs from Last Element in being true when Set rather than when "Set and Stream is empty". But if the Stream has only one element, these become the same thing! I suspect that at some point, the Developers realized that "Write with Abort" made no logical sense for One-Element Streams, never created it, but didn't notice that it was showing up in the List of Available Channels as a "Documentation Bug".

I'll try to confirm this and report back here.

Bob Schor

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

cous — Mon, 29 Jul 2019 13:44:20 GMT

Yes, I agree with your logic here. The abort is redundant for the single element stream. The only reason I can see keeping it there would be consistency with other types of channel reads. But I think it'd be better to remove it and document why it isn't there. NI could just remove the abort and quote your justification directly in the documentation...with a reference and some royalties of course 😉

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

cous — Mon, 29 Jul 2019 13:46:50 GMT

@lgc102 wrote:

I also am unable to create One Element Stream, Reader With Abort - same error 1055.

Thought this was just that it was my first project using channels, but found this forum post.

I guess it's just broken in 17.0.0. Not seeing it in bugs.

Old thread, but is there a workaround that friendly for channel newbies? You said you could get code running...

I'd be curious to know if anyone else is able to create a one element stream with abort channel reader. Takes <2min to try out 🙂

Also, I should note that this error hasn't prevented me from getting code running. I've been able to use the stream with abort without any problems. Still, it's disconcerting to have this error with the one element stream with abort.

It's been a while since I worked on that application, but I'm pretty sure that I just used the stream with abort in place of the one element stream with abort. I really wanted the use "abort" since it was on manufacturing equipment that in some cases needed to be put into a safe state immediately.

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

lgc102 — Mon, 29 Jul 2019 14:02:47 GMT

Makes sense.

The behavior I was looking for in the channel was an upstream message, sending back from Consumer to Producer to "Hey Stop!". As I'm trying to send my state-command from master event/gui loop to data acquisition subloop to tell it to Run/Pause, I wanted the daq subloop to be able to tell the master loop that Something Happened and the whole program needs to safe the equipment and stop.

As a channel newbie it seemed the One Element Stream with abort had the ability to send a boolean back upstream without the potential pitfalls abundant in the tutorials on Tag channels. I used to do this with functional globals or events and thought the channels would make the code more readable.

Working through channel tutorials, seems a tag channel is probably the better way to do this, although I'm still futzing with architecture. May not use channels for the command/coordination portion and just for data production/analysis where it fits better.

@Bob_Schor wrote:

So having said that, I'll ask the question "Why do that?". I think I would argue that a single element Stream does not need an Abort, as Last Element? will do the same thing, namely immediately shutting down the Channel when the Reader next accesses the Channel.

.

In the paragraph before the one above, I said that Abort differs from Last Element in being true when Set rather than when "Set and Stream is empty". But if the Stream has only one element, these become the same thing! I suspect that at some point, the Developers realized that "Write with Abort" made no logical sense for One-Element Streams, never created it, but didn't notice that it was showing up in the List of Available Channels as a "Documentation Bug".

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

cous — Mon, 29 Jul 2019 14:10:32 GMT

I vote to use a tag for sending the stop signal back to the producer. I've done that with good success in the past.

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

lgc102 — Mon, 29 Jul 2019 14:20:25 GMT

Cool - thank you.

Interestingly the Channel - One Element Stream.lvproj in the labview\examples\Channels\One Element Stream directory has a reader that works, and you can copy/paste this if you want a one element stream with abort reader typed for I32.

So it wasn't always broken, at least for tutorial writers at NI. Theoretically I could use this as a workaround, type casting my control enum to/from i32 to get it through the channel. Then whoever inherits the code from me...muwahahaha.

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

Bob_Schor — Mon, 29 Jul 2019 14:24:05 GMT

Thanks for bringing this up! I've just filed a Service Request about this "anomaly", referencing this Forum Post, and expect that this will get "escalated" to the team responsible for Care and Feeding of Channel Wires. I will update this Forum post as I learn more.

Bob "Channel Wire Enthusiast" Schor

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

lgc102 — Mon, 29 Jul 2019 14:28:37 GMT

Just found that you can create a One Element Channel reader, then right-click Replace-->Channel Endpoint and pick One Element Channel With Abort. So it's only when creating it without a channel reader in place, if that helps localize the bug.

@Bob_Schor wrote:

Thanks for bringing this up! I've just filed a Service Request about this "anomaly", referencing this Forum Post, and expect that this will get "escalated" to the team responsible for Care and Feeding of Channel Wires. I will update this Forum post as I learn more.

Bob "Channel Wire Enthusiast" Schor

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

Bob_Schor — Tue, 30 Jul 2019 17:54:51 GMT

I have heard (indirectly) from LabVIEW R&D that they have verified the behavior of the One Element Stream with Abort Channel that has been reported here, both the problem creating a Reader (with Abort) and the "work-around". A CAR (Corrective Action Record? ... Report?) will be filed, and "Something Might Be Done". This is usually accomplished by being included in a Patch Release, an SP1 Release, or a subsequent Version of LabVIEW. If/when I hear more, I'll post again.

Thanks, @cous, for finding this "feature" (there are no bugs, of course) and posting it here!

Bob Schor

Re: Error 1055 when Creating One Element Stream Channel Read with Abort

cous — Tue, 30 Jul 2019 18:00:33 GMT

Thanks @Bob_Schor for pushing to get the CAR filed for this Fingers crossed that it makes the cut for implementation in the next release...