Having diffculties understanding the concept of arbitration ID

[LV]

I am having diffculties understanding the concept of arbitration ID. Not the
part of how message collision is avoided, but the part regarding it's
contents specification. Is it a fixed value indicating the sender's ID? Is
it part of the message proper so I can change part of the ID to indicate
changes in my message?

can someone point me to a tutotial in NI or to example messages?
Yes, I know it's an open standard, so I can specify pretty much whatever I
want, but still I need to see some examples.

Thanks

LV

[dhuff]

First of all, the type of High Layer Protocol (HLP) you are using will define what is in the arbitration ID.
Some protocols, like J1939 have a definition for parts of the Arbitration ID, such as Senders CAN address, Destination Address, priority, and Data Page (what message subset is it.)
Other protocols like CANopen do not nessarily have the senders address or destination in the Arbitration ID. They instead have a system internal to the controller that knows that any message with a certain ID is important, and messages that don't match are ignored.

If you reply with more details maybe I can be more specific.

check out the following link for more info:
<>

[LV]

I don't have a standard protocol that I have to stick to. But it would be
nice to be familiar with one like J1939. Is this standard publicly
available?
In my setup I have a "master" node (a Control PC) and slaves (nodes that
receive commands form the PC, act on them and return a status or data. None
of the slaves need to talk to another slave. All communications is initiated
on the Control PC, except for a "Is Alive" ir "heartbeat" message sent by
every slave every every 5 seconds.
What I wantead to do was, if possible to include the the master's ID and a
message ID (command) on the arbitration ID and use the data segment
precisely for dats and/or command status.

Is this possible?

Thanks
LV


"dhuff" wrote in message
news:50650000000500000025020
100-1042324653000@exchange.ni.com...
> First of all, the type of High Layer Protocol (HLP) you are using will
> define what is in the arbitration ID.
> Some protocols, like J1939 have a definition for parts of the
> Arbitration ID, such as Senders CAN address, Destination Address,
> priority, and Data Page (what message subset is it.)
> Other protocols like CANopen do not nessarily have the senders address
> or destination in the Arbitration ID. They instead have a system
> internal to the controller that knows that any message with a certain
> ID is important, and messages that don't match are ignored.
>
> If you reply with more details maybe I can be more specific.
>
> check out the following link for more info:
> <>

[dhuff]

If you don't have to follow a standard, invent your own. I would suggest reading all the information you can about CANopen, which is a master / slave protocol system, you can base your system on that.

I would start by making a list of what messages you need to send, and who sends them along with priority of message. Avoid using 0x000 and 0x7FF arbitration IDs (or 0x00000000 and 0x1FFFFFFF if you want 29 bit IDs) and make each node unique. You don't want 2 slaves trying to send the identical message to the master at the same time, assign messages to each individual slave if you can. Then start assigning numbers to them, remember that the lower numbers win CAN arbitration, so the lower the number, the highter the priority the message will have.
Then when you have that sorted out, you will end up with messages the master needs, and messages the slave nodes need or can ignore.
Some people try to make 1 version of software for both the slave and the master. (you use a set of switches, connectors, or Non-volatile memory flags to tell the node if it is a master or slave when it runs) Others will write 2 seperate versions of software, a file for only the master, and another one for only the slaves. Don't forget a way to tell each slave apart, if they all have the same slave code in them, then they need a serial number or set of switches to make each one unique.

J1939 (which is a standard available for a fee from Scociety of Automotive Engineers www.sae.org) is more of a peer to peer network. Some of the CANopen specs are avilable for free, but others may require paying for them.

Remember, this can be complicated stuff, but there are lots of people out there who have made it work (including myself)

[LV]

dhuff

You have no idea how incredibly useful your one-page comments were! I was
told that the arbitration ID was a fixed value for every node and that
messages and data had to be stuffed inthe data section of the message. It
seemed like a waste of space and an unfair way to distribute traffic since a
lower numbered node would always win the bus above others.

Lastly, any special keyword to search the J1939 standard. Many documents
appear under that name and at $49.00 a pop it's a little steep to try trial
and error searach.

Thanks

LV

[dhuff]

All of the major protocols will cost you to get the documents, that is how
they support the cost of the committees and publication.

Again, if you are inventing your own protocol, you really don't need to
follow J1939 or CANopen, they would require a lot of overhead and extra
work. You only need to follow one of the protocols if you connect to an
existing bus that uses a certain protocol.

I just found a link to a document which might help explain arbitration IDs
(CANopen based protocol), it was written by a CAN Automation company
<>
And speaking of CAN automation companies, if this all gets to be too much,
there are many companies out there (including the one I work fo
r,
www.distek.com) with experience in CAN to write code for you.

If you are really serious about using J1939, look for the J1939/21 Data Link
Layer document. It includes descriptions on ID's and sequences for lots of
special
conditions.

The cheapest solution might be to start looking at the examples and
documents that come with your NI-CAN system. The example code will show you
some hints about the arbitration ID.