> "Tim Wescott" wrote in message
>>I'm not sure exactly what you want. I feel like I should, but I haven't
>>had breakfast yet!
>>But I can see the core of what you want: event A happens, then at some
>>time T later you want code B to execute. Usually the way that I do this
>>in a non-interrupt-driven system is to set up one of the processor clocks
>>to free run, then on the event set
>>extern int time_now; // set by hardware
>>timeout = time_now + T;
>>enabled = true;
>>Then in my task loop I'll have a check
>>if (enabled == true && time_now - timeout > 0)
>> // put your code here
>>Note that the order of operations in the test is important: time_now
>>_will_ roll over; if you test on time_now > timeout you will get
>>different, and quite possibly undesired, behavior from your code. Note
>>also that whatever size your 'int' is (probably 16 bits), this method
>>will only support a timeout of MAX_INT (32767, if 16 bits) ticks.
>>Alternately, you can have a routine that just runs at 1ms intervals, and
>>keep track of all your timers there.
>>Control system and signal processing consulting
> Oops, something I didn't make clear.. millis() is part of the Arduino
> From Arduio Reference:
> Returns the number of milliseconds since the Arduino board began running the
> current program. This number will overflow (go back to zero), after
> approximately 50 days.
> So what I want to do is make my loop run as fast as it can and control by
> setting flags and conditions, sort of parallel processing like in a PLC, not
> sequential style programming.
> A little background. My first computer was a sinclare zx 80 (IIRC) for
> $199, later I bought a Commodore 64, did some Basic and 6502 assembly
> language. Later I played with PIC microcontrollers, 16C84, 16f84 came out
> later. So about everything I learned was pretty much sequential style
> programming. When I got a 286/12 I bought Turbo C++ and a "Teach yourself
> C" book, got where I could write programs but not enough practice to get
> good at it. After some time I ended up with an Engineering company that did
> industrial automation type work. It was difficult at first for me to get
> PLC's to work like I wanted, I was used to writing sequential type of
> programs and the PLC was parallel, all rungs execute at the same time, well,
> not really but I learned that I should write programs as if they did.
> Here's a project I designed, built, and programmed the controls for.
> You can see there are a lot of things happening at once.
> Anyway, over the years I have pretty much figured out how I can write the
> same type of programming in other languages beside ladder logic. The
> straight runs just AND and OR conditions to control outputs when they should
> be according to the logic. I think I could write the bulb machine program
> in 'C' very much like it was written in ladder logic.
> One of the problem areas is getting timers to work like PLC timers, they can
> have dozens timing multiple events at once, none interfering with the
> others. So I'm trying to come up with a good function that will compare the
> preset time with the system time and execute additional code 1 pass per pass
> through the loop (won't hang up the loop).
> Now I know I can write something to hog the processor with a loop and halt
> the main loop, but I will have to be careful not to, if it happens I will
> have to correct the error.
> The system timer will overflow once every 50 days so I need to set an
> "will_overflow_bit" when the destination time is less than the current time
> ( a positive number plus a positive number is greater unless there is an
> overflow). So once the timer condition is true, and the timer preset is
> timed out, the code will be executed once per loop, like an if() function,
> not cycled inside continuously like a while() function.
PLC's capture all of the inputs and output states just prior to a
scan of your program. When OS of the PLC scans ladder rungs, it is
simply viewing and modifying the captured values, not the actual values
sitting at the hardware outputs/inputs. This allows for a ladder program
to see the same values captured through out, however, changing the state of
any outputs with the ladder code, only changes the captured values but
does not actually change the hardware output, yet. So this means that
any remaining ladder code there after will now see this change. Care
must be taken when doing this because it can cause debugging problems
when more then one point in the ladder code is setting the value of an
At the end of all scans, these values that were captured to reflect
output states, which also could have been altered ofcourse, get written
back out to the outputs.
You can in effect do the same exact process and that is, to simply
capture all of the needed values and hardware states at the start of the
loop and store them in variables. You then address those values instead
of directly accessing the IO on the fly in your program. This would
solve problems where you may have an unpredictable event due to noise or
what ever changing the state of an input while you're scanning your code
and thus if your code is referencing this input several times, would end
up causing your code to fail on making a proper determination with
Also, you should do this with the outputs, too. That would prevent an
unwanted pulse to appear if your code is changing the output hardware
value before it actually decides where it will stay.
I could be wrong? But, that PLC shown in the video looks like a PLC5
family from AB ?