Plugin update for 2CAN

[ozrien]

A new plugin has been released for the 2CAN. This addresses the issue where the plugin had to be added at the end of the startup dll list in ni-rt.ini. Now the procedure is identical to installing the FRC_BlackJagBridgePlugin. Place the out file immediately after FRC_NetworkCommunications.

Symptom that should be fixed:
Labview/C++/Java examples from first forge returning error -52010(in console output and error output in VIs)

Testing with latest Labview example from firstforge still appears to be returning error code -52007. We are working with Joe Hershberger(NI) to resolve this as soon as possible. However the latest C++ and Java examples from firstforge should work.

New User manual (1.2) and out file can be downloaded at...
http://www.crosstheroadelectronics.com/2CAN.htm

Labview/C++/Java using CAN plugins should be downloaded at firstforge.

C++ implementation of 2CAN plugin is also on firstforge but a release has not been placed in "File Releases" yet.

Upcoming Fixes...
-Functioning Labview support
-New LED state for 2CAN when plugin is loaded, but cRIO team application is not yet running (this has been requested in several places on CD).
-Will change LED states in 2CAN to better differentiate between bootloader blink and normal blink(robot is disabled/off/plugin not loaded). Currently both are an orange blink.

We apologize for these delays. The specifics on implementing a CAN plugin were released just prior to kickoff and we are reacting as diligently as possible. As a team mentor I understand the importance of having these tools function in a timely manner. I hope the diagnostic features of the 2CAN have been beneficial in the interim.

[Jon236]

A couple of questions:

1. Time frame for working Labview code (still getting -52007)
2. How are the PID constants set using LabView and the 2CAN?

Thanks for all the hard work!

[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!

[jhersh]

Originally Posted by ozrien

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.

It seems that the Black Jag bridge sets the remote bit automatically. Call me and we can discuss the interface change to specify remote frames.

Originally Posted by ozrien

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.

That's true... this example is more meant to test the features than to be a forgiving robot program. The "CANJaguar for LabVIEW/RobotDrive Robot Project" shows a standard robot program much more similar to the Voltage Mode example in C++. Sorry for the confusing naming of the examples across languages. My bad.

-Joe