CAN Bus with automatical bus termination

Hmmm... why do it on the module at all? Wouldn't it be a heck of a lot simpler to do termination as a dummy plug on the output connector, given you're already willing to spend plugs where a single one should do? Or, if you really have to, use an output jack with a switch in it that is operated by inserting a plug, like those headphone jacks that automatically switch off the main speakers usually found on boom-boxes and notebooks.

Conceptually, termination is a feature of the *bus*, not of the individual node, so IMHO it should be handled by mechanical design of the cabling. A terminator on the node, whether controlled by a DIP switch or a CAN command, can only ever be a second-best method.

And that's before you start considering that CAN is a bus without a physically preferred direction of travel, so your node can't really know which of its two plugs is the "input" and which the "output". Or that you would have to actually *disconnect* the cable on the "output" side for your trick with electronically controlled termination inside the node to work --- otherwise the (still active) terminators of the other nodes further down the bus would cause no end of troubles. Now, what if the node is plugged in "backwards", i.e. the cable leading to the master, which you called "input", happens to be plugged into the "output" socket? A guaranteed non-working system.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Thanks for your answer!

Some more informations:

1. The input and output connectors have to be different types to avoid illegal connecting the plugs.

1. If the switch is in boot-up position, the bus termination is enabled _and_ the CAN output connector ist disconnected (toggle switch). So the termination of the next module will not give some troubles.

An other motivation for this idea is the information of module position inside the CAN bus I'll be able to detect. In my application I should find out which module is next of CANopen master (#1), which is after that (#2) and which is the last module (#n). Otherwise each module has to be configure manually (present solution non user-friendly).

Thats also a good idea! But I need an industrial connector and I've never seen any with switch in it...

I now, a really disadvantage is the non standard of my idea! :-( But I'm searching for a user-friendly solution for the themes 'bus termination' and 'order of modules'!

Thanks very much!

Markus

Not necessarily.

IIRC, CANopen is supposed to be using software protocols to handle node address assignment instead. Assigning node numbers by cable positions seems like the wrong thing to do. It links two design decisions (cable routing and CAN node numbering) together which should really be independent of each other, thus reducing your flexibility.

If you need a method to select a given CAN node by its function, give it a physical ID (e.g. a Maxim 1-wire "serial number" thingy that can be read out via CAN-bus).

That still doesn't rule out the "terminator plug" idea, though. I.e. make a rule that all jacks must have something plugged into them, and provide two kinds of things to be plugged in: a cable with two different plugs, and an isolated terminator plug that fits into output jacks only.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

In my application it is necessary! Not for the CANopen communication, but for the business himself! There are severeal identical I/O modules and the CANopen master must recognize, which input ON WHICH PHYSICAL POSITION on the bus has toggled! In the present the service engineer has to configure each module: module next of CANopen master setting to #1 and so on. After replacing a module in fact of defect the same activity!

Now I'd like to simplify that! I'd like to have a table in my software application like that: serial number of module (for LSS) node ID physical position on the bus.

Rightly! But in the meantime I now the service engineers: '...why I have to plug in this silly plug without cables? It works well with out!" (the question is: how long) ;-) Or: "...uuups, I loose this funny plug! What the hell!"...

Thanks for your tips!

Markus

But with your cable selection scheme, you get the same kind of problem, if not a worse one, as soon as you have to add or remove any device: unless you're lucky and this happens at the end of the bus, you'll modify half or all the numbers of the existing devices, when in fact you changed only one. That's why a board identifier is better than cable-addressing: it changes only if and when you exchange the actual CAN module doing a given job (which should not be necessary unless that particular module broke), and it leaves all the others alone.

Well, if they want to be stupid, there's nothing you can do about it anyway. Let them. Just make sure you have a nice hardcopy printout of the manual to whack over their head if they come to you with this kind of self-induced problem.

--
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.

Without following the whole thread, this is not CANopen anymore. Using two differnet types of connectors is ugly. DS 303-something (1) defines different types, but assumes if you have different types, they should be the same for in/out, right/left or whatever it is called. Look at the typical CANopen nodes using the very same DSUB-9 kind of thing.

--

with best regards / mit freundlichen Grüßen

Heinz-Jürgen Oertel

+=================================================================== | Heinz-Jürgen Oertel port GmbH | mailto: snipped-for-privacy@port.de | phone +49 345 77755-0 fax +49 345 77755-20 | Regensburger Str. 7b, D-06132 Halle/Saale, Germany | CAN Wiki | Newsletter:

:-))

Thanks!

Markus

You'r right! First I'll study the CANopen specifications...

Thanks for the answer!

Markus

I don't know of any such standard. But

you can buy such modules at my company, see e.g.

(only in german right now, sorry). The english prospectus at doesn't mention this feature, as it's rarely requested.

We implemented this because a) we (and some of our customers) believe that it eases replacement with spares b) sometimes you can identify and locate modules with defect interfaces or cable problems.

Andreas

--
Patron: I'd like coffee without cream.
Waiter: We don't have cream, but I can give you coffee without milk.

Hi Markus,

I can confirm from several of our clients that for their way of using CANopen this would be a very desirable functionality. Unfortunately, the switch has another problem. Every switch adds a little noise and/or delay to the signal. And with CAN it is quite crucial to specifically avoid any delays...

So what you are suggesting might reduce the total number of nodes that you can connect to a segment or reduce the maximum length of the cabling that you can use.

In case you are still interested in a solution for auto-termination only: that is quite easy to do with Ethernet sockets that can detetct if a cable is plugged in or not. You just have to wire the termination resistor in a way that it is automatically "hot" if only one cable is inserted, but it gets removed when you plug-in both.

Olaf Tutor at ESAcademy dot com