Go Down

Topic: Multi-node CAN bus: a progress report (Read 8657 times) previous topic - next topic

bernt


By sharing and critiquing each others ideas all of us can hopefully come up with something better, and yes, you certainly could use an FET or two to do whatever it is that is in the Recom.  For me, it was just easier to use something already assembled and CE certified.
Ciao,
Lenny

There might be a point. I already thought about the Recom when looking the first time at your schematics, and now a second time and still can't see a clear advantage for one of the Traco TSR or the Recom solution. There is much bigger stock here in Europe for the Traco, there are more big worldwide distributors holding the Recom devices. I prefer the Recom's SMD package and now the power down pin. The TSR has a larger input voltage range and bigger current, and its less expensive here in Europe. And finally, I use the TSR for several years now, the component does the work and while having done several redesigns caused by components disappearing from the market, the TSR is still there. And I don't like much the diode in the output with the resistor to adapt output voltage, because changing current consumption has influence on the output voltage. I finally put the question on the ToDo list for the next revision!

Thank you again,
   Bernt

LROBBINS

Recom is made in Germany and stocked by RS.  Traco is, of course, widely available everywhere, and I think that they also have models with sense pins, and Traco is even cheaper if you order from China.  The Recom, though it costs a bit more, has tighter EMI certification, but it's mostly six of one half a dozen of the other.  Ciao, Lenny

P.S. I haven't checked the tracor data sheets, but what do they say about reverse voltage on the output if there's no voltage at the input?  Also, if you don't like a blocking diode, you can use a bypass diode instead.  You probably know this already, but as you design your own enable circuit, make sure that you can never have voltage on an FET gate if that FET is un-powered.

LROBBINS

A couple added comments and a bit of update.

Bernt.  I was thinking about your adding an external circuit to control a DC-DC converter, and just wanted to suggest something to consider while you are designing it.  If possible, you might want it to trigger ON at (CANH+CANL)/2 <= 1.6V so that it would work if you ever used a 3.3V transceiver instead of the MCP2551, or at least have the possibility of just changing some component values for it to work with both types of transceiver.  The Recom will not be suitable for this: the minimum ON trigger voltage is 2.4V rising, typical 2.6V.  It does provide a kind of secondary brown out protection, however, as (CANH+CANL)/2 going <1.6V (power supply falling to < ca. 3.4V) will cause it to turn OFF taking that node off net.

Rob.  I have been thinking further about your worry that I don't fault check until after averaging analog reads of the joystick.  My last comment had been that given the inertia of a wheel chair, I doubted that this could physically be a safety issue, but it bothered me that I hadn't actually checked this.  So I did check how far a chair could move if a fault was not detected until the end of a second averaging set.  I made some conservative assumptions, so this is really worst case:
(1) from the motor characteristic curves, maximum torque at 150 Amp limit is 203 Nm per motor.  (That is for a high quality, high torque, relatively low speed (8 kph) wheelchair motor; faster motors produce less torque, so using this number is conservative).
(2) I assume that torque remains constant as the chair accelerates, whereas it actually falls off with RPM.  Again, this is a very conservative assumption and I know it's not true, but the calculations get too complex if I include (for Rachi's motors), torque = -1.037*RPM + 136.46 and have to integrate.  (I have always hated working with integrals.)
(3) force generated on a 18 cm (7") radius wheel is therefore 2288N for two motors, and acceleration is 15.25m/s^2 for a 150 kg chair+driver (Rachele is quite light, a heavier user would accelerate less, so, again, a conservative assumption).
(4) A fault within the first few analog reads would be detected in that cycle as the average would be out of bounds, but I calculated distance traveled assuming that the fault isn't detected until 2 full cycles through loop (). 
(5) With  20 reads/average, measured loop cycle time is 11 msec, and with 200 reads/average it is 86.5 msec.
(6) From rest to fault detection, this means that the chair would travel 0.09 cm (20 reads/average) or 5.7 cm (200 reads/average), and the total distance from undetected fault to full stop is twice that.  Clearly, 0.18 cm of travel isn't going to be in any way dangerous (it's less than the sidewall flex of the tires), but 11.4 cm might be getting toward worrisome.  For now, I'll leave the code as it is as I don't know how much averaging is actually needed.  If it turns out that we need 100 or more reads/average, I will find averages at some part-way points as well.  I think that this approach is a safe compromise between excessive travel caused by delayed fault detection and "false" detections that would cause (quite unsafe in many circumstances, and extremely uncomfortable in all circumstances) emergency stop reactions.

