SalvageS10 Build Thread

[thingstodo]

This is a discussion of the shunt resistor used to measure the current in the VIDEO GAME ONLY - you would not waste battery energy like this in a working installation.

The battery shunt for the battery to the motor is a bit problematic. The hall effect current sensors I salvaged from a VFD are not the right range to measure 2 amps. The smallest I have are rated for 50A, as far as I can make out from the downloaded data sheets, even though that VFD was rated at 5 HP, 208V or 22A. I can measure 0 - 10V with a PLC input directly, but that would waste a LOT of the battery power as heat across a resistor to measure the current.

But this IS a VIDEO GAME, so wasting power should not be the issue. I need to get the formulas right. And I need to be as accurate as I can manage. If I need to use 3 batteries in series and 36V so that I can waste 10V on measuring current ... what's the problem with that?

So my 'shunt' needs to take about 1 amp continuous, 5 amps for a few seconds to spin up the grinder. My input is 10V, it should measure a maximum of 5.5A, that's just under 2 ohms. 2 ohms at maybe 2 amps continuous (I measured 1 amp, but that's without the encoder as a load). I have 10 Ohm, 0.25W resistors. 4 resistors in parallel would be ... 2.5 ohms and 1.0 W. Maybe I should check through my junk and see if I have anything that is rated a bit higher.

Success! The pre-charge resistors for some of the failed VFDs that I have salvaged are 8 ohms, at an unspecified wattage but they are ceramic and large. Significantly over 1 watt. To get 2 ohms, I need 4 in parallel. No problem, I seem to have about a dozen.

How large should I make the resistor? What are the trade-offs ... for a simulation?

There are 4096 counts of the analog to digital converter in the PLC input. So the PLC can measure 4096 different values. With a 10V range, that is 10.0V / 4096 counts = 2.44 mv per count. So if the count was 1, the voltage would be 2.44 mV. If it was 15, then the voltage would be 36.6 mV. Actually, 36.6 mV is the middle of where it could be. It could be as low as 35.16 mV and as high as 38.04 mV and still show as 15 counts ... but that's getting into fine details.

If I assume that my measured 1A is the minimum I'm going to see, that is 1.25V for the 10 ohm resistors and 2.00V for 4 of the 8 ohm resistors in parallel. 1.25V measured / 2.44 mv per count = 512 counts. At the other end of the range, 5.5 amps peak would be 5.5 * 1.25V = 6.875V Divide that by 2.44 mV and you get 2818 counts. That's over half scale, with a bit of room to make sure that the PLC input is not damaged by having the voltage too high. Repeating this for the 2 ohms (4 of the 8 ohm resistors in parallel) gives 1A * 2.0 ohms = 2.0V / 2.44mv per count = 820 counts for the minimum. 5.5A maximum * 2.0 ohms = 11V ... but 10.0V is as high as the input will measure. That's not going to work.

With 5 of the 8 ohm resistors in parallel, the resistance will be 1.6 ohms. Run through the numbers again. 1 A * 1.6 ohms = 1.6V measured / 2.44 mv per count = 656 counts. At the other end of the range, 5.5 amps peak would be 5.5 * 1.6V = 8.8V Divide that by 2.44 mV and you get 3607 counts.

512 counts per 1 amp load give me 1.95 ma or just under 2 mA per count. 656 counts gives me 1.52 ma, or just over 1.5 mA per count. I'll use 5 of the 8 ohm resistors for the better accuracy and because I have them. They could likely take 5A each ... they are 3.5 inches long (each) and .75 inches wide and .75 inches high.

I guess I have some wiring to do.

[thingstodo]

It should come as no surprise to anyone who's read this far that things did not go as planned.

Attached is a simple list of the connections that I began with. The power is routed from the battery pack, skips the PLC output for now, goes through the load, a 5A self-resetting fuse, the shunt resistor, an ammeter that I'm using to determine how accurate the shunt is, and finally back to the battery pack. So the PLC is not involved in driving the motor and is not measuring the voltage or current from the battery pack.

