Basics about defining identifiers in CAN bus.

[gjmaeda]

  I got an vehicle that was used as an experimental platform,
  with several sensors and motors, all connected to servo controllers that
  talk to each other by CAN.

  I do not have any documentation about the machine concerning
  CAN and I am new to CAN bus, but I have to restart/upgrade this machine.

  Up to now I could connect a CAN card and read some random
  messages on the bus (just by turning the controller on). However, I
do not know the meaning of the messages, and although I have their
identifiers, I do not have a map between identifiers and nodes.

  Thus, my questions:

  1. How can I know the relation between the CAN ID and the
  sensor sending the message? Is there a possibility that the
identifier I see in my messages now were programmed by previous
engineers? (should I assume they recorded the identifier in some eprom
or  set it physically with jumpers?)

  2. Also, if I want to send, for example, 5V to motor A , how can I
set one identifier
  that say "this frame contains voltage for motor A"? And how can the
motor A understand the message is for him?

  Thank you. Any help is appreciated.
--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-owner@...>

[Ron-114]

Without any documention it could be a challenge unless all the
modules are commercially available and you can find them online
somewhere. Do you have the software for each module? If so you
should be able to use that.


Ron

www.emicros.com

>   I got an vehicle that was used as an experimental platform,
>   with several sensors and motors, all connected to servo controllers that
>   talk to each other by CAN.
>
>   I do not have any documentation about the machine concerning
>   CAN and I am new to CAN bus, but I have to restart/upgrade this machine.
>
>   Up to now I could connect a CAN card and read some random
>   messages on the bus (just by turning the controller on). However, I
> do not know the meaning of the messages, and although I have their
> identifiers, I do not have a map between identifiers and nodes.
>
>   Thus, my questions:
>
>   1. How can I know the relation between the CAN ID and the
>   sensor sending the message? Is there a possibility that the
> identifier I see in my messages now were programmed by previous
> engineers? (should I assume they recorded the identifier in some eprom
> or  set it physically with jumpers?)
>
>   2. Also, if I want to send, for example, 5V to motor A , how can I
> set one identifier
>   that say "this frame contains voltage for motor A"? And how can the
> motor A understand the message is for him?
>
>   Thank you. Any help is appreciated.
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector-informatik.com/canlist/
> Report any problems to <canlist-owner@...>
>

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-owner@...>

[Allen Pothoof]

Some parts of this message have been removed. Learn more about Nabble's security policy.

