SalvageS10 Build Thread

[thingstodo]

Safety, Safety, Safety ... and cheap

Safety is a big concern for me. I work, and drive, by myself for the most part, so there is no one around to assist. When you are on your own, you SHOULD pay more attention to doing things safely.

I am likely planning to go a bit overboard on Safety, but that's just some healthy paranoia on my part.

Safety Inputs:
- forward/backward inertia switch
- side to side inertia switch
- emergency stop slap button

These inputs will be wired to two different input cards, so if one card fails, the other will report correctly. This is a bit paranoid.

The inputs will be wired so that they are normally 'ON' or have voltage present. If a cable is damaged, they go 'OFF' and the system behaves as if they were activated. This is pretty standard.

The safety inputs will also wired to remove the output power from the PLC outputs. This means that it does not really matter if the PLC turns off the outputs, their power supply turns off anyway. This is a bit paranoid, similar to the safety systems on petroleum plants.

There are a couple of analog inputs that will be quite important, but more so for equipment damage. There will be two encoders, both connected in about the same place. They are different resolutions and will connect to different input cards, so that I always know what the speed of the motor is. This is a bit paranoid. The accelerator and brake positions both have two position sensors, and they will be connected to different analog cards to ensure that they match, and that I always have one working (card failures are rare, but they happen). The battery and motor currents are too numerous to duplicate. So are the various temperatures for the VFD, motor, batteries, DC/DC converters, and PLC. The VFD will shut itself down on high temperature or high current, but the high current is what the electronics can take, not what the motor can take. In order to get acceptable acceleration from the system, the VFD settings for the motor are about double what they should be. This relates to equipment damage only, not safety. I'm relying on the mass of the iron in the motor to absorb some punishment, like 2 - 3 times the rated current for about 40 seconds on acceleration. This is one of the things that I'm planning to test.

The redundant inputs are the same channels on adjacent cards, so if a card fails or a sensor fails, switching the wiring arms between the cards isolates the problem quickly. This has worked well for me in the past on many systems.

There will be an output from the PLC that enables the VFD. When that signal is lost, the VFD goes to a 'safe' state. That is, it decelerates at it's programmed maximum safe rate (will not lock up the rear wheels and skid) and dumps the generated energy from slowing down a 5000 lb vehicle into a large heater connected to the DC brake resistor connections. Loss of the same enable signal from the PLC will also drop the high voltage power to the VFD, so that it cannot continue to supply power to the wheels.

There may be a large e-brake handle mounted between the driver and passenger that pulls a load-brake on the high voltage to the VFD. I have a breaker that is rated to break 1000 amps at 700 VDC. This is one of the things that I've seen on other EV builds. I am keeping this option open.

The important gauges will be driven directly by the sensors or via the PLC. The aim is to drive the truck comfortably with NO extra displays and NO additional computers, even an arduino. The arduino, the extra gauges and displays, the communications, will give more information, and it will be prettier, and make troubleshooting easier, but they are NOT REQUIRED to run the truck. PERIOD. Nothing with a hard drive, or a command line prompt, or a display controller will cause a failure and make the vehicle undrivable.

[thingstodo]

The DC input card, DC output card, Analog input card, and analog output card are communicating to the PLC.
- 24 VDC was applied to each input and they all show up where they should.
- 24 VDC was applied to the output card. Each output was driven. The indicator LEDs lit and turned on the input that it was wired to.
- DC input 1 is a bit sensitive. When the output turns off, the input stays on. The output, as a solid state device, 'leaks' about 0.5 mA when off. This is the only input that shows ON when the DC outputs turn off. It does turn off when 24V is removed.

The analog output card worked fine, but is 0 - 10V output instead of 4 - 20 mA (which is what I thought I purchased ... my bad)
- The analog output card has no external power required. The outputs were varied from 0 - 100% and measured with a multimeter.

The analog input card does not appear to work.
- 15V, 5V, 0V and -15V was applied to the analog input card (combinations of 9V and 1.5V batteries in series packs, through small regulators where required). 2, 4, 8, 15, 20 and 22 mA were applied to each channel and the results read into the PLC. no indication was observed at the PLC. I SHOULD have observed under-range, 0%, 25%, 75%, 100% and over-range. The -15V was measured at -14.65V +15 was measured at 14.8V. +5V was measured at 5.01V. Two analog input cards were tested. The results were the same, so I expect a problem with my setup. Two failed analog cards is not very likely.

Encoder
No progress so far on the encoder card. It does not accept communication signals from the PLC thus far.


The AC input and output cards were not tested yet.


