![]() |
Program Pnuematics
I have a Team Member who is needing help in Programming. One of his MAJOR problems is he does not know how to program Pnuematics. If you have any links that will help, or advice, please comment. I will have more post soon probably. All help is appreciated. Thank You.
|
Re: Program Pnuematics
What language?
There are examples of each we can direct you to. |
Re: Program Pnuematics
English
|
Re: Program Pnuematics
It is in the c/java manual on the WPI website!
|
Re: Program Pnuematics
our programmer is using labview, by the way....
|
Re: Program Pnuematics
And Where Can i find that. Do you have a link
|
Re: Program Pnuematics
1 Attachment(s)
Quote:
You can talk at them, but they won't answer except maybe to sigh... There is a compressor example on the LabVIEW startup screen you can click on to see how it's done. |
Re: Program Pnuematics
:cool: What tools make the pneumatics change is pressure?:cool:
|
Re: Program Pnuematics
WE USE LABVIEW
|
Re: Program Pnuematics
Thanks, Mark. We got it.
|
Re: Program Pnuematics
Quote:
It will need to be translated somewhat to fit it into this year's default framework. For instance, the compressor open and enabled should probably go in Begin.vi The solenoid stuff belongs in Teleop.vi or Autonomous Independent.vi Let me know if your programmer needs more and I can knock out a few screenshots. |
Re: Program Pnuematics
Quote:
One other way you could do this is use multiple regulators all being tied to the same piston with solenoids regulating each and fire different solenoids in order to send different pressures to the cylinder. Another way you could do so would be to only turn the compressor on for a specified amount of time, but the problem with this would be the fact of how unreliable it would be in competition. |
Re: Program Pnuematics
Our team is also using Labview to program.
We had trouble in programming the pneumatics in the beginning too, because we were using the compressor start.vi and Compressor stop.vi for the compressor and the solenoid vis for the solenoid actuator. we weren't able to get those vis to work properly, so we just replaced the Compressor vis and the Solenoid vis with Digital Output vis- that way we were able to set them true or false using a constant. P.S.- we also used the Digital Input vis for the Pressure switch so the compressor turns off at ~115psi. |
Re: Program Pnuematics
Quote:
We will be programming in labview for the compressor control. If you could include some screen shots for guidance, that would be helpful. Lance |
Re: Program Pnuematics
4 Attachment(s)
Here are those screenshot examples. The autonomous certainly isn't complete. In Auto the robot will turn to face the target, then kick. Of course there won't be a ball there unless you do some more Auto work.
We have a page of screenshot examples from last year that might help some, but they haven't been updated to the 2010 style yet. We'll probably get to that this Sunday. |
Re: Program Pnuematics
Thanks Mark!
|
Re: Program Pnuematics
Thanks that helped. but there is no way to control the psi with labview?
|
Re: Program Pnuematics
There isn't any device that LabVIEW can control that adjusts the psi.
You can develop your own device, but some kind of device would be necessary. |
Re: Program Pnuematics
Your webpage is very helpful, Mark. Thanks. I'm forwarding to our programmers.
|
Re: Program Pnuematics
Mark,
In your telop example, is it necessary to reference Joystick 1 again and unbundle the buttons? Could you just use the other "Joystick Get" block that comes from the "Joystick Read" you have unbundled the axis off of? |
Re: Program Pnuematics
Sure.
I just wanted to emphasize how to access a joystick and keep the whole process as a somewhat isolated case. |
Re: Program Pnuematics
Mark,
We tried the compressor programming and were not able to get it to work. In trying to debug this, I need to understand more and I have some basic question about the setup in this 2010 Framework. From the screen shots, it looks like begin.vi has the initialization and operational functions for the compressor. Am I to understand that the compressor control (with feedback from the pressure switch and drive from the relay driver) is done completely within begin.vi? I would have thought that the solenoid control needs to be part of teleop.vi or some other recursive vi. Also, unbundling the buttons within the joystickget block is possible, but when I edit the block and then save the changes, the periphery of the joystickget block within the teleop.vi does not have the added buttons. What else needs to be modified within the joystickget block to enable the buttons being accessible on the block periphery? Thanks in advance. Lance |
Re: Program Pnuematics
Quote:
Quote:
|
Re: Program Pnuematics
Ok. Thanks for the help.
Unfortunately, the more magic that happens 'behind the scenes', the less one is able to understand how things work - especially for debug. I did open 'down' into each vi to try and understand what each was doing. Sometimes the vi's look a bit cryptic to the 'casual observer'. Thanks again. |
Re: Program Pnuematics
Quote:
I think how the "magic" works (Alan please correct this if wrong) is that when the compressor code is initialized in Begin vi, it sets up an event-driven task. This task is triggered by an external hardware interrupt. So for example, when the pressure sensor detects the compressor pressure has reached a certain level, the pressure sensor sends a discrete signal (perhaps by grounding the line) to one of the IO ports of the cRIO. This IO port is configured to sense this change and interrupt the cRIO processor and run the compressor task mentioned above. The compressor task asserts the cRIO IO that triggers the relay to shut off the compressor. When the pressure drops below min operating level, the pressure sensor sends another signal (perhaps by un-grounding the line) which generates another interrupt, which runs the compressor task again, which turns the compressor back on. What I've described above is sometimes referred to as "event-driven programming". You can see why there is no need to put any code in teleop vi, because the task is event-driven and does not need to be "called" periodically. The teleop vi is also a form of event-driven task, but in this case it is not driven by an external event but rather by an internal clock. Every 20 milliseconds an internal clock in the cRIO generates an interrupt which runs the teleop task one time. This is probably documented somewhere but I haven't found it yet. If my explanation here is redundant or incorrect I certainly welcome input. We haven't gotten to the compressor code yet so any info is appreciated. ~ |
Re: Program Pnuematics
Quote:
|
Re: Program Pnuematics
Quote:
Or for what you're really looking for, you'd have to attach a motor to a regulator and control the position of the servo/motor. |
Re: Program Pnuematics
Quote:
~ |
Re: Program Pnuematics
Welll - minor things like "not reading directions" contributed to our not getting the compressor code to work. It is working now after properly compiling (build) and loading into the cRIO (run as startup).
More code and integration of the hw/sw and in 8 or 9 weeks, we'll be done. ;) Thanks again for the help. |
Re: Program Pnuematics
I'm not magician responsible for the compressor code, but I'll take a pass at pulling back the curtains.
As mentioned, the compressor code is a bit more complex than most of the WPI code. This is because there were multiple authors writing modules, and each has their own personal style. On the one hand it means that there is a bit less consistency, but on the other, it means there are more samples to learn from. The compressor implementation in LV demonstrates how to kick off totally asynchronous tasks which communicate with both HW and other compressor API calls. The key to this approach is really in the Open VI. Provided there are no errors on input, the code allocates the DIO and Relay channels, creates two communication channel called RT FIFOs, Opens a reference to a reentrant VI, writes the I/O and FIFO refnums into the controls of the VI, and then invokes the Run method. Essentially pushing the Run button on the VI. Honestly this is probably overkill for a single compressor, but the code spawns an asynchronous task so that it could handle any number of compressors, each with their own communications channels, I/O refnums, and timing loop. Again, probably overkill, but not a bad pattern for more complex entities where you have an undetermined number of instances. To see what this spawned task does, double click on the static VI refnum, located towards the left of the diagram and looking like a document with a dog-ear tab and an alias/reference arrow. The double click will open the VI being spawned -- RunCompressor.vi. The VI loops, but blocks waiting for the enabled FIFO to be written to or for a half-second timeout. If not enabled, it ensures that the relay is off. If enabled, it checks the pressure switch on the DI, updates the relay appropriately, and publishes the latest relay state so the API call to give compressor state has the current value. The loop terminates when the I/O is closed elsewhere and goes invalid. The rest of the API updates the enabled FIFO, reads the relay state FIFO, etc. The important take-aways of this code are ... LV has a way to spawn any number of tasks, peek and poke values into the instance to act as parameters, block until completed or run asynchronously. LV has a more efficient and more controlled data sharing mechanism than the global variable. It isn't clear that this is actually necessary for FRC robotics, but if you want to move from soft realtime towards hard realtime, this is the sort of data sharing mechanism that enables precise control of the various loops, VI instances, and parallel code. To compare this approach to the other posts. The compressor could certainly be done in the FPGA. The FPGA would allow for polling at very high rates and would allow for a miniscule latency between the pressure switch transition and relay updates. Since there is really no need for this timing precision or loop rates, it would be relatively expensive in FPGA fabric for something that is easily done in other ways. Similarly, interrupts could be used to have small latency response, and might make sense for a small micro, but for an I/O rich environment, you quickly run out of interrupt lines to directly tie to a switch. Again, a relatively precious resource for a task which doesn't necessarily need it. I hope this was clear, but if not, please ask followup questions. Greg McKaskle |
Re: Program Pnuematics
4 Attachment(s)
Quote:
|
Re: Program Pnuematics
Error 8 indicates you a problem with file permissions. While building the executable, LV was unable to create directories or save files into those directories because the account you are logged in as cannot write in that location.
Check to see that you are logged in as who you intended. Have you made changes to the Build Spec that would ask it to write to a particular file location? As a check, try creating a new project from the getting started window saved to a new location. See if that builds and deploys. If you are wondering about an error code coming from one of the tools in LV, the Help>>Explain Error dialog is often useful for giving a bit more info for the numerical codes. I wish the build system handled those more gracefully. Greg McKaskle |
Re: Program Pnuematics
Quote:
Anyway, the picture of the error message is just the part that says there was an error. The part that tells what the error actually was is not visible in what you posted, though it hints at a file permission issue. Please copy and paste the full details of the error message so we can try to help you. |
Re: Program Pnuematics
Okay, thanks for the help i looked up the error that helped lol... Doing that didn't even cross my mind..::ouch::
|
Re: Program Pnuematics
Quote:
|
Re: Program Pnuematics
That example of mine is for a single solenoid.
If you want to use two different buttons to kick and retract here is an example of a double solenoid. That other example can also be a single button by just using a boolean "NOT" on one side. You can also do a timed set of actions with a state machine: Trigger the kick with a button and save the time to check, check the time until you retract, then enable kicking again. |
Re: Program Pnuematics
3 Attachment(s)
Ok I cant seem to get why my compressor wont turn on. I followed almost every single example and nothing turns on. What I dont get is why the relay wont turn on....
Heres my code if what I said doesn't make sense. |
| All times are GMT -5. The time now is 11:25. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2017, Jelsoft Enterprises Ltd.
Copyright © Chief Delphi