Anyone worked with CAN networks?

[Triode]

My supervisor at the lab where I work wants to look into using CAN in some of our automated systems. So I got some PIC18F46K80 chips, a MCP2551 tranceiver, and got to work on it. We would like to use CANOpen higher layer protocol. I've looked at the application notes, but none of the code I can find compiles without modification and it's hard to debug the code when the device wiring and hardware are also new, and to try it out I need two working nodes.

The lab had an old PICDem can lin 2 board, so I set that up and the CAN king software, it works, but I have yet to get a device to interface with it.

With the PIC18F46K80, the MCP2551 tranceiver, and the CANOpen example code in AN945 do I have what I need?

Update:
I have so far found that the AN945 code, which is written for the 18F8680, needs the following changes to compile for the 18F46K80

Replace PIR3bits.RXB1IF with PIR5bits.RXB1IF
Replace REQOP2 with REQOP
And of course replace #include "P18F8660.H" with "p18f46k80.h"

So now I'm working on finding where I set the frequency and baud rate and what function I call to transmit a message.

 

[duffy]

Somebody's going around selling management a bill of goods on CAN bus. Happened over here a couple of years ago, we got stuck using it for a while, then went back to SPI bus because it's quicker and easier and more stuff uses it.

 

[Triode]

I have been at it for about a month or so and I have to say I think it is oversold. For our application I don't really know why not use SPI or RS485 networking. We need to monitor a handful of sensors and control a few motors. It requires fast response and reliable networking, but nothing that those couldn't handle, based on what I know anyway. Maybe a salesman did get to the Dr.

 

[ericgibbs]

hi,
This link is to microchip CAN apps.
**broken link removed**

 

[wkrug]

At Begin I have to say, I Play around about only 3 Weeks with the CAN Bus now.
There are some good advantages about CAN:
Collision Handling with fast recovery.
Multimaster ability.
Message based protocol.
Easy cabelling.
No adresses for nodes!?
Quite long ranges at the cable.
Cheap Controller and Bus Driver chips availible.

I work with the MCP2515 Chip. Because its from Microchip, I think your Controller uses the same Operation Scheme.
In a Can System would not used a baud Rate for configuration. Instead oft that the Master Clock will be divided into Time Quotas.
In a register there is to set the prescaler factor. Best there are 8 up to 16 TQ per Bit.
With this prescaler factor you have to count how many Time Quotas fits into 1Bit of a CAN Message.
The TQ's must fit exact into one Bit of the choosen Bus Speed.

This calculated Time Quotas will be splitted into some sequences.
First ist the sync Quota that allways is 1 TQ, followed by the propagation segment that is programmable.
Now is to programm the lengh in TQ of phase segment 1 and then the phase segment 2.
The Bit sample point is between phase segment 1 and 2.
The Sample Jump Width is the maximum allowed Jump wide for the internal PLL of the CAN Controller.
The internal Bus Speed PLL syncronizes to the falling edges of the CAN Signal.

Next step is to set the Operation Mode of the CAN Controller and the input Message Filters.
Then you can fill the Transmission Buffer Registers and send out the Message by setting according Bits in a register.

The Message Filter should decrease the Load for the Controller.
You have to set witch Address Bits are to use for filtering and in other Registers is to set the state of that used bits.
Only Messages with Identifiers that fit to the filter mask will be signalled to the Controller.
The filtered out messages will be thrown away internally into the CAN Controller.

The CAN Controller itself confirm all incomming Messages at the CAN Bus without any looking into the message filters.

To use that Bus in a self developt network should not be a great problem.
To implement new components into an existing Network, without detailed message documentation and structure, is not possible.

The problem I see are the higher layer protocols of CAN like Isobus, CANopen or NMEA 2000.
There where used Node Names and Addresses again.
They doesn't fit good into the Message Identifier structure of basic CAN
To find useful informations about the usage and data format of higher protocols is a very hard job.

A little Exmple:
At ISOBUS the 29bit of the Can Identifier are splittet into 3Bit Priority + 1ReservedBit + 1Page Bit + 8PF Bit + 8 Destination Address Bit + 8 Source Address Bit.
For PDU2, appends of the Message Field PF, were used a 16Bit PF field without Destination Addressing.
You know - The Identifier was thought to choose between different message types and not for any adressing. But in higher protocols an adressing will be pressed into the Identifier field.

A further one:
CAN provides up to 8 Data Bytes in one Frame.
In some Higher Protocols the first Data Byte is used to Numbering a Frame, to transmit up to ~1700 Bytes. Therefor own Identifiers have to been used. Because the receiving Node must know wheather the frame is a single or a multiframe one.

An Additional:
In Isobus a Node has an Address. When a Node is connected to the Bus it request the Adresses of all the other Nodes on that Bus.
When the priority of that new Node is Higher than one existing in the Bus, it can steal the address of this Node! That victim get's than the address 0 and has to start a new Address get procedure ( Address Claim ).