1771-IF - the analog input card - Dip Switches as received
- sw1 - L - R, off/open, on/closed, on, off, off = 1/4 off gives stand-alone, sw2 on = bcd, sw 3 on gives block transfer, sw5 off gives normal operation not calibration
sw2 all ON or closed = 4 - 20 ma range.
sw3 off, off, on, on, off, on, off, on, off, off = 4 - 20 ma with SW2 set as it is.


Change switch 1-2 to off for binary, SW1 = FFOFF
Leave SW2 = OOOOOOOO
Leave SW3 = FFOOFOFOFF

1771-IK - encoder card - switches as received
SW1 - OOOFO - Single xfer, x 1, counter mode, binary
SW2 - OFF - pullup resistor, float, filter out 50 Khz

Change SW1-4 to ON, for encoder mode.
So SW1 shows as OOOOO, for Single xfer, x 1, encoder mode, binary

change SW2 - pullup and pulldown as required

register 0 - 11, 0 - 4095.
bit 12 - 1 = fault
bit 13 - 1 = borrow bit
bit 14 - 1 = carry bit
bit 15 - 1 = home bit, marker high, home latch high

control word, bit 8 and 9, 00 - count, 10 - reset accum count to 0, begin count immediately, 01 - reset to 000 and hold there
15, 14, 13, 12 - 1 0 0 0 for control word

memory mapped. no block transfer

[thingstodo]

I would like to UNDERSTAND how SalvageS10 works, to WORK on it when there are issues, and to GATHER every piece of information I can think of to assist me in WORKing on it

To accomplish that goal, I plan to connect an arduino to the serial port on the PLC5, logging all of the data that is sent out the serial port to a USB stick/Compact flash. This arduino will then source this data to the other displays - as yet undetermined. The logged data files will be downloaded to a PC daily for analysis and history.

The PLC will decide when information has changed, or when it needs to be reported. The plan is to have the Arduino acknowledge received data, pass through GPS data, and request an update to some data, but it is a limited interface.

Along with the Inputs and outputs, the PLC will be logging decisions. For example, based on .. speed, heading, position and a look-ahead of 5 seconds for the terrain from the map, the throttle setpoint was calculated as 98 kph for the Cruise setpoint of 100 kph. This is useful for troubleshooting cruise control, but has many other applications.

The arduino is also planned to gather environmental data such as outside air temperature, wind speed and direction, barometric pressure, and anything else that I can think of. If I see a troublesome trend, I want to be able to correlate it will anything and everything and determine what is important.

Another arduino is planned to interface to the OBDII interface and the ability to 'fake' these signals for the systems that require it. The idea is to be able to run a vehicle like it still has it's ICE engine and ECU. It could also provide information to a scangauge or other third party OBDII devices, if I get around to that part.

[thingstodo]

Originally Posted by thingstodo

The analog input card does not appear to work.

Happily, I had a poor connection on one jumper for the 1771-IF analog input card. The jumper was designed to be an input from an old linear power supply that indicates that the voltage from the power supply, +15V, common, -15V and a separate +5V and common are all stable and within published specifications.

The jumper was not making contact - either corrosion or errant insulation that was not properly stripped. It is working now thanks to two helpful experts at the PLCS.net forum.

Now, with proper voltage applied, the analog input card measures all 8 channels of 4 - 20 mA input signals
- 2, 4, 8, 15, 20 and 22 mA were applied to each channel, I DID observe under-range, 0%, 25%, 75%, 100% and over-range.
- the spare analog card also works fine.

Originally Posted by thingstodo

Encoder
No progress so far on the encoder card. It does not accept communication signals from the PLC thus far.

The 1771-IK encoder card does not work as I expected. Instead of having the 16 bits of input and output addressed as the first slot occupied by the 2-slot card ... the first 8 bits are accessed in the first slot and the second or upper 8 bits of the inputs and outputs are accessed as the first 8 bits in the second slot.

Many thanks to another expert at PLCS.net for pointing out the solution in Allen Bradley's knowledgebase tech support database.

[thingstodo]

PLC Programming is under way - until the next challenge is found.
- I need some code working with the encoder rollover/rollunder to verify that I can monitor an electric motor turning at 2500 rpm, driving the 1024 pulse per revolution encoder that I have.
- I have a bit of code to write for doing Pulse-Width Modulation of a 24 VDC output. This is intended for testing, in my basement, a small DC motor instead of a 40 HP VFD. If I can control the speed of an unloaded DC motor, which drives an encoder, the system and instrumentation should be fast enough to control a 40 HP motor with a 5000 lb truck as a load.
- The 24 VDC motor will give me an opportunity to test a current shunt, a smaller scale DC voltage input, and DC voltage inputs for a small DC battery pack.

