[Visual-devel] Re: [MAT-devel] MATplc - VISUAL interface

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

On Monday 25 November 2002 18:33, you wrote:
> Good news!
>
> The module to communicate MATplc with hmiViewer from the VISUAL project
> is now on the cvs: mat/scada/visualview/hmiViewerServer.py
>
> Some comments about the module, I already tested it and it works, but it
> still has some issues to solve.

 I am assuming that all points are floats
> (the module has no way of checking the type of type of each point).
Another one may be the support for hmiPushButton widgets. There may be ways 
to avoid their use, but in many cases they simlify things. Let's consider you 
want to start/stop an elevator. You would want to set/reset an "on" flag with 
a start and a stop button, so you can reset it also in the control program 
when reaching the final position. Hence it is necessary to transmit a 
volatile "on" signal long as the button is pressed. In VISUAL, this is done 
in cooperation between server and PLC driver. The hmit uses a special call 
named "tset". 
Tset puts a 1.0 to the variable.
Tset marks the variable saying this is from a pushbutton.
The PLC driver is called because variable has changed.
The PLC driver transmits the value 1 to the PLC.
The PLC driver, seeing it is marked as "from a pushbutton", sets the value to 
0.0 and marks it as "ackknowledge for a pushbutton".
In the next cycle, the PLC driver is called because variable has changed 
again.
The PLC driver transmits the value 0 to the PLC.

These are possible solutions that come upon my mind:

First, in the communication interface: It can transmit a 1 first and mark the 
variable internally. When it reads values next time, it looks whether the 
value is already 1. If so, it issues a nother write to set it back to zero. 
If the zero is read back, it removes the mark. I use this method in the 
modbus communication interface. It is in CVS (hmiModbusCI.java).

Possible dangers:
1.The one might be read back but might not yet have been processed by the 
PLC. In this case the operator would probably press the button again, until 
the machine reacts.
2.The client/server connection may break before the zero has been sent. This 
is more dangerous. In the elevator example, it must be made sure that reset 
wins over set or the elevator will not stop in final position. On the other 
hand, this is also true for a mechanical button that gets stuck...

Second, in the (mat)PLC control program. You could implement the "tset" 
command in your server like the set command and every control program must be 
written to reset the button states after processing them.
Possible dangers: none
Drawbacks: Who does a control program must be aware of this.

Third: In your server. The "tset" command sets the variable like "set" would. 
Then it should remember that there is something more to do for this 
variable/point. After at least one complete cycle of the control program, the 
server should set it back to 0. The server should reset these variables also, 
if the connection is interrupted unexpectedly, thus avoiding buttons getting 
"stuck".
>
> the rest. The only requirement is that the points are defined in the
> MATplc configuration file, if this is not the case then the points will
> only exist (including their value) in the hmiViewerServer and the
> hmiViewer will be able to read and write them 
The intended reaction for a nonexisting variable is that the server sends 
some question marks. Different strings of 1 to 3 or four question marks are 
interpreted as different error conditions. 3 "???" means that the variable 
doesn't exist. Any widget will show the variable name white on red ground 
instead of it's normal appearence. 2 Question marks "??" mean that a value is 
uncertain. This may not be meaningfull for matPLC. In VISUAL, it usually 
means that the value could not be updated because of PLC communication 
errors. The widgets will show the question marks white on red ground in this 
case.

A last hint: In VISUAL and hmiViewer, all values are doubles. This ensures 
that when 32bit values are tranproted over the net and converted back, all 
bits are correct, which is not so with float. This is currently a concern 
when using variable color values according to the 24bit RGB model (by binding 
4th to 13th widget parameter to a variable). In the future, there may be 
other widgets that interpret a value as an assembly of up to 32 bits, e.g. to 
show input/output states.

Thomas