Seeking instances of nearly identical code on the same diagram

[Aristos Queue]

We all know about the pain of having to write two nearly identical VIs, differing only by some single function or some data type and the code maintenance burden that creates. There's lots of discussion about what LV could do about that.

 

Today I'm asking about a different problem entirely. I want to hear about (and if possible, see posted pictures of) VIs where you have multiple blocks of nearly the same code over and over. Maybe its some manual pipelining that you've done, or for some reason you manually unrolled several instances of a loop. Perhaps you have six copies of your UI on the front panel and so you have six identical event structure loops on the block diagram. These are the trivial cases that I can rattle off the top of my head.

 

Do you have examples of places where you had to ctrl+drag blocks of code? They can be the same block of code exactly or code that you duplicated and then tweaked each copy. Regardless, it needs to be on the same block diagram.

 

Why am I looking for these? There are a couple categories of code replication that R&D has identified as a priority to do "something" about to make writing and maintaining such code easier. The current proposals would address some fairly specific niches on FPGAs, but we think we can create a feature that is much more powerful with about the same amount of effort, but we need VIs as fodder for analysis.

 

So, if you have a VI with such replicated code and you don't mind discussing it and/or posting pictures of it, please, load 'em up in this thread.

[Yair]

I have something in mind - There are three flurbs, each with a few pages worth of code, all in the same VI (they're actually called in sequence). The flurbs are similar, so the code for them is similar, but the code has many constants which are different for each flurb, as well as some actual differences in code, some of which are quite significant (to the degree of "the first half of the flurb is similar, but the second half has mutated and now has four arms"). For ease of coding, understanding and debugging, the code for the flurbs is duplicated rather than handled using other means, but that means that every change which affects all of them has to be made to all of them separately.

 

Is that the kind of thing you were thinking of? I'm curious as to what mechanisms NI has in mind which can help with such code.

[ShaunR]

I have something in mind - There are three flurbs, each with a few pages worth of code, all in the same VI (they're actually called in sequence). The flurbs are similar, so the code for them is similar, but the code has many constants which are different for each flurb, as well as some actual differences in code, some of which are quite significant (to the degree of "the first half of the flurb is similar, but the second half has mutated and now has four arms"). For ease of coding, understanding and debugging, the code for the flurbs is duplicated rather than handled using other means, but that means that every change which affects all of them has to be made to all of them separately.

 

Is that the kind of thing you were thinking of? I'm curious as to what mechanisms NI has in mind which can help with such code.

I'll have a quart of what you are drinking 

[Tim_S]

I have FPGA code where I take 54 quadrature inputs (A and B phase) and determine linear encoder position. This has a very long I/O Node, followed by 54 instances of debouncing subVI and quadrature-decoding subVI, followed by all 54 encoder positions put into an array (Replace Array Subset). Each of the linear encoders also has an error line, which has 54 inputs geting packed into three U32s. (The encoder positions and status values are DMA-ed off to the PC at internal or external clock intervals, but that's not important here.)

[Aristos Queue]

Tim_S has the classic pattern that we are investigating. Yair, yours sounds like one I'd like to see a visual of. It sounds distinct from the ones collected so far.

 

 I'm curious as to what mechanisms NI has in mind which can help with such code.

We don't have anything in mind to solve your case at this time. We're collecting use cases to see what we can come up with. Tim_S's use case might be solvable with some extensions to the Parallel For Loop, but we're looking into other possibilities.

[Tim_S]

Tim_S's use case might be solvable with some extensions to the Parallel For Loop, but we're looking into other possibilities.

 

As much of a pain as it was to copy/paste, the code operates in a single clock cycle. Would the alternative methods be able to do the same?

[Aristos Queue]

As much of a pain as it was to copy/paste, the code operates in a single clock cycle. Would the alternative methods be able to do the same?

If the alternatives didn't do the same, we wouldn't call it a solution. :-) 

[JamesMc86]

Tim_S's use case is an interesting one I have seen on FPGA several times. I did put in an idea exchange for a loop unrolling system for FPGA, you can't use a for loop because it is forbidden in an SCTL (and would take too long) but semantically it is so much easier!

 

This is the link:  http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Allow-Parallel-For-Loops-on-FPGA/idi-p/1599930 In that case I was thinking the parallel loop syntax could be used.

[Aristos Queue]

Tim_S's use case is an interesting one I have seen on FPGA several times. I did put in an idea exchange for a loop unrolling system for FPGA, you can't use a for loop because it is forbidden in an SCTL (and would take too long) but semantically it is so much easier!

 

This is the link:  http://forums.ni.com/t5/LabVIEW-FPGA-Idea-Exchange/Allow-Parallel-For-Loops-on-FPGA/idi-p/1599930 In that case I was thinking the parallel loop syntax could be used.

To be clear... when I said "could be solved with the parallel For Loop", I did not mean the parallel For Loop as it exists in LV today. ;-)

[Tim_S]

I'm not sure how prevalent my use case is, but all that copy, paste, wire, etc., took a couple hours that a for-like structure would have made much faster. The code takes multiple screen-heights, so anything that could reduce the code sprawl and make it more readable would be a big plus.

[Yair]

I have something similar to Tim's example on an FPGA - there are 64 DIs which are used as counters, so there's a reentrant VI which takes in a boolean and increments a counter in a feedback node each time the boolean changes to true. That VI is called 8 times in parallel in a reentrant "port VI" and the port VI is called 8 times in parallel for a total of 64. The results are then combined. I didn't work on this directly, so I have no idea how this compares to Tim's version (although I'm assuming it's not as efficient), but that gives another version of this type of code duplication.

 

As for the previous example I mentioned, AQ got a cleaned up version of the code. The rest of you will have to manage without.