Boolean triggered numeric indicator plus minus

[Akello]

Hey all,

I've been making a VI to read a joystick and then serial write ASCII values based on the input. At the same time I am doing a continuous serial read.

The VI is operational, thanks in large part to the fantastic support I've found here on the forums but I am still having a small problem. I wanted to install a speedometer that could be triggered by the joystick's buttons (one for plus, one for minus) and updated continuously. A friend gave me a basic schematic that worked perfectly but I have so far been unsuccessful in getting it to work in my larger VI. I checked it over several times and it seems I followed his example to the T. 

Currently my -1 works fine but for some reason the +1 won't work. I suspect it might be an issue of the shift registers, which are new for me, but I am not sure. I thought I would try the forums; any help would be truely appreciated.

Thanks,

Yusif

P.S. I've included both my VI and a snapshot of the example I am trying to implement. Any advice on how to fix it would be appreciated but an explaination of what I did wrong would be even better!

[Bob_Schor · Accepted solution]

Yusif,

     First comment -- really, really try to make your VIs compact enough so they fit on a single screen!  It is very difficult to follow wires if you need to scroll back and forth, up and down.  [Hint -- taking "big" (in screen-space) code sections and making them into a single sub-VI works wonders ...].

     If I understand the problem correctly, you have two buttons -- pushing Button 1 should add one to the speedometer, and pushing Button 2 should subtract one from the speedometer.  The easy way to program this is to have a single shift register that holds the current speed (and to which you wire your Whimsical Speedometer indicator).  Surround this wire with a Case statement wired to Button 1 that contains an "Increment" in the True case, and just passes the wire through in the False case.  Put a second Case statement on the same wire, but wire this to Button 2 and put a Decrement in the True case.  Simple, no?

[Akello]

Thanks brother that did the job!

I am still new to LabVIEW. I picked it for this control project so as to get better acquainted with it but there are still things I need to get familiar with (like shift registers). I have a nice book I am trying to follow so I'm making progress. As for the subVIs, I actually know how to use them and generally I'd agree but I am handing this thing over to someone who will be messing with it to get it to work with hardware and I have the feeling that it would be easier for him to see the whole picture versus jump into VIs.

Thanks so much for your help!

Yusif Nurizade

[SteveChandler]

---

Akello wrote:As for the subVIs, I actually know how to use them and generally I'd agree but I am handing this thing over to someone who will be messing with it to get it to work with hardware and I have the feeling that it would be easier for him to see the whole picture versus jump into VIs.

Yusif Nurizade

---

Yusif, here are some thoughts. You can take it or leave it but it is not only directed at you but at anyone else reading this thread who thinks in the same way.

With a block diagram that size there is no way to see the whole picture. Well designed subVIs do a very specific thing. If they have good documentation and icons then the person you are handing this off to only has to think about what the function does and not how it works. If they want or need to know how the specific function works they can open the subVI and not be distracted by code unrelated to that function. Think about the multiply function. You look at it and you know what it does. You can implement your own multiply function using a loop, shift register and addition but it is much cleaner to have a multiply function. Maybe that is too simplistic of an example but I think it does illustrate the idea.

I see some code along the bottom that would be a really good candidate for a subVI. The input to the multiply with pi should be controls in the subVI. Better yet all of the inputs can possibly be a single cluster input.

Also the case structure could be a subVI. Just doing those two things will go a long way towards making this readable but you could go even farther. The function in the snippet outputs a boolean and you are building an array from several instances of the function. If it were in a subVI you could build the array using a for loop. Now your entire code will easily fit on a single block diagram window that is not even maximized. On a side note the selector for the case structure could be an enum so that the cases are a little more self documenting. Another good subVI would take the boolean array as an input and return this (typedef) enum as it's output.

Much easier to see the whole picture!

On a positive note your code is very well documented and clean. I have seen lots of block diagrams this size that are horribly cluttered with wire bends, overlapping nodes, etc. I have not seen many this large that were so clean. In fact it is much cleaner than many small block diagrams that I have seen. I can tell that you really do take pride in your code. But as you can imagine, if someone starts adding functionality to this, it will be incredibly difficult to maintain such neatness.

[Akello]

Steve,

Thank you for taking the time to explain the value of the subVI. You are, ofcourse, right about the need for them and it did become bothersome as more and more code was added to wade through the space of it.

Having spent so much time on it, this was essentially a project meant to help me better understand LabVIEW, I knew right off the bat where everything was but there is no denying it would be difficult for someone else. In fact, though it may not be evident, the code is much smaller and less cluttered than it was initially. Take for example the atan2 function; I started out essentially doing the whole thing with things like multiplication and division until I found that such a function was possible so I definitely see the benefit of what you are suggesting.

What it boils down to is that I was on a self-imposed deadline to finish this before my semester started so I can focus on school. It's getting handed off to someone who will interface the hardware and I didn't have the time to either explain the subVIs to him or include all the necessary explainations in the VI itself. Our understanding is that he will either take it as is and ask me about it or make the transition to subVIs himself.

Thank you again for the explanation and the complements about the VIs merits, I will certainly make sure to implement subVIs in the code I am currently working on so that there will not be a similar problem.

Yusif