Sub vi not working in loop

[AndyKron]

I have a vi that works fine as a standalone, but for some reason it doesn't seem to work in a loop. I don't know how much code I can divulge right now, but I'll start with screen shots of the vi, where it's called and part of the main. The vi is supposed to look at the checksum and sequence # in the string data, then update the sequence # and checksum using a counter that resets after a fixed number of counts. the vi works great by itself, but in the loop it looks like it just returns the original string value without updating. This is a Producer/Consumer pattern.

Consumer loop in "Main"

---

CMD Encode where vi in question is called

---

Sequence updater that isn't updating

[GerdW]

Hi Andy,

all we got are some images instead of code when we should discuss those code problems!?

Why is there a feedback node next to the loop with a shift register?

The whole loop could be replaced by an increment and a Q&R function...

[altenbach]

I agree that the combination of shift register and feedback node does not look right. Too many cooks!

Also, the "CMD encode" is way more convoluted than needed. First loop could use a concatenating tunnel instead of a shift register and that entire "padding" monstrosity could be replaced by a "reshape array" which pads automatically. You could even reshape to 2D with 6 columns and autoindex on the next loop. You could use an array for the LUT. Seem more elegant than extracting characters from a string. Etc.

[wiebe@CARYA]

---

@altenbach wrote:

I agree that the combination of shift register and feedback node does not look right. Too many cooks!

---

It's not right. But the loop and shift registers don't do anything. Except cluttering.

Right click the while loop, remove it. Solved that problem (, not the problem)

[wiebe@CARYA]

What do you see when you open that VI (while running the main) and probe the checksums, etc.?

Without actual code, we can't rule out anything, and there's simply too much. You might even wired to the input string of the SubVI instead of the output string (in either the CMD Encode or Main, or both). That will look exactly the same.

[AndyKron]

Hi Gerd,

I didn't want to post code because I don't know what I can and can't post at this moment. 

Thank you for everyone's responses. The loop with feedback node and Encode sections were designed by a computer science intern working here for almost two years ago. I didn't write any of this code myself. The main producer/consumer loop was designed by a contract software engineer who is on vacation until Tuesday, although he did Teams me today and worked on it a bit. 

I sent him the responses to see if there is any cleanup he'd like to do. The last time I posted the intern's code here a year or so ago, someone called it a "Rube Goldberg structure". All that's left of the intern's code is that sequence loop and the encode section, which still seem to raise eyebrows.

-Andy

[wiebe@CARYA]

---

@AndyKron wrote:

The last time I posted the intern's code here a year or so ago, someone called it a "Rube Goldberg structure". All that's left of the intern's code is that sequence loop and the encode section, which still seem to raise eyebrows.

---

There's still a few things that would qualify as RG.

As GerdW mentioned, the loop and feedback node could be like this:

Obviously an improvement.

Also the build array in a shift register  sticks out. We have concatenating indexing for that (but only since a few years):

Knowing each and every LabVIEW trick, and understanding how to apply them, takes time. The 3 of us that replied to your post so far probably have >60 years of LabVIEW experience...

We point out RG because those are contained and 'teachable' problems. They raise (our) eyebrows, but how would someone improve if we don't point them out?

The program's structure is much more important. That is actually more 'computer science-y', and that looks pretty decent.