Team 1726 button toggle & SR Latch code

[BitTwiddler]

We used these handy little utilities last year and I'd like to be able to re-use the code this year if it comes in handy again. Therefore I am posting the source VI code for other teams to use in the spirit of R13 for the 2015 game.
Button toggle allows the drive team to use a game controller button like a toggle switch. It detects the button press and flips the true/false state of the toggle output to turn something on or off as desired.
SR latch uses one button to set the output to true and second button to reset it back to false.
If you wish to clone multiple copies of these VIs in your code make sure to make them re-entrant to avoid confusion with shared resources.
Hope some other teams also find these useful.

[nwall]

Thank you for posting this. Our team has always done it one way (since I've been here) and haven't really thought about other ways of doing it because it worked. I do have a question about your "Button Toggle.vi", which is why you use the blocks used. (i.e. Not and And for "Pulse Out", Not and Select for "Toggle")

I have attached our version of the "Button Toggle.vi", which swaps out the two sets mentioned above with Greater Than and XOR. I ran a benchmark on both methods to compare the time required to do each operation 100 million times, and after taking the average of 25 runs, our method took ~1551ms to complete the 100 million iterations, with your method taking ~2000ms. I assume that this is because LabVIEW doesn't have to wait on the output from a block to put it into the next block, but I'm not sure.

For a competition, either would be plenty fast enough, so I'm just wondering why you do it this way.

[wt200999]

Originally Posted by nwall

I ran a benchmark on both methods to compare the time required to do each operation 100 million times, and after taking the average of 25 runs, our method took ~1551ms to complete the 100 million iterations, with your method taking ~2000ms.

For your benchmark, try setting your execution settings to preallocated clone reentrant, remove the checks for debugging, and add the check for inline and run it again. (see attached)

[nwall]

Originally Posted by wt200999

For your benchmark, try setting your execution settings to preallocated clone reentrant, remove the checks for debugging, and add the check for inline and run it again. (see attached)

Thank you! I did that, and you're right, they both ran for an average of ~459ms. I've never really messed with the Execution settings too much, so would you recommend disabling debugging once the robot code is finalized and on the robot, or would the speed gained be negligible for the loss of debugging?

[wt200999]

You shouldn't have to worry about it for the robot code since when you 'deploy' the code (at least by default) debugging is disabled. You can see that this is true if you look under the Advanced category for the build specification in the default robot project. In fact I would leave it in for most of your VIs so when you load your code using just the Run button, you can still debug as usual.

Inlining the VI will give you some small performance benefits at the expense of larger compiled code. Just this check box alone will change your benchmark results. It is good for small widgets like the ones in this thread. For the reeentrancy you just have to be careful depending on the VI.

[BitTwiddler]

Originally Posted by nwall

Thank you for posting this. Our team has always done it one way (since I've been here) and haven't really thought about other ways of doing it because it worked. I do have a question about your "Button Toggle.vi", which is why you use the blocks used. (i.e. Not and And for "Pulse Out", Not and Select for "Toggle")

.

As a digital electronic technician (now retired) I am used to approaching these kind of problems at the lowest bitwise level. The use of the greater than comparison operator just seems wrong to me but that's just me. I must admit however that I had a "slap myself on the forehead" moment when I saw your elegant use of the XOR operator for the actual toggling of the output. I'm gonna use that one from now on.

Since Labview is an optimizing compiler, it will probably come up with a more efficient solution during compilation anyway.

[BitTwiddler]

Originally Posted by wt200999

Inlining the VI will give you some small performance benefits at the expense of larger compiled code. Just this check box alone will change your benchmark results. It is good for small widgets like the ones in this thread. For the reeentrancy you just have to be careful depending on the VI.

Thanks for your insight regarding the inlining. I missed that one.

[nwall]

Originally Posted by wt200999

You shouldn't have to worry about it for the robot code since when you 'deploy' the code (at least by default) debugging is disabled

Oh, okay. Thank you! I figured this was the case, but I wasn't sure, because I haven't spent enough time in the settings.

Originally Posted by BitTwiddler

As a digital electronic technician (now retired) I am used to approaching these kind of problems at the lowest bitwise level. The use of the greater than comparison operator just seems wrong to me but that's just me.
.....
Since Labview is an optimizing compiler, it will probably come up with a more efficient solution during compilation anyway.

I assumed it was something like personal preference, but I was curious if there was something I didn't know about LabVIEW (turns out how to turn off debugging). Our previous programming lead showed me the greater than two years ago, and because it worked I've never really given it too much thought until today. Thanks for putting this up!