Basic PICAXE CAN Network

mst

Member
G'day guys, need some help with coding and what not for a project on mine.
You see the problem is that I'm building a rally car and I am going abit overboard with the weight stripping thing. I want to remove the extensive wiring from the body harness (controls stuff like wipers, lights etc..) and replace it with a serial network of pics (master controler and slave nodes).

A 20 pin part has enough inputs of correct sorts (master) and 8 pin parts have enough outputs for the various places a node will be required (1 pic per tail light cluster, 1 per head lamp bank etc.).

Now I've completed some basic projects with pics but nothing requiring serial coms to another pic. I understand the basic ideas behind it but I want to make it slightly more complex than just the master sending a command and hoping that the node that is supposed to recieve it is still working.

So I thought a 'heartbeat' from each node sent to the master to say 'yo i'm here' only sent when the master asks 'yo are you there?'. I suppose 2 serial lines can be used (transmit and recieve) and to prevent collisions the slaves will only transmit when asked to do so by the master.

Any ideas would be greatly appreciated!

Edit!: Before anyone says anything, yes... I know I put CAN Network. I myself laugh at people who say ATM machine >: (
 
Last edited:

Rickharris

Senior Member
general comment - microprocessors and cars are adifficult mix - big voltage spikes - large currents all spell doom to electronics - that's why the manufacturers charge so much for replacement black box's.
 

hippy

Ex-Staff (retired)
Welcome to the PICAXE forum.

I think the system is going to be far more reliable if you simply throw the data from the master to the slaves and hope it gets there. The slaves can have error checking to make sure what they receive makes sense.

At the moment you've got three basic failure modes -

* Master stops working
* Data to slaves gets corrupted or doesn't get through
* Slave(s) stop working

When you start adding in handshaking and "I'm alive" processing you get a massive increase in the number of things which can go wrong, particularly if the master stops working because a slave has. You have a far greater risk of the entire system failing.

If you are going to put anything in, a separate system to check slaves are working would be it.

All the caveats as per normal on installing electrics into cars apply, especially if this is also going to be used on the public highway.

Also, you need to work out if you are improving things or making them worse. Will you really be saving weight overall, will you be more at risk from a minor crash taking out the entire system. The worse that can happen when you lose a tail light to a tree is a dangling wire which shorts the chassis and blows the fuse ( okay, wire catches fire is worse, but assume the fuse does disconnect the fault ). When the same wire which used to go to the bulb ( because ultimately there will be one ) shorts to chassis, and is controlled by a PICAXE what happens then ? If it does take out the PICAXE network, not only don't you have a tail light which you didn't really need but you could lose everything else.

Rallying is probably one of the harshest environments for electronics. Not just the problem of electrical noise but mechanically ( vibration etc ). My personal opinion is that the benefits won't outweigh the negatives. It would be a lot of effort to go to for little gain. I'd probably strip out such electronics and replace with a wire straight to the switch if I were going for maximum reliability :)
 

mst

Member
Thanks for the reply guys,
After reading your responses I have a few ideas and I'd like to clear up a few issues that you have raised Hippy.

First things first, safety - This vehicle will never be driven on a public road again. It does not have 'B' registration and it's sole purpose is for rally.

I suppose I should have said there's more to this than just weight stripping, it's also to reduce the amount of electrical power the car uses, therefore less mechanical energy wasted from the motor. To that end Luxeon LED will be used everywhere except for the headlights where discharge fixtures will be used (2x35w). Hopefully load will not exceed 85watts in total (excluding ignition) as I am working to remove the alternator all together (less mechanical energy but more importantly less rolling mass for quicker response).

One of the other reasons why I wanted to use picaxe in the first place is because regulations for different events specify that rear lights must do different things, so programmable tail lights mean that I'll never have to re-wire.

To combat the vibration each node was to be encased in epoxy.

Coms: Would I be right in saying that slower data rates are more reliable? I cannot imagine that this would require a data rate that is particularly fast. As far as status updates from slave nodes, I was thinking that every perhaps 30 odd seconds the master could send a request to the slave nodes in incremental order. When a slave receives a status request it will send an answer back to the master. The lack of an answer won't affect the operation of the master, it would simply light an led or something to warn the engineer that something is a miss. Having said all of that a separate pic could handle the error system so as not to bother the master (listens to both data lines and when it hears the master ask for status it then listens the the second data line for the response).
 

