We have a few questions regarding our Auto. Part of our Hybrid program.
-
We would like to make sure that when both of our lift limit switches are hit, then our sequence only happens once and will continue on EVEN if either of the limit switches are released and pressed again and again. How should we go about and accomplish this?
-
If you look at the various loops, they each indicate after a certain amount of time when to stop and continue to the next loop. Have we done this right?
Do you think that we would have any problems with each of the timing sequences?
You want to wait until both switches are pressed, then run the stuff in the True case, right? To do that, you need to be reading the switches in a loop that runs until both switches are pressed. You don’t need the case, but it might be easiest to leave it there and make the switch-reading loop produce a True value when it terminates, with that value wired to the case structure. The False case will never execute, and the True case will execute only once.
And Just Like Alex Kipman said at Kickoff this Year…
…and with that, we programmers seem to follow along with this idea.
So, will this do the trick?
That’s exactly what I had in mind. It looks to me like it’ll do what you want.
Alright, now that I have that settled, the next question would be for our Teleop program. It is not to solve a problem, but rather confirm if what we did was correct.
Just like in the Auto program, I have the same 2 limit switches put to use. When Our lift activates both limit switches, we want to prevent the Joystick from inputting any more positive value (to prevent breaking our lift, burning out motor, etc.), just the negative to get it down again.
In the Case structure, I have placed the two limit switches just like in Auto, and if they are both true, a second case is started. The statement we thought of was: “If both of the limit switches are pressed, another check is made. It checks to see if the Joystick value is less than or equal to zero. If the Joystick value is less than or equal to zero, then the input is allowed. If not, the motor is set to zero input.”
We have done the same thing to the third limit switch at the bottom of our lift, so it can be changed accordingly.
So, have we set this case up right?
I’m not going to attempt troubleshooting the logic on this. Here are a few suggestions though.
- You really should put your switch reads in a loop in Periodic Tasks. It is more of a safety net for what you’re doing, just to ensure that nothing holds up reading the switch values. You could then combine these switch values to different states then use those states in your other code, which could drastically reduce the complexity of this.
- It is much better/easier to troubleshoot if you put your motor sets at the very end of your teleop vi and wire the numeric outputs of each of your case structure to the motor drive itself. Again, a safety net to ensure that you aren’t getting to a “weird” (i.e. unanticipated) state where you set the motor to different values at the same time or they flip back and forth. As it is right now, it is very easy to set a motor reference to different values at the same time, you should try to avoid this.
- VI encapsulation… Makes your code a lot easier to read. What you have here is what we like to (affectionately) call spaghetti code.
I will say that your comments are great, very rare to see code documented this well.
Your limit switch code looks like it will do what you want, but without having the live VI to look at closely I’m not going to guarantee anything.
You’re doing a lot of stuff with case structures that I think can be implemented more simply using other tools. For example, I typically suggest using “select” nodes and “in range and coerce” functions for limit switches. This isn’t the time or place to be making major changes to your code, though.
I don’t know if this will help greatly, but with what you said, I will provide you the teleop VI.
Oh, and sorry about those arrows I placed, I just looked at them and noticed that they both touch a text box to the same case structure.
When you look at the diagram, just know that I placed the text boxes right next to the corresponding case structure.
*Thanks David for that complement, I learned how to place a description of what “should” be going on in the code when I worked with MultiSim and Xilinx in my Digital Electronics class. That way, anyone who looks at the code can see (and hopefully understand) what that part does and what physically goes on.
Oh, and about the resulting “spaghetti code,” I am not in any worry about what leads to where, for I made the program one section at a time and organized it as I went along…again something I learned from DE when I worked with programmable breadboards…*
Teleop.vi (52 KB)
Teleop.vi (52 KB)
