[JasonStern]

Thank you for the information, feedback, and suggestions!

Originally Posted by Bryscus

...because the SYNC message is not destined for just one device, the device number should NOT be sent. It is a broadcast message, as you have shown below. This could cause some issues. I think my setting of the m_deviceNumber to zero before sending the SYNC message is still the best way to go. OR, one could modify setTransaction().

I haven't looked at the C code, but in Java m_deviceNumber is only used in setTransaction and not sendMessage. However, I didn't realize before that JaguarCANDriver.sendMessage is static (CANJaguar.sendMessage is not). Because the sync should be send to all devices, I recommend modifying syncUpdate to

public static void syncUpdate(short syncGroup){
        byte[] dataBuffer = new byte[8];
        dataBuffer[0] = (byte) syncGroup;
        JaguarCANDriver.sendMessage(CAN_MSGID_API_SYNC, dataBuffer, (byte) 1);
}

This removes any potential tie to the device id since you won't have to have created an object first and better matches how the CAN bus actually operates.

Originally Posted by imac256

For the syncronization program I am writing for my team in C++ I include every field so that my final message ID is this:

#define CAN_MSGID_MFR_BCAST         0x00000000    //Define the Broadcast manufacturer
//Define the Syncronization message Header
#define LM_API_SYNC       CAN_MSGID_DTYPE_BCAST | CAN_MSGID_MFR_BCAST| CAN_MSGID_API_SYNC

Thank you for the suggestion!

Originally Posted by Bryscus

1.) I'm not quite sure why you chose to make your LM_API_SYNC_GROUP_...(s) of type short and not byte.

Java doesn't have unsigned numbers and makes it tricky to interface with outside systems that do. Stepping up the variable size to the next level was partly force of habit and partly because the IDE was complaining otherwise. I agree the 'final' version should be using byte instead, but this code was written an hour before crating and I wanted something I knew would (should? ) work. :-)

Originally Posted by Bryscus

In public void setControlMode(), you disableControl as you should. Do you make sure you re-enable control? You should also set up your encoder references again just to be safe and probably the number of lines too (couldn't hurt).

I thought about this and decided it was better to re-enable control and perform the config outside of the method to avoid potential issues. This way, the setControlMode() method should be functionally equivalent to creating a new CANJaguar object.

Originally Posted by Bryscus

At this point, your code seems to look pretty good to me at least for switching modes.

You would think that, but it only worked a few times before stopping randomly and failing to work again!

Originally Posted by Bryscus

Anyway, I think these are your problems. I have not implemented these changes in C++ yet, but I do have the plan to do so. I'll email Joe Hershberger about these potential issues.

On a semi-related note, shouldn't the sync code be trusted as well? Otherwise I see a potential case where you define the set point when the robot is enabled, the robot then gets disabled, and then the sync command gets sent. Or am I missing something else that would prevent this from happening?

Originally Posted by Bryscus

What is the status of the LEDs when your system stops working?

I honestly couldn't tell you at this point. I know it worked a few times before stopping, but I was testing this an hour before shipping so everyone was breathing down my neck to give them back the robot . We have a spare cRio and I think we still have some old CIMs with encoders on them, so I will try to get the team to do some more testing before the competition on Thursday. (The joys of being in a first week regional. ) However, at this point it is more for my interest and to help the FIRST community than for us to put into production use. I gave guidance to our programmer to only operate in speed control mode using the current functionality due to the issues we experienced. It would have been nice if he was able to say "drive forward 10 feet" in autonomous mode, but I guess that is something to look forward to next year!