06-17-2015 08:51 AM
Hello All,
We are currently using Aeroviroment's ROS setup to try and automate our Battery Testing, with an NI-XNET card for the CAN messages, our computer’s Serial Port for ROS, and an ABC-150 testing apparatus. The problem comes in where our battery is sending debug messages too quickly for ROS to parse, and I was wondering what our options would be for setting up an intermediary to filter CAN messages between the Battery and ROS to keep communications to a more reasonable level. I understand I can set up a virtual CAN Port through NI-CAN that I might be able to get ROS to read, then real time filter what I recieve from the XNET card into the port, then try and funnel that into the ROS program, but since ROS communicates on the X-NET protocol, would it be wise, or even possible, to set up a fake XNET port to pass through the filtered signals? Or is working with NI-CAN or some other filtering solution my best bet?
06-18-2015 04:51 PM
Hello ProJoeSchmoe,
I am not sure I completely understand your problem statement. The issue seems to be that the ROS cannot parse\process the CAN message coming from the battery quickly enough. Therefore, what you are looking for is a system that would allow you to buffer incoming CAN messages and then send these CAN messages at a slower rate to the ROS? Is this correct?
Where does the NI-XNET card fit into this application? Are you currently using LabVIEW in conjunction with the NI-XNET card? If so, what version of LabVIEW are you using and what XNET hardware are you using?
Regards,
J_Bou
06-19-2015 05:18 AM
06-19-2015 07:27 AM
@JGruenberg: Thank you for the suggestion, will look into that.
@j_bou: You got the jist of it, but the main factor would be to filter out the Debug messages coming in at 10 millisecond cycles, as the rest of the messages are coming in a little more reasonable rate of once a second. LABVIEW is the 2014 Version with SP1, and the XNET card is a PCI-8512/2, if that helps. A fix from Aerovironment that was supposed to speed up the scan rate either didn't work or wasn't correctly configured to XNET, so I'm trying to poke at it from another angle.