Inexpensive CAN interfaces

T

Thread Starter

Tom Bray

After I asked for a cheaper CAN interface, I went looking. This is what I
found.

I have been looking for ways to talk on CAN that cost less than the SSS
board. If you want high performance or are running on a computer that
potentially has performance problems, the SSS card is probably the right way
to go since it can run DeviceNet and several other "Field Bus" protocols
directly on the board, saving the processor a lot of work. For me, this
card would make most sense for people running dual operating systems to get
"hard realtime", like iRMX and NT, such as Steeplechase or one of the Real
Time Linux versions that uses a hard real time kernel while runing Linux as
a guest.

For a lower cost solution, Advantech has both PC-104 (PCM-3680 - which
doesn't appear to be in their online store), and ISA (PCL-841 - approx $303)
cards. The 841 comes with C examples and support for Windows in the box. I
dealt with Advantech a few years ago and they seemed like reasonable people,
but I haven't worked with them since. They buy other peoples cards and
equipment, then resell them.

Tom Bray


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Hi, Tom

Another good resource is the Linux Lab Project. They have some CAN drivers available, but nothing specific to devicenet. I suspect some of the reason that SSI did what they did was due to timing constraints and the cyclic nature of
polling slaves. If I find something cheap with DeviceNet branding, I may work on an interface to lplc. I doubt very much that I can write a DeviceNet proto and release it Open Source, so that part has to be canned (no pun :^) )
CAN by itself, doesn't get much use in the US except for cars and a few more specialized applications. From the Linux Lab Project list, I would guess it gets quite a bit of use in Europe. I'm curious what all they use it for, maybe we
could use it for the basis of a free and open automation protocol (If it's open and free)

Regards

cww.

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> CAN by itself, doesn't get much use in the US except for cars and a few more
> specialized applications. From the Linux Lab Project list, I would guess it
> gets
> quite a bit of use in Europe. I'm curious what all they use it for, maybe we
> could
> use it for the basis of a free and open automation protocol (If it's open and
> free)

It's often used as a (very) short-range internal system bus to interconnect various devices within a larger box. Examples are medical devices like magnetic scanners, mechanical devices like
tooling machines, automation systems like intelligent i/o, and others. Not to forget applications like supermarket automation -- no
joke: control and maintain power consumption from remote (light, temperature in a mall, fridge temps, ...)

While there is (still) CANopen, you'll typically find all sorts of homegrown (or homebrew) level 7 protocols, typically evolving around cyclic i/o transfer from master(s) to i/o slaves and in some
cases bulk volume transfer of messages larger than 8 bytes.

Regards,
Harald

--
Harald Albrecht
Chair of Process Control Engineering
Aachen University of Technology
Turmstrasse 46, D-52064 Aachen, Germany
Tel.: +49 241 80-7703, Fax: +49 241 8888-238
email: [email protected]-aachen.de

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C

Curt Wuollet

Thanks Harald

So it sounds like it's used for some of the same uses as i2c along with devicenet type applications. I used devicenet for a sort conveyor that we retrofit. It was slow, but that wasn't a devicenet problem, the Horner devicenet master seems to be synchronous with the scan.
The attraction of CAN is that the silicon is cheap and the proto itself not very fussy. I've been looking at i2c to drive IO with a low pin count bus. It might be worth a look at CAN, especially if someone else has written a driver :^) I2c has the advantage of no extra hardware needed but I can't find parallel ports with the features I need.

Thanks again

cww

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
A quick background on US Industrial CAN as far as I have used it:

There are 2 major US companies pushing CAN for industrial automation, I am ignoring Siemens for now. A-B Rockwell is the champion of Device Net and Honeywell has SDS (Smart Distributed System or something like that). Automation Direct supports both SDS and Device Net with their remote I/O card racks as does Opto-22 with one of their Brain boards.

Coming up with a Device Net or SDS driver for Linux would be fairly practical because teamed up with Automation Direct or Opto 22 you now have
an industrial strength I/O system at a fraction of what A-B or GE sells stuff for. Plus there are a whole host of special purpose modules that can be hung off of Device Net.

On the SDS side, Honeywell sells a Powered Roller Interface Module (PRIM) that builds a 4 section accumulating conveyor which seems to be very popular these days because powered roller is significantly quieter than conventional
belt or roller conveyor. I think these were originally developed for Postal applications, but they are applicable to any application moving parcels under approximately 75 lbs.

I am going to check out if there are any licensing costs of doing a Device Net interface and see if one can be put in Open Source Software. There can't be much to the CAN part of the code since there isn't much to a CAN
interface, so it should be fairly portable. I is a good chance I will not be able to actually do the interface because I may have to write one for the contract I am working on, and I don't have time to do it right now.

The best part of CAN in an industrial setting is that it optically isolates the devices from each other. The common configuration is a separate
CAN/SDS/Device Net power supply that powers the transceivers and part of the Opto Isolators. The individual devices power the other half and the
interface locally along with the CAN controller. This is actually better than the capacitor and transformer coupling used in some of the other remote I/O systems.

The standard specs for industrial CAN are also pretty good, usually allowing up to 64 physical nodes (virtual nodes can usually reach 128 - for example each slot in an I/O rack will often get a virtual address). The spec also usually says something like a maximum of 1500 feet for the network, but power supply placement and wiring connections start to become real critical when pushing these distances. Also I have learned not to push the 64 node limit and the distance limit on the same network, reliability really suffers. Mostly I have only run 128K baud networks when using the in industrial settings.

As an aside, the rumor in Michigan is that all the major US automakers will be switching to CAN by the 2003 model year. This will probably have an impact on the availability of CAN products here.

So much for my babbling ...

Tom Bray

_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
H

Harald Albrecht

> So it sounds like it's used for some of the same uses as i2c along with
> devicenet type applications. I used devicenet for a sort conveyor that
> we retrofit. It was slow, but that wasn't a devicenet problem, the
> Horner devicenet master seems to be synchronous with the scan.
> The attraction of CAN is that the silicon is cheap and the proto itself
> not very fussy. I've been looking at i2c to drive IO with a low pin count
> bus.

Especially the Siemens C16x 16bit cpu's are very neat -- comparable cheap, single chip, i/o, flash (some types) and CAN (some types). If you don't need to do floating point number crunching, and if it can work from the internal RAM and ROM it is fast. External RAM however slows the system to some extend.

> It might be worth a look at CAN, especially if someone else has
> written a driver :^) I2c has the advantage of no extra hardware needed
> but I can't find parallel ports with the features I need.

