You don't need loops inside of loops. The loop() function that goes after setup() is enough by itself since it runs over and over.

right now inside loop() you

- read the sensor

- set/adjust off time

- set and show warnings

- set on time

- open the valve and wait for on time to go by

- close the valve and wait for off time to go by

and then the loop() ends

All I suggest you try now is to change the last two parts.

You'd need 1 variable to tell if the valve is open or closed.

If it's open then check how long it's been open and if 'on time' is up then close it and set the open/closed to closed.
ELSE If it's closed (not open and since you checked if open you don't need to check if it's not)  then check how long it's been closed and if 'off time' is up then open it and set the open/closed to open.

That bit of logic takes very little time to run through, less than an analog read. It don't wait at all!

byte closed = 0; // use any numbers you want but 0 and 1 ... if (0) works out to false, if (1) works out to true
byte open = 1;   // so if open = 1 and valveState below is set = open then if (valveState) runs as true that time
byte valveState = 0; // and then you can code for open and closed with the same piece of code
                                 // honest, just trying to get you started down the easy path
// the bytes open and closed are there because it will make your code below more readable
// they could be const byte types but don't have to be, don't worry about that now

in setup() {
  digital write the valve to the valveState you started with
}

...
down inside loop()
...

// this is a structure to get past the delays
if open {
  if 'on time' is up {
    close the valve
    set valve state = closed
  }
}
else {
  if 'off time' is up {
    open the valve
    set valve state = open
  }
}

Yeah, that can be shorter but I'd rather you see how close it is to what you already have.

Could you (crazy) glue something to the top of a switch button?

Look at Disney.

I knew a place that printed on cans and bottles (yes, a cannery) by turning the object under the print head as it printed. That was back about 20 years ago and the results were functional but not precise. Very often when machining parts the tool head moves at most on one axis while the part is moved on the others.

Add: the smart thing would be to print on the piece -as- it is being made.

What little code you have there runs in about no time flat -compared to the delays-.

The next longest thing are the analog reads which take about 100 microseconds (1/10th of a millisecond) each.

At 16 MHz the Arduino runs 16000 cycles per millisecond with many instructions taking 1 or few cycles but some you write one word and many things happen for that. To make an if happen, numbers must be loaded into registers on the CPU and then it takes a cycle to compare them. Of course if one number is already still in a register from last compare it won't take as long to do the next. Still, to do a few extra compares that the first has made unnecessary does not help but it's no more than a scratch next to a 1 millisecond delay -- but the scratches can add up like nickels and dimes.

One thing to look at and improve is that every time through loop() you have a long cycle of this-this-this-this ending with delays. But except for the delays it's not really loaded down yet.

A 20 millisecond delay is so short a led turned on and off that fast flickers. On for 20 ms, off for 130... maybe you should step back and make a variable time led blink just to see and know what speeds you are using.

Perhaps also to find a way to know the real speed your engine runs at, does it have a tachometer and is it 2 stroke or 4 stroke or something else? Is it a 1-cylinder engine? Some of what you write, I think you have documentation or that kind of knowledge or some numbers you believe. Just to say the valve runs at certain speeds, you must have done some tests or have documents there.

At 10 cycles a second, a single cycle is a long time to an Arduino running short code.

Me, I would arrange it so the analog reads are done in between waiting to open or close the valve and take averages of those reads or even watch the rise and fall of O2 during the periods that the vale is open or closed. I would do this instead of waiting for the valve to cycle before taking a single read then basing knowledge of how the engine is running on that.
There is no need to do everything every time that loop() runs. In fact, it is counter-productive to run that way. To do one thing in one execution of loop() and something different the next with priority of time critical tasks is a better way that keeps doing-nothing tasks from holding up doing-something tasks, which is one form of 'blocking code'.

You can unblock simply by watching the time and operating the valve as needed or you can run the PWM library... either way will get rid of those delays that block your code from doing anything more than 99% of the time it runs. You already compute the on and off time and have to either way but it's a mystery to me why you'd want to run the rather large software PWM library when you can check time and do a digital write in a very few lines of code at all. But hey, it's your project!

If what you have works at all then it's not bad.

I thought that the valve was only good for 5 Hz (5 open-close cycles per second) which would be a minimum of 100 milliseconds (1/10th second) between start of one movement and start of the next, yet you have minimum off time at 20 milliseconds. Sure, the instruction will run but that doesn't guarantee the valve will move that fast.

