Paul & Sabrina's cheap DIY 144v motor controller

[MPaulHolmes]

The thermistor is pushed into a hole that's drilled into the heat spreader, so there would have to be leads that get connected to the control section. I think those Molex connectors, that plug into pins that get soldered to the PCB, like the ribbon cable inside the computer would work really well. I don't know a good way to coat the bus bars. Can it be spray painted? Or does it have to be electrolysis?

[esoneson]

Boy, we are really coming a long way here. Such great ideas, great improvements and additions.

Up to this point Paul has been handling all the integration of parts, design, ideas, features, etc, etc.... Great job Paul!!!!

And now we have several enthusiasts that are chomping at the bit to get going with implementation. Gee, even before Ben has had a chance to do a full 144 Volt test. This only shows the confidence of the masses in the fine design of the Paul and Sabrina motor controller (name TBD).

At this point I will urge the incorporation of version control to the design. Yes, I know, version control may sound like overkill at this stage but it will help all of us when comparing our implementations. And vastly help the designer (Paul.....Yowza!) to maintain a history of changes and why the changes were made.

I have been involved in software/hardware development for more years than I care to think about. It may be a pain in the butt to get set up, but please start thinking about it now.

We need version control on 1) Parts list, 2) schematic, 3) Software, 4)(not quite there, yet but) PCB layout.

It is easy to add version control by hand but it is so very much more useful to use a program to handle it. There will be a need to relate bug descriptions to bug fixes to changes in parts/code/schematic/layout and to versions of those components.

I will look into some choices, but if anyone out there has a favorite version control tool (free, easy to use, simple, open source product that Paul could use) please bring it to the discussion.

This will also enable us, when adding big features and design changes, to integrate them and give back to the open source community as alternate motor controller designs. Example: I would like to be able to control two motors at the same time with one controller.

Version Control.....think about it. Let me know what you think.

Thanks,

Eric

[Roger Heuckeroth]

There has been a lot of discussion on the EVDL about corrosion caused by dissimilar metals. When you put two dissimilar metals together they act like a battery, and one metal gets oxidized and the other gets reduced. Two metals that are very prone to this effect are aluminum and copper. Whenever those two metals come in direct contact they will have this red/ox reaction. So, for example when a copper heat spreader comes in contact with an aluminum heat sink without an intermediate metal, of something like Noalox, or Oxguard. When an metal like zinc, lead, or gold are used to separate that metal to metal contact, the potential goes may down. On little parts on computers gold is sometimes used, because it is the best, and the amount used is tiny. Two other metals with a high dissimilarity are copper and steel. So, this is just something to keep in mind when designing the power section of the controller.

I think Eric is right. It would be nice to have version control. I don't have any experience in it so I can't really be of any help there. Maybe just a simple spread sheet would work, along with labeling schematics, and parts lists with Rev X.XX, or something. Again this is not my forte, but I can see the value in it.

[GrahamMc]

Roger-
Dissimilar metal corrosion requires an electrolyte to occur. If the dissimilar metals in question are kept completely dry, it will never be a problem. Might be a good reason for a good enclosure. I am trying my first attachment here, it is a chart that helps determine whether or not 2 metals qualify as dissimilar. You draw a line between them on the scale and if they cross in the acceptable range it is ok to use them. Thought you might be interested.

I agree about the version control, but right now it is essentially Paul's baby and so the brunt of that endeavor would likely fall on his shoulders. I would be willing to model components if you wanted 3D models for things. I use UniGraphics at work. Right now we do little with schematics in UG so I don't really know how to use the harness software, let alone circuit board design side.

Graham

[GrahamMc]

Hmm, let me try that attachment again. Oh, it is too big. If you are interested I can shrink it at home later. Let me know.

There we go. Man those files really need shrinking! Hard to read but there is an address at the bottom of the page that is where I got it.

I think all it would take is a little moisture to act as the electrolyte, though, the heat generated should keep it pretty dry.

[Roger Heuckeroth]

Sure I would be interested in the dissimilar metals chart. Did you download it from the net. If so maybe just a link to the site would do. Or try zipping it?

As far as an electrolyte is concerned, I was under the impression that all you need is humidity in order to get things started down that path. I don't know how the heat conductive goo that is often used to assure the transfer of heat effects this reaction. Just things to keep in mind.

[GrahamMc]

Paul-
I would like to plug Open Office as well. It is a free download that will open and edit Word or Excel or Powerpoint and save in those formats as well all for free. Silly to pay for the others, wish I had heard about Open Office earlier.

[wjdennis]

Paul, speaking of source control, have you posted the latest source code? The last file I saw in the thread was from March 7.

Bill

[Roger Heuckeroth]

I assume the source code will change when design is updated to the ATMega16 micro?

[MazdaMatt]

On that topic, i have a suggestion for your code. It is wise to create a HAL (hardware abstraction layer). It is as simple as creating a ".h" file with a list of all of the ports that you use, defined with a logical name.

This is not a code snippet from this or any project, just an example.

before:
(source.c)
PORTB &= 0x04; //this turns on the overvolt LED

after:
(hal.h)
#define OVERVOLT_LED_PORT PORTB
#define OVERVOLT_LED_PIN 0x04
(source.c)
OVERVOLT_LED_PORT &= OVERVOLT_LED_PIN; //this turns on the overvolt LED

The benefit of doing this is extreme portability. You can move from atmega to atmega by simply changing the HAL.h file. You can also re-layout the board using differnt pins/ports and you only need to change code in ONE place for it all to work. Additionally, I could then take your source code, lay out my own board using a Freescale Coldfire chip and re-write the HAL for my own purposes. All of your code stays the same.
You can also abstract the HAL! so HAL.h only has:
#include <paulATM80.1HAL.h>
and all the rest of your files include the HAL. Then as people create new board layouts, they just create their own. titleChipVerHAL.h file and they can switch between them by changing a single line of code.