Hello everyone,I'd start by saying that I'm very amazed with community here, very helpful indeed. I am only sharing ideas here, and getting contributions to make my project more efficient.

The incubator I'll be building will host 19,200 eggs. This might sound like a lot, but my family already owns a business and has the machines going. The only problem is that they rely on boards made in 1980. which are now rusty and very high maintenance, not to mention they are not debug-able and are very annoying to fix (i.e testing about 20 shift registers, or something like that.)

enough with that long story...bottom line, machines available, I'm only replacing the logic inside them to something more powerful and easier to maintain, also cheaper(i.e 1980 models discontinued or very very expensive spare parts).

Important events:Initial start --> there is a special starting routine (like oven preheat), that's different from the main program.Door Open/close --> lights are turned on , LED indicator, pulsator fan is stopped(not to hurt the workers appraoching).

I am still in the flow chart phase, The reverse engineering phase is incomplete. so here's how i plan to make this work:- Going to use an RTC and a function to import the parameters from a table, that's for automatically fixing parameters.- might have to make some work arounds in the correcting function to prevent over-correction.- still have to find the acceptable deviations and when to start correcting them. (in temp. its 0.3*F)- going to use 6 interrupts: Temprature, Humidity, Co2, Open door, turner (time since last turn)

questions:-can 2 interrupts work at the same time? like if 2 values deviate at the same time, is it possible to correct them at the same time?-to use interrupts, do i have to use analog sensors?-any brilliant ideas?

I am still learning to code BTW, I hope i provided people seeking to do the same thing with useful information. feel free to ask anything, I'm more than willing to help.

Don't. There is nothing in what you've described so far that requires the use of interrupts. Interrupts are typically appropriate when the time scale is short (e.g. controller must respond within 1.2 milliseconds). Everything you've described is on the scale of days and hours.

Interrupts add a great deal of complexity to an application and a large amount of risk. Only tread down that path once you've determined nothing else will solve the problem.

Exactly what wires in the old machine do you need to interface to? Presumably some sort of temperature sensor. What kind?And some kind of humidity sensor. What kind?And something to run the egg-turning motor, and something to run the ventilation fans.And a switch to sense when the door is opened. And something to control the lights?

What controls were on it originally? What user-interface readouts, etc?It would be almost trivial to add logging, and a graphic readout of current status and a log of temp, humidity, egg turns, vent, door opens, etc. With microprocessor power, you can do a lot more than back when the machine was designed.

yes temp/humidity sensors, but they will be changed to something of my liking. its 2011 who uses analog now?egg turning is periodic. to clarify (internal vent. is by a pulsator fan, to cycle air inside, ventilation is to allow air exchange)yes, door sensor is available. lights relay, available. I plan on using 4 digit LEDs for temp/humidity/vent(co2)/time since eggs went inRTC, should rely on capacitors and a battery to retain their time

update : definitely replacing with modern equivalents. temperature accuracy is very important, a deviation of a single degree could kill a whole batch. we use RTD temp sensors, very very accurate.

update 2 : this is where i plan to pick a suitable sensorhttp://www.sensorsportal.com/HTML/SENSORS/TempSens_Manufacturers.htmprovides a huge list, should be stickied in the scientific projects section.

I am undecided in temperature sensors. as the machines currently use RTDs. but to think, they didn't have digital ICs capable of doing such measurements back when the machines were designed. RTDs were the only viable option. so maybe i'll go for a good i2c digital sensor with the minimal deviation possible and see how it goes. maybe RTD's 0.02 accuracy is not that necessary after all.

as for the RTCs, NVM storage sounds like a great idea.. since the plant is situated in a rural area and experiences power outages a lot, we have a generator though. i am also thinking about using a UPS, since the arduino and its sensors and relays don't consume that much power. its the heating and cooling systems and motors that drain electricity.

I think its time I go back and go over the 500 page manual to figure out some more functions to implement.I will be playing with the board to try to emulate different conditions and see how's the board going to react, so that i can find out if i missed anything.

thanks ke7gkp for the great advice and link and thanks to coding badly as well

About the real time clock: It will make your life a lot easier, get one. The $20 spend are worth it.

As your working period well over 1 seconds, use the Time library. It manages the handling of the real time clock out of the box and you can work with Unix Time Stamps (seconds since 1.1.1970) instead of millis() for long term periods. For the scheduling of the next temperature measure, millis () is good enough.

For the internal EEPROM, you will find out that it's rated only for 100000 write cycles on each byte. In your case, I would save on each cycle change the current cycle and the date. I guess at maximum you'll save data every 30 minutes and the EEPROM will last for the next millenia. This way, if your power fails or the Arduino reboots, together with the RTC date it will pick up where it left.

