Planning a DIY Data Acquisition/Engine Controller

[Crumpite]

BruceM,

I've looked pretty closely at your design, and I like it.

Myself, I'm like you, KISS principle first, get it working, then add on the fancy stuff.

Pic's are rugged as anything and I do love the Picaxe chips - I've got several on my workbench right now that I've been working with.
My only complaint is the language limitations, but at least I don't have to learn *another* proprietary language to get the job done...

I really like the idea of a Picaxe to do the control, and something else to do the DAQ part of the system.
Pic's are so tough, hardware wise, and the language is so simple that I think it lends itself well to a critical system like engine control.

The last few jobs I worked on used a distributed control system, and I fell in love with the ruggedness of the systems.
Any failure isolated itself to that particular subsystem, so that the rest of the system kept running.
Since I'm the guy who'll have to do all of the repairs, I want everything as simple as possible.

I'm thinking about a Picaxe/Adrundo communications link.
You mentioned opto-isolated links for communications, what exactly did you do ?
I'm a bit shy of Ethernet due to voltage drops/potentials across the lines.

Yah, Open Source... More of a CYA for code reuse so far as I'm concerned.
Still there is a lot of good software coming out of open source development, I'm just uncertain how well it will work on the hardware side... 
It's still an experiment, IMHO...

Daryl

[Crumpite]

dubbleUJay,

What parts are you currently using or planning on using ?

I'm trying to get an idea of how many digital and analog I/O's will be available.

Thanks,
Daryl

[BruceM]

I agree, Daryl, divide and conquer (mulitprocessor) can sometimes speed things along greatly. It might apply to WJ's situation, depends on his operations vs data recording needs.  

I'm not pushing the Picaxe on anyone, I'm glad to try and help out with whatever toys the boys like.    

I agree the Picaxe Basic is very basic (though better than Parallax Stamp), but again, it's just an pokey engine controller where the lack of arrays and floating point math are not traumatizing. It just forces you to keep things simple, which isn't a bad thing for a simple controller.  The same code could be rewritten in Arduino or AVR C.  I think AVR C makes more sense if one was bothering with a rewrite; Arduino is too rudimentary and Arduino mixed with C seems a bit of a frig.)  Another option would be to use the 40X2 Picaxe as a I2C slave (or master) along with the Arduino. You get a boat load of I/O on the 40X2 chip, almost all reconfigurable as in, out and analog, and you can always upgrade to a Compiler (almost any language) later if you decide to get fancy.

Regarding my communications link-  it's a matched impedance, opto-isolated current loop. (Dirt simple and cheap.)  It runs at only 600 baud, though it will certainly go 2400 baud or better.  (It is limited by the filtering of my processor board in my setup.)

I went the opto-isolated current loop route as the Cat5 cable is very long (560 feet), and run in the same steel conduit with my AC power.  (A no-no, but I didn't want to do another 560 foot of conduit run.)  I wrote some serial loopback test software and then fired up the big shop central vac (brushed motor makes mega EMI.) Zero data errors.

I'll find the schematic for it and post it.  Glad to help modify it for your needs.

Another rock solid serial link is using plastic fiber optics; you'll never have EMI or lightning issues with fiber.  Industrial fiber optics makes cheap plastic LED/photodetector emitter/receivers ($3-4 each), and you just cut the fiber with a razor blade, then shave it smooth. It's great stuff.  I couldn't use it on my Lister project as about 400 feet is the distance limit for plastic fiber.  I like and use multimode glass fibers a lot, but the transmitters and receivers are spendy and take too much power for my Lister application.

PS- Regarding the schematic- sorry it's hand drawn but I was having vision troubles at the time and computer use was a bitch.  My processor is in shielded enclosure with 10K ohm impedance,  LC filtered connectors for the data lines.  I do this because my brain is fried from MS and epilepsy and I can't do the debug work near a running processor otherwise.  If you get rid of that, you don't need the buffer to drive the signal, and it just becomes two 200 ohm resistors on the driven end. You get better noise immunity with matching the impedance on the pair, though it isn't absolutely necessary.  The PC123 optoisolator is cheap, fairly fast and only takes a couple ma to light up, the resistor across it's inputs increases the current requirement a bit to improve noise immunity, also. Obviously, the other end, my remote display of LEDs and switches is exactly the same circuit for TX and RX, and is in fact another 40X1 (the X2 wasn't out yet).