The idea is to check if my 5.5A maximum is still the same, now that I have the resistors in series. A simple check of the rest of the circuit was done with an ohmeter and all appears to be good.

Connect Power from the battery pack. Nothing appears to happen. The load does not rotate. I check the temperature of the shunt resistor - warm. Why would that be warm already? Check the maximum current on the clamp-on meter (on one leg of the load - not on the list of terminals since it does not connect to a terminal). 5.1A seems reasonable. Touch the self-resetting fuse ... it's HOT. Disconnect the battery pack. Check the fuse with a meter and it is open circuit (or above 100 Mega Ohms, at least) A 5A self-resetting fuse should not trip at 5.1A for a short time.

A self-resetting fuse looks like an automotive fuse, at least this one does. It has two leads, and it does not matter which way current flows through it. There is a strip inside that heats up and changes it's resistance quickly when more than rated current is put through it. This does not really 'turn off' the current, but it is reduced by a whole lot. Enough voltage is dropped across the fuse that the rest of the circuit basically does not function. This particular self-resetting fuse is stamped as 5A. I don't expect it to be super accurate, but a 5A fuse would normally run for several minutes at 5.5A and perhaps a minute at 7A and a few seconds at 10A. The specification sheet shows a curve of input current versus resistance.

I think that this would need to be a 0.5A self-resetting fuse to reduce the current so quickly without the load (my grinder) actually turning.

So I tried a different one. The grinder actually turned this time, but not enough to tell me anything more than the load DID get some current ... the peak current was captured at 5.0A. Something is very wrong here.

Remove the battery pack. Check each connection with an ohmeter. The connections check out. Check again after connecting the negative battery pack. There is a large drop in the resistance. It appears that by attaching a jumper cord to the terminal strip, the terminal strip rotates and puts some pressure on a poor wire connection, which then bridges across the load. The screw on the terminal strip was tight. I must have neglected to pull on the wire after tightening to verify that it was grasped well by the terminal ... I guess. It is difficult to see, but there appears to be a 'whisker' of copper wire that is not in the terminal and can touch the adjacent wire if the terminal block is rotated a bit. The first trial did NOT turn the load at all. The current seen by the clamp-on is a bit of a mystery. The rotation of the grinder in the second trial shows that the bridge is intermittent. I have no idea how much current went through the fuse. It DID do it's JOB .. in both cases.

To me, this again illustrates that a short cut is indeed the longest distance between two points. I saved maybe 20 minutes on the wiring by jamming things together. And I wasted an evening tracking down the problems.

The fix is to spread out the wiring, putting spare terminal blocks between those used, using wires on the terminal blocks, even the ones that I'll be connecting to alligator clips, so that the wires fit snugly and you can actually see where the wires go and what they do.

There are a couple more things that I take away from this:
- in NO CASE should you skip the FUSES! This limited the current and the result was NO DAMAGE.
- the sensors should be set up to handle worst case. In this case, 24V was dropped across the 1.6 ohms of shunt resistor. The voltage across the shunt was 24V. If the PLC analog input had been connected, as designed, that would have failed the PLC analog input, which can only deal with 18V maximum. So I need to add some protection to the PLC's analog input so that I don't blow up any equipment with silly wiring problems.

The wiring is a bit tedious. But it's important. I'll get things cleaned up and try again.

[thingstodo]

A bit of a change of pace ... switch from wiring to communications

I reviewed the requirements for my Arduino sketch:
- interface to GPS - accept data in standard format, parse, save info to memory and to file
- interface to PLC - accept data in text format, parse, save info to memory and to file
- select data from memory and display locally
- select data from memory and send out USB to local PC
- interface with Labview, data exchange

So this application is the hub of communications ...
- it accepts data from GPS and PLC when supplied, parses it into a usable form, stores it in memory and to diskdoes stuff to it, and stores it
- it supplies this data to a local display, a PC interface, or a Labview interface

