I'm using several MDL-BDC24 devices connected over CAN, with one of them acting as a bridge to RS232.
How long does it take to translate the RS232 message to CAN?
What is the typical time between a device receiving a CAN message and sending a reply?
Is there anything else I need to take into account (aside from message size and communication speed) when calculating how long a CAN command should take to be sent and executed?
Diffiult questions to answer. CAN and UART messages are handled in their respective interrupt handlers. However, both of these interrupts are configured as the lowest priority in the system. Latency will vary depending upon when these messages arrive relative to other events in the system triggering higher-priority interrupts.
Regarding the second question, the reply time will vary depending upon the command being issued. Not sure if I can state a "typical" value.
Is there a specific issue or problem that you are trying to address?
--Bobby
In reply to Bobby Bradford:
I have the RS232 connected to a NI cRIO, and I use a 3rd-party driver to format the data and arbitration ID to the message sent over RS232.
I found the communication was surprisingly slow (for example, it takes 15 ms to set the number of encoder lines, and 11ms to set the speed setpoint).
I'm trying to determine how much of that is due to the 3rd-party driver, to the RS232 communication, and how much is inherent in the CAN network itself.
In reply to Marshal Horn:
Marshall -
Please list the specific concerns you have here, for completeness.
I've been following your thread on Chief Delphi. Small world, eh?
The quick and completely unsatisfying answer I can give you is that we (NI & TI) are actively looking into it, but have not yet identified all of the causes.
There are a few changes scheduled to the `RIO's driver that should alleviate some things. We just want to be sure we know all the issues before claiming victory.
If you don't mind, I'd like to involve you in some of the Beta process this year. I mentor FRC in the September - December time frame, but haven't been able to contribute during actual build season for a few years, due to the time required as an FRC developer. This means I miss out on an unfortunate portion of the "actual user experience" - Teaching CAN on a white-board is a bit different than band-aiding a robot while queuing!
In reply to Eric Vanwyk:
Okay, here's something that would really help me reduce the amount of data I need to send. The most common thing I run into is that the Jaguar becomes disabled. Now, to actually detect it is disabled, I must check and rule out all other possibilities. (Is there communication? Are there any faults? Any limits?) And then I must get the current setpoint, and compare it to the value I last sent.
What would be extremely useful is a status message that tells whether the Jaguar is enabled or disabled. Perhaps this could be put in with another message (bit # 3 of fault condition?) to save communication time.
My goal is to have a fault-tolerant control system. If a Jaguar gets spontaneously disabled, it should be re-enabled. If something draws too much power too quickly and some Jaguars lose power, they should be reconfigured and re-enabled when they come back up. All this has fairly high requirements of the CAN communication compared to a simple project using only open-loop voltage control. (I use speed mode with synchronous update) However, I can do the high-level software as long as the hardware is capable. I've made numerous improvements to the canJag VIs, and at some point I need to join the repository at First Forge review those changes and make them available for everyone.
I'm more than happy to run tests. During the summer I usually have time to work with a robot at least 8 hours a day. During the rest of the year, it varies with homework load.
Eight hours a day to play with robots... sounds like a dream.
I've copied your notes here into the tracking database. Any suggestions are always welcome.
About my initial questions, could you give me a range of values? The Jaguars are the only CAN devices I have; I don't have a way of testing it. I understand that I can only make estimates with approximate data, but at the moment, I have no idea if it's capable of greater throughput. This will also help me make estimates about 2CAN.
The interrupts you refer to would be limits and faults, correct? Would they include encoders? At full speed, my 100 count encoders are going at 20,000 RPM, because we found it easiest to mount to the back shaft of the motor. For testing conditions, there's no need to replicate my outlandish setup (which is near the maximum speeds for the encoder AND the Jaguar), but perhaps speed mode, with a constant speed and no faults or limits, could be considered fairly normal operation.
For you conveniance, I've reposted the questions below:
Here's some things that were brought up in ChiefDelphi threads:
I found an issue that might be a little tougher to fix: Speed status is positive regardless of the encoder direction. When the encoder is turning backwards, it does not become negative.
Marshal Horn I have the RS232 connected to a NI cRIO, and I use a 3rd-party driver to format the data and arbitration ID to the message sent over RS232. I found the communication was surprisingly slow (for example, it takes 15 ms to set the number of encoder lines, and 11ms to set the speed setpoint). I'm trying to determine how much of that is due to the 3rd-party driver, to the RS232 communication, and how much is inherent in the CAN network itself.
Wouldn't it be option for you to work straight with CAN messages, thus using a CAN PC interface(be it USB-CAN, PCI-CAN, PCMCIA-CAN), instead of using a MDL-BDC24 to translate from RS232? This will also eliminate some communication overhead for that specific MDL-BDC24.
It’s been a few months now that I worked with the MDL-BDC module, I’m using it to control a fuel pump, which is controlled by an engine management, using PWM(I’ve changed the original servo motor control PWM firmware, so I can use a simple PWM signal running forward only), and use the CANbus to monitor the module only, works really good.
For your other questions, I should reopen the project and look into it, but at this point I can’t help very much as I only needed the PWM (voltage control) side to work, and a CAN message send periodically.
In reply to marc_rir:
Those options could work if I had a PCI bus on my controller. However, all I have is RS232, Ethernet, I2C, and SPI. There *is* an available option for ethernet, but I'm not confident that it will actually provide greater speeds, seeing as I don't have data on where the slowdown in the network is.
Oh, and I found a missing feature: Control Mode Status.