Another gimmick you might consider is a cheap LCD display of the HD44780 type. On ebay (for example this a random hit when searching for lcd and 44780) those cost $5 and interfacing with it easy with the LiquidCrystal library. Add also a rotary encoder or 2 buttons and you have a user interface. Programming this will be a bit more complicated, but this can be left for later when the basics work.

If you need to replace the relay boards anyway, you probably will end up using shift registers too. ShiftOut supports these kind of operation and there are many good tutorials how to use it.

Consider adding to each relay a way of checking whether current is going through it on the primary side. This will add a little circuitry - I guess a resistor an opto-coupler per relay and an imput multiplexter per shift register - but you can add to your system a self-test mode for diagnostics and check whether something supposedly on is really on. Together with the display on the Arduino, the debugging and maintenance will become a lot easier. The checking on the Arduino side won't be time critical.

And as a last advice, once your project becomes better defined, post here about it. You'll find here many helpful people with practical experience in the hardware and software development. Read the tutorials first, play around a little and once your think you got it right or are stuck, post. Real life project on the industrial scale are specially popular, specially if you post some images too to give us a better idea what kind of beast you want to hook up.

All in all, you have a fun project well suited to start learning to develop with the Arduino. You can start out with the most simple programs and add in small steps the necessary additional functions.

That is why I suggested storing the start time in non-volatile memory (NVM) somewhere so you can restart the cycle if you haven't lost too much time. There are also tricks of saving "checkpoints" to NVM every so often (like every 60 seconds). So that if you lose power, you can check how long the machine has been down and take the ambient readings to see if the batch is still OK or doomed.

Consider getting a suitable shield and using a SD card for this - it'll mean you can do huge amounts of logging, which will be invaluable while you're debugging your build, or diagnosing a failure when you have deployed it for real.

Consider getting a suitable shield and using a SD card for this - it'll mean you can do huge amounts of logging, which will be invaluable while you're debugging your build, or diagnosing a failure when you have deployed it for real.

For this application, that would be overdoing it. The hassles to log to the SD-card are greater than the benefit it brings. And for the general state of the system, the 512 bytes provided by the processor itself is amply sufficient.

For your door open/close you should just have your fan wired through a contact on the door. I.e. door open, contact is open, fan shuts off. Safer than relying on on programming.

nah, what if door contact malfunctions , the arduino should be able to trigger the high alarm

i forgot to mention that in the original post. there is an implementation of a high alarm and a low alarm.

and as for the LCD i have thought of that but discarded it due to the complexity of the amount of buttons needed, but the rotating encoder revives the concept again. can u further elaborate on the opto-isolator concept to detect if the relay is activated, as i can't imagine that in action.

what i mean is, if the worker does not shut the door properly, there will be no way to indicate that the pulsator fan is halted. that way the eggs will be toasted... so its better to rely on the arduino to detect the door opening. via a contact or proximity sensor or any i2c option. gosh! i love i2c

and as for the LCD i have thought of that but discarded it due to the complexity of the amount of buttons needed, but the rotating encoder revives the concept again.

Samples on for rotary encoders with push button exist plenty and if I'm not mistaken, there's even a library out there handle LCD menus with an encoder. Even if this would be a little complex for beginners, I guess it's a task you'll be able to handle once your project is at a stage where you can use it.

can u further elaborate on the opto-isolator concept to detect if the relay is activated, as i can't imagine that in action.

First I have to admit, I'm more a software guy and not so much from the hardware side. So better have the idea checked by the hardware fraction. Now, what kind of things are attached to the relays on your shift registers? Are the switching for most part just AC appliances running at 220V AC (or 110V AC if you're on the American continent)? If so, look at your basic LED AC Circuit, those are quite simple. One or two diodes, a capacitor, a resistor. If you put this in parallel to your load between the switched part of the relay and the AC-ground, you'll have for each relay a LED as an indicator whether the relay is open or not. Of you take the idea a step further not to connect an LED but the emitter part of an opto-isolator, on the receiver side of the opto-isolator you have galvanic separated a nice TTL level to tell you whether the relay switched or not. Collect those input with a CD4012 and read them with ShiftIn. If you use quad opto-isolators like the NTE3221, this will set you back less than $10 per block of 8 relays. On the software side you will need to take into account that the signal on the input side is non rectified AC, so that it might read low from time to time, but as your timing isn't that critical, you have lots of leeway.

Another idea is to add a hall current sensor like the ACS712 (or the models matching the amperage going through the relays) per relay. This will allow you to get an idea about the current and you can estimate in software whether the consumer working properly (eg if the current drops a lamp might have blown). The main problem here might be cost, as those current sensor will set you back $3 to $7 per relay. The access would then be multiplexed with cascaded 4051B as described here. The coding again won't be time critical and you might have average several measures to weed out flukes.

I hope this gives you some ideas. More details can be worked out as your design progresses.