Planning a DIY Data Acquisition/Engine Controller

[dubbleUJay]

Gentleman, this post is an update to where this project is heading to at this moment.

I've asked Bruce (BruceM) & Daryl (Crumpite) to amend this specific post as not to have a long discussion/posts about probable faults exec.
For now, Daryl is writing the User Interface for the PC side of thing, Bruce & myself are keeping us busy with the electronics, with help from Daryl as well.

Lets call it a short WIKI-post if I may! I've taken the important parts of email correspondence between the three of us over the last few weeks and put it in this post.

This project has now escalated and it's heading in a different direction as first intended and IMHO, I think it is to the benefit of all people looking for Data Acquisition and Controllers.
Please note that this project is not finalized and there are still a lot of work to be done, but the fundamentals are more or less set, well, sort of!
(Names and such for the project and components are just thumb-sucks by me and can be changed as seen fit.)

µCogen Data Acquisition & Controller System (McGuino or µCoguino )

1st a Proposed System Layout for clarity:



IMG place holder (I need to draw a diagram for some Slave Examples)

A list of priorities from Daryl:
1. Everything to be easily available.
2. Off the shelf if possible, PCB files available if not.
3. Robust mechanically and electrically.
4. Expandable.
5. Inexpensive.
6. Programmable to suit the user.
And, the order above doesn't matter...

PC User Interface program requirements from Daryl:
1. Receive real time data from the Master/Slave
2. Receive logged data from the Master/Slave
2. Log data to a file
3. Graph it
4. Send commands out to the Master/Slave
5. Send commands to the Master/Slave at a certain time.
6. Receive requests from the Master.
7. Blow a horn when an error condition happens.
8. Some method to select which Slave to talk to.
He will be using the Python language.

It is the intention that the UI will be able to work to just one Slave (1to1 operation) for those that need just a single system or to many via the Hub Mux Controller up to 8x Slave units.
As stated above, we would like of the shelf hardware where possible, but something like the Multiplexer Hub Switcher will have to be made at this stage if one want more than 1 Slave!  

Bruce & myself has come up with a few Slave units I/we might need:(And some of your suggestions, thx)
(I cannot get the "Insert Table" function to work properly)            
Wind Generator
Volt   Analog      
Amp   Analog      
RPM   Analog/Digital      

Borehole Pump
3x Status LEDs   Digital      Existing dedicated control
On/Off      Digital   

Irrigation
On/Off Digital Timer controlled
4x Moisture Sensor Analog
                        
Mains Power
Volt   Analog/Digital      
Amp   Analog/Digital      
Meter "tick"   Digital      Utility meter 1000imp/kWh

Battery Controller   
Volts
Amps-IN
Amps-OUT         

Engine Controller
Throttle Control
Emergency shutdown
Idiot Lights            

Engine Data Logging            
6x Temperatures (<125C)
2x Exhaust Temps (High)
RPM
Fuel Flow
Low oil pressure
Aux digital Inputs

Weather Station         
Wind Speed
Wind direction
Rain Meter
Humidity

The otpo-coupled serial bus between the Master and Slaves are an adaptation of Bruce's existing one and I'm sure he could explain it better than me as I'm still learning myself. Bruce?

That's it for now folks, I'm sure this post will change quite a bit over the next few days.
There ARE stuff I'm forgetting now offhand and I'll put it in as I remember them.

dubbleUJay

[BruceM]

WJ, The diagram is not correct, it's not a flow diagram, and it's not right as a block diagram.  There would only be I2C bus between the serial hub processor and master, and the interface to the up to 8 slaves is opto-isolated current loop, not I2C.  I've never seen this before!

Some of the slave functions should be shown, like engine controller and data collection,  for example.

[dubbleUJay]

OK Bruce, I changed a few thing in the diagram. There's still discrepancies I'm not sure of though.
Surely the actual data being relayed from the Slaves, between the Serial Hub Processor and the Multiplexer hub wouldn't go via the 3to6bit parallel bus that controls the actual multiplexer addresses?
Modified: I've read an email of yours after writing this and will make the changes.

I'll have to draw a diagram for some examples of the Slaves, as I don't have enough place on the existing diagram for it. I left a place holder in the post for it now.

