Producer Consumer Error

[Miller37]

Hello.

Originally, in my code, I was doing signal input, signal output, and writing files all within the same loop. For the most part, the code worked, but occasionally, I had issues with control and sometimes the output signal wasn't correct. I think that I was running into communications issues, so I reorganized the code into a producer-consumer architecture. I put the user control/input and signal input in the producer loop. I then put the signal output in a consumer loop and the file writing in a second consumer loop. I think that the flow is correct, but I am getting the following error, which corresponds to the string used to control the consumer signal output loop. 

Thank you for helping me work through this issue.

Sincerely,

Emily

[Bob_Schor]

Your Error Message talks about unwired Tunnels (those would be on the right edges of For and While loops, typically), but when I opened the code you attached (thank you!), those errors were not present.  Instead, there were a lot of "missing VIs and DLL" messages that spawned errors of their own.

So I thought I'd take a look.  Ouch -- how can you possibly deal with such an enormous Block Diagram?  It must take a bank of 20 monitors, 5 across and 4 deep, to see the whole thing.  Small is Beautiful -- keep your Block Diagrams the size of a laptop screen (and not the modern Ultra-Resolution variety).  One great way to do this, which can also greatly improved your code, is to gather a section of code that "does one thing" and make a sub-VI out of it.  Be sure to "help yourself" when creating such sub-VIs by following these simple rules:

• Always use the 4-2-2-4 Connector Pane.
• Always have Error In and Error Out at the lower corners.
• If you only have 1 or 2 inputs and outputs, that's good.  If you need more than three Ins or Outs, consider grouping (Array or Cluster), or consider "doing less" or "making two VIs".
• Every VI should have an Icon, even a White Square with Black Border and 3-4 lines of (short) type ("Setup A/D", or "Find Max and Min") -- you want to instantly know what that Block on the Block Diagram is supposed to do.
• Think Hierarchy and Abstraction.  It is not unusual for me to start writing a sub-VI and realize I can "hide some of the details" by making another sub-VI inside of it.
• As you design "simple sub-VIs", don't forget to do "simple tests" so you are confident they'll do the right thing when used.
• Do use the Error Lines!

Bob Schor

[Miller37]

Hello, Bob.

Thank you for your quick reply. I appreciate your feedback. I realize that my code is not pretty and I definitely have a lot to learn. Now that I have functioning code, I want to make proper code. I will work through creating sub-vis. Thank you for your suggestions.

What version of LabView did you use to view my code? I realize that there are "missing VIs and DLL". I didn't attach all the sub components, but it is encouraging that you didn't see the tunnel error. I am working on an un-networked computer with LabView 2012. The digital controls that I am using are not compatible with later versions of LabView. Maybe there is an upgrade/bug fix for 2012 that I need to install that will reconcile the tunnel error.

Regardless, I realize that my code needs work and I appreciate your feedback.

Thank you.

Emily

[paul.r]

I agree with most of Bob's advice - one other issue I see is that in several of the cases in your upper loop you are passing a default queue type out onto the the shift register - losing your active, valid queue reference. 

[Miller37]

Thank you. I will fix that error.

[Bob_Schor]

---

@Miller37 wrote:

What version of LabView did you use to view my code?

---

Hi, Emily.  It was either LabVIEW 2016 or LabVIEW 2018, as those are the versions on my Laptop and Work Desktop.  [I am still "testing" LabVIEW 2018, so I run that in a VM on my Laptop as the sole LabVIEW version so that I don't "accidentally" upgrade code I'm developing in 2016 ...].

Bob Schor

[paul_cardinale]

---

@Bob_Schor wrote:
...

• Always use the 4-2-2-4 Connector Pane.
• Always have Error In and Error Out at the lower corners.
• ...

Bob Schor

---

I have a particularly low opinion of rules that say "Always do X" or "Never do Y".  Simplistic rules almost never universally indicate the best way to go.

1. There's nothing special about the 4-2-2-4 connector pane (except that it's very popular).
2. It's almost always best to have Error In and Error Out terminals.  But for some very simple things, it can be pointless.

[Mark_Yedinak]

---

@paul_cardinale wrote:

---

@Bob_Schor wrote:
...

• Always use the 4-2-2-4 Connector Pane.
• Always have Error In and Error Out at the lower corners.
• ...

Bob Schor

---

I have a particularly low opinion of rules that say "Always do X" or "Never do Y".  Simplistic rules almost never universally indicate the best way to go.

1. There's nothing special about the 4-2-2-4 connector pane (except that it's very popular).
2. It's almost always best to have Error In and Error Out terminals.  But for some very simple things, it can be pointless.

---

I completely agree with your comment. ONe thing that I would add is that I do have a fairly general "always" rule that I follow. I will always use the same connector pane for my public/API VIs with a library or class. This will keep wire flow much cleaner. In addition, I try to maintain a consistent position on the connector pane so that wires truly flow and don't have to bend going from one VI to another.

[paul_cardinale]

---

@Mark_Yedinak wrote:

---

@paul_cardinale wrote:

---

@Bob_Schor wrote:
...

• Always use the 4-2-2-4 Connector Pane.
• Always have Error In and Error Out at the lower corners.
• ...

Bob Schor

---

I have a particularly low opinion of rules that say "Always do X" or "Never do Y".  Simplistic rules almost never universally indicate the best way to go.

1. There's nothing special about the 4-2-2-4 connector pane (except that it's very popular).
2. It's almost always best to have Error In and Error Out terminals.  But for some very simple things, it can be pointless.

---

I completely agree with your comment. ONe thing that I would add is that I do have a fairly general "always" rule that I follow. I will always use the same connector pane for my public/API VIs with a library or class. This will keep wire flow much cleaner. In addition, I try to maintain a consistent position on the connector pane so that wires truly flow and don't have to bend going from one VI to another.

---

I also generally try to minimize wire bends; but some people don't like the way I do it.

For instance, instead of this:

, I do this: 

[RavensFan]

---

@paul_cardinale wrote:

---

@Mark_Yedinak

---

I also generally try to minimize wire bends; but some people don't like the way I do it.

For instance, instead of this:

, I do this: 

---

That I do not like at all.  It feels like something is hidden.  It breaks the idea that wires should generally flow left to right, or more precisely that they should flow into the left side of a node and out the right.  Of course some functions and subVI's have inputs that are at the top and bottom borders, and they would flow up or down into the node.  But the view like the right makes me thing that function has nodes on the top and bottom that you connected to rather than the right and left.

In short, it doesn't look right.  Yes, you want to minimize wires bends,but there is no real advantage of having only one wire bend instead of two, but the disadvantage of a node that doesn't look like it is wired correctly is significant.