Program Pnuematics

[thatoneguy23]

Thanks, Mark. We got it.

[Mark McLeod]

Originally Posted by thatoneguy23

Thanks, Mark. We got it.

The trouble with the example is that it is setup as a stand-alone program.
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.

[sparks-1784]

Originally Posted by Mark McLeod

The trouble with the example is that it is setup as a stand-alone program.
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.

Mark,

We will be programming in labview for the compressor control. If you could include some screen shots for guidance, that would be helpful.

Lance

[Mark McLeod]

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.

[sparks-1784]

Thanks Mark!

[Ozomalti]

Thanks that helped. but there is no way to control the psi with labview?

[Mark McLeod]

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.

[Homsar66]

Originally Posted by Ozomalti

Thanks that helped. but there is no way to control the psi with labview?

Sure. The longer the compressor is on, the higher the PSI!

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.

[PaW]

Your webpage is very helpful, Mark. Thanks. I'm forwarding to our programmers.

[Hadi379]

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?

[Mark McLeod]

Sure.
I just wanted to emphasize how to access a joystick and keep the whole process as a somewhat isolated case.

[sparks-1784]

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

[Alan Anderson]

Originally Posted by sparks-1784

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.

The actual control of the compressor relay is done in a separate task which gets created when you open the Compressor. It's magic that happens without any attention from the rest of the project.

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?

Delete the Joystick Get from the Teleop vi block diagram and add it back again. Then the new terminals will be noticed. You'll have to reconnect everything that was already wired.

[sparks-1784]

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.

[Ether]

Originally Posted by sparks-1784

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.

Our team is new to LabVIEW this year too.

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.


~