Please let me know if I get the names wrong of stuff, that's a common problem of mine, I once called my wife Mary while she's actually called Xmas! (Only once though, didn't see her for a whole year!)

dubbleUJay
PS- I've sent you so many emails the last few days, I'm sure you missed the 2nd diagram.

[BruceM]

Thanks, WJ, much better.  The SD card should be moved to the single I2C bus off of the master, there's aren't 2 I2C buses off of a single Arduino.

The serial hub controller is essentially an 8 channel smart UART, with data buffering and an I2C interface to the master.  It offloads the overhead of servicing serial I/O from the master.  In  WJ's system,  it's typically about 100 feet between subsystems, (except for one 1000 footer which is going to be a radio link), thus the use of optically isolated current loop for subsystem communications.   It's robust and simple. 

[dubbleUJay]

Jens, you keep gobetwino running continuously and in Kst that I used the 1st time, you set it up to read to the end of the file all the time.
Kst has a lot of setting and I just hit the right combination by accident, I must still read the manual.
I think there must be a way to let Exec update periodically, I haven't tried it this way yet!

[Crumpite]

Folks,

Just a quick note to let you know I haven't been hit by a beer truck or something... 

I'm still plugging away on the GUI and the system communications.
I've written a whole bunch of pages on the communications protocol and a quite a bit less on the GUI.

Python should be called Painthon as far as I'm concerned, but I believe I'm getting the hang of it slowly.

I've manages to draw some pretty boxes on the screen with menus and click-able buttons that do what I want.
I decided I needed to define the communications between the PC and the the micro units before I could go on.

So far I've got a command and reply structure that's readable by both human and computer (a big aid to troubleshooting) and that's both flexible and has minimal overhead.
Also, I don't think it will add much overhead to the slave's code.

The only drawbacks I've got so far is that the PC and/or master will need to know what to expect in the replying data stream from the slave.
Also, it's going to be difficult to get the GUI to respond correctly to older data files if the you add to the system later.
(Python is so flexible that it *may* be possible, I'm still learning...)
We'll still be able to export the older data to some other application if we need to via the old CSV method.

It looks like you'll be able to send a command to a given slave by this nomenclature:

CMD#2#4#1Subcommand (two char)

this would send the command "CMD" (a three letter command) to slave processer number 2, which passes the command to slave processor 4 which sends the command to slave 1.
The subcommand is two chars right now, but I can expand if needed later.
I'm thinking of subcommands of AI, AO, DI, DO, ST - or Analog Input, Analog Output, Digial Input, Digital Output and finally Status.

The slaves can be a microprocessor or a 'virtual' slave like a digital or analog or serial expander.

Asking for a full data dump from Master 0, slave 2, digital expander 1 would look like:

DMPS0S2S1 which would then return all of the digital inputs in the form:
DTA021x,x,x,x,x,x, etc. CR

All the slaves strip their address (Sxx) from the command and pass the messages downhill to all their slaves until it hits the right address.
Since all data is assumed to be going to the Master, we don't need a return address, just the address of the sending unit, hence the 021 address after the dta (data) command.

The data will be stored in a file that contains the address of the slave unit (the PC considers the Master to be a slave with the address of 0) in the form of CSV's.

This is still very tentative, so feel free to add you wants/needs/opinions !!!
That Christmas has taken up most of my time lately is my only excuse. 

Daryl

[BruceM]

Sounds like you're making some good progress Daryl. I hope Python will pay off in the end.
Bruce M

[dubbleUJay]

That's great news Daryl! I've also been hit by the holiday bug! Not myself, but a secondary condition by the people around me!
I thought this year I'll be ready and I could continue to work through it, but things never turns out that way, maybe next year!

[AdeV]

Wow, I've just played mega-catchup with this thread. Seems like it's gone a hell of a long way since I took proper note. Oops.

Have just ordered an Arduino + "experimenter's kit", which has useful stuff like servos, temp sensors & multiplexy latchy things in it

As far as what's now being proposed for this DAQ/ECU; unfortunately it's shot far beyond my comfort zone. There's lots of electronic trickery and fancy stuff (I2C) going on which, frankly, I just don't understand...

So, I guess I'll be ploughing my own furrow, but I'll share it with you guys if you're interested.... As a software guy, I'll be sticking with simple stuff when it comes to the hardware. I'll probably end up with a single engine controller, with multiple sensors, which will output data points through the serial port to a PC. The software on the PC will then be tasked with data acquisition/reporting, as well as possibly sending instructions back to the ECU.

Analogue MUXing was mentioned a few pages back: Here's a 4067-based solution that's ready to go, and gives you 48 of the little blighters: http://mayhewlabs.com/arduino-mux-shield. I reckon 48 analogue in/digital in-out pins is plenty... and it wouldn't be hard to hook up another 48 using a second shield (you'd have to use flyleads though).

[mike90045]

What about a simple shutdown, like a weight/pulley on the fuel lever, which is held up by a meltable link on the head?

Is the fuel lever un-reliable, and the rack a better shutdown?

[BruceM]

The fuel lever just operates the rack. 

For emergency shut downs only, sure, a brass wire fuse link can be used.  A brass wire fuse link holding the end of the governor spring will also cause a shut down, this I have experimented with myself and found it reliable. 

Ade, I'm using a 16 bit I2C port expander for a my battery bank charge controller.  It sure was easy to use once I lifted someone else's initialization code.  Then all that remains is an I2Cout addr, data command to send a byte to one of the two new output ports.  The physical interface is also easy- just two wires with pull up resistors (2K-4K), plus power and ground for the I2C chip.  All I2C chips use the same 2 signal wires, only one set of pull up resistors is needed.

I had almost no analog inputs on my Lister(oid) controller, but lots of digital inputs and outputs.
Unless you are doing a bunch of experimental analog data logging, I can't imagine needing analog expansion on an engine controller.

I'd recommend starting with one of the 40 pin Arduino processors, good chance you'd need no expansion at all.

[AdeV]

Bruce,

The kit I've bought is this one: http://www.oomlout.co.uk/arduino-starter-kit-ardx-p-183.html It should get here tomorrow, so I can have a little play with it.

Agreed, I shouldn't need loads of analogue pins to make an engine controller; that was in response to some of the posts earlier in this thread where the 4067 was mentioned; thought I'd pass on the link. That said, once I do get into making a "proper" CHP system, I'll want lots & lots of temperature sensors....

Maybe I'll have to take another look at I2C. You certainly make it sound simple - but, then, I've read a lot of your posts which sound simple on the surface, but dig a bit deeper and you're doing really clever stuff...

I can see me needing maybe 2 or 3 temperature inputs for a Lister(oid) controller (1x water & 2x fuel, if I go with heated veg oil), as you say the rest would be digital (rpm, fluid levels). Then lots of digital outputs - idiot lights, throttle, decompression, etc.

[BruceM]

I2C is pretty well supported on most processors/languages.

Here's the total initialization code on a Picaxe 40X1:

'initialize for mp23017
hi2csetup i2cmaster,%01000000,i2cfast,i2cbyte
hi2cout $0A, ($00, $00) 'ICON config register for sequential
hi2cout $00, ($00,$00) 'set port direction to all outputs

'After that, it's-
hi2cout $12,(b0)  'b0 or any byte variable containing the 8 bits to be output
hi2cout $13,($FF)  ' this is the second 8 bit output port, getting all ones for example

[AdeV]

[sheepish]

OK, I just googled. On the Arduino, you need a couple of lines of code:

Code Select Expand

#include <Wire.h>
(That one references the I2C library)

and:

Code Select Expand

Wire.begin();
// or Wire.begin(address); to start in slave mode



Mind you, I guess there must be some send/receive code too. Probably also one-liners.

Well, bang goes any excuse I ever had for not using I2C...

(BTW, the page I got that from - http://www.arduino.cc/playground/Learning/I2C - also suggests the processor has its own internal pullup resistors, suggesting that maybe you'd need no external components other than wire?

[BruceM]

Ade,
I think the AVR  internal pull up resistors might be 10K, you need 2K-4K for reliable operation in my experience.  You'll have to check, I'm not that familiar with the AVR processors.  

Edit- I just checked and the AVR internal pull ups are 20K- 50K ohms, so for I2C, you must use external pull ups of 2-4K ohms.