The NEW look of Producer Consumer design pattern

[AristosQueue (NI)]

Ben:

Minor tweak to your image that I recommend: Your "running average" subVI should have a While Loop glyph on its icon. This is a convention that I've encouraged people to adopt when a subVI completely encapsulates the processing of a channel inside a loop. By putting the While Loop glyph on the subVI icon, people's ability to grasp what the block diagram is doing appears to shoot up considerably.

That glyph is in the standard glyphs in LV's Icon Editor.

[Ben]

---

@AristosQueue (NI) wrote:

Ben:

Minor tweak to your image that I recommend: Your "running average" subVI should have a While Loop glyph on its icon. This is a convention that I've encouraged people to adopt when a subVI completely encapsulates the processing of a channel inside a loop. By putting the While Loop glyph on the subVI icon, people's ability to grasp what the block diagram is doing appears to shoot up considerably.

That glyph is in the standard glyphs in LV's Icon Editor.

---

Valid point!

Of course what I posted was just playing around.

But I have to think about that practice to decide what I really think about it. I have often told rookies...

"Your Icon and documentation should tell you WHAT it does and not HOW it does it."

using that approach will let us modify the workings of sub-VI while maintain the Icon, functionality and documentation without changes. A couple of quick examples would be the old recommendation that Action Engines should have "AE" or "ENG" in the VI name. now that Action Engines no longer have a loop and can be implemented using Feedback nodes or DVRs... the "how" really does not tell us much as "what".

So I have to think how your suggestion fits with 40 year old habits...

Thank you!

Ben

[Ben]

redid the above using vertical.

Exact same code (OK I tossed a bunch of free labels) but just re-arranged how it is presented.

Which version do YOU like more?

Which version would you prefer to find if you found yourself discovering this code?

Ben

[billko]

---

@Ben wrote:

redid the above using vertical.

Exact same code (OK I tossed a bunch of free labels) but just re-arranged how it is presented.

Which version do YOU like more?

Which version would you prefer to find if you found yourself discovering this code?

Ben

---

It's a tough decision.  The OCD monster in me likes the top one, but my LabVIEW instincts like the bottom one.

[AristosQueue (NI)]

---

Ben wrote:

"Your Icon and documentation should tell you WHAT it does and not HOW it does it."

---

In this case, I believe the While Loop indicates WHAT the subVI does: it is executing an ongoing process that is live and listening for async inputs, executing executing in parallel with the rest of your code, not a simple subVI function call.

While Loops can exist in many subVIs without becoming a part of the icon. What matters -- I believe -- is whether the ongoing execution of that while loop is contingent upon other parts of your program feeding it information asynchronously. That changes it from a functional while loop to a process while loop. And that difference is important to callers. Its *role* in the system is different.

The other option, if you do not like the while loop, would be to put the actor gear glyph on it. The metaphor is the same. "I am an ongoing process". You could argue that the While Loop is an implementation detail and therefore the gear [or similar symbol] is clearly superior, but the while loop is the fundamental unit of iteration in G -- there is no other mechanism for infinite iteration, so at some level, somewhere, all nodes that implement a process will use a while loop.

I've been thinking that the same rule should probably have been applied long long ago to producer/consumer pairs when they are encapsulated in subVIs when you route a queue refnum (or your favorite communications device) into both subVIs. I've seen users have trouble understanding what's going on on the top-level diagram... since working with channels, it has occurred to me that maybe this convention would help in those cases also.

[Jacobson-ni]

I tried "rotating" the channel readers and writers and ended up with the code below.

I'm sure I could get it looking better but it was close enough to what I was thinking. I'm glad I tried this out because it didn't really work as well as in my head. Besides not going through subdiagram labels very clearly, I think it's hard to have long vertical wires without a lot of wire crossing (maybe that could be fixed by moving things around). I think it's clearer that the loops are operating in parallel and there are a lot less wire bends in the channels but I also think the channels kind of get lost which I think is a major issue if one of the big advantages of channels is being able to clearly see the data connections between processes.

I kind of like having each while loop in its own subVI and having the channels go vertically between them at that level is what I would try. You miss all of the detail of each module but I think it gives a clear overview of the modules and which ones communicate to each other.

[Bob_Schor]

---

@AristosQueue (NI) wrote:

Ben:

Minor tweak to your image that I recommend: Your "running average" subVI should have a While Loop glyph on its icon. This is a convention that I've encouraged people to adopt when a subVI completely encapsulates the processing of a channel inside a loop. By putting the While Loop glyph on the subVI icon, people's ability to grasp what the block diagram is doing appears to shoot up considerably.

That glyph is in the standard glyphs in LV's Icon Editor.

---

Look at the Plot ToF Data sub-VI in the lower left corner of my Snippet.  The "border" is a stylized While Loop, inspired by something I saw in an early AQ Presentation on Channels.  I created this as an Icon Editor Template, but discovered an unexpected "Feature" that Templates cannot have more than a one-pixel bottom border (or else the Icon Text tries to squeeze in between these two bottom lines).  I attempted to bring this to NI's attention (I may have created an Idea Exchange about this), but found a crude work-around that "works for me" ...

I really like the mnemonic quality of a sub-VI Icon for a "Loop" VI "looking like" a loop!

Bob Schor

[Bob_Schor]

---

@Ben wrote:

I suspect you can not share that project (so that we can poke at it and learn). Being the anal-retentive type, my first reaction is that I would like to move stuff around to minimize the length of the channel wires and try and reduce the number of bends.

---

It wasn't that I "cannot" share the Project, it's that this is only a small piece, and there's a lot of irrelevant (for the purposes of discussing the Joys of Channels) stuff that detracts from the Main Point.  And I have a deadline looming ...

However (and don't forget, You Asked for It) I'll try, maybe over the weekend, to pull this code and the accompanying sub-VIs into a Project with a little Documentation to explain some of the design decisions.  If so, I'll probably post it as a new Entry and put a link in this thread to point to it.

Bob Schor

[Ben]

---

@AristosQueue (NI) wrote:

---

Ben wrote:

"Your Icon and documentation should tell you WHAT it does and not HOW it does it."

---

...

The other option, if you do not like the while loop, would be to put the actor gear glyph on it. The metaphor is the same. "I am an ongoing process". You could argue that the While Loop is an implementation detail and therefore the gear [or similar symbol] is clearly superior, but the while loop is the fundamental unit of iteration in G -- there is no other mechanism for infinite iteration, so at some level, somewhere, all nodes that implement a process will use a while loop.

---

...

If the sub-VI was a dll call that kept running once invoked or a Call By Reference to allow control over what is using the channel...

I am going with the Gear icon. Sorry Stephen I am siding with Stephen on this one.

Ben

[Ben]

Hi Jacobson,

While that modification is quite nice, I do not think that we should get lost in the weeds errr Top Level VI.

The modifications we have shared so far are still simply examples and in real life applications, I will often try to minimize the code in the top-level VI and push the details of implementation down into sub-VIs.

Looking at the example which is trying to show us what is involved in a CMH the green decorations have broken it down into section associated with the components of the CMH. If we push each section into a sub-VI we get a diagram that approaches a Channel Only Diagram that clearly shows how the components interact.

If we did not have to fuss with the GUI (as could be the case in sub-VIs) we could have a diagram that uses only Channel wires.

Ben