As has been said before, if these are commercial modules, get in touch with the company, or at least the sales rep, and get manuals.  At the very least, find out which high-level protocol they adhere to (commercial modules have to work to a standard for interoperability reasons but it may be an "internal standard" if they aren't intended to work with other suppliers controls).
 
If the modules were developed "in-house" (and, although you haven't said, I do understand that this might be someone's "class project"), the first thing you need to do is go to the head of the project and complain.  This won't help *you* but for the documentation to have been lost shouldn't happen; for it to have not been developed in the first place would be inexcusable!  People need to know that this is unacceptable and not to be allowed (not even by, maybe ESPECIALLY not by, students).
 
But you're stuck with what you have so let's see if we can help.
 
The identifiers were undoubtedly programmed by previous engineers, either the manufacturer or whoever developed it in-house.  Is it in EEPROM?  Maybe but I probably wouldn't look for it there; it's likely within the code.
 
Do you have access to the source code?  I'm assuming no, certainly not for commercial modules.  But, if they were developed in-house, and you can get your hands on it, you just became a maintenance programmer: analyze the code, figure out the protocol (perhaps easier said than done, particularly decoding identifiers) and you're done.  Piece of cake.
 
That's the easy way.  No source code, no manuals, we do it the hard way.
 
Get a "bus sniffer", a module that sets on the bus, acts like a silent node and allows you to record bus traffic (sounds like you already have one).  Turn on each module separately and record the traffic.  Manipulate the module (turn buttons, twist knobs, whatever), if you can, and see if the messages change.  If you are lucky, analysis of the bus traffic will allow you to match action with identifier with data.  Now start turning combinations of the modules and try again; now you're looking for who sends and who responds so you can tie identifiers with modules.
 
This is time-consuming, error-prone and will likely be incomplete but its what you have to do in the worst case.  The worst of the worst case is when the modules don't have user-interface and everything is done over the bus but, guess what, that means there is (or was! and pray that it still exists) a controller program that was (probably, you hope) developed in-house and you can get your hands on it.  Hopefully, that means source-code and you're back to the easy way.  If all you find is an executable (inexcusable!  Someone needs to be fired or flunked), you are out of luck.  Don't even try to reverse-engineer the code from an executable; unless you have experience and are reasonably good at it, it will take longer and cost more than starting from scratch with a green-field project.
 
I hope this has been some small help.  I have been in similar situations myself and it is my nightmare.
 
Regards,
Allen Pothoof
 

> Date: Thu, 24 Sep 2009 20:10:07 +1000
> Subject: [CANLIST] Basics about defining identifiers in CAN bus.
> From: gjmaeda@...
> To: canlist@...
>
> I got an vehicle that was used as an experimental platform,
> with several sensors and motors, all connected to servo controllers that
> talk to each other by CAN.
>
> I do not have any documentation about the machine concerning
> CAN and I am new to CAN bus, but I have to restart/upgrade this machine.
>
> Up to now I could connect a CAN card and read some random
> messages on the bus (just by turning the controller on). However, I
> do not know the meaning of the messages, and although I have their
> identifiers, I do not have a map between identifiers and nodes.
>
> Thus, my questions:
>
> 1. How can I know the relation between the CAN ID and the
> sensor sending the message? Is there a possibility that the
> identifier I see in my messages now were programmed by previous
> engineers? (should I assume they recorded the identifier in some eprom
> or set it physically with jumpers?)
>
> 2. Also, if I want to send, for example, 5V to motor A , how can I
> set one identifier
> that say "this frame contains voltage for motor A"? And how can the
> motor A understand the message is for him?
>
> Thank you. Any help is appreciated.
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector-informatik.com/canlist/
> Report any problems to <canlist-owner@...>

---

Microsoft brings you a new way to search the web. Try Bing™ now

[gjmaeda]

Ron and Allen thank you for your answers.

I do have the source code, but this source code was not using all the
functionality of the machine (some sensors and motors were not being
used by the program, but they are physically installed in the
machine).
I found just some parts of code that have a CAN frame with some
identifiers written there, although it does not say what such
identifier really identify.

However, I know there are more sensors and motors than the number of
identifiers written in the code. I was wondering, how is it possible
for me to define my own identifiers? Can a CAN identifier be
programmed as I wish?

Thank you.


On Fri, Sep 25, 2009 at 5:07 AM, Allen Pothoof <apothoof@...> wrote:

> As has been said before, if these are commercial modules, get in touch with
> the company, or at least the sales rep, and get manuals.  At the very least,
> find out which high-level protocol they adhere to (commercial modules have
> to work to a standard for interoperability reasons but it may be an
> "internal standard" if they aren't intended to work with other suppliers
> controls).
>
> If the modules were developed "in-house" (and, although you haven't said, I
> do understand that this might be someone's "class project"), the first thing
> you need to do is go to the head of the project and complain.  This won't
> help *you* but for the documentation to have been lost shouldn't happen; for
> it to have not been developed in the first place would
> be inexcusable!  People need to know that this is unacceptable and not to be
> allowed (not even by, maybe ESPECIALLY not by, students).
>
> But you're stuck with what you have so let's see if we can help.
>
> The identifiers were undoubtedly programmed by previous engineers, either
> the manufacturer or whoever developed it in-house.  Is it in EEPROM?  Maybe
> but I probably wouldn't look for it there; it's likely within the code.
>
> Do you have access to the source code?  I'm assuming no, certainly not for
> commercial modules.  But, if they were developed in-house, and you can get
> your hands on it, you just became a maintenance programmer: analyze the
> code, figure out the protocol (perhaps easier said than done,
> particularly decoding identifiers) and you're done.  Piece of cake.
>
> That's the easy way.  No source code, no manuals, we do it the hard way.
>
> Get a "bus sniffer", a module that sets on the bus, acts like a silent node
> and allows you to record bus traffic (sounds like you already have one).
> Turn on each module separately and record the traffic.  Manipulate the
> module (turn buttons, twist knobs, whatever), if you can, and see if the
> messages change.  If you are lucky, analysis of the bus traffic will allow
> you to match action with identifier with data.  Now start turning
> combinations of the modules and try again; now you're looking for who sends
> and who responds so you can tie identifiers with modules.
>
> This is time-consuming, error-prone and will likely be incomplete but its
> what you have to do in the worst case.  The worst of the worst case is when
> the modules don't have user-interface and everything is done over the bus
> but, guess what, that means there is (or was! and pray that it still exists)
> a controller program that was (probably, you hope) developed in-house
> and you can get your hands on it.  Hopefully, that means source-code and
> you're back to the easy way.  If all you find is an executable
> (inexcusable!  Someone needs to be fired or flunked), you are out of luck.
> Don't even try to reverse-engineer the code from an executable; unless you
> have experience and are reasonably good at it, it will take longer and cost
> more than starting from scratch with a green-field project.
>
> I hope this has been some small help.  I have been in similar
> situations myself and it is my nightmare.
>
> Regards,
> Allen Pothoof
>
>> Date: Thu, 24 Sep 2009 20:10:07 +1000
>> Subject: [CANLIST] Basics about defining identifiers in CAN bus.
>> From: gjmaeda@...
>> To: canlist@...
>>
>> I got an vehicle that was used as an experimental platform,
>> with several sensors and motors, all connected to servo controllers that
>> talk to each other by CAN.
>>
>> I do not have any documentation about the machine concerning
>> CAN and I am new to CAN bus, but I have to restart/upgrade this machine.
>>
>> Up to now I could connect a CAN card and read some random
>> messages on the bus (just by turning the controller on). However, I
>> do not know the meaning of the messages, and although I have their
>> identifiers, I do not have a map between identifiers and nodes.
>>
>> Thus, my questions:
>>
>> 1. How can I know the relation between the CAN ID and the
>> sensor sending the message? Is there a possibility that the
>> identifier I see in my messages now were programmed by previous
>> engineers? (should I assume they recorded the identifier in some eprom
>> or set it physically with jumpers?)
>>
>> 2. Also, if I want to send, for example, 5V to motor A , how can I
>> set one identifier
>> that say "this frame contains voltage for motor A"? And how can the
>> motor A understand the message is for him?
>>
>> Thank you. Any help is appreciated.
>> --
>> Archives and useful links: http://groups.yahoo.com/group/CANbus
>> Subscribe and unsubscribe at www.vector-informatik.com/canlist/
>> Report any problems to <canlist-owner@...>
>
> ________________________________
> Microsoft brings you a new way to search the web. Try Bing™ now

--
Archives and useful links: http://groups.yahoo.com/group/CANbus
Subscribe and unsubscribe at www.vector-informatik.com/canlist/
Report any problems to <canlist-owner@...>

[Allen Pothoof]

Some parts of this message have been removed. Learn more about Nabble's security policy.

Can you define your own identifiers and program them as you wish?  Based on what you've said so far, I think the answer is no.
 
The controller and the sensor/actuator modules have to agree as to what an identifier means and what the data looks like (i.e. units and precision).
 
IF you have source code for BOTH controller and modules then, and only then, can you make up identifiers and data formats.  If all you have is the controller code and you add identifiers or change data formats, the modules "won't know what you're talking about"; they'll either ignore it or do something unexpected (and, given that this is a remote-controlled vehicle, probably dangerous).
 
As an aside, there have been whole threads here on developing HLPs and what to consider when creating identifiers.  Short answer is, don't do it if you can avoid it, there's a lot that goes into doing it right.
 
My advice at this point would be to take a close look at the identifiers and data formats that you do have and see if you can discern a pattern.
 
Regards,
Allen Pothoof
 

> Date: Fri, 25 Sep 2009 18:02:01 +1000
> Subject: Re: [CANLIST] Basics about defining identifiers in CAN bus.
> From: gjmaeda@...
> To: canlist@...
>
> Ron and Allen thank you for your answers.
>
> I do have the source code, but this source code was not using all the
> functionality of the machine (some sensors and motors were not being
> used by the program, but they are physically installed in the
> machine).
> I found just some parts of code that have a CAN frame with some
> identifiers written there, although it does not say what such
> identifier really identify.
>
> However, I know there are more sensors and motors than the number of
> identifiers written in the code. I was wondering, how is it possible
> for me to define my own identifiers? Can a CAN identifier be
> programmed as I wish?
>
> Thank you.
>
>
> On Fri, Sep 25, 2009 at 5:07 AM, Allen Pothoof <apothoof@...> wrote:
> > As has been said before, if these are commercial modules, get in touch with
> > the company, or at least the sales rep, and get manuals.  At the very least,
> > find out which high-level protocol they adhere to (commercial modules have
> > to work to a standard for interoperability reasons but it may be an
> > "internal standard" if they aren't intended to work with other suppliers
> > controls).
> >
> > If the modules were developed "in-house" (and, although you haven't said, I
> > do understand that this might be someone's "class project"), the first thing
> > you need to do is go to the head of the project and complain.  This won't
> > help *you* but for the documentation to have been lost shouldn't happen; for
> > it to have not been developed in the first place would
> > be inexcusable!  People need to know that this is unacceptable and not to be
> > allowed (not even by, maybe ESPECIALLY not by, students).
> >
> > But you're stuck with what you have so let's see if we can help.
> >
> > The identifiers were undoubtedly programmed by previous engineers, either
> > the manufacturer or whoever developed it in-house.  Is it in EEPROM?  Maybe
> > but I probably wouldn't look for it there; it's likely within the code.
> >
> > Do you have access to the source code?  I'm assuming no, certainly not for
> > commercial modules.  But, if they were developed in-house, and you can get
> > your hands on it, you just became a maintenance programmer: analyze the
> > code, figure out the protocol (perhaps easier said than done,
> > particularly decoding identifiers) and you're done.  Piece of cake.
> >
> > That's the easy way.  No source code, no manuals, we do it the hard way.
> >
> > Get a "bus sniffer", a module that sets on the bus, acts like a silent node
> > and allows you to record bus traffic (sounds like you already have one).
> > Turn on each module separately and record the traffic.  Manipulate the
> > module (turn buttons, twist knobs, whatever), if you can, and see if the
> > messages change.  If you are lucky, analysis of the bus traffic will allow
> > you to match action with identifier with data.  Now start turning
> > combinations of the modules and try again; now you're looking for who sends
> > and who responds so you can tie identifiers with modules.
> >
> > This is time-consuming, error-prone and will likely be incomplete but its
> > what you have to do in the worst case.  The worst of the worst case is when
> > the modules don't have user-interface and everything is done over the bus
> > but, guess what, that means there is (or was! and pray that it still exists)
> > a controller program that was (probably, you hope) developed in-house
> > and you can get your hands on it.  Hopefully, that means source-code and
> > you're back to the easy way.  If all you find is an executable
> > (inexcusable!  Someone needs to be fired or flunked), you are out of luck.
> > Don't even try to reverse-engineer the code from an executable; unless you
> > have experience and are reasonably good at it, it will take longer and cost
> > more than starting from scratch with a green-field project.
> >
> > I hope this has been some small help.  I have been in similar
> > situations myself and it is my nightmare.
> >
> > Regards,
> > Allen Pothoof
> >
> >> Date: Thu, 24 Sep 2009 20:10:07 +1000
> >> Subject: [CANLIST] Basics about defining identifiers in CAN bus.
> >> From: gjmaeda@...
> >> To: canlist@...
> >>
> >> I got an vehicle that was used as an experimental platform,
> >> with several sensors and motors, all connected to servo controllers that
> >> talk to each other by CAN.
> >>
> >> I do not have any documentation about the machine concerning
> >> CAN and I am new to CAN bus, but I have to restart/upgrade this machine.
> >>
> >> Up to now I could connect a CAN card and read some random
> >> messages on the bus (just by turning the controller on). However, I
> >> do not know the meaning of the messages, and although I have their
> >> identifiers, I do not have a map between identifiers and nodes.
> >>
> >> Thus, my questions:
> >>
> >> 1. How can I know the relation between the CAN ID and the
> >> sensor sending the message? Is there a possibility that the
> >> identifier I see in my messages now were programmed by previous
> >> engineers? (should I assume they recorded the identifier in some eprom
> >> or set it physically with jumpers?)
> >>
> >> 2. Also, if I want to send, for example, 5V to motor A , how can I
> >> set one identifier
> >> that say "this frame contains voltage for motor A"? And how can the
> >> motor A understand the message is for him?
> >>
> >> Thank you. Any help is appreciated.
> >> --
> >> Archives and useful links: http://groups.yahoo.com/group/CANbus
> >> Subscribe and unsubscribe at www.vector-informatik.com/canlist/
> >> Report any problems to <canlist-owner@...>
> >
> > ________________________________
> > Microsoft brings you a new way to search the web. Try Bing™ now
> --
> Archives and useful links: http://groups.yahoo.com/group/CANbus
> Subscribe and unsubscribe at www.vector-informatik.com/canlist/
> Report any problems to <canlist-owner@...>

---

Bing™ brings you maps, menus, and reviews organized in one place. Try it now.