[dubbleUJay]

Daryl, I just got this and have to read your post thoroughly, I just have to go to town 2day and I'll post a bit later this afternoon.

[mobile_bob]

i too have been following this thread with some interest, i am always amazed at what folks do with controllers
and the numbers of such to work with, compounded by the different programming languages and then the
millions of ways of using all this to approach a problem.

the more i look at what is being presented the more i think i am staying in the multiprocessor (master/slave)
camp, not because i see anything wrong with what you guys are doing, but rather because of my shortcoming
in ability to program to that level of complexity.

even the various serial communication protocols seem to be of questionable use to me, one you start onto the path
of the master/slave architecture it just seems easier to me to just use simple "hi/lo" on a wide buss.

for instance you have a master, it only job is to scan and make decisions, and once a decision is made
it sets a line on the buss to "high" and the slave attached to that buss line which has been in a short loop
breaks out and starts to do its specialized operation.. this leaves the master to carry on scanning all manner
of stuff, making decisions and sorting out requests to start and issueing permissions to start.

it seems to me that the master can then have such a simple program loop that doesn't require a bunch of math
computations, or conversions, lookup tables, etc. so that the likelihood of a lockup would be greatly deminished?

so the master just keeps on trucking, doing its thing and the slaves can do the intricate detailed work to handle
very specialized operations, such as engine autostart, warm up, glowplugs, fuel solenoids etc etc. and while doing
so have a line of code that has to be bumped every so often so that the master knows the slave is not locked
and continuing to do its thing, if the expected high is not on the buss line when the master rechecks, then it can
intiate a shutdown. that sort of thing.

it just seems so easy to break the work load up among several processors and program them to react to commands
and report back periodically so that the master can maintain control, and also setup a failsafe so in the event the master
should fail the slaves can take over and effect a shutdown.

i am sure you smart fellars can do this all on one microcontroller, but it is so far beyond my capabilities and my interest
to learn at this point in my life that it isn't even funny.

now having said all that, what i think would be very cool would be to at least agree to a buss architecture that would be
very simple as described, that way everyone that decides to build whatever processor controlled project could take it
and plug it into the buss and get it to play well with others built by other folks using different microprocessors and different
programming languages.

last count i have my system laid out to have one master and up to 7 slaves to manage a complete system from loads
to power sources. 

looks like i might have a bunch of free time on my hands in the near future while healing up from surgery, so i guess i will have
time to further develop my simplistic view of what an automated world should look like.



bob g

[BruceM]

Bob, Nothing wrong at all with your strategy, and that's just how I designed the first multi-microprocessor flight simulator (a technology demo for the U2/TR1) back around 1980.  It had 8 microprocessors with hardware floating point coprocessors. Every processor had it's own private hardware bus for all of it's cockpit hardware interfaces, plus a fast 8 bit wide block transfer capability to the master.  It ran at a 15Hz frame rate, with the flight model split in two processors.  A single PC would run circles around it now, of course.

Regarding: "master/slave architecture it just seems easier to me to just use simple "hi/lo" on a wide buss.".  Sure, if a slave function is as simple as do it or don't.  But most of the time at least status information and often some data is needed back by the master.  A common serial (or byte wide parallel) communication bus solves both problems.

The PICaxe 40X2 parts (or AVR or PIC with compiler) would make a widely distributed architecture fairly easy by supporting I2C buss between processors. That gets you 400KHz serial via the chips hardware, so less impact on processor time.  SPI bus is even faster, and might be used the same way. The routines for the PIC chip's hardware I2C are direct in the basic language of the 28X2 and 40X2 Picaxe chips, I've used it, it works fine. The only fly in the ointment is that with only one I2C bus in hardware per chip, you'd have to avoid I2C expansion chips on the slaves.  Or add some hardware to do it, such as gate the I2C pins to a secondary bus and then switch to master mode.  If using chips like the 40X2, it seems unlikely a slave would need I2C expansion anyway.