To interface to several things at once, I will likely need an additional UART. This can likely be done with a software serial port if it is not very fast

Set up all of the serial interfaces
Activate interrupt handlers
main program loop waits for a data flag, then calls a few routines to process and log

Sounds pretty simple ... but I'm sure it will be a pain.

Nonsense ... this is the FUN part!

[thingstodo]

Sketch Logger

Start with the hardware serial port connected to USB and to PLC
Read a line from PLC (actually from laptop via debug port)
Parse the line into variables
print variables

sscanf does not want to work with the input buffer. It expects a string, an array of characters. The String object, the Arduino String, has an array of characters but it also has a length as well as other stuff.

I found a copy from String to a normal C character array. sscanf works with the integers .. but not with the floating point value?

That seems to work after a few iterations. The floating point variable still does not want to scan ...

But this is progress ... the string that my PLC sends out is parsed into integers and stored in memory.

[thingstodo]

Sketch LoggerGraphics

Try the 4D OLED shield, a 1.7 inch OLED with a built-in joystick, a speaker ... this is pretty complicated, and WAY overkill for what I need. This thing is a user interface that can be used on it's own, without the arduino!

The splash screen shows on powerup. I need to initialize the screen by sending a 'U', then send commands to display text.

After many iterations, some web searchs, reading the manual ... I got to the point of initializing the autobaud so the splash screen does not show. That's it for progress.

No display of any text as yet. The 'simple' serial interface still requires a bunch of numbers, X and Y starting location, text color, font number, etc. 'Hello world\n' requires 6 numbers before the text string. The text color is a 2-byte string, but there is no explanation of how to choose the colors or what the bits mean.

If the order was changed, with the text string first, the program interface could leave parameters that are not supplied as 'default'. No provision for that.

/Begin rant

The web site has no examples to get 'something' working. I think that the Arduino has spoiled me for the normal ****ty documentation that comes with products... maybe its not the documentation, maybe I can't figure out how to print control characters from the Arduino ... but the IDEA that it makes SENSE to send 6 control codes to display a simple text string. That the way a GEEK thinks ... no one who has USED other people's code would think that is a good way to do things. Why NOT have the program interface over-ride parameters that are not supplied with defaults that just MAKE SENSE?

end rant/

[thingstodo]

Sketch BarometricPressureWebServer

Gave up on the OLED interface. Let's try the ethernet shield.
Copy the example script and change the hard-coded ip address. Download and it compiles and downloads! This is within 5 minutes of opening the box.

Connect the ethernet port to my router with a cat5 cable. Connect to 192.168.0.20 with my web browser and I get a (very basic, text only) web page!
THAT'S WHY THE ARDUINO IS SO POPULAR. YOU PLUG IT IN, LOAD THE EXAMPLE, AND IT WORKS!
Total time from plug it in to a display on my laptop web browser - 20 minutes. Compare that to the OLED above - 2 hours and nothing works.

Sketch LoggerWeb

Now to make it work with my Logger program.
Copy chunks from the example into my script.
The code appears to need SPI.h ... hmm

After a few program/compile/load/test cycles ... everything that I print out as a debug to the serial port/Arduino monitor now also displays on the web page. I need to keep refreshing it .. but that's OK for now.

Hey, my Nook(book reader) has a web browser. How about I see
if the web page displays on there? 192.168.0.20 ... it does!

Making something work ... a feeling like no other!

[thingstodo]

This is quite exciting. I now have:
- a serial interface on the arduino UNO that looks like it will work with the output from my PLC
- an ethernet interface that looks like it will display info from the PLC to a web page
- the web page display works through a wireless router - wire is required from the arduino to the router, but the displays do not need to be wired to the router. Wireless works fine.

