FAQ.zip_canopen

1) Will the CAN interface card likely be installed as a COM port? 2) How do I break up a message to be sent as separate frames? What about assembling data from multiple frames received into one message? Is this a valid concern? 3) What is the CANopen stack? If I already have an API for communicating with serial ports, can I have my program read/send CANopen messages without the CANopen stack? What exactly does my program have to do? 4) What is the ideal/correct way of implementing the object-dictionary in software? 1. that depends on your interface card. But most likely, it won't be a COM port but you'll get a dll which has exported functions to access the card (most available CAN interfaces are connected via the USB port to your PC). But don't worry: even though it's not an official standard, most of those dlls use the same functions so that you can exchange your CAN interface with another from another manufacturer with no problems. 2. It's very uncommon to send so much data over the CAN bus that you have to split them up into multiple frames. But if you absolutely have to, then you have to d o that yourself. 3. A CANOpen stack is a library which provides higher-level functions for you to use. It takes care of everything CANOpen requires (e.g., heartbeat) so you don't have to do it yourself. A good stack also takes care of multiple frames (2). Unfortunately, such stacks are not available for cheap, but IMHO they're worth it. 4. Most implementations use a struct, either in ROM or RAM, depending on whether the OD can be modified or not. But a good CANOpen stack also takes already care of this for you. Q: When and why would I need a higher-layer protocol such as CANopen® instead of plain CAN? A: CAN by itself only provides a method of exchanging up to 8 data bytes using message frames that have an identifier. Once you sit down and specify which identifier is used for which purpose - and what the contents of each message means (data types, byte order, variables) you are already starting to specify your own higher-layer protocol. As soon as a certain number of nodes, messages and network variables are involved, an in-house specification of that higher-layer protocol needs to be written and maintained. With CANopen® all of that work has already been done. Instead of re-inventing existing technology, engineers can take advantage of CANopen® and adopt existing technology. Due to the "openness" of CANopen®, it is even possible to pick and select the features required by an application and skip the unwanted ones. CANopen® literally reduces an in-house specification to a document that states which features of CANopen® are used. Most commercial CANopen® source codes support the selection of features via "#define" statements in the source code. If you are not yet certain if you want to use CANopen® or implement an in-house higher-layer protocol, consider using www.MicroMessaging.com or www.MicroCANopen.com instead.