OK, with this I've at least satisfied myself that my intuition wasn't misleading me.

General:

(1) There are a number of situations in which we might want to reduce a chair's speed: rough terrain (for about a year now Rachele's chair has had a 3-axis accelerometer and Uno to do this), changes in geometry with seat lift or tilt (e.g. limit switches) etc.  Detecting these signals is part of the Aux node's role and it now sets a byte SpeedSlow to 0 (don't move), 1 (very slow), 2 (slow) or 4 normal.  At first I handled this as a query/response in the same way Master asked Roboteq for, say, a battery amps value, but we need to respond to SpeedSlow if it changes with little latency.  Hence, I was doing the query/response in every cycle through Master's loop().  Given that it's ridiculous to query every few milliseconds for something that will change at most a few times a day, this seemed like a terribly wasteful way to do things so I've now inverted the logic.  Aux broadcasts a SpeedSlow message any time it detects a change, and Master checks the ID every time it reads a message to see whether a SpeedSlow message has arrived.  If a SpeedSlow message has arrived, Master then sends a confirmation message to Aux.  Aux continues sending the SpeedSlow message until it receives the confirmation, then stops doing so until the value of SpeedSlow again changes.  This reduced Master's loop cycle time by 384 microseconds.

(2) The way I'd programmed Query/Response or Command/Confirm, both the Query and Response or both the Command and Confirm were repeated until OK, or a fault was declared.  By watching ID values when these repetitions occurred, I realized that this too is time wasteful.  There have been only two circumstances in which a repeat Query/Response or Command/Confirm was needed: if a receive buffer still had some irrelevant message, or if the other node hadn't yet sent its reply.  Thus, what needs to be repeated is not the whole Query/Response or Command/Confirm (a complete loop() each time), but just the buffer reads (hardly any time at all compared to loop() for even 50 MCP2151 buffer reads).  So, I've restructured things to do this, but (for safety's sake) I also repeat the Query/Response or Command/Confirm once if just repeating message reads doesn't validate the messaging and then declare a fault .  Previously, depending on various conditions, as much as a third of all loop cycles were taken up with repeating Query/Response or Command/Confirm; that's now been reduced to zero.  So far, the longest latency I've seen is 10-11 buffer reads until the message arrives from the other node, most often it's 5-7, and validation has never needed a repeat of a Query/Response or Command/Confirm doublet.

(3) I've been running the net at 1 Mbps, figuring on using say 250 kbps on the chair to have a nice safety margin, but I've now also tested it at 10 kbps to see if restricted bandwidth would expose any bugs in my programming.  The net and programs work just as well at 10 kbps, and surprisingly, I didn't sense any loss of responsiveness when twiddling my "joystick" pots.  I guess a wheelchair just plain doesn't need the bandwidth of an automotive ECU.

I think that's about all I've gotten done, aside from tweaking component values for the DC-DC converter, since my last summary.  There's lots more yet to be done, so you can expect some more of my verbose postings down the road.

Ciao,
Lenny

bernt

Hi Lenny and Rob,

Thank you Lenny, for the idea for 3.3V logic, I would never have thought so far.

Some of Rob's ideas are going into the protocol. Our approach is somewhat reversed compared to yours Rob, no documentation and hands-on first. Yellowsky is already programming, documentation has to be done once things work.  This morning LEDs were blinking on two separate nodes, synchronized to 250us, which is not yet good but probably sufficient for most applications. There is no code to show yet, these are just early trials.

For the bootloading over CAN stuff, I sent Yellowsky's adaptation to Arduino back to the original author last week, who said he could probably start to put more of his programming on github (before having seen our not perfect code). If somebody is interested in seeing the code earlier, I could publish it as is.

Have a nice evening,
   Bernt

Graynomad

Quote
Our approach is somewhat reversed compared to yours Rob,

Yes, I'm all doco and no do, you're at least getting something done :)

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

LROBBINS

