Flush Stream Missing (?)

[AristosQueue (NI)]

TimVargo wrote:

     Hint: Always Create/Modify Write endpoints BEFORE their corresponding Read endpoint(s).

I would, but I don't think that hint is correct. The hint is "always set your element type to a non-array before trying to create a Read Multiple endpoint." Which is what the current text essentially says, isn't it?

[TimVargo]

Stephen,

Indeed your words are way more than just a 'hint', they are perfect for THAT EXACT situation that generated THAT error (which is precisely what belongs in any error dialog).  My suggestion to also append a 'hint' is more akin to advice which suggests to the user a best practice, implying "this may or may not apply to this particular situation, but many errors like this one can sometimes be avoided by ..." 

I think that MANY users will get various errors by erroniously attempting to modify a Read endpoint first, which is really a matter of (lack of) education.  I'm just trying to think of some ways to reduce that confusion, frustration, and eventual support calls.  I know it is somewhat uncommon to see a supplemental 'hint' in an error dialog like that, but the error dialog may perhaps be a great tool for also educating the user as to what it was that they did wrong.

[Skydyvr]

Ok, so I'm the end user to this type of error dialog. And for me TimVargo's "hint" would tell me more about what caused the error then the suggested dialog box.

I say that because I am confused with what is being said. The output of Analog 1D Wfm NChan NSamp is an array. So your error dialog box to me is saying that the read/write multiple isn't supported with arrays. That is not correct, because I'm using read/write multiple with the Analog 1D Wfm NChan NSamp now. When I dequeue an element from the stream, I have to go though an array index to get the waveform back out.

This could be all about termanaligy. To me the "element" is what I'm feeding into the stream and not the stream itself. I'm guessing that most people would look at it like that - who may come across this dialog box. But I don't really know. I'm mostly a self-taught LabView person.

[AristosQueue (NI)]

What is the element transmission type of the channel? See the part I circled in red in the image. That channel is currently transmitting each array as a single element. Attempting to replace the Read with a Read Multiple is not going to work because the channel is carrying arrays as elements. Contrast that with the second picture below.

In the second image, I've replaced the writer first... that changed the transmission type of the stream. Now I'm transmitting each waveform as an element. In this case, Read Multiple works.

Here's the difference:

[AristosQueue (NI)]

> To me the "element" is what I'm feeding into the stream and not the stream itself.

You are correct. But when you have already established the type of the stream, Read Multiple and Write Multiple are about multiples of the element type -- which can be an array.

[AristosQueue (NI)]

Skydyvr wrote:

But I don't really know. I'm mostly a self-taught LabView person.

In this case, I don't think that matters. The terminology for channels is new to most users... we in R&D are still learning exactly what terms make sense when we talk about them. Thus this lengthy conversation about a dialog box. 🙂

[AristosQueue (NI)]

After chewing over this a bit more, I'm going to expand the text like this:

[TimVargo]

I LIKE IT !!!

[AristosQueue (NI)]

Good. I've submitted the change for 2017.

[Skydyvr]

Agreed, that is perfect. It lets people know the proper order to change the read/writes. I just happened to be looking at my read circuit when I decided to change from high speed to multiple. When there is a 50-50% chance that someone chooses the right one, I'm sure there will be many people doing the same thing while learning this new feature.

I do really like the concept of these new queues. But I still think that there should be a way to flush the stream by one of these methods:

• Flush stream by someone who is not the reader or writer. (I don't expect this one, but I just added it because I thought of it. )
• Some way to mark all elements in the stream (queue) as invalid data. Kind of like you can do with an individual element. But changing that "property" for all elements in the stream.
• Being able to enqueue an element in front of the stream. This way I could tell the reader that all data in the stream is suspect (invalid) and to flush the stream with a multiple read as you suggested earlier.

I am getting around this by having two streams between my writer and reader loops. One for data and one for the message stream for when to flush the data stream. It works, but IMO it is kind of bulky and caused some issues in trying to get it to work the way I wanted. It would be easier/nicer/less spaghetti codeish if I could do that all in one stream.

And thanks for discussing this with me and taking my inputs into consideration. This is my "BEER" input for LabView. <- It's a skydiver thing if you don't know what that means...