kam

Member
Hey,

Interesting project indeed... something i want to do somewhere down the line.

Could you please explain the Epoxy thing?

Kam
 

Dippy

Moderator
Sounds like an interesting project.

I'd agree with Hippy's data sending idea suggestion.
You could send a 'command' as several bytes (i.e. several times) and build in a data-integrity check at the slave end.

Yes, I'd use 2 wire serial otherwise you'll need an 'open' configuration for the 1-wire.
Mind you, come to think of it...

I'd be tempted to go for slower data rate as it'll give you a chance to include a bit of spike suppression without affecting the data too much. i.e. if your suppression takes the 'edge' off a data bit then its a lesser effect on slow data.

Each PICAXE-node will require transient and spike suppression with good regulation and decoupling.
And maybe even screening if needed.
This isn't difficult, contrary to the persistent Gloom & Doom messages.
But it WILL have to be done carefully and with thought and patience - BUT if care, thought & patience are a problem then just get someone else to design it and pinch the idea.

Obviously you will pay attention to using good cable and connectors - an area where so many people penny-pinch in the Ebay-mentality era.

I like the whole idea - chuck in some diagnostics too, so you can have a display to tell you your rear light has failed.

Nice project.

Do you have a 'scope?
A 'scope could save you hours/days...
 

Andrew Cowan

Senior Member
Encasing it foam sounds like a much better idea than encasing it in epoxy...

Epoxy will send all the vibration straight to the electronics.

Maybe use latex or something?

A
 

RexLan

Senior Member
general comment - microprocessors and cars are adifficult mix - big voltage spikes - large currents all spell doom to electronics - that's why the manufacturers charge so much for replacement black box's.
Always doom and gloom as soon as automotive is mentioned and I just don't get it .... micros have been running our cars, and doing engine management, for decades ... successfully.

Jeremy and I used a Picaxe (in a car) which is being used in a variety of vehicles without issue.
http://www.gpxt-data.com
 

Dippy

Moderator
I don't get the persistent Doom & Gloom either.
However, I assume, that as this Forum is read by a whole range of viewers then it's a good idea to include caveats. So, there is a little more to it than stick it on some tatty vero and stuff it in Dad's car.

(Which, by the way, is what I did for my very first Tacho project on my Dad's Ford. Car survived, but my tacho didn't :( )

Any person with some experience should be capable of designing some protection and use the appropriate components - ability to read Data Sheets required.

Also, for yer average vehicle, I don't like the idea of potting components (unless a proper enclosure cannot be found).
A good, tough enclosure IP'd appropriately for its position, preferably painted/coated metal is surely better.
Serviceable and better thermal properties generally.

And if people decide to penny-pinch on a significant project then tough ;)

End Proc // Moan.
 

BeanieBots

Moderator
It's not a question of doom & gloom but simply pointing out that there are things in a car which can catch you out that don't exist "on the bench".
Also, depending on what you do, you can end up voiding your insurance.

Like everything in life, common sense. Not everyone has that.
 

hippy

Ex-Staff (retired)
Always doom and gloom as soon as automotive is mentioned and I just don't get it .... micros have been running our cars, and doing engine management, for decades ... successfully.
But they are mostly microsystems designed by experienced professionals, extensively tested to be fit for purpose and safe, and certified by independant bodies.

Just like Pufferfish ( fugu ); entirely safe if prepared properly, it can be lethal if not.

Nothing can stop anyone taking risks, but it's not unreasonable to warn that there are risks which many readers may not understand or be aware of. They may also not appreciate the scope of the risk. While it's easy to be blasé, "if I kill myself, it's my own misfortune", an automotive failure can have far greater consequences on innocent third parties.

It's not "doom and gloom", it's discouraging avoidable recklessness and negligence, encouraging people to make informed decisions, not giving a casual, "sure, you can do that", answer which may lead people to believe it is risk free when it isn't.
 

SilentScreamer

Senior Member
Its better to warn and tell people what needs to be taken into account rather than just saying "don't do this". They'll do it regardless, they might as well stand a chance of doing it properly.

Another slant on it tell a person specifically not to read what is written on a piece of paper left face up in plain sight. Who could resist?
 

hippy

