Timer value input

I have a fairly simple orienting program that requires "quick reflexes". I need for an operator to be able to input a 3 digit number as timer value. The problem is that I'm hesitant to use an HMI, mainly because of scan time issues. Does anyone have any ideas for simple ways for a user to enter a 3 digit number into a progam? I was thinking along the lines of a piece of thumbwheel-type hardware, but don't let that confine your thinking. I am using a Automation Direct DL-05.

Thanks in advance for any and all ideas.

Here's what I've seen before:

HMI TouchScreen - Hey! The're not that slow
Thumbwheel - Fast has your slowest operator
Old dial type telephone - You count the pulses
Barcode reader - If those setting can be pre-printed into a barcode
Push buttons - You count the pulses again
Potentiometer - Analog input and Set Push button

You could also :

Voice activated - This would be fun to do ...

I can't imagine an HMI where the "scan" time exceeds the time it takes for an operator to adjust a thumbwheel! (I assume by "scan time" you really mean the lag time or latency from the communications link.)

For most operator interfaces, the operator accesses the current data from a separate setpoint entry function. The PLC registers remain unchanged until the operator presses the enter key, and then the register is updated over the serial link, usually in much less than a second. If you use a three digit data field on the HMI all three digits in the PLC register will be updated simultaneously.

An alternate would obviusly be a BCD thumbwheel from Red Lion or such, but this requires more prgramming.

Pierre mentioned rotary telephone and push button, counting pulses.

Why not just 10 small pushbuttons, like on a touch-tone phone, directly wired to PLC inputs? Add one or two more for "Enter" and "Clear". 12 inputs is the same as 3-digit BCD, and faster for the operator to key in. And being I/O, no worries about data transfer latency (not that, from an key-enry perspective), an HMI is slower than spinning 3 wheels and pressing a button.

To save on inputs, you can do what the phone co. does. Each row of keys generates a single, pure note. Each column generates a different note. When you press a key, you get both notes together. (On older models of phones, if you pressed two keys in the same row or column at the same time, you could hear the pure tone). So 12 keys in a 3x4 phone arrangement would only need 7 inputs, and lots of paralell wiring.

But Tom is right - go with an HMI. The operator get feedback, which will improve speed & accuracy.

Thanks for your input input.

Your assumption is correct, Tom. My concern with the HMI is that the operator might choose to push some buttons while the process is in operation, which is fine, except that I've had problems in the past of exceedingly long scan times while the PLC is reading and writing to the HMI. In another machine, it was long enough to prevent the machine from working correctly (missed inputs, etc.) Just a few ms. can cause a fairly large gap in registration in this instance. Perhaps the writing of just a single value is negligible, though.

The phone dialers, rotary and touch tone, both sound like fun.

Brad

Which HMI are you using with the DL05 - is it the DV1000? In that case, it's the display which is slow. The numeric entry is very slow and it does work as a thumbwheel does - each intermediate number is reflected to the PLC. There is no ENTER key.

I haven't worried about this too much but to address this I would have the timer preset come from a different address than the displayed value. Also keep a 'previous' copy of the displayed value. If the 'previous' and 'current' differ (operator is beginning to change the value), then set a flag and keep copying the 'current' into the 'previous'. When they have stayed the same for a reasonable amount of time (the operator has stopped changing the number) then copy the current into the 'timer preset' location and reset your flag.

Thanks Bernie. Yes I probably would use a DV1000, if I go that route. The display updating slowness is not the problem, though (although the technique you mentioned might come in handy on another project).

My concern is more with the increase in scan time caused when the PLC reads from/writes to the display. In the application, an eye stops a high-speed rotating cylinder a user-specifided number of milliseconds after it sees the registration mark. A small "hiccup" in scan time from HMI communications could translate into an error of several degrees in rotation.

Is STI an option?
I'm not well versed in AutomationDirect.com.

If the DL-05 were initiating the communications with RX and WX commands there will be an effect on scan time. However, most HMIs (not the DV-1000 though) operate as the communications master, and the DL-05 will be the communications slave. Check with the guys at AutomationDirect.Com tech support to be sure (1-770-844-4200), but I believe the communications will have a negligible effect on scan time if the HMI is the communications master.

Let us know what you find out from tech support - this is an interesting question.

Brad,

If you want to use a thumbwheel...

Some code is constantly reading the thumbwheel or, if not reading constantly, the code just happens to grab the thumbwheel data right in the middle of a change. This can lead to some serious problems in some systems.

If you want to use a thumbwheel, then mount a pushbutton next to it.

The operator can change the thumbwheel in any manner he wishes and then press the button to say "Data Ready" to the PLC. Using the "Data Ready" method is an old TTY technique for indicating that the data is now valid. A "debouncer" for the push-button is not necessary for this particular situation.

At "Data Ready" ON, have your code accept the thumbwheel data and hold it in some V-Mem location.

Since you know when the new data can be entered into the process, you can have the code read that V-Mem location each and everytime it is OK to change the value. Whether the value has changed or not, you have the latest value and can apply/re-apply it to the process. You can also check the value while it is in V-Mem to see if it is really valid in terms of the process. If not, then, don't apply the new value and call a FAULT Handler.

If this is the only reason you have to use an HMI.... you might want to consider the "Data Ready" method.

I have used the Optimate OP-1500 panel with a DL-05 as an HMI panel for entering timer/counter presets, alarm trip points, setpoints, etc. and to provide passcode protection for remote field mounted units. I did not see a problem with the scan time, but I was only moving small amounts of packed data. The panel polls the PLC. This panel does have data ready / data acknowledge capability so there is not a problem with worrying about the time it takes the operator to input the digits. AutomationDirect can probably tell you how much you can expect it to extend your scan time. I suspect if you can connect with DirectSoft and monitor and control the process with data charts without impacting your process, this panel will work. It does require code in the PLC to handle packing of the data and receipt and acknowledgement of user input. That in itself will cause some scan extension.

My program was scan time dependent due to some calculations using the high speed I/O circuitry to calculate RPM of rotating equipment. I chose to set a fixed scan time in the PLC to ensure this would not be a problem. If I remember correctly, I set it at 20 mSec. Yours may have a faster scan time requirement.