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
 

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.

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.

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
 

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.


~

Re: Program Pnuematics
 

I don't have the detailed understanding of the system to be able to give a confident answer, but I thought the compressor control was essentially a hardware task, handled entirely by the FPGA.

Re: Program Pnuematics
 

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.

Re: Program Pnuematics
 

Aha. Thanks. I hadn't thought of that. If I ever find some docs I'll post links here.


~

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