Thread: Plugin update for 2CAN
View Single Post
  #4   Spotlight this post!  
Unread 01-02-2010, 16:26
jhersh jhersh is offline
National Instruments
AKA: Joe Hershberger
FRC #2468 (Appreciate)
Team Role: Mentor
  
Join Date: May 2008
Rookie Year: 1997
Location: Austin, TX
Posts: 1,006
jhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond reputejhersh has a reputation beyond repute
Re: Plugin update for 2CAN
Quote:
Originally Posted by ozrien View Post
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.

Quote:
Originally Posted by ozrien View Post
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
Reply With Quote