[Hugh Meyer]

Joe,

Your summary of the “Jag” situation is dead on. This is based on my experience from using CAN since FIRST allowed us to use it.

One aspect that you didn’t mention is the interface to the CRIO. There are two primary interfaces, the serial port on the CRIO which uses a serial converter within the jaguar to convert to CAN and the 2CAN device which is a bridge between Ethernet and CAN.

When we started out using CAN I said we would try the serial interface, mainly to save money. We like to log lots of data, so we were attempting to transfer lots of data both directions using 8 Jaguars. It wasn’t very long until we discovered that the system couldn’t keep up. Switching to the 2CAN increased throughput by at least a factor of 10. Even with the 2CAN we could still take longer to transfer what we wanted than our periodic loop in the main code would support.

As a work around we changed our periodic loop to 100 msec and multiplexed the logging data. As I recall we divided up the requests for data from the Jaguars into 2. One pass through our main loop we request data from half of the Jaguars, and the next time through we get the other half. This seems to work good enough. But we must keep a close eye on the delays to be sure the code run time does not take longer than the periodic loop.

We monitor the code run time by setting a digital output pin high at the start of our loop, setting it low at the end of the loop and a second pin is a toggle at the start of the loop. We monitor these signals with an oscilloscope to be sure the timing is what we expect.

The code does indeed block and waits for the communication to complete each cycle. This wastes most of the time just waiting. Based on our testing it always does this.

I think a simpler system where commands are sent without waiting for an ACK would be fine. This is done all the time with DMX control systems in the theatrical lighting industry and it works fine. That way we could send out data in sequence to all the Jaguars, then by the time we did that, the first one would be ready to respond again. I am hoping we see a change in this direction, but that is beyond our control.

This year our team is discussing using the Jaguar PID to close loop on speed, then use a slow loop around that for position with the CRIO. I think that would work well. Another approach we may try this year is to go back to PWM and make a separate thread for each loop in the CRIO. I really like the CAN and want to stick with it. The data we get back from the Jaguars is priceless to knowing what is going on.

As Allan mentioned the source code for the Jaguars is the way to find out what the PID implementation is doing.

I hope this has been clear. If not I will gladly expand if you have specific questions.

-Hugh