But for an engine controller, it's hard to imagine the need; a single processor or  can do the job without a fuss, or any backflips.  My Lister controller doesn't use a single interupt, even.  Just write the code for each of your little tasks, as if you had a processor for each and then I'll give you a hand in combining them.  It's only daunting the first time.    If you're dong battery and power management, too, then I can see dividing things up more.  Dedicated serial data links (like my simple opto isolated current loop) can be used for that sort of division, as there isn't much data involved, and it isn't very time critical.

The reliability and durability of the PIC processors is legendary, and I think most of the others are damned good too. My fiber optic link, Picaxe 18X cell phone controller is out running continuously in a somewhat insulated doghouse off it's battery and little PV panel, glitch free for two years and counting.  You don't need to worry about redundancy or anything else.  If you program it simply and well, and your hardware put together decently,  it will run and run and run without a hitch. Micros only seem unreliable to you because you're a hands on guy and you need more hands on micros time.  

[dubbleUJay]

dubbleUJay,
What parts are you currently using or planning on using ?
I'm trying to get an idea of how many digital and analog I/O's will be available.

OK Daryl, this is what I have at the moment: (As I mentioned before, my intentions is to keep the non-electronic guys in mind, that's why I chose the Arduino as a base system board, popularity and info available for the novice is plentiful IMHO)
There's more info than you asked for, but I'll have to post it all together some time anyway. 

Hardware:
1x Arduino Duemilanove (ATmega368)
1x Extended Analog Input board (16ch HEF4067BP Multiplexer)
If one don't need to many sensors, you don't need this extension board!

OK, now I have a micro with the following I/O still free or to use:
10x Digital I/O pins (4x PWM capable)
5x Analog I/O pins (Original)
16x Analog I/O pins (Extended)
1x Voltage reference pin for Analog inputs (AREF)
and I still have access to I2C bus and a few other goodies if I need it in the future.

Probes I have in mind with these inputs:
1x  AC Volts/Amps/Power              (extApin0&1)    (Alpha)
1x  Thermocouple for Exhaust        (extApin8)        (Alpha) 
7x  TempSensor(LM35or36)           (extApin9-15)    (Beta)
1x  Engine RPM Sensor (Opto-???)  (extApin7)        (Not Started)
1x  DC Volts/Amps/Power              (extApin2&3)     (Not Started)
2x  Digital Inputs Fuel-/H²O Level                          (Not Started)
1x  Oil Pressure Sensor (Maybe)      (extApin6)        (Not Started)

Controller: (I'll get to this later and might use a dedicated micro for it.)
1x  Digital Output Emergency Shutdown       (Not Started)

I've got the Arduino and multiplexer setup and some code for it to read the extended values:

Code Select Expand


// START of:  16 Channel Analog Input Extender
// Extended Analog Input pins 0to15 = ExtAin[0] to ExtAin[15]
// Some TEMPORARY CODE for testing to serial port, to be deleted later.

byte chActive= 16;  // The number of channels active.
byte chNumber= 0;   // Keep count of the channel number to read.
int currentVal= 0;  // Current Value of channel
int ExtAin[15];   // Store 16x Extended Analog Input values in Array here

byte binA0 = 0;  // Set initial Address Input values for 1st bit A0
byte binA1 = 0;  // Set initial Address Input values for 2nd bit A1
byte binA2 = 0;  // Set initial Address Input values for 3rd bit A2
byte binA3 = 0;  // Set initial Address Input values for 4th bit A3

void setup() { // Setup Digital Pins & Serial COMM's

  pinMode(10, OUTPUT);  // Set Dpin to Output (A0 <-> pin10)
  pinMode(11, OUTPUT);  // Set Dpin to Output (A1 <-> pin11)
  pinMode(12, OUTPUT);  // Set Dpin to Output (A2 <-> pin12)
  pinMode(13, OUTPUT);  // Set Dpin to Output (A3 <-> pin13)

  Serial.begin(115200); // Set Serial COMM's to PC
}

void loop() { // Get 16x channel Values

  // Loop through the 16 channels and read each one.
  for (chNumber = 0; chNumber < 16; chNumber++) { // Address ch's & read values

    // Generate Address Inputs for HEF4067BP A0 to A3 (pin 10 to 13)
    binA0 = (chNumber & 1);     // Create 1st bit for Address A0
    binA1 = (chNumber & 2)>>1;  // Create 2nd bit for Address A1
    binA2 = (chNumber & 4)>>2;  // Create 3rd bit for Address A2
    binA3 = (chNumber & 8)>>3;  // Create 4th bit for Address A3

      // Send current Address Inputs to Multiplexer
    digitalWrite(10, binA0);  // Set bitA0 on pin10
    digitalWrite(11, binA1);  // Set bitA1 on pin11
    digitalWrite(12, binA2);  // Set bitA2 on pin12
    digitalWrite(13, binA3);  // Set bitA3 on pin13

      // Read the common I/O pin0 value for current channel
    currentVal = analogRead(0);

    // Write Current Value to Array index position
    ExtAin[chNumber] = currentVal;

    if(chNumber < (16-1)) {  // Step through all 16 channels until end
      //Serial.println("");    // TEMPORARY CODE: Continue next Print from next line.
    }
    else { // Start over
      // TEMPORARY CODE:Serial Print Channel Values stored in array
      for(int indexStep=0; indexStep<16; indexStep++) // TEMPORARY CODE: Index step for array values     
      {
        Serial.print(" ;");  // TEMPORARY CODE
        Serial.print(indexStep);  // TEMPORARY CODE: Print Channel Number dirived from current Index Step
        Serial.print("-");  // TEMPORARY CODE
        Serial.print(ExtAin[indexStep]);  // TEMPORARY CODE: Print Value for current Channel
      }
    }
  }
  // TEMPORARY CODE: Take a break (1000 = 1sec)
  Serial.println(""); //TEMPORARY CODE

  delay(2000); // TEMPORARY CODE: Wait a while before starting over
}
// END of:  16 Channel Analog Input Extender


For some reason I cannot may the display of the code bigger, sorry!

I've got the code for Temperature, also Vac, Aac & Power and most of the other probes, its now a matter of incorporating it into the code above. (Once I've got all the sensor hardware sorted)

The 16ch Multiplexer board is straight forward & you can probably buy one similar somewhere ready made, cct & board at the bottom of this post. Its not final & I've got it built on a Vero-board at the moment and I will most probably add more things to it, for starters a 5V PSU as to keep the supply voltage away from the PC USB port.

For now the various values are printed to the serial port and written to a file with a program called "gobetwino".
From there I use a real-time graphing program (Kst) to extract the data and display it or I've used MS Excel to do the same thing. (OpenOffice would probably do it as well, just haven't tried it yet)

