Hi,
We have a compressor that will stop and start multiple times before reaching pressure.
Works fine on template code (Hatch Bot Example Code), so its not a wiring issue.
Lots of traffic on the CAN bus due to 20+ items on the bus. Were having loop overrun issues, but after turning off a heap of Smart dashboard writes, this seems to be under control. Were also having scheduler over runs at one point, but believe these are under control now. Is it CAN bus congestion or code loop overruns that will cause the compressor to stop pumping before pressure switch tells it to stop?
Also is there an easy way to restart a command group from the first command in the group if it hasn’t finished going through all of it commands yet?
Lastly, creating your own custom triggers, is the current WPIlib documentation on this up to date. There doesn’t seem to be a get() function in the base class that can be overridden as shown in the C++ example snippet.
Regards
Warren
In the driver station there is a log for CAN usage. I had to check this today for similar reasons actually. For a quick view you can also click the little lightning bolt tab on the driver station and it will show you can usage in that view.
I have also seen similar results caused by the pressure switch being located between the compressor and a too-tight bend in tubing, all upstream of the first storage tank.
I would recommend looking into CAN frame values, especially for CTRE devices. Our team faced the exact same issue when we got above ~15 CAN devices, and the robot became uncontrollable and the compressor was especially bad when we got up to 19 CTRE motor controllers, 4 CANcoders, and 3 solenoids on the CAN bus. Due to the fact that CTRE devices have priority over other devices, and motor controllers have priority over pneumatic controllers and compressors, if your CTRE devices are using too much of the CAN network, the CAN network will prioritize them over anything else, and it will cause the symptoms you are facing.
In order to see your CAN usage, the driver station logs has bad data this year, though this is a known issue. Just look near the average value if it’s an incredibly spiky line in the log file.
I would recommend looking into setting the CTRE status frame periods, which from my understanding is how often the controllers send information back to the RoboRIO. For talon SRXs and FXs, there are 16 status channels per motor controller, and most of them are likely unused by your code. When we set all channels on our motor controllers to 255ms, and only used low millisecond values (e.g. 20ms-50ms) on the channels we were actually reading from, it lowered our CAN utilization substantially and completely solved the issue. Commonly used values for CTRE controllers include the sensor value selected in the PID 0 loop on status 2 (which includes the FX internal sensor), quadrature sensor data on status 3, supply battery voltage on status 4, and pulse width sensor data on status 8.
Thanks WVGman,
This is exactly the information we need. The first thing I’ve got the coding team to do is make sure that they are not requesting info from a CAN device more then once in an execution cycle. (eg in subsystem periodic).
I’m still a bit un clear on CAN bus traffic.
So we have got 4 CAN coders sitting on top of 4 Swerve modules, that we only reading once at power on. Are you saying, even if we don’t read them again, they will still consume CAN bus utilization? Do we have to change the status period of these devices to help reduce traffic. I suppose the question is, are CAN devices constantly putting info on the CAN bus or are they only putting it on when you request it?
Regards
Warren
I hope that CTRE might consider doing some optimization in this area, since many more people are facing this CAN utilization issue due to the increased size of the REV power distribution hub and the use of encoders connected directly to the CAN bus (@ozrien?). Not sure if that’s possible with how the bus functions, but if it’s possible I hope it could get fixed.
And @warren.reynolds1, if you’re using LabVIEW i’m able to share my team’s code to correct this issue, just let me know!
Hi Joe,
No I haven’t tried using a lamda. We have only just moved across to c++, (a decision made to align with the Arduino programming our school does). In regards to using lamda’s, I’ve been teaching the students the long hand way. I know this bloats out the code because what can be done in a one line lamda requires an entire class definition + an instance of an object, etc, etc. But seeing as I struggle sometimes with lamda syntax myself, I’m not going to put code on the robot that students don’t understand if there is way to make it work using code the students can follow.
Having said all that, and going back to the original question, is there a get() function that I should be trying to override?
If someone could provide some example c++ code (both long hand and by using a lamda) that creates a trigger that fires if subSystemA::isLoaded() returns true, it would be greatly appreciated. Also where should the customer triggers be defined?
R718 *USB to CAN adapter permitted. Additional CAN bus connections may be added to the roboRIO using the CTR Electronics CANivoreTM P/N 21-678682 USB-to-CAN adapter. Any additional CAN bus added in this manner satisfies the requirements of R714 (i.e. you may connect motor controllers to this additional bus).
I barely understand lamdas in java let alone C++, but the frc-docs example seems pretty simple to copy and paste
If you take a step back, there’s probably other ways to do what you want without a custom trigger, for example having a command that ends when subSystemA::isLoaded returns true followed by the command you want to run.
So what percentage of CAN usage is considered “a lot”?
Our compressor stopped working after a reboot, and has not started working again. Our CAN bus is 35%-60% ish.
(We’re just getting into trouble-shooting the issue and have ruled out the pressure switch, but not the PDP or the compressor, but I figure I’d get a jump on this possibility with the question. Thanks!)
I think you’d be surprised what students can master given the opportunity. Lambda expressions are not that complicated - capture semantics are about the only tricky part.
Any additional