Does the rev PDH have adjustable periodic status frames?

[Tom_Line]

Just trying to squeeze every ounce of of the can bus.

[Sunny_Leveson]

If your trying to optimize canbus have you looked into a carnivore? CANivore

[Daltz3]

CANivore only works with CTRE devices.

[gerthworm]

please let the answer be yes please let the answer be yes…

[Sunny_Leveson]

Sure but it allows the creation of a second canbus network which if you put all the ctre stuff on it could reduce the load on the main network substantially

[Tom_Line]

We are borderline on our usage. We have

4 drive talon fx’s
4 steering neo 550’s
4 cancoders
1 intake falcon fx
1 indexer neo 550
2 shooter falcon fx
1 hood neo 550
1 turret neo 550
1 kickup falcon fx
1 pigeon
1 intake lift neo 550
1 climb falcon
1 climb neo 550
1 pdh
1 pcm

For 25 items on the bus. Driver station log file shows us averaging 90% usage and we are also seeing dropped data from our cancoders and motor encoders (returns zero when it doesn’t receive new data). We’ve mitigated most of the error messages through a strategy (return the last good value when a frame is dropped), but I’d like to move to not having errors at all.

We’ve moved all status frames to max. We’re removing the PCM. After our first competition we’ll be removing the intake and indexer from the bus and transitioning them to PWM. That will leave us slightly better than borderline - if we can adjust the PDH status frames that might move us from the ‘questionable’ to “ok” category on utilization.

@Greg_Needel , any chance the PDH status frames are configurable?

[Ryan_Blue]

Just a thought, and you might already be doing this, but could you adjust code so that motor set commands are only sent when the set point changes?

I.e.

if(requestedValue != prevValue) {
  motor.set(requestedValue);
  prevValue = requestedValue;
}

[Tom_Line]

It’s been a long time since I looked - but I believe you need to continue calling the motor sets or you’ll watchdog the motors. I could be wrong.

[Ryan_Blue]

You can disable the watchdog if you want, or feed it manually

[Tom_Line]

Huh. That’s an idea. I think when I get to robotics today I’ll try doing a blanket motor-set disable just to see what type of difference in can bus to see if it’s worth it. That would only take a second.

[Thad_House]

Doing that doesn’t help anyway. Because the CAN Heartbeats for all the existing motor controllers are sent as part of the control packets, the control packets have to be repeated over the bus anyway. So the control packets are going to go out anyway.

Note this could have changed in recent years, and also could change in future years, but based on the last time I looked at the control encryption this was how they all worked.

[Tom_Line]

I appreciate the suggestion, but rewiring the can bus isn’t something we have time for, and I’d like to avoid spending the money this year if possible. We already blew our robot budget with 12 swerve modules, and the last couple years haven’t exactly been sponsor friendly. The benefit is that we will use those swerve modules well into the future (assuming swerve friendly games).

[Tom_Line]

Darn. Thanks for the good info Thad.

[dyanoshak]

The PDH and PH status frames do not have adjustable periods at this time. We intend make them adjustable in the future but I don’t currently have a timeline.

[Jacob_C]

Couple of other points on improving can bus util (for CTRE devices):

• When setting status frame periods make sure you check the error code and try again if it’s non-zero. Your bus util with that selection of devices will be at or over 100% on boot so you may see timeouts in Begin.vi and need to try again until they succeed.

• Double-check you’re only calling config* routines once or on trigger and not accidentally calling them in a loop - they generate extra CAN traffic.

• As Thad mentioned, calling Set does not generate CAN traffic. HOWEVER, you can change the send period of the control frame as well as the status frame. By default this is 10ms so you can save quite a bit of bandwidth here. As long as you’re comfortable with the response time of your mechanism you’re probably OK changing this to 20ms on most controllers, and on followers you could set it as high as 50ms and likely be safe. Note the controller will timeout and disable if the control data hasn’t been received in over 100ms so I recommend 50ms as the absolute maximum for control frame periods.

[wrueter]

If I call a get function, say motor.getSelectedSensorVelocity(), will I generate CAN traffic? Asking because our code currently constantly updates SmartDashboard with data about the shooter motors, wondering if that could be causing more CAN traffic.

[Ryan_Blue]

No, devices constantly send status updates. The get functions just return the latest cached update.