You can use else if to reduce the number of if's the code has to process.
example:

Code:

if ( error > 50 ) {
   off = off - 12;
}
else if ( error > 20 ) {
    off = off - 5;
}
else if (  error < -20 ) {
    off = off + 12;
}
else if ( error < -80 )  {
    off = off + 70;
}

BTW, the IDE copy code for forum button gets the html tags wrong and the code won't all always show up right. Instead of quote and /quote inside the brackets you want to use code and /code. There's the # button in the forum post editor that makes them, next to the word balloon button that makes quote tags.

And here's something you might like. There's leds with 3 leads that can be red, green, or amber (just using full power, with PWM there's a full range of red/green mix), and don't cost much. More expensive are 4 lead RGB leds that can be pretty much any color you want. So your two warning lights can be one light that too hot is red, too cold is green and just right is amber or even tell you just how much hot/cold you're running. With RGB led you could get real creative.

A high power programmer might rescue it.

I think that 16 MHz needs over 4V just to run stable.
 

Yeah, you'd need -two- variables to store separate ON and OFF time and another to know if the valve is open or closed.

Compare all that to uneven PWM manipulation which BTW would take the same number of variables and more actual code work.

Yah. PayPal charged me IIRC 1% on a $164 purchase last December.

I can't afford to buy $100 in Arduino boards just to give then $20 or so. Sorry but that's how it is. Maybe they could sell expensive coffee mugs or something?

Correction...

but I'll try that next w/ a 10k 120 ohm resistor

...connected between RESET and +5V.

I was using a 10uf cap between reset and grnd. It worked when I programmed a Tiny85 but is the resistor method better?

Please, if it's not the same then you should put a comment block telling the revision above the others. Some poor sap like me might think he has two of the same and throw one out otherwise.

I think your idea of using the existing PWM outputs would probably give you the best result, but if you prefer to avoid playing with the timer configuration then what you're trying to achieve could be achieved quite simply within the sketch itself.

The idea would be that instead of having a loop() function that completes a full PWM cycle, you write a loop function that completes very quickly and just does a couple of things each time through:

If it is time to read the EGO sensor then read and store the sensor value and do any processing necessary to recalculate the PWM settings.

If it is time to change the PWM output state then change the output state.

Both these functions would be controlled using the technique demonstrated in the 'blink without delay' sample sketch i.e. have a variable that holds the time you last did <thing>, and compare this against current time to see whether it's time to do <thing> again.

 

The logic loop is definitely good, but how to make use of this without using timer change would  be rather complex. 

How often to "do" something is useful, I appreciate the heads up, but how to use that loop to change the ratio of on vs off time, while keeping the total of on + off the same is not something that's readily apparent to me.   I"ll let that stir around in the brain a while and see if I get inspired. 

Thanks.

It's very simple.

-One variable holds the number of milliseconds per pulse. 5 Hz would be 200 milliseconds. More to slow it down, less to speed it up. Or if you open and close 5 times per second then 100 milliseconds between changes, right?

I'll call it changeValveMillis.

-One variable holds the last time the valve changed.

I'll call that lastChangeMillis and make a companion variable called nowMillis.

All of those will be unsigned longs as that's what the millis() function (milliseconds since startup) returns, and there's a great 'feature' where the result is always right even when the counter 'rolls over' in about 50 days.

-Each time loop() runs you set nowMillis = millis(). Then you check if nowMillis - lastChangeMillis >= changeValveMillis. If it is then change the valve state (open to close or vice-versa). If it isn't then do the next thing like check the EGR and possibly change valveChangeMillis to adjust your engine.

You see, the loop() may run many 100's of times between changing that valve once.

Perhaps there is a maker of printers in India that you could make a relationship with, like intern or consultant? Then you would know exactly what they use and be able to get parts at cost if not free?

The only way the wrap should be a problem is if you're watching for durations longer than 49.71... days.

How about time64_t for clarity as well as uniqueness?

Hmmm, I know the ATmega is 8 bit.. by handle I mean actually able to do calculations with, shift, etc.

I have a box in a closet with my late 70's TI programmable calculators, a TI-56 and a TI-59 on print cradle. I believe they're 4-bit machines capable of 20-digit precision, probably using BCD in microcode. Back in 1977 I used the 56 to run the map table while in a US Army radar crew. Months later the Sound-Flash guys all had green TI-56's. I think that by 81 the expected upgrades obsoleted the lot.