This morning, we set out to get the compressor running.
Our electronics guys wired up the compressor, and I “wired up” the program. It didn’t work. So I re-did the program a few times, and then we ran some sample compressor programs… they couldn’t run the compressor either. The mentor that I was working with was convinced that we have to write the compressor logic on our own, but we decided we should check to see if we have a relay problem first. At that point I found the logic in the WPI Compressor library, and we decided that it’s another issue altogether.
Turns out, the compressor VI wanted the compressor to be on, but the sidecar just doesn’t want to flip that relay. We tried it on slot 4 and slot 6, and we tried 3 different sidecars.
Yes, the PWMs work flawlessly, and the digital input works. I’d hope a low battery wasn’t to blame, we were running at about 12.3 volts.
I haven’t checked the diagnostics tab specifically for relay errors, I didn’t know those were displayed… I’ll do that on Monday, but from what I recall, the errors there were all camera related.
I didn’t check the electronics too much, but I recall there being 3 LEDs lit… I’ll look into that a bit more on Monday.
That’s actually the check we were doing. When we changed the relay values, no LEDs came on.
From the list you gave me… well, it points right to the code. We got power. We got PWMs. We got DIO… but we used the sample programs, and that still didn’t work. We tried “Compressor With Cylinder.vi” and “Solenoid With Compressor.vi” and “Relay Example.vi” and yes, we did configure them properly when we ran them.
Thanks for all the hints so far, everyone… it’s really a huge help, we were pulling our hair out.
If you have wired the compressor correctly, it is powered via a spike (powered by a dedicated 20A circuit breaker from the power distribution board) and the spike’s fuse has been replaced by a 20A circuit breaker IAW <R60> part F.
It is possible that
One of the two circuit breakers as bad.
The pressure switch has a bad connection somewhere.
The current draw from the compresser is too high (bad compressor or shorted wiring).
I really do not think that could be a software issue but I’ll defer that issue to others.
Well we found the underlying issue of that, too. The watchdog timed out - it was software.
We put the light on for the first time, the bracket just got it, and we noticed that the light turned off every time the compressor turned off. Then the diagnostics tab told us the rest of the story.
So now, the new issue, WHY is our watchdog timing out?
It was originally hard wired, and we thought maybe we might have more luck wireless. Same thing. We tried it with the default robot project, no changes at all, and we tried sevral examples. It always did the same thing. We thought maybe the program was timing out because we didn’t have a camera on there and the request wasn’t going through, but then we attached that and nothing changed at all.
Make sure you have installed the latest driver station and labview updates from www.ni.com/first.
These updates have resolved some of the watchdog issues.
Here is my very broad understanding of watchdog issues at the moment. Each time the watchdog encounters an error it pauses your code running on the crio (watchdogs want to stop the machine from hurting itself if there is an error). If you call something in teleop.vi that is not opened in Begin.vi the whole control system will “pulse” in between pauses for example.
The update addressed this by making the watchdog ignore smaller errors. Ignore more small errors and you will have less watchdog errors. If you do something to cause a more “major” error you will still see watchdog timeouts.
Again, people who really know what the watchdog does are likely to wince at my explaination but it boils down to
-make sure the update is installed.
-make sure you have error free vis.
I think there was a “watchdog for beginners” explaination thread somewhere on the boards today …
We had the update installed on the laptop being used, but for good measure we installed them on the driver station pc as well. Then we imaged the cRIO from the driver station and deployed the unmodified default FRC project.
Everything was as fresh as possible. And we STILL couldn’t get it working.
We think it may be hardware, because with some testing, it seems we don’t get watchdog errors when we unplug the digital sidecar.
I got to the school at 10 am and I left at 7 with this issue still unresolved.
Yep, it was a bare sidecar connected to power, the cRIO, and the status light. And we also tried it without the status light.
We didn’t try a new power cable, but I doubt that’s the issue because we checked all the connections with a multimeter and it read the same as any other connection - the same exact voltage of the battery. And I don’t think shorts can be that intermittent, while at semi-regular intervals… we’ll try it tonight, anyways, though.
I know this is a shot in the dark, but we are having very similar problems, so I thought I would throw in my $.02.
By any chance are you running your compressor code in the timed loop section, either 10ms or 100ms?
If so, by any chance is the camera not currently hooked up?
Here is why I ask.
In the past we have had lots of trouble when our camera cable had come unplugged and we had a lot of robot code that was included in the same loop. The huge amount of load placed on the system with bad or no data from the camera prevented the rest of the code from completing. What I am wondering is if the same thing is happening now. We currently do not have our camera plugged in, but the code is still running. The vision code runs in the same “Frame” as the periodic loops. Could the camera errors be preventing the periodic loops from updating the output to the relay controlling the compressor?
I will be investigating this around 4:30pm PST today.
OK, the camera was not the problem, but our code was. We now have it working!
The root cause was that we had set the relay definition as “Forward Only” in the Begin.vi. Changing it to “Both Directions” did the trick.