Next on the agenda:
- get a second serial port working on the Arduino so that it can capture GPS data as well
- solder up the datalogging shield. Use the examples to add logging of the data from the PLC to a data file on the compactflash. Log GPS
data there as well as weather station info if I can get that into the Arduino as well
- research the OLED shield some more, find some examples, and get it working so that I have a local display that will show me some data without the router, nook, etc
- work on the excel spreadsheet to trend the data that is logged by the datalogging shield
- see if there is a CAN enabled version of the Arduino, or a shield, so that I can log this type of data for my CAR

[thingstodo]

Originally Posted by thingstodo

...Next on the agenda:
- get a second serial port working on the Arduino so that it can capture GPS data as well...

Things did not go as planned this week. You may remember that I'm using an older laptop to program the Allen Bradley PLC 5/60 - the industrial computer that will be controlling SalvageS10 along with a modified industrial VFD.

Well, hardware eventually stops working. In this case, the LCD screen on the laptop stopped working ... sort of. The backlight appears to be on at full brightness all of the time, making the screen hard to read. The whole display 'ghosts' all of the time, so moving the mouse is an adventure in locating the pointer first of all, then making a series of moves that bring the pointer closer to what you remember was likely the icon you wanted to use ...

An external monitor helps, as the video card still seems to work OK. But the external monitor has a minimum resolution of 800 x 600, it will not run at 640 x 480 (plain jane VGA), which is how the laptop boots to dos. So I can't change the PLC program right now, or see what's going on inside.
(Correction from later - This monitor works at 640 x 480 just fine. I just need to turn on the external monitor, which the BIOS won't do on power up until after the POST. After that FN+F6 turns on the external VGA monitor)

While trying to locate an older monitor to use, this problem has helped me to see that I was very dependent on this old laptop for troubleshooting and programming. I have a spare (sometimes several) for every part that I'm planning to put into the truck ... and the laptop is not required to RUN the truck ... but it really IS required for any sort of troubleshooting. So I need to set up a 'spare'.

I was not successful, in my original search for a programming PC, in locating a DOS driver for PC cards (or PCMCIA), so a couple of my older laptops cannot be used simply because there is no serial port on them. The version that I'm running right now has drivers for USB storage, but not USB serial interfaces.

My 'newest' retired desktop is a P4 of some type ... but I think it still ran a Voodoo 2 video card, if anyone remembers those ... it may start up in VGA mode ... I guess we'll see. It's not exactly portable, but it can be moved and set up ... with some effort.

It's getting pretty old, and you can't purchase ... I think it was IDE hard drives (not eIDE, or Sata) any more, so it may be limited as a backup.

[thingstodo]

The wiring update is close to completion, but not quite there yet.

I needed to change the wiring on my 'video game'. The shelf that the PLC was sitting on was not set up for backplates. There was some re-organization needed. I added another set of terminal blocks, some small salvaged wire ducts. I bolted down the grinder. The coupler for the encoder is now a 'cone' that should self-center ... I guess we'll see ... the PLC is hanging on the backplate. The backplates give the shelf some structure - it's more rigid. The wires are easier to see. The labels are not all on yet, but I've got a start.

I managed to lose two fuse blocks between packing up the parts and putting them all back in ... I must have carried them away and put them down somewhere. They NEED to be in there before things are powered up.

The power supplies are set up as -15V, 0V, +15V, +5V. This is for the encoder input card, analog input card, the analog output card, and the digital input card.

The 25.2V from the 'battery bank' supplies the digital output card and is measured for the analog voltage and the current driving the grinder motor/ being charged by the battery charger.

[thingstodo]

Wiring was completed last night.

Turned it on and the fuse on the PLC output card blew. The shunt resistor limited the current to 25.2V / 1.6 ohms = 15.75 amps if there is no resistance in the load.

The fuse that blew was a 10 amp slow-blow. The 5A self-resetting fuse is still in the circuit ... I messed something up.

Perhaps I don't need to control the speed of the grinder with the PLC. I can test basic stuff with a display, then use the variac to change the speed of the grinder ... until I track down my wiring error. Perhaps it isn't an error in wiring, but an error in how I expected the PLC output to act.

I will go through my assumptions and test a few things on low-current loads ... tomorrow