Hope this answers your question Daryl

Wilhelm

[BruceM]

Nice work, WJ.  

[dubbleUJay]

Thanks Bruce, I must say that without your help I would've never gotten this far with the project!

I saw that question about the 10k's seconds before you took it off

I'll leave them in for now until I'm sure which inputs I'm going to use. Maybe suggest a switch array in the final version like you said.
It's just easier switching an input "off" or to "0"  than changing the program to not read it every time.
That's why I was pushing it with a 100k so that I might leave them in if they didn't influence the signal significantly, but like you said, it will. 

I'll firstly incorporate the code for the temp sensors as I have that all working.
Then I can carry on with the cct for the AC Volt-Amp probe, I'll have to read through our conversations again about it and come up with a solution. There is just so many ways to do it and I'm not sure which one to chose

[mobile_bob]

Bruce:

that was precisely what i had in mind, that being the use of a slave dedicated to each of numerous subsections of the system
such as

the master to scan loads and determine the best power supply for that load or combination of loads

a slave to do the engine management
another slave to manage battery and inverter issues
other slaves for control of other power sources such as wind or solar, alternator control, etc.
another slave to manage hvac loads,
other slaves for refrigeration loads, water management (well pump or containment supply)
other slaves for thermal storage etc.

and the list could go on depending on size and complexity of a system.