Ex-Staff (retired)
I agree, it would be fantastic if we could lead every poster through the pro's and con's of what they are considering and tailored to their particular circumstance but there's just not enough time to do all that, but more importantly, most of us are not experts in the specific field.

Whole books could be written on the subject and the best we can manage is a brief synopsis. In terms of what they should take into account therefore becomes the headline issues, which is generally what gets given.

Unlike battery powered desk work where there's little chance of things going wrong, and if they do it is largely inconsequential, where we'd say go ahead and try it, the higher chance of something going wrong and far greater consequential effect means we generally advise against.

To cap it all off, we all have moral and legal duties of care and therefore have to be careful how we phrase things in a public forum. Should something be taken as encouragement to do something which turns out badly that can turn into a nightmare of liability, unintended or not.

There is previous discussion of this elsewhere in the forum. The issue only generally arises where there is some significant adverse risk involved.
 

mst

Member
Wowzers that all got a bit outta hand! Anywho, I'd just like to restate for the record that this is purely an off road vehicle where the malfunction of any of these modifications would not adversely affect the vehicle, occupants or third parties. The words spoken above are sound advice to be taken seriously, and modification like this should not be carried out to any lethal machinery (cars included) without the proper knowledge, fail-safe protocols and experience. The intended use is for rally where the closest person travelling behind is over a minute in time and I intend to employ fail-safes which will do exactly what they say, FAIL in a SAFE condition. With that in mind I'd rely like to push on.

Cable should be screened 2 core (like microphone cable)?
connectors to use, perhaps 3 pin XLR?
encase it all in a die-cast metal box
Andrew, perhaps silicon to encase it in?

I'm working on some diagrams at the moment and will post when done.

Sorry if this sounds stupid what what was meant by 'do I have a scope'? Like a oscilloscope, or a definition of what this project is meant to achieve and in what manner?
 

Andrew Cowan

Senior Member
Scope = oscillocope
Silicon sounds good (although some types of window sealant are acidic, and eat wiring).
Screened cable also sounds good.

A
 

Dippy

Moderator
Very true. Important and valid points - [ regular viewers may be having deja vu again :) ]

I don't mean to sound that I'm treating the potential problems lightly but this subject is second only to MOSFET driving in its repetition.

Suggestion.
As it crops up so often why not include a section in Manual 3?
This could be a page or two showing an example circuit, an example method of construction, and an example list of suggested components.
And it could include the list of caveats, disclaimers and warnings.

Then, when the question crops up again we could do a simple link to the Manual followed by more specific help.

In the many postings on this subject only about three or four of us have suggested an actual circuit.

Surely this would be more helpful and constructive than just listing the pitfalls and the D&Gs every time a question like this is posted?

It could be authored by hippy or BB in their coffee breaks ;)

Sadly, I know it'll never get done, so remember this thread... we'll see it again!
 

Dippy

Moderator
Yes, sorry, oscilloscope.

Sometimes you can have a lovely comms until you turn on the engine.
Whats gone wrong?
Spikes on the power line or spikes on the data line?
Is my line condtioning affecting data pulse shape too much?

Just a couple of simple examples of the use of a 'scope.

(Having said all that it may work first time :) )

If you are putting it in a sealed diecast metal box why fill it with goo?
You'll never be able to fix it again.
Worry about that sort of stuff later.

Are ECUs/EMUs filled with goo?

I'd get the basics going before worrying about cables and connectors.
There are a zillion options for that bit.
 

mst

Member
It's 50/50, Toyota don't they just solder everything to the board and screw the board in a metal box and that's it. However Nissan does in some instances fill with epoxy, and I have scene various others do that do.

What about washing machines? Almost all are full of epoxy, is that for water protection or vibration (maybe both).
 
Last edited:

Dippy

Moderator
Whether you pot it or not is up to you.

My Hotpoint Dishwasher, Washing Machine and Tumble drier control boards are in non-sealed enclosures outside the 'working area' which is obviously sealed - no potting and have been working for 8 years.
So, not sure about 'almost all' - I've never taken 'almost all' washing machines apart , have you? :)

Potting does have benefits, I won't disagree.
But there are downsides - and you will kick yourself if something minor goes wrong and you have to make a whole new PCB and buy a new enclosure.
Up to you. Personally, I'd use a conformal coating top and bottom of PCB and mount it in a metal IP55 box for inside car or something better for under the bonnet.

