Plugin update for 2CAN

[ozrien]

An update has been made available at...
http://www.crosstheroadelectronics.com/2CAN.htm

It consists of new 2CAN Firmware (1.6) and a new plugin (FRC_2CANPlugin.out).

Symptoms fixed...

After deploying code for release there may have been a delay between the driverstation displaying "no code" and then "disabled". This delay could have been several seconds. The fix was basically adding a sleep() to the plugin, as well as elevating the priorities of the tasks (threads) used in communicating with the 2can. It also seems to have improved the performance of how quickly you can update Jaguar voltages.

All of this is committed and available at FirstForge's SVN server. However a release has not been placed in "File Releases" on the website. You can get the out file at the link mentioned above.

New Features...

User Manual 1.3 has the specifics but basically the LED states have changed. When 2CAN boots it blinks red. When the plugin loads in the cRIO it sends heartbeats to the 2CAN which will cause it's led to become solid orange (this distinguishes from bootloader's orange blink). When the plugin starts transmitting CAN (robot enabled or user code getting voltage/temp/etc...) the 2CAN blinks green. Furthermore if there is a problem with CAN (bad cable/missing termination resistors) the 2CAN blinks red/green instead of green.

The webdashboard has a new status line to indicate in colored text everything mentioned above.

In order for the LED states to function correctly you need to use latest plugin(dated 1/30/2010) and latest firmware (1.6).

Labview...

It appears that requesting firmware version will always return an error code. The specifics as to why are explained below. As a workaround for now I would recommend removing the call to the VI that checks Jaguar firmware version. Of course be sure that your Jaguar firmware is up to date (at the time of writing that would be v87).

The culprit of the -52007 issue is that the wrong CAN frame is sent to fetch the firmware version of a connected Jaguar. The frame should be 29 bit extended and remote but instead its just 29 bit extended (I confirmed with a CAN tool that this is the case). This is because the plugin interface has no options for the caller (CANJaguar/Labview/etc...) to specify remote vs non remote. This can be fixed a couple ways, I can modify the firmware in 2can to treat these messages special (i can check the arbid ) but it might be better to modify the plugin interface so that in future teams can expand to using other modules that require remote frames. Either way another update will be on the way soon.

One final note...

It seems that the labview voltage example is written in such a way where if any single CAN transaction fails (timeout occurs before Jaguar responds) the entire Labview application stops. This is different than the C++ example where the code continues attempting to drive motors regardless if one transaction fails. Although failing immediately was great for catching this bug, I should point out that loose connection can also cause the voltage example to "give up", so those of you using LabView may want to change this behavior. I primarily tested the voltage example so the other example VIs might be different. I haven't tried the Position example yet (look forward to it!). Also I do not claim to be a Labview expert so perhaps when deployed the application restarts? Anyway just thought I should mentioned what I observed.

Next update...
I plan to permanently resolve the request firmware bug in the next update (likely by end of next week). In the meantime I will be regression testing against the various close loop modes of the Jaguar in C++/Java/Labview.

I hope your build season is going well and good luck!