Again, thanks for answering my previous question.
My knowledge about CAN bus is less than 4 weeks old. It is growing, but there are these gaps where outside assistance is needed.
Here is my real world scenario.
Our CAN bus network uses NMEA 2000 protocol for control and instrumentation for maritime use. Engineering has decided to use CCP v2.1 in the ECUs and I am to develop the PC tool to interface with the ECUs. NMEA 2000 and CCP v2.1 are upper protocols of CAN bus. Will this configuration work? Is there any drawback to this scenario? Or is this a stupid question?
Follow Up Question
Re: Follow Up Question
Hello tj_40071,
it is not quite clear if your tool has to do with both protocols at a time. Do you have to transport data from one protocol to another? Nevertheless, the base of all is CAN, as you already said, and, since higher protocols use normally different ways for handshaking and/or data transport, they are able to coexist within the same CAN network.
CCP defines only a peer-to-peer communication which uses two CAN IDs (two 11-bits standard or two 29-bits extended IDs) for the communication, one for each direction, sending each time a maximal of 8 data bytes (as the underlying CAN).
NMEA 2000 ( based on the J1939 protocol, which is itself based on CAN, of course) in the other hand can handle large messages (1785 bytes at a time) and for this it defines a complex method for message packaging and node addressing, allowing nodes in a network to communicate in a peer-to-peer or in a broadcast form. The protocol use extended Identifiers for coding in it the source and destination addresses, the PGN (parameter group number) identifying the content of the message and some other information.
By the way, there are not stupid questions. There are many CAN based protocols which are itself base of other higher protocols. For this reason, in some cases it is possible that some drawback can appear. But in your case I think is not a problem.
As conclusion and to respond to your actually questions:
I wish you good luck with your project and have fun by learning CAN.
it is not quite clear if your tool has to do with both protocols at a time. Do you have to transport data from one protocol to another? Nevertheless, the base of all is CAN, as you already said, and, since higher protocols use normally different ways for handshaking and/or data transport, they are able to coexist within the same CAN network.
CCP defines only a peer-to-peer communication which uses two CAN IDs (two 11-bits standard or two 29-bits extended IDs) for the communication, one for each direction, sending each time a maximal of 8 data bytes (as the underlying CAN).
NMEA 2000 ( based on the J1939 protocol, which is itself based on CAN, of course) in the other hand can handle large messages (1785 bytes at a time) and for this it defines a complex method for message packaging and node addressing, allowing nodes in a network to communicate in a peer-to-peer or in a broadcast form. The protocol use extended Identifiers for coding in it the source and destination addresses, the PGN (parameter group number) identifying the content of the message and some other information.
By the way, there are not stupid questions. There are many CAN based protocols which are itself base of other higher protocols. For this reason, in some cases it is possible that some drawback can appear. But in your case I think is not a problem.
As conclusion and to respond to your actually questions:
Yes, it should work without problems. Since NMEA 2000 uses only extended ids, keeping the CCP CRO/DTO Ids with standard Ids avoid any collision problems between the protocols.tj_40071 wrote:Will this configuration work?
Only if the Ids for CCP packages are defined as extended and when these can reflect any NMEA 2000 Id that can appear in the network in a given time.tj_40071 wrote:Is there any drawback to this scenario?
I wish you good luck with your project and have fun by learning CAN.
Best regards,
Keneth
Keneth
Re: Follow Up Question
Do you have to transport data from one protocol to another? No, I am only doing CCP master/slave communications. NMEA 2000 communications to my project is background chatter.
When I started looking into CCP v.2.1 support I was stymied every direction I went. Finding your company and its support for CCP was like finding a needle in a haystack. You put everything up front and your documentation/support is outstanding.
I am familiar with one of the United State distributors, Grid Connect. I bought a USB Serial Device from them. Very good company.
Thanks.
When I started looking into CCP v.2.1 support I was stymied every direction I went. Finding your company and its support for CCP was like finding a needle in a haystack. You put everything up front and your documentation/support is outstanding.
I am familiar with one of the United State distributors, Grid Connect. I bought a USB Serial Device from them. Very good company.
Thanks.
Re: Follow Up Question
Hello,
By the way, if you want to share any code, file, or anything that could help other people to start with the API, feel free to contact us as well, or put the information here in the forum. I'm sure other people will be glad to find help on this point.
Yes you're right. There is no much information about this and other protocols out there. Even the official documentation for it is a little difficult to follow.tj_40071 wrote:When I started looking into CCP v.2.1 support I was stymied every direction I went
Thanks for the compliments. We try to document things as simple as possible. If you have any comment about the API use, please don't hesitate to contact us.tj_40071 wrote: You put everything up front and your documentation/support is outstanding
By the way, if you want to share any code, file, or anything that could help other people to start with the API, feel free to contact us as well, or put the information here in the forum. I'm sure other people will be glad to find help on this point.
Best regards,
Keneth
Keneth