Hi, I’m the lead (student) programmer for team 848. We have had no formal LabVIEW training, but we are pushing through.
Now we’ve run into another problem. We have a Pneumatics System where 1 Air Compressor feeds 4 Pneumatic (Air tank)Solenoids that are Physically attached to 8 Spike Relays. Those are all the physical connections that we have.
Now for my job. We want the first Solenoid to raise and lower while we then use the other 3 Solenoids to dump in 1 of 3 (forward/right/left) directions. I need every one of the functions that I mentioned above to be mapped and controlled to/from one joystick in USB port 3. This Joystick will be our “buttons” joystick and no axis control will be assigned to this joystick. Thia is where we encounter problems, and thus I turn to you guys. Any visual aids or advice or directions are greatly appreciated. Thank you guys so much.
One of the outputs of the Joystick Get VI is a bundle of buttons. Wire it to an “Unbundle by name” VI, which will provide boolean outputs representing the state of any of the joystick buttons you choose. The buttons are labeled by number on the joystick itself.
Do you need help connecting those booleans to Solenoid VIs?
Here’s the setup we had last night from the limited info I and my team were able to compile. I had figured out the buttons unbundle, but now the design of the robot has changed and I need to control not 4 but 3 pneumatics via Joystick buttons. I thought that the setup pictured would fill the compressor and allow us to activate the solenoids, but nothing happens when we press buttons. Is there anything wrong with our setup?
I also have 2 additional questions.
Can I wire the 3 Joystick to a 3rd Motor via a “Get Axis” VI like I did for the tank drive system? I had a 3rd Joystick for buttons per my designers request, but I now need to wire it to a 3rd motor that I have not created yet on the block diagram.
Why does our robot only move in 2 second increments? No matter how we move the joysticks, the robot only moves for two seconds, then pauses momentarily, then moves again. Is this a mechanical problem or did we code something wrong? I should state the changing the battery alleviates this problem, but only for 2-3 minuets, regardless of the energy level of the battery.
I don’t see anything wrong with your code per se, but you probably should change your SolenoidChannel, SolenoidChannel 2, Solenoid Channel 3, etc. from controls to constants.
Right click on each solenoid channel control and select “Change to Constant”. Then make sure the constant is the correct channel. If you leave them as controls, once the VI leaves memory and you reopen it (for instance if you deploy the code as standalone and reboot, or the next time you open LabVIEW), all the controls will revert to their default values unless the values are wired in from a calling VI. This means that they probably all will revert to channel 1, which is most likely not what you want.
That sounds like you have circuit breakers tripping. Check your drive train for binding gears, too-tight chain, excessive friction, or anything like that. It might even be a wiring problem with motors fighting each other.
Hi, I am the lead (student) programmer for Team 848. huskyrobotics is as you all could tell, a team-wide account. RedWolf55AJ is the account I made so that I wouldn’t have them looking over my shoulder.
As it turns out, 2 minutes after I posted that last message, one of the other guys came over saying that it was probably a circuit breaker problem. I agreed.
Now we have an arguably worse problem. The circuit breaker issue only happens when we deploy OUR code. When we format the cRIO via the cRIO imaging tool, the robot drives like a dream. As soon as we upload the code pictured above, the controls become laggy (.5-1 second delay).
what is even worse is that mysteriously, the right side of the robot stopped working, without any changes in code that I could see. Fearing a joystick problem I swapped the joysticks in USB Ports 1 and 2. The Right Jaguar Speed Controller remained inoperative regardless of the joystick. When I did reach into the code to switch which USB Port fed which side of the “Tank Drive” VI, the problem then switched to the other motor/jaguar. I fear that somewhere between “Open Joystick” (USB 2) and “Close Joystick” USB 2 some input is being lost. Can anyone help me with that? I really only have one more day to work on this thing and I’m fighting time.
The problems above only occur when we deploy our code.
PS, I can see that the cRIO retunrs to “46% empty” each new time we deploy/run our code. When the time comes, how will we get our code to “Stick” to the robot’s cRIO? I want it in deeper than just RAM or wherever it is now.
I notice that you are setting PWM5 and PWM6 motors to 255 immediately. If the breakers are continually tripping, maybe you should set these to a control and start with the speed at zero initially and see if you still trip the breakers.
Also, did you change the solenoid controls to constants as I suggested?
If you want the stand alone deployment to be Set as Startup, right click the build specification and select “Set as Startup”.
The code pictures you posted are not clear enough for me to follow the connections. You can debug a running program by clicking wires and placing a “probe” to show the live value on that wire; maybe that will help you determine where the fault is.
:mad: Alright, this is now officially ridiculous.
I’m working with the code the we(huskyrobotics is a team account) had yesterday and now the robot will not move at all. when I probe the connections, I see an obvious problem in the Get Axis VIs.
The Front Panel of the “Get Axis” VI is now reading USB 3 instead of USB 1. I have 2 instances of my “Get Axis” VI running, but on the Front Panel, I see 2 near-identical diagrams. One says USB 3 in serveral spots and the one below it says USB 2 in those same places. I need the USB 3 changed to USB 1 Please.
Now when I probe the connection between the 2nd “Get Axis” VI and the other input of the Tank Drive system, I get no recorded input, as if there is no controller there. At all.
This is ridiculous and my team and I are at our wits end pondering why it does not work. Screen schots will be up momentarily
Be aware that if you are calling a subVI from multiple places in the program, it can be misleading to open the subVI and view its front panel to try and understand what is going on because you may or may not see all of the data that is flowing through the subVI. The data may move to quickly for the screen to update and display every piece of data.
For instance if the system alternately calls the GetAxis with USB1 and then with USB2, you may, or you may not see the alternating USB1 and USB2 values. Depending on the timing, you might see just one, or the other, or both at different times.
Also, since your diagram is large, it may be easier for us to diagnose your actual code than screen shots of it.
Alright, well, my team decided to try and clean up/clean out our old code, with a heavy emphasis on following the LabVIEW examples that we were provided with. With that said…
The first thing that I notice is that you are using Controls to specify which channels you are using. You should right click these and Change to Constant because otherwise they will revert to the default value of the control when you deploy a stand alone executable and reboot.
Other than that I don’t see functional problems with the code.
Aesthetically you should separate your subVIs on the diagram so it’s clear where the wires are going. You want to expose all the wires and try not to cover any of the wires up when possible.
Hey, I was looking at the pictures of coding from the attachments, and I was wondering, how do you get the status thing coming from the compressor enabled vi’s error out, and how do you get the TF status things that aren’t selecting true or false like the others. Sorry if this sounds somewhat stupid, but it’s over my head.
The status is using Unbundle by Name to pull the status Boolean out of the error cluster. You can access it in programming -> Cluster, Class, & Variant -> Unbundle by Name.
I think you’re referring to the indicators. You can right click on any output on the block diagram and choose create -> indicator, which will create an indicator of the correct type on the front panel. You could also make an indicator on the front panel, and then wire it on the block diagram, for example, using a round LED. A Boolean indicator will normally have a picture of an LED on the front panel, but if you right click on it and unselect view as icon, it will use the same type of picture as the screen shots above.
"One of the outputs of the Joystick Get VI is a bundle of buttons. Wire it to an “Unbundle by name” VI, which will provide boolean outputs representing the state of any of the joystick buttons you choose. The buttons are labeled by number on the joystick itself.
Do you need help connecting those booleans to Solenoid VIs?"
To: Alan Anderson
Yes i do need help with this. I’ve tried using your example but im kinda confused. Can you please reply as soon as possible?? Thank You.