Having returned a week ago from a wonderful week of vacation in the mountains and by the sea in Abruzzo, I thought it well to tie up some loose ends in this project and to post the current program and circuit files. They are attached below. I won't bore you with all of the changes, but I have tried to keep a "change log" of the programming changes/additions in comments at the end of the Arduino files. I think that this is now close to a final version for 3 of the 4 nodes needed, except for adding CAN messaging to the fourth node (the display) that I've not yet started on. The circuitry should also be close to a "production" version, except for the high-current stuff for lights, seat actuators and so on. Major changes are: (1) single button control of power to all of the nodes (including the Roboteq), (2) fault handling for four levels of criticality (is that a word?), (3) multi-level speed inhibition triggered by actuator position and/or shock(stability) sensors, (4) reading and responding to Roboteq fault and status flags. There were also a lot of detail changes to improve (I hope) readability of the code and CAN network and power management. The circuit files include both pdf and DesignSpark versions.

The next big chunk to work on is a display node. Because Rachi's set-up will have both switch driving and attendant joystick, and I'm keeping track of both voltage and amp-hours used, there's a fair amount of information to display and a small screen (about 2" diagonal) can't be avoided. I've explored the notion of using an e-paper screen because of its daylight readability, but it's probably not practical yet so I'll most likely be using a TFT screen which will, unfortunately, probably be unreadable in sunny (at the moment) Siena. The problem with e-paper is that one can't re-write just a portion of the screen as information changes -- you have to un-do everything that's there and re-write every pixel on the screen at each update. That requires a lot more memory than is in the processors I'm using, and using something like an SD card for this would be far, far too slow. There are some reasonably priced e-paper boards that have their own 32-bit processors with lots of RAM, but that would mean having yet a third programming environment (on top of Arduino's C++ and Roboteq's Roborun+MicroBASIC) and I'm not willing to do that. If anyone has a suggestion about small, serial-interface (SPI or other) graphics boards, monochrome or color, that are good in strong daylight, I'd love to hear it. Or if anyone can suggest a solution for dealing with e-paper from an 8-bit MCU (for example, an SPI FRAM chip breakout board) I'd like to hear of that as well.

Ciao,
Lenny

bernt

Hello Lenny,

I just took a quick look on your schematics and here come my random questions and remarks :
- Why do you use 10 uF electrolytic capacitors and not ceramic multilayer versions ?
- The optional diode D3 on the switch multiplexer, isn't it put it the reverse direction ?
- The diode has no direction mark on the silk screen.
- I don't fully understand what the multiplexer board does, does the relay switch inductive loads ? If so, the free wheeling diode is missing in the output.
- All the logic of the multiplexer board, couldn't it be advantageously replaced by a CPLD or even a micro-controller ? This would allow to correct errors in software, allow to reprogram interconnections when needed and perhaps to make it smaller and easer to assemble.

All those are surely only details.

Thank you for sharing your work,
   Bernt

LROBBINS

