[Visual-devel] Re: pushbuttons in MAT

[Thomas H. <Tho...@we...>]

> Thomas,
>
> I don't like implementing a pushbutton's I/O debounce behavior in the
> HMI. If an output is a momentary command, I feel its momentariness
> should be implemented in the PLC.
I do not think so. With the mechnical button the widget tries to replace, the 
momentariness is in the spring, hence outside the PLC.
That can be done, as I did point out in a former mail. The drawback is that 
the programmer of the PLC must be aware of programming for interoperation 
with a or this specific HMI. (Personally, I more often modified or enhanced 
existing machinery then designing from scratch.)
>
> The HMI can simply write a 1 to the output point when the button is
> clicked, and assume (if the HMI cares at all) that it will reset to 0.
It can still be done in the PLC. Use a switch widget. It would only write the 
one. Bind a read and a write command for the PLC driver to that variable and 
reset it in the PLC. One extra point: If used with VISUAL, the PLC drivers 
read and write to the PLC without synchronization to program execution. Hence 
if you write to some flag between evaluation and reset, no action will be 
taken. So you need one more flag. In PLC program do:
read the flag the HMI acts on.
copy to another flag.
reset the flag the HMI acts on.
perform any actions depending on the copy.
next cycles' copying resets the copy.
>
> If the HMI needs to know whether the command was effective or not, there
It doesn't really NEED to know. Usually, in my designs the button changes 
color when the corresponding variable is nonzero, providing a visual feedback 
that the state is "pressed". When for whatever reason (cut the cable) a reset 
doesn't take place it remains so. This is a perfect analogy to a mechanical 
button that gets stuck.
> should be some other point (or points) in the PLC to feed back the
> current status of whatever circuit was affected.
"Some point" means extra programming in the PLC. I do not see what it would 
be good for. It only has to be done.
>
> I see other benefits, particularly in the area of permitting more
> sophisticated PLC handling of the command: preventing multiple commands
> within too short a period of time (regardless of the source), generating
> an alarm if the command doesn't have the desired effect within some
> (possibly configurable) timeout, etc
Ok, this is useful if and only if it would be useful with the mechanical 
button also. Examples: a lamp as feedback for "on", delay of an input to 
prevent a counter from counting multiple events. There may even be cases 
where you would introduce a timer for the input from a mechanical pushbutton 
to give an alarm if someone fell asleep with his head on it....

As I mentioned above, users are completely free to use a hmiSwitch widget 
instead of the specialized hmiPushButton.  
With VISUAL, read and write instructions for the PLC driver targeting the 
same coordinate would be necessary. With matPLC, I'm not sure whether this 
could be specified.
Order of execution:
read from PLC: result zero
read from PLC: result zero
Press button
write to PLC. PLC has a one.
read from PLC: result one, button color changes (if parametrized so)
read from PLC: result zero if PLC has yet taken action.

To summarize: I like to simulate the behaviour of the simulated things 
(pushbuttons) as closely as possible. And I like PLC programmers to use their 
usual style and methods. I hope people will regard this as "natural".

Regards,

Thomas