I remember the motherboard diagnosis sensors (fan rpm, temperatures, voltages) to be connected to the southbridge through some kind of I**2C -- what Intel left of it... But I might also be wrong.

Harald


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
S

Simon Martin

Hi,

I work for a servo control company, amongst other things. We developed an
interface to the Infranor drive (Infranor are distributors of our equipment
in some areas). Mostly I was in charge developing the drive configuration
software, but I have a reasonably good grasp on the real-time side as well.

In the not too distant future I will have to develop a DeviceNet interface
for our controller. As far as I can see, the protocol is documented and
available, so why can it not be Open Source?


Debian GNU User
Simon Martin
Project Manager
Isys
mailto: [email protected]

There is a chasm of carbon and silicon the software cannot bridge


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
C
Hi Simon;

From reading their materials, and this is a while ago, they require certification (read Big Bucks) for a device to be DeviceNet. This leads me to believe they would not take kindly to circumventing their cash cow. This does not preclude the use for example, of a SST card that is already certified. If a person were to use a generic CAN controller and implement DN in software, I'm not sure what they could do about it. But, with a legal defense fund of $1.98 chances are, things would go their way. That's why proprietary interfaces have to stay outside the project proper, that is, for the lplc not part of the lplc so that proprietors can't
shut the whole thing down. I could have misjudged their reply to my inquiries but, I don't think so. They are not about Open.

Regards

cww


_______________________________________________
LinuxPLC mailing list
[email protected]
http://linuxplc.org/mailman/listinfo/linuxplc
 
Top