Bernt,
Maybe details, but I think that they're important ones.
Quote
Why do you use 10 uF electrolytic capacitors and not ceramic multilayer versions ?
Ignorance and age (mine).  I was not even aware that uF range ceramics had become affordable; I'm still working upfrom a vacuum-tube era knowledge base.  The data sheets for these are pretty thin, but there's a pretty comprehensive Wikipedia (http://en.wikipedia.org/wiki/Ceramic_capacitor).  I will make this change, even for the Al can input capacitor on the DC converter boards.
Quote
The optional diode D3 on the switch multiplexer, isn't it put it the reverse direction ?
Thank you - that was a just plain goof and I've already fixed the drawings.
Quote
I don't fully understand what the multiplexer board does,
This design was a quick translation to 5V SMD from the 12V hand-wired board that's been on Rachi's chair for the last 13 years.  It gives 3 sets of outputs from one group of 5 input switches (more below).
Quote
does the relay switch inductive loads ? If so, the free wheeling diode is missing in the output.
No, the load is an SSR to switch 220V AC loads such as from a kitchen mixer.  However, I see no reason to not add a kickback diode in case something else ever gets plugged in there.
Quote
All the logic of the multiplexer board, couldn't it be advantageously replaced by a CPLD or even a micro-controller ?
Yes, it could, but there was a reason for cho0sing the 4066 when I made the first one of these 20+ years ago and I think it's still valid.  One can control a wide range of external circuits to the output of these switches without worries about polarity, or whether you need to switch DC or AC.  (There is, unfortunately, a limit to this as polarity can become important if the voltage on the controlled line exceeds Vdd on the 4066.)  For something that is essentially a patch board with lots of 3.5mm jacks, I think that this is a useful safety and flexibility factor.  As presently used, and as will be used in the new system, one output set goes to the CANbus WC controller (presently a Dynamic DX controller), one output set goes to a board stolen from a cheap USB keyboard for input to Rachi's PC, and just two outputs of the third set are used to flip the latching relay or connected directly to the external SSR when latching isn't wanted.  Before major mechanical improvements to the chair, the last two unused 4066 gates also controlled an optical-sensing steering correction servo, that is no longer needed as we have powerful-enough motors that simple IR motor compensation works the way it should instead of running out of torque to overcome the mechanical hysteresis of casters displaced after a turn.  On her original chair, about 25 years ago, that had a single-board analog controller, the chair-driving set of outputs selected voltage dividers to mimic an analog joystick (and, in that case, were handling both positive and negative DC signals).  The physical size of the box is actually fixed by needing to mount 15 mini phone jacks, not by the size of the board.  A programmable multiplexer would be nice, but not at the cost of giving up the flexibility of connecting different output types (and protection from someone, most likely me, plugging in something that's incompatible).
Quote
The diode has no direction mark on the silk screen.
Actually, none of the diodes, on this board or the others, have polarity marked on the silkscreen, and adding that to the DesignSpark footprints is a very good idea.  It's even worse than that on the multiplexer board as the PCB footprint came from an old library and is 0805 but should be DO-214.

Ooops. I have to go pick up my daughter and I'd lost track of time.  Be back later.
Ciao,
Lenny

Graynomad

Quote
A programmable multiplexer would be nice, but not at the cost of giving up the flexibility of connecting different output types

If you are referring to the polarity issue how about using a crosspoint switch?

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

LROBBINS

Rob,

A crosspoint switch or another (non-matrix) analog mux (or is it a demux) would certainly reduce package count, and could handle both polarities, but I haven't come across any that are also as voltage-tolerant as the simple analog switch.  Although one has to pay attention to polarity when switching >Vdd, the 4066 can connect without level-shifting to 3.3V or 5V logic, an audio line with a DC component, or a low-current 12V supply to a small amplifier.  Do you know of any devices that package ca. 20 switches that have that kind of tolerance?
Ciao,
Lenny

Graynomad

Have a look at

AD75019, 16x16, 24v or +-12v
CD22M3494, 8x16, 4-15v
MAX4456, 8x8, +-12 I think

I don't know if they are suitable WRT voltages relative to Vdd etc but maybe.

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

LROBBINS

Thanks Rob.  I'll take a look at them, especially the CD22M3494 as I could power that one from 5V if the output characteristics are what I want.  Ciao, Lenny

LROBBINS

An aside, but perhaps useful information for anyone contemplating using mini phone jacks in a vibration/shock environment like that of a wheelchair.  Most of the jacks on the market use bent flat metal strips as both contact and spring.  They lose contact integrity after a short while.  Switchcraft (perhaps others as well, I just don't know) makes a line with coil springs and hinged contacts.  Pricey, but they last years and years.
Ciao,
Lenny

LROBBINS

Rob,
I've taken a look at several crosspoint switch data sheets.  Impressive devices, but they won't do what I need.  In general, the analog outputs can't go outside Vdd, but, of more importance, as all switches have one side in common they are either all "positive" or all "negative".  With the 4066, for any given input signal I have 3 analog switches that are completely independent with two leads each just like on physical switches.  They are all bipolar for analog voltages <= Vdd, but need to be treated as polarized, or have a current limiting resistor, if the analog signal is > Vdd.  Five 4066-type chips are also a lot cheaper than 1 crosspoint switch and don't require an MCU, though an MCU on the input lines (in place of the 4049) could be used to add some flexibility if really wanted.  In summary, bulkier, but I think more robust for my purposes.
Ciao,
Lenny

Graynomad

Ok, worth a look I suppose. The good thing about the 4066 is that every man and his dog make them as well, the x-point switches are much more esoteric and single source which is a risk.

_____
Rob
Rob Gray aka the GRAYnomad www.robgray.com

Go Up