basically a master could be programmed to scan loads and determine for instance that the refrigerator needs
serviced (power provided), the well pump needs to start, and someone happens to have just started the washing machine
under this set of demands it is likely that providing the power would be most effective "if" power from the wind is low, it is cloudy, or
there is also need to do  some battery charging, and there is a use for the excess heat recovered from the exhaust, then go ahead
and issue a command to start for the genset,

if on the other hand the loads are determined to be such that the duration is short, and within the capability of either the batteries and inverter, or windpower at the time, or solar at the time, then issue a command to connect the appropriate power sources to the load
and not start the genset.

i can envision many different combinations of loads and power sources being able to be sorted and a determination of the best match
being determined by the master in a relative short amount of time, and control could have taken place quicker than i could use a pencil
and paper or check a chart and connect things myself.  and at least things would follow a standard flowchart and be done the same way
each time, leaving out the human factor of not only myself but the wife or others.

also it is fair to note, that rather than reinvent the wheel i am of the "group" that subscribes to integration of existing and appropriate technologies where i can into the system, items such as a balmar controller is much easier for me to deploy than building my own controller and working out its kinks, at least in the beginning stages. at some point down the road however i might well find that a more
specific design that fits my need would serve the purpose better and then i could set out to design and build such a controller, safe in
knowing that i have a balmar controller that just works i can fall back on.

as for I2C protocol, i suppose it would be prudent not to paint its use out of the corner but leave it as a possibility should
i find it useful down the road?

as for your early experience with flight simulators and multiprocessors, i did some reading in the use of such back in the day to
do all sorts of stuff, looks to me that if it was good enough back in the day to get things done for a flight simulator or put man
on the moon it surely ought to more than adequately provide all my control needs today?

before i started in with the BS2 stamp i had to work with basic relay logic, and either electrical or mechanical timers and the like
so making the move to the stamp and its pbasic was very much like making a quantum leap for me. i just figure that if i could do
it with basic relay logic and electromechanical means then i need to fully exploit the very basic means of control (relatively speaking)afforded by the stamp before i worry about trying to get it all done on some incredibly fast processor using many pages of very
complicated codeing (again relatively speaking)

i am thinking it is unlikely that i will outgrow the capabilities of the BS2 stamp anytime soon, most especially in a master/slave system
where the number of I/O would be quite staggering compared to the actual needs of even a fairly complex system. (again relatively speaking, 7 slaves x 16 I/O = a bunch)

this also leaves me the possibility in the future to adopt something like a pic controller should the need arrive to do a specific slave
where the pic would do a much better job and have that slave integrate into the system as a whole, and still have the fall back position
of a known working slave based on the bs2?

a lot for me to think about and consider, i am already 30 plus years behind the curve, and the curve it moving away from me
at a very fast clip!



bob g

[dubbleUJay]

Bob, I see that one can get a Arduino like node called JeeNode which has a few I/O's and its wireless. Can be programmed with the Arduino code.
It was specifically made for Node applications for users that just have a few I/O's at certain places where Xbee would be overkill and expensive.
http://news.jeelabs.org/projects/

One can build a barebone Arduino and put whatever comms you want to use onto it as well.

The thing is with all these multi micro systems is that you get to a stage where you need a killer application to run it all because it gets so big.
I've seen this in Home Automation packages for free and commercial, IMHO anyway. I still have to get a UI for this project of mine in the end when all the hardware is working.

[BruceM]

I'd avoid wireless except were no other viable alternative exists.

