Default queue element

[cirrusio]

I find this difficult to believe that this has not been suggested before, but a search of the Idea Exchange has come up null.  And maybe there is a reason why this has not been implemented of which someone can enlighten me, but...

Is there anyway we can get a default queue element that is used when a dequeue element times out.  I have found that in several recent projects, I end up with queued state machines that look like this:

where I use a select to define a default queue value.  It would reduce some of the code bloat if we had a default value available (that was not necessarily the types default value) such as what you might find in the RT FIFO:

But, maybe I am missing something?

Matt

[Intaris]

I think I see the benefit for the queuing of enums or simple datatypes.  It's essentially redundant functionality though.  The Dequeue primitive has a "timed out?" output to determine exactly this.

[cirrusio]

I don't understand the above comment, Intaris.  How is the functionality redundant?  I agree that if the dequeue primitive times out, you will get a default value, but unfortunately that default is determined by the default of the data type itself, not the default for the particular use.  Also, in order to ensure that you are getting the default value you desire, you will have to somehow be explicit.  This, it seems to me, is just good practice - what if you decide to change the order of states in a type-def'ed enum?  or, what if you are queueing numbers or strings and you want something other than the default 0 or empty string as your default value (such as NaN or whatnot)?  In these cases, you will either a) have to ensure that the queue always has a fresh value if it is polled periodically or b) do something such as what I show in the first image above.  In either of these cases, you have produced more code than you would have to if you had a default value available.  

Just some thoughts.  Cheers, Matt

[Intaris]

The point of my statement is that the case of the queue timing out means there was no communication.  This lack of communication can be caught by the "timed out" boolean output where you can set the value to whatever you want.

In my code I never trust the output of a queue without first checking the "timed out" boolean.

[Intaris]

In addition I think this is perhaps better served by allowing a typedef (queued outputs should generally be typedefs) to have a custom default value.  This way the functionality you describe can be implemented without the need for an extra configuration option for queues.  Imaging you dequeue in 10 different places and you want to change the default.  This is done muchmore quickly via typedef default value than the proposed solution.

Q: Can we set default values of (for example) enums?

[cirrusio]

Intaris - 

I believe the default value will always be the first element (0 as all numeric data types) and requires the enum to be rearranged specifically to fit the use case.  Obviously, you can see that I am doing the checking you mention in the first image which simply states that if the queue times out then set the state to "Wait".  And it seems that you are suggesting this is what you do also.  That being the case, it would seem that this functionality is not redundant.  There are many things that, based on that statement, are redundant.  A for loop is simply a while loop that executes n times; an enummeration is just an integer; an event structure is simply just a more efficient way of polling a UI; and on and on.

I am not trying to be flippant, just trying to point out that redundancy is in the eye of the beholder (obviously).  All of the above examples have very reasonable benefits - they not only reduce code bloat therefore making code more readable but also confine certain operations to lower level code which may have the benefit of making the code a little more efficient.  The default value would get rid of the necessity of having some case structure or select primitive to test whether and what to do if the dequeue times out.  In this case it just all becomes internal to the primitive itself.  And good programming practice would suggest that, as you imply, we need to be explicit in how we execute these structures thereby defining the need for the select or case structure if no explicit default is available.  

It seems to me that somebody in NI identified that this was beneficial at some level given that they implemented this feature in the RT FIFO read.  I am just suggesting that maybe this should be considered for the Dequeue primitive.

Cheers, Matt

[Intaris]

I understand the benefit of the idea.

I don't think a default value per dequeue node is the best way to deal with it.  I think a custom default value for typedefs would be a much more elegant solution.  I think I'll make a new proposal.

[cirrusio]

Haha!  Go for it!

[Intaris]

New Idea HERE.

[AristosQueue (NI)]

> In addition I think this is perhaps better served by allowing a typedef (queued outputs should generally be typedefs) to have a custom default value.

I posted in the new idea's thread why it is really infeasible for typedefs to define their own default value.

[AristosQueue (NI)]

As for the main idea...

There are three cases where the Dequeue node generates a default output value: when the node times out, when an error comes in on the "error in" terminal, and when the node itself generates an error. Do you want the same default for all three? Do we need three different inputs (or at least two to differentiate error from timeout)?

Essentially, it seems to me that if the default value isn't good enough for you, then you probably have multiple values you need to be checking for and a single input value isn't going to help much.