search

emrebekar / node-red-contrib-opcda-client

Node-RED Opc DA reading and writing node
Apache License 2.0
21 stars 11 forks source link

Status "GOOD" required - logical bug ? #7

Open DS-DE opened 3 years ago

DS-DE commented 3 years ago

There is all fine, if the data quality is good, else no data is sent. ( use can observe the state only ) Logical BUG (my point of view): Data quality like bad or uncertain are valid information - and should be send. Not matching data shoud be handled somehow, but good, ungertain, bad, ... data should be send, each item with its quality. ( on complex engines some data are sometimes bad or uncertain, but this information shoud be published )

emrebekar commented 3 years ago

Yes that is good point. May be we can put a timer in order to remove the quality information after a few seconds to Ready.

DS-DE commented 3 years ago

My note does not refere to the Server-Client-OPC-IO, which may have a timeout. EXAMPLE: Assume you build an OPC-Server offering the local temperature and it uses a serial-io-line to read the local detector. Now the srial io fails and the OPC-Server decides after 10 seconds to switch TAG-state to 0x14=BAD(last known value) and after a minute to 0x18=BAD(communication failure). Now the owner of the Server reboots the systen, without success the state may become 0=bad(non specifid). This behaviour belongs to the OPC-DA-Server. Thus the client shall: a) show the state as it is b) if severals variables have several states, then all the variables should be handled, even if some values have state "bad". Imagine the server publishes the humidity also and this data+io never fails, then you have one good and one bad tag. (( my problem ist that the first "state != good" stopps all data ))