We have recently made changes to our breakaway! robot and are attending CAGE Match. With the recent changes I just wanted to double check some programming thing before we get the robot ready to leave.
A) The purpose of the code: When button 6 is true the motor goes forward (aka lifting the lifting device). When False the speed is set to 0. When button 7 is activated, the lifting device is lowered. (Pictured Below)
B) I really needed to reduce the sensitivity of our drive system. I tried a method of hooking buttons up to cases and then multiplying the motor speeds by .5. However, when I built and deployed the code, all I got was watchdog errors. Is there any example code or anything of a simple drive system sensitivity system.
A Watchdog error could also be cause if you have connected a watchdog to a “Everlasting loop”. The watchdog would have to wait for that everlasting loop until it can continue to the next task, but if you have connected it to a case that never stops, the watchdog is not going to move on.
Check if you have connected a loop that runs forever before watchdog can move on. That was our problem and we fixed it by rechecking this.
I agree. However, there might be a problem if the driver were to press button 6 and 7 at the same time. I would change the logic selecting the case statements, the first one would be button6 AND !button7; and the second would be button7 AND !button6
There’s also a problem with the snippet you posted if both underlying FALSE cases are setting the motor speed to 0.
They will be contradicting the other button’s TRUE case.
You only want to set the motor speed to zero if both buttons are FALSE.
Using one of the joystick throttles for adjusting sensitivity would give you the most control.
As Mark pointed out, your code gives an indeterminate result when either or both buttons are pressed. Both case blocks will try to set the motor at the same time, and which one actually succeeds is not predictable. To fix this, don’t put the blocks in parallel. Put them in series. Instead of actually setting the motor speed inside the blocks, set it after them both. Here’s how I suggest you do it:
Wire a constant 0 into the first block, connect Button 6 to its select input, and in its false case just pass the input through to an output. In its true case, connect a constant 0.5 to the output instead.
Wire the output of the first block into the second block, connect Button 7 to its select input, and in its false case just pass the input through to an output. In its true case, connect a constant -0.5 to the output instead.
Feed the output of the second block into the Set Motor vi. Done! This makes the “down” button take priority over the “up” button. Change the order of the case blocks if you want the “up” to override the “down” instead.
For this kind of thing I would actually use select functions instead of case blocks, but that’s not a big deal.
Thanks guys. I think I have it fixed now. I will try it tonight at the shop and post my results.]\
– Results–
Below I have included pictures of the section of code I’m wondering about. (I fixed the watch dog error thanks to whcirobotics and I got a rough version of motor sensitivity down.) This is the code that Alan suggested (well as I could understand from the text). Should it function properly?
It looks like it will do what you want. You got it exactly as I described (except for the superfluous wiring through of the select input to an output of each case block – that can be deleted without worry).
It takes a while to get used to the “sensical” way of doing things in LabVIEW.
The TechnoKats 2009 robot had several motors that were used as either off, fixed speed forward, or fixed speed reverse. Our code got a lot less cluttered when we build a subVI to handle that function. Given a motor reference and a pair of button inputs, it did exactly what you were asking for. The forward and reverse speed values defaulted to +/- 1, but could be overridden by additional inputs. We also added limit switch inputs to disable travel in one or the other direction. That exact subVI wasn’t reused in 2010 because it had never been published and was therefore not strictly legal for the new season according to the manual, but it was only a matter of minutes to recreate it from the basic concept. If we need it again next year, we know how to do it, and we’ll probably put it out for public enjoyment this time.