Bob, I'd love to wean you off the Basic Stamp,  it's real time capabilities aren't nearly as good as the Picaxe's, and it costs 4x as much.  The 40X2 is $10, and has 32 I/O, and can handle serial data with timeouts via hardware (doesn't tie up or hang the processor), and has  other real time support that is better, including servo control done via timer hardware that doesn't tie up the processor.  I draw the line in functionality at having a timeout for serial input; no hava, (ala Basic Stamp) no use to me, and I'm not frigging with an external interrupt or timer to work around it. If a vendor is too stupid to realize the need for timeout on serial input command, they just shouldn't get your business.  The basic language is almost the same for Stamp or Picaxe, in fact their program editor has a Basic Stamp code mode, and you'll find first class help on their forum.  I never had a question that wasn't well answered the same day, they have tech support staff that are on the ball.  I'm just thinking about how to make your job easier for you. The Stamp is a handicap you don't need. Now I should shut up about it!  

Your plans are reasonable, certainly it should be distributed to a few different processors, just to make it easier to tackle.  How far apart physically are the processors? Distance is an important factor in deciding how to communicate, as well as speed requirements. A simple asynchronous serial bus (9600 baud or less), 2 pair and two signals on Cat 5 might be all you need.  Or even less if the distance is short.  

[BigGreen]

I must say this thread has grown as much as your project. Nice Work!
A lesson I learned was not providing failure mode status. The system could shut down from any of six different failure modes and I didn't have any indication of what shut it down. It wasn't as apparent after failure as I thought it would be. After chasing my tail and scratching everything I had to scratch I created an 8 bit status register on the flash RAM, assigned each bit a failure mode, created an interrupt to bit-wise OR the register once a failure was detected and display the word. Only then did I discover an intermittent drop in a dirty flow sensor signal. Of course, this can be done with extra d i/o's as well.
Post failure diagnostics is on the top of my list forever more

By the way, I'm a PIC guy. I run my world with a 16F877A

Dave

[BruceM]

Dave,
Thats same PIC chip is the 40X1 picaxe as I recall. (My memory is VERY leaky.)

What's your favorite compiler(s)?  Your review would be appreciated. I have some upcoming projects (a hybrid ultra low EMI resonant inverter design) were I need a compiler.  Boost C is cheap and seems adequate, but I was disappointed that floating point (not needed for the inverter) was only by library call, and the documentation was only so-so.  

WJ's been a boon for the forum, and I really value his contributions. He's picked some good gear, and is making good progress, which is fun for us all.  There's nothing like an ongoing forum project to keep all of our braincells stimulated. His project is much more mainstream than what I'm working on right now. When he's done, I'll help clean up and make a special project thread so all our ramblings don't distract.  So you don't need to thank me, WJ, it's the other way around! Thanks!

[mobile_bob]

Bruce:

the distances are very very short
actually i am planning on using a rack mount drive case, that has 8 bays
into which i am using ide drive caddy's that are removable

the ide cable that attachs to all 8 drives will be my buss, and the power supply
has both the needed 5 volt supply and also the 12volt supply needed for my little relay
boards.

the caddy's are just big enough internally to use available relay boards and also a daughterboard
that will socket my BS stamps.

this setup will allow me to withdraw a single processor unit to allow for bench programming, and then
reinsertion, or if need be removal and reassignment by reprogramming for another use should the
need arise.

i am kind of committed to this direction mainly because i have all the hardware bought and ready,
all the relay boards with parts, the daughter boards, the processors, caddy's and bays, along with
a very nice rack mount case to house it all. i also have all the external terminal strips and some nicely
shielded cable that is 24 twisted pairs to interface with the outside world of heavy contactors/relays, solenoids
and all the other stuff to be controlled.

i am not married to the bs2 stamp, just have them already and understand them well enough to get done
what i need for now, however i certainly see the attraction of the pic processors and would like to work with
them in the future perhaps to replace certain elements of the system where they could do a better job.

thanks for your input it is appreciated

bob g