tags:

views:

541

answers:

2

This is continuation of the series of questions I have posted last week at http://stackoverflow.com/questions/423526/java-and-canopen.

Thank you, Matli, for having answered all my questions.

Current Situation

I have to write a Java program to interpret CANopen messages.
Due do certain circumstances, I am unable to get my hands on the CAN hardware.
I have a tight deadline to meet and in order to get started on my Java program quickly, I am hoping to make some assumptions with the help I can get here in StackOverflow.

Questions

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?


Many thanks,
Frustratedone

+1  A: 
  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 do 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.
Stefan
A: 

3) While a commercial CANopen stack is most certainly a good idea, it is still possible to read/send CANopen messages without using one.

We don't know what the purpose of your application is. But an example when you probably would be fine without a CANopen stack is if you already have a functioning CANopen bus with master and slave nodes and you just want to listen in on a particular message. Another example could be if you are writing a small configuration or test utility with a small and well defined set of messages being used. In such cases a full-blown commercial CANopen stack could be a lot of overkill.

matli