I've been side-tracked a little bit by an open-source HMI called AdvancedHMI, which is at version 3 and available on sourceforge.

I loaded it onto an older laptop and am trying to get it up and running. If I can, it should simplify debugging and datalogging.

I'll post links if it works out.

[thingstodo]

The PLC5/60 is reading the encoder signal (or count) once every 10 ms and appears to be keeping track of the revolutions that the drill is turning

1260 rpm is what the PLC calculated for a speed. I have to dig through my pile of tools and locate my tachometer to measure out the actual speed.

1260 rpm is 21 revolutions per second. At 1024 pulses per revolution, that's 21504 pulses per second. Every 10 ms that is 215 pulses. It's not clear if that works out to 21.5 Khz or if the A and B channels add, for 43 Khz.

The IK card states that it can deal with 50,000 Hz. That works out to 500 pulses in 10 ms, just under half of a revolution. 50 revolutions per second is just over twice the speed that my drill is turning (or that the encoder shows that the drill is turning.

More testing tomorrow.

[thingstodo]

Check the cordless drill speed. Tach lists 1160 - 1162 rpm
The PLC/encoder combination lists 1166 to 1172 based on a 10 second sample time multiplied by 6.

That's not fast enough. I need to check if the electric motor can run 2500 rpm or so.
Use a small router ( 25000 rpm no load) with a variac to adjust the speed.

The coupling is a bit of an issue. I ended up holding the router up against a liner of plastic pipe on the encoder. Any type of solid mount ended up binding quite badly within a few seconds. The router vibrates since it is not centered well. The alignment goes bad and puts a load on the router, which slows. The router bit (old and dull as it is) starts to chew up the plastic pipe and the router starts to spin faster than the encoder ... and the test is done.

So I held the router with one hand, with the encoder shimmed and clamped. The other hand adjusts the variac and checks the rpm with a digital tach. It's a slow process. And not too very accurate!

So here are the results:
- 1236 - 1260 rpm on the plc/encoder. Measures 1211 - 1230 rpm on the tach
- 1560 - 1674 rpm on the plc/encoder. Measures 1730 - 1766 rpm on the tach
- 2040 - 2100 rpm on the plc/encdoer. Measures 2001 - 2012 rpm on the tach
- 2400 rpm (solid) on the plc/encoder. Measures 3318 - 3330 rpm on the tach.

This tells me that I have a measurement limit at 2400 rpm or a problem with my program that won't allow it to measure higher than that.

So I think that I can reasonably measure at least 2000 rpm, likely closer to 2300.

I took my router, mounted it on a piece of scrap wood, mounted that to the bench, and added a friction coupler to turn the encoder. After tightening things up to that the encoder turned, the coupler split. And so did the next one. I'm having trouble locating something that will fit into the router and will also fit into the 5/8 hole in the encoder hub.

The adventure will continue - and I'll post some pictures so that you can see what I'm actually talking about.

[thingstodo]

The router mounting proved too much trouble. Every coupler that I came up with required more mechanical skill than I have. I split couplers, I clamped things with straps, clamps, screwed things down ... all failed. Holding a router with one hand, making adjustments to speed with the other, and remembering the data does not work for me.

So I found something different. I have a 10,000 rpm side grinder. The middle of the disk appears to be about the same size as the encoder disc.

So I can use the Variac to adjust the speed of the grinder, mount the grinder to my shelving, then use a friction drive between the encoder and the grinder disc. I used electrical tape and that worked OK for me.

See the picture for a bit more info. I have the PLC on the middle shelf, the 12V power supply below, the Variac on top. The tach is strapped to a piece of scrap lumber and aimed at the encoder disc. The encoder disc has electrical tape on it to block reflection of the laser tach for most of the revolution and a small window is shiny aluminum that reflects well. The side grinder is clamped to the top shelf and the handle drops through a hole in the shelf.

The blue laplink cable connects to the 25 pin serial port on the PLC, set for 19200 baud, BCC error protection, no parity, 1 stop bit. The laptop is an older Dell D820 running DOS 7.0 and the old Allen Bradley 6200 series programming software. The laptop display is showing the calculated RPM by measuring the pulses in one second and scaling to rpm as well as the number of pulses in 10 seconds and scaling to rpm.

Variac tach encoder/60 encoder/6
10 112 120 114
15 600 540 588
20 1179 1260 1212
25 1780 1740 1752
30 2720 2760 2550
35 4000 2160 1824

The encoder has 1024 pulses per revolution. At 2720 rpm, that is 2720 * 1024 = 2785280 pulses per minute. Since there are 60 seconds in a minute, that is 46421 pulses per second, which is pretty close to our rated maximum of 50 Khz.

So under ideal conditions - well shielded cable, good connections, etc - I should be able to measure 2929 rpm.

From the ev calculator, that's over 90 mph (which is 2875 rpm). I think that a reliable 2200 rpm (just under 70 mph) is a reasonable target.

This part of the investigation is done - the encoder signal can be read for the speed range that is useful for me.

Next - how can I drive a 'dashboard' so I don't need to keep looking at the PLC programming software to see information that I need.

[thingstodo]

Originally Posted by thingstodo

I've been side-tracked a little bit by an open-source HMI called AdvancedHMI, which is at version 3 and available on sourceforge.

I loaded it onto an older laptop and am trying to get it up and running. If I can, it should simplify debugging and datalogging.

I'll post links if it works out.

Well, the drivers will presently communicate to SLCs and micrologix, ControlLogix, and modicon. The PLC5 is not supported, so I guess this is not a practical option, at least for now.

It DID sound pretty interesting ...

[thingstodo]

Another long post ...

Well, it's not REALLY a video game. But that's what I call my 'TEST environment'. It's going to be a test bench of sorts that lets me 'shake out' some of the obvious bugs before I get to the real truck.

The PLC5 will be set up and wired as it will be in the Truck (well, as close as I can make it). The software will have a few signals ignored because they are not there, but I will be doing everything within reason to make it as real as I can.

First - the simulated truck motor.

The PLC5 will have one output wired to a cordless drill. A calculation based on the VFD speed reference (that won't be connected to anything) will drive the drill. Forward and reverse are ignored. The drill will be wired from 2 12V gel cells in series through a DC output on the PLC that only switches at about 100 Hz. The 32 different patterns should give 32 different no-load speeds. The motor is unloaded and may jerk a bit, but it should turn an arbor that has one encoder mounted on it and the encoder will be wired back to the PLC. That's my drive train simulation.

The accelerator/brake

The 'accelerator' signal will not be a 'real one' - likely a potentiometer connected to an analog input ... perhaps a modification of an old analog joystick. The speed reference will generate the expected signal to the VFD, which will 'look up' a code pattern for the single digital output to make the 24V drill turn. It's a crude PWM signal, but it should work. The brake will likely be identical, but connected to a separate input.

The Real S10 digital instrument cluster consists of, top row, left to right ...
Gas gauge, battery voltage, signals indicators over the digital speed, temperature, oil pressure
bottom row, left to right
Service engine soon idiot light, seat belt indicator, ebrake indication, anti-lock brake status, high beam indicator, parking light indicator
Above the P R N O D 2 1 indicator is the odometer
to the right on the second level is the tachometer

The cockpit

The 'video grame' drivers seat is a chair at a desk. The instrument cluster will be a number of surplus 50 ua - 500 ua gauge movements wired to an analog output card. These 'video game dashboard' meter movements will have a few extra resistors wired in series and parallel to scale the output signal from the PLC. The meters are mostly 50 microamp.

The planned 'video game' dashboard

Top row, left to right
(1) amp-hours used meter, (2) voltage meter, a (3) temperature meter,
Bottom row, left to right
Planned for but not there yet are a few idiot lights as well - pre-charge/run, motor turning, ebrake, brake lights, etc.
(4) current meter (shows + and -), (5) Tachometer
I need an indication of the P R N O D 2 1 - for the first while it will be a number that is entered into the PLC.

I need to display a digital status that shows which voltage, current, and temperature the gauge represents.
Voltage is planned for:
- the battery pack total
- the difference between the split pack(to show imbalance)
- the ground leakage voltage

Current display is planned for
- the battery current
- motor current
- charger current
- ground leakage current

The temperature is planned for
- battery temperature
- motor temperature
- VFD temperature
- ambient temperature
- coolant temperature (if I go liquid cooled)

The plan is to cycle through these displays and have them calibrated so that green is 0 - 60%, yellow 60 - 80% and red above 80%, similar to a real cockpit. This is, of course, not the same as the real dash will be. I'll b e experimenting with that.

The PLC outputs to the dash will be set up as 0-10V signals for one card, that has 4 channels, driving meters 2,3,5. -10V - 10V is set up for meters 1,4 to show amp-hours outgoing or incoming and amps outgoing and incoming.

I guess we'll see how close I get to that. It should be useful for testing and debugging before building the truck. It may even be useful after the truck is built for testing changes before deploying.

It's a good way toprove that my full set of spares works ... being a paranoid ...