"PWM" output versus simply using a timer

[PlasticsDude]

simple, short question: Why is it "more proper" to use PWM as opposed to simply using a timer to control pulse width? Is the answer that a timer will be affected by scan time whereas PWM will not be?

[panic mode]

that's the idea...

[PlasticsDude]

But in the case of a relatively simple, short program is it kinda like not a big deal to use a timer?

[Peter Nachtwey]

Every time/counter you reset the timer you lose half a count/period on the average. Timers and counters are a monsterous evil that PLC manufacturers tempt you with. They look easy but they aren't any good for insuring periodic events. They can only delay or count.

[PlasticsDude]

So what is the correct way to time longer events...say I want something to happen for 5 seconds...should I use an interrupt?

[TERdON]

Some PLCs have built in clock bits (on Omron: P_1s et al). They should be exact, I suppose.

[Peter Nachtwey]

Suppose? They clock bits will be exact IF 1. They are implmented in hardware. 2. You can't reset the bits or clock.

[paulengr]

Two possible ways around this: 1. If the PLC supports a timer-event that triggers your code, this is one way of getting around scan time problems. I routinely stuff all timer-critical code into the "software timer interrupt" (STI) of Allen Bradley PLC's. 2. Access the internal accumulator value. Starting and stopping is frequently affected by the PLC scan (among other things), but once it's running, the internal timer is driven by the PLC's clock. For instance, here's pseudo-code for a common Allen Bradley routine for triggering an event (or accumulator or whatever) once per second that doesn't use a timer interrupt: a. Run retentive timer for 2 seconds with a 0.01 second resolution (timer counts from 0 to 200). b. Check if timer is >100 counts. If so, then latch the "1 second pulse bit" which triggers the rest of your code. Subtract 100 counts from the timer. The timer is intended to NEVER actually finish (reach 200 counts). The PLC is measuring scan times for you and updating the timer. You're just tapping into that latent capability. In my experience, it appears that PLC clocks are good for about 10^-4 to 10^-5 accuracy. PC clocks typically already provide 10^-7 to 10^-8 so you WILL notice some clock drift over time. If you want to plumb the depths of 10^-8 or higher, then you need an external clock. A good oven controlled oscillator won't set you back more than $100. If you connect it to a high speed counter, you should be able to trivially achieve 10^-12 accuracies. Heck, I've been starting to see those kind of accuracies even for off-the-shelf temperature compensated oscillators. The temperature compensated oscillator is about 10% of the price but in the grand PLC scheme of things price doesn't really matter because you'll have more money tied up in the counter than the clock source. Another alternative would be a radio tuned to WWVB or a GPS receiver, which gets you almost instantly to the same level of accuracy, although you need an antenna and weather becomes a factor. If you have a PC/HMI, there is another alternative. You can provide the PC's clock to the PLC. The PLC can run a routine to periodically compare the PLC and PC clocks. If they drift apart, the PLC can intentionally skip/miss a second to align the clocks. You *could* just stab the value of the PC clock into the PLC every so often but the advantage of doing it this way is that your timer routines are unaffected by the clock drift updates (something you can't do if the PC just adjusts the PLC clock without telling you).