Again, worry about that after you've got the basic comms working 100% on the bench.
But design your PCB to fit in a suitable enclosure - with space left for connector bodies ;)
 

Dippy

Moderator
There are oodles of spray coatings available Martin.
Farnell, RS, etc.
Poly-U, Silicone, old fashioned laquer etc.

Just take care. Most can be soldered through for repairs and mods, but check this first.

Some need heat curing so can be a pain for kitchen-table work. Unless your Mum/Wife/GF doesn't mind you using the oven :)
 

Andrew Cowan

Senior Member
Maplins PCB laquer is available for a few quid. Takes about 20 minutes to dry in the air (depending how enthusiastically you apply it). It can be soldered through. Makes continuity checking a pain tough, and it will make
Permanent pen ink run.

A
 

mst

Member
So as far as a circut goes it's as simple as the serial out pin (whichever is chosen) is directly connected to the serial in pin. Does it matter how many devices are connected, i'm sure there's an electrical limit but is say 10 devices ok?

What are the methods of filtering that could be used to help insure relyable transmission? Worth doing or is it worth a try without?
 

Andrew Cowan

Senior Member
Higher baud rate = more chance of interference/signal loss.

Low (eg 1200 baud) = a good strong signal.

Impedance of input = 20K (roughly) = 0.25mA.
Max serout current = 20mA

So maximum of 80 devices per network (electrically).

In a car, over long distances/close to ther wiring, sheilded cable would be good.

A
 

Dippy

Moderator
This is just me thinking out aloud.

I would pay some attention to the PICAXE you choose here.

Connecting several PICAXE O/put pins together is not wise.
The O/P pin when not 'high' will be (almost) grounded. So, if another PICAXE on the same wire outputs data the signal will be 'lost' or may even cause damage.
However, if you choose a PICAXE where after your Serout the pin can be set to input mode (high impedance) - this is fine if the data is polled but not so good if each node volunteers data.

Alternatively a simple transistor circuit can make the o/p look open and behave a bit like an I2C line.

There are many signal conditioning techniques.
If you are screened all the way I'd try a tiny bit of RCR with a slow baud rate as my first attempt. The RC filter will take the corners off the data signal, but if the baud is slow then it may not be significant.
This is where the old 'scope could save you days or work.
On the other hand it may be fine without it.

Power supply filtering will be imporant.
 

mst

Member
So when it comes to coding should I establish the state of each input (high or low for 7 digital inputs) store each value in a variable and then serout a string of all of the variables?

serout 0,N1200,b0,b1,b2,b3,b4,b5,b6,b7


If this works like I think it does it would send all of the values one after the other. serin command could recieve it? don't know where to go from here. Also note in the serout command that I'm trying to send 8 variables, the eighth is a value to tell which slave device to report it's status.
 

mst

Member
This is just me thinking out aloud.

I would pay some attention to the PICAXE you choose here.

Connecting several PICAXE O/put pins together is not wise.
The O/P pin when not 'high' will be (almost) grounded. So, if another PICAXE on the same wire outputs data the signal will be 'lost' or may even cause damage.
However, if you choose a PICAXE where after your Serout the pin can be set to input mode (high impedance) - this is fine if the data is polled but not so good if each node volunteers data.
Would 08m parts make good slave nodes then? assign 3 pins to output, 1 to serial input and 1 to serial output. The serial output pin can be kept as a input (high impedence) untill it is required to transmit.

Can the 08m continue to output PWM while it is waiting for serin? The brake/tail light intensity was to be controled via PWM.

Current pin config for slave nodes could be:
1. +ve
2. serial in
3. serial out
4. reverse (LED via darlington array)
5. brake/tail (LED via darlington array + components for PWM controled intensity)
6. indicator (LED via darlington array)
7. N/C
8. GND
 
Last edited:

hippy

Ex-Staff (retired)
There are a number of ways to connect multiple outputs to one input, but as Dippy notes just wiring active outputs together is not wise nor safe. The simplest method is to diode-mix the signals.

Low baud rate and interference reduction is a dubious correlation in itself as it depends upon hardware and nature of the interference. Bit-banged serial ( as with SERIN ) samples the data at a single point in time and uses that; there's just as much chance of interference causing an incorrect data read then no matter what the baud rate. Anti-interference devices can be used which have less effect on a signal at lower baud rates.

