New CAN device
kelvin james
Posts: 531
Can anyone explain in a little more detail about this, the doc is a little vauge on the operation. I would assume it is meant to be a serial buffer. Just wondering how it is considered a coprocessor, other than a communication buffer ?
kelvin
kelvin
Comments
Consider it a 'network card' for your BS2.
CAN = Controller Area Network
Post Edited (Gadgetman) : 5/7/2005 12:11:19 PM GMT
If so, Kevin may want to know.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
DTQ
For the vehicle's On Board Diagnostic system (OBD II), there are currently 5 different protocols used for the vehicle to communicate with·a scan tool. Some manufactureres already use CAN.
Starting with 2007 (or '08, can't remember now) all vehicles sold in the United States with an OBD II system must use the CAN communication protocol.
I had thought that CANbus was a complete microcontroller system, but now you have got my attention.
Can anyone diagram a simple setup with the BS2 and CANbus? It would help get me started.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
The 'CAN device' seems to give the BasicStamp more autonomy that other schemes of DIP microcontrollers that support CANbus. Servo Magazine (April 2005) has a list of 26 of the leading DIP microcontrollers and it missed mentioning that the BasicStamp is usable with the CANbus. I was beginning to wonder if you really could use the BasicStamp together with CAN.
The main thing that seems attractive is the CANbus reduces wire. It is a 'bus' that mutiplexs information to/from other devices. If I was clear on what the other devices were or could be, I would have some idea of how to begin to apply all this. I guess I will have to look around.
Is there a CANbus LCD interface? Is there a CANbus input device [noparse][[/noparse]keypad]?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
The bus would remain their for control of various actuators and collection of sensor info from more distant locations.
Is that a reasonable way to go?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
G. Herzog in Taiwan
I work for Machine Bus Corp. We are the developers of the Stamp/CAN Interface sold by Parallax. I agree that the documentation maybe a little vague. I have requested that the documentation be updated. For now, you can view the latest doc and PBasic examples for the product at http://www.machinebus.com/downloads/mci100p.zip. There is also a white paper that describes the Controller Area Network (CAN) protocol in great detail.
I think that Gadgetman described it best. The product is a CAN network card for your BS2. CAN has many wonderful qualities, but it is more complicated than other forms of serial communications. This coupled with high bus speeds can easily swamp a small processor. Much of the overhead associated with CAN communications is taken care of by this device.
As for the applications of CAN, everyone in this post is correct. It is used in many industries. Upon further study, you will find that CAN is one of the best, embedded networking technologies available.
If you would like to create a distributed control network, using CAN, I would recommend the BASIC Stamp since you are all familiar with it. The architecture of a distributed control system is often dictated by physical requirements. For example, you may need a keypad, a sensor and an LCD display in separate locations. Create your network using a BS2 and a Stamp/CAN Interface for each processing node. Write the PBasic code for the keypad, sensor and LCD as you normally would and add the CAN API code from the example. You will find simple examples in Appendix A and B of the datasheet.
If you have a CAN bus that you would like to tap into, you would only need one BS2 and one Stamp/CAN Interface. Just be careful about transmitting messages on a working CAN bus. You could inadvertently cause a machine to fail in unexpected ways.
If you have any additional questions, feel free to ask.
Dan Mannisto
Machine Bus Corp.
danMannisto@machineBus.com
I can't find it on parallax website and search doesn't either...
CANbus is a great solution, but the economics is pretty much dictated by those chip producers than offer the device inclusive of a micro-controller. Microchip's PIC have devices that include CANbus and really cannot be beat for costs. A 28pin PIC with CAN included can cost about $7USD if you shop around.
If you really want the network to interface with other micro-controllers, the MCP2515 and MCP2551 chip set is available and Parallax even has an object in OBEX to support use on the Propeller. I have had good luck with using their SPI interface and BS2s.
In my own case, I had 25 boards made to hold the MCP2515 and MCP2551. These allow me to use any micro-controller with them. But at the end of the day, it seems much easier to give in and use all Microchip products for a CAN solution as the CANbus itself tends to have tens of nodes that do tiny tasks as slaves and only a few masters.
The product mentioned in this thread was a bit of dead end as it used CANbus, but also created its own system that limited what could be done. Most users just didn't see the value in such an expensive solution.
Great!
I am guessing that you are using the MCP2515 and MCP2551. I worked through getting them to operate on the BS2 and the learning curve was mostly about the initialization code. Once the device is working, it just hums along rather reliably. I found that using the recommended defaults worked fine for many months of having a pair of nodes working on 100 foot coil of telephone extension cable. It is nice that the unit actually gives you a tally of failed tries.
The cost of a set of chips isn't really that much. It is just when you try to go to some convention like CANopen that you find they want thousands of USD for participation. That is a rather absurd jump in costs for the average user.
You got it. You're right, once things get going it's not bad at all.
Nonetheless, if one searches "Open Source CANbus", one does find that there are applications for people wanting to get started without a huge cash outlay.
http://sourceforge.net/projects/can/files/Very%20Simple%20Control%20Protocol/0.2.0_RC1_C/vscp_src_0.2.0rc1c.zip/download?_test=goal
'
I have really wanted to read some data from my trucks OBDII jack with out having to use my lap-top.
'
I ran into the same high priced software/hardware blocker too.
'
I see you guys have broke through this.
'
I hope you guys can find the time to keep this thread informed.
'
Many Thanks
After getting the hang of CAN while working with a customer I have decided to make a board for my [original] Propeller Platform (same ExpressPCB mini-board size though I have switched to DipTrace for design). The board has the MCP2515 CAN interface and an MCP2551 driver -- pretty standard stuff. The MCP2515 connects to the Propeller through a SPI buss. The only connections to the MCP2515 are through SPI, but as this is intended to be an experimenter's board I have added pads for the other pins on the MPC2515 that an engineer might want to work with, and filled the unused PCB space with pads for extra circuitry.
For those interested in connecting to the CAN signals on a OBD-II connector there is a DB-9 on the board. In order to keep things as flexible as possible there is a 9-pin female socket behind the DB-9 that matches the 3-pin female socket behind the CAN terminal block. These sockets allow the user to route the CAN-H, CAN-L, and ground connections to the DB-9 as desired (using jumper wires).
I'm about to send the board out for prototypes and the write-up and my object will appear in the March edition of Nuts & Volts magazine.
The MCP2551/2515 has multiple buffers, more than most people need to use on one CAN node, but I'd love to hear more about what people have found useful for all these different address slots. In the automotive context, I suppose one could be always following a certain engine function - like TACH - while another monitor other key features.
I had been looking for a nice bus to use for my boat - lots of sensors and controllers located around the boat to reduce the wiring. I wired my vessel and others like her. I accidentally blew my smart alternator regulators and at ~$750 a pop I have decided to build my own and fix & add modifications to improve things, including reduced wiring, and modular design.
I will use the CAN bus but I think I will just use a subset of the CANbus protocol to simplify, at least for now.
Jon, thanks again for your enlightening thread (the other one). It opened my eyes to a nice well thought out industrial (well automotive) bus with good immunity to RFI. And the bus chips are cheap.. MCP2551 from DigiKey $0.78/100.
'
Great news.
'
I want one of those boards!
'
I'll definitely check-out the March N&Vs
Got me thinking though. I knew I wanted to create a bus on the boat for a few things...
Smart regulator:
I have two Volvo 30hp Diesels with 135A alternators fitted with external smart regulation. While the now defunct expensive regulator can drive two alternators, it does so completely in parallel. If the engines are at different revs then the one alternator will be generating all the power. If I use a pair of shunts to detect the current being generated, I can adjust the individual field currents to get better current out.
The regulator died when I accidentally switched off the battery from the regulator. I was switching over from house to engine battery (I had a flat engine battery). However, this was not the main problem. When the regulator dies, it then pumps out 16V and increases, causing other possible damage! Not a good design by any means. So, I intend to take care of this problem too. I have seen it before when someone had a failed regulator, but fortunately it was under warranty at the time, although I am unsure what killed it.
Because I wired the boat(s) I know how much cable is used, and better ways to do it. If I run a bus around the boat (2wire for CAN plus 2wires for power 12V & Gnd or maybe 5V & Gnd) I can place the actual alternator regulator section at each engine, but control them from the nav station. At the same time I want to collect other information such as engine revs, oil pressure, water temperature. By making a fairly standard pcb with a few sensor inputs and a MOSFET driver (to supply PWM to the alternator field), I can have some spares onboard that can be swapped out in an emergency without costing the earth. Other sensors include battery voltage, current and temperature (2+ locations); fuel (x2) and black tank (x2) level sensors; fresh water x2 level sensors; Anchor Winch (MOSFET) control and chain length.
Next I thought about the lighting. We are now moving to LED lighting and there is considerable savings by using lighter cable (weight and cost). Place a tiny controller at each light and control each light remotely too. We have two toilets on board, so flushing (macerator and water intake pump).
And I havent even got to the main area of electronics. Currently I use a laptop for main navigation with C-Map and SOB software (Software on Board) and this is fed with GPS info. The backup is a Chartplotter with C-Map & GPS, plus an autopilot (another set of MOSFETs). Add Depth, Log (speed through water) and water temperature; Wind direction and speed; and of course the VHF radio which also gives out barometric pressure. All these instruments are currently on an interconnected bus and I can get all this info to my laptop via the prop chip. I want to add an AIS system too. I have actually thought about using a prop to decode the VHF AIS data using the work done by Phil and the Software Defined Radio.
Anyway, this project is going to take a while to develop and I have some other things to do with the prop first.
But, I digressed...
Today I designed a circuit to implement the CAN bus. It will be a tiny smt pcb (as usual) and it plugs into a prop. It has USB and CAN options with each being a 2-4 circuit interface. I am using the MCP2551 CAN transceiver. Also on board is an ATTiny which I can program with the prop to do either USB (LS) or CAN functions, or the Prop can bypass the ATTiny and drive the USB and/or CAN bus. There are two prop connections of 2-4 pins each. The ATTiny also has 4-6 ADC and/or I/O pins as I dont want to waste any resources. This is just a toy to work on the interfaces and code.
Keep us posted on your project, it sounds really cool.
I started the pcb layout, and the space taken with all the links is excessive. So I had a rething overnight and will probably think again tonight. Maybe I'll keep it KISS w/o all the options, although I do intend to get the prop doing the protocol, so only a transceiver like the MCP2551 is required.
kwinn: Yes I am looking into the CAN protocol and I do realise that it is possible to use another protocol.
The demo code is written in polling mode (just a CAN buss sniffer) and also sends a set of timer registers to the buss -- just to show how easy it is to setup and send a custom message. I've done all my testing with a commercial CAN buss device so I feel pretty good about my object and it working correctly (see images of my code output being used with PCAN-View software). That said, I'm human, can and do make mistakes, and am always appreciative of any feedback.