Need to modify/filter a signal in a CAN bus.. picture inside

[iso9001]

Hi,

I've been working with CAN a little bit and come across a problem where like the subject says I need to take a specific couple of signals from a CAN network that is already in place (DeviceNet between two machines) and modify just those signals. Dual wire, High speed. These are big complicated machines so remaking them or reprogramming is not an option.

The signal that is modifed goes from A to B, one way but B receives a LOT of other signals from A. My idea was to have two transceivers, a pic with can or a stand-alone unit. Hook the RX of A to the TX of B so that all messages coming in on A are auto-fowarded on to B, no pic interference. Then, hook the RX of B to my pic (receive the signal), modify it then send it out to the TX of A. This is why I included a picture along with the post :?

So what I'll need to do is pull in all signals from B, pass along most, modify one and hopefully neither machine will be any the wiser. There is one other machine involved here but its a minor one and I'll be interupting the wires between A and B only.

I am aware that there is the possiblity of an arbitration error occuring if both A and B start at similar times but I think this will be minor.

Any ideas ?

 

[instruite]

Another Idea will be to use a microcontroller with two CAN channels ( I dont know if PIC ICs come with two CAN channels, but microcontrollers from freescale and renesas are available)
Connect one channle to device A and other to Device B and in your software simply pass on the data form channel 1 to 2 (two ways) of microcntroller except for the one you need to modify

 

[iso9001]

Well, actually only a little of the sketch is shown. At the same time I will be accessing three other CAN networks. So if I choose the stand-alone I can do that no problem.

I think I need a link from RX of transceiver 1 to RX of my controller.... Otherwise without that how would I send messages ? Without that link I wont know if the bus is clear, it'll cause faults for sure.... But then I can't just link it up b/c I'de be creating a loop at Transcevier 2, I wonder if I could use a diode there. So in effect I'de have RX of the controller reading two different buses.

Its CMOS/TTL, I could probably add a diode there and not mess it up too much right ?

 

[instruite]

Hi,
just for your information
when A device sends a command over CAN line to another device it accepts a response from the receiving device
you will have to check since there will be an intermediate device in the communication path there will be some delay in this response and depending on the kind of command and its cycle time this delay might produce some problems
Is the control of CAN IDs in your hand?
or can you give more details of the messages/commands?

 

[Oznog]

when A device sends a command over CAN line to another device it accepts a response from the receiving device
you will have to check since there will be an intermediate device in the communication path there will be some delay in this response and depending on the kind of command and its cycle time this delay might produce some problems

Well if I recall correctly the ACK bits are the response. And that was my thought when I read this, there's no way a pkg generated on A is going to be bridged and recreated on B, then the ACK responses from B sent back across the bridge in time to respond to the initial pkt.

I don't think ACK bits serve a great deal of required function, though. This isn't at all the way CAN is supposed to be used, so there's no predicting if the senders on A would be harmed by not getting the ACKs from receivers on B. The arbitration is another wild issue.

 

[iso9001]

I have no control over the IDs. The timing is pretty fast, ~12ms, but no one will get mad as long as it arrives within 64ms. So I have 'some' time, but bus load is ~60% as is.

Yea, I'm not worried too much about the ACK bits b/c other units on the bus will reply. But the arbitration would kill me trying to do it like this! See, machine 2 would see machine 1 still talking, but if machine 2 looks out the door, sees its clear to talk and then machine 1 does the same thing, machine 1 will not see 2's signal and it will corrupt it. So it doesn't seem this is going to work.

My new method is to put in two standalone controllers, and pass all the data in transfer it right away to the other then bring in from machine 2 modify and pass that. That fixes the arbitration, the ring-back/ACK, etc. However it does suck b/c I need to bring a LOT of data into my processor and pass it right out. So I need to be fast about it and that cuts into the other things I want to do.

Kinda sucks but its the only option I have it seems.

I was thinking about a way to figure out if Machine 2 was sending a message and then block the line from machine 1's trransceiver but I can't really figure out how to do that effectively.[/i]

 

[instruite]

when A device sends a command over CAN line to another device it accepts a response from the receiving device
you will have to check since there will be an intermediate device in the communication path there will be some delay in this response and depending on the kind of command and its cycle time this delay might produce some problems

Well if I recall correctly the ACK bits are the response. And that was my thought when I read this, there's no way a pkg generated on A is going to be bridged and recreated on B, then the ACK responses from B sent back across the bridge in time to respond to the initial pkt.

I don't think ACK bits serve a great deal of required function, though. This isn't at all the way CAN is supposed to be used, so there's no predicting if the senders on A would be harmed by not getting the ACKs from receivers on B. The arbitration is another wild issue.

Well I was not talking about ACK bit here, I was talking about the full response like from the receiver
Like for example A sends a data read command to B, then A expects some data from B in a certain time frame depending on the time cycle of command and if it does not get the response then it may consider B device is in fault stage
This was just an example depending on applications some devices have very critical functions which have limited time periods of execution