@ mst : If you are just sending bit data there is no need to move the data into separate byte variables you can SerOut "bit4", "pin3" and so on, or the the entire set of "pins" ...

SerOut 0, N1200, (pins)
 

mst

Member
@ mst : If you are just sending bit data there is no need to move the data into separate byte variables you can SerOut "bit4", "pin3" and so on, or the the entire set of "pins" ...

SerOut 0, N1200, (pins)
So it would just rattle off a '1' or '0' for every input? Can you add a variable to the end of that statement?
 

hippy

Ex-Staff (retired)
SerOut 0, N1200, (pin0)

Will send a byte of value $00 or $01 depending on if input pin0 were low or high.

SerOut 0, N1200, (#pin0)

Will send a byte of value $30 or $31 ( ASCII characters "0" and "1") depending on if input pin0 were low or high.

SerOut 0, N1200, (pins)

Will send a single byte whose value will depend on which pins were high or low. If all are low $00 will be sent, if all high it sends $FF, if pin0 were high and all others low it sends $01.

Multiple variables can be sent in a SerOut command.
 

mst

Member
Ok so as far as network traffic goes the statement 'SerOut 0, N1200, (pins)' would be the shortest message to send. Can this be decoded at the recievers end so the slave knows which input was high and which was low? Or is it just a value that increases due to how many inputs are high (therefore impossible to know what was high and what was low).

If the latter is the case then use 'SerOut 0, N1200, (#pin0), (#pin1), (#pin2), (#pin3)'.
The resulting data being somthing like $30$30$30$30 (if all pins were low)
 

hippy

Ex-Staff (retired)
The "pins" variable is a bit-mapped indicator of each "pin" variable so the position of each bit refelects an input pin; pin 0 is high = lsb set, pin 7 is high = msb set.

When received, the byte value is still bit-mapped so the bits set indicate which "pin" variables on the sender were set.

Sender:
Do
SerOut 0, N1200, (pins)
Pause 1000
Loop

Receiver:
Do
SerIn 0, N1200, b0
If bit2 = 0 Then : SerTxd( "Pin 2 is Low", CR, LF ) : End If
If bit2 = 1 Then : SerTxd( "Pin 2 is High", CR, LF ) : End If
Loop
 

mst

Member
Wowzers, that's abit over my head, i understood very little of that so I'll have to go away tomorrow and read up about what each of those commands means. So far my programing has been limated to basic goto commands and such like.

I have most of the parts I need but I'll grab what I don't have and prep it so I can do some testing.
 

kewakl

Senior Member
By 'bit-mapped', I'm sure that hippy means binary weighted.
Since the 20M supports 8 in and 8 out:

Bits 7 - 0 = Inputs 0 - 7 (could also be used for the output byte)
(forgive the abuse of the CODE tag, I could not find a better way to align the bits & position weight)
Code:
bits      7  6  5  4  3  2  1  0
weight  128 64 32 16  8  4  2  1
00000000 = 0
00000001 = 1
00000010 = 2
00000011 = 3
/ --------- /
11111101 = 253
11111110 = 254
11111111 = 255


Still confused, use the Calculator in scientific view.
Click on the Dec (decimal) radio button, enter your decimal value.
Then click on the Bin (binary) radio button to see the binary representation.
eg. 164 = 1010 0100
use 'digit grouping' to separate the byte into two groups of four bits.
eventually, you'll get it.
 
Last edited:

kewakl

Senior Member
RE: Post 30 (EDIT)

From manual 2:

Qualifiers are used to specify a ‘marker’ byte or sequence.
The command
serin 1,N2400,(“ABC”),b1
requires to receive the string “ABC” before the next byte read is put into byte b1

Without qualifiers
serin 1,N2400,b1
the first byte received will be put into b1 regardless.
All processing stops until the new serial data byte is received.
This command cannot be interrupted by the setint command.


(the color and bolding is mine)
 
Last edited:

mst

Member
Thanks hippy for the code and kewakl for the definition! I think I get it now.
So can the 08M continue to output PWM whilst serin is in operation? (PWM is required on the brake/tail output to produce 50% power for tail and 100% for brake)
 
Top