Synching asynchronously

This should be a good one.

Within my plc (unitronics V280), I am collecting data, and every 60 seconds, I cache this data to a buffer (11 integers total).

I want to poll this cached data every 60 seconds via OPC (matrikon modbus plant-based) and stash it in a database.

I'm trying to do this asynchronously, meaning no timing exchanges between the controller and the PC running OPC software. Hence the cache buffer, so data remains stable until picked up by OPC.

Here's the catch (catche?) : If my OPC is reading the data from the controller at the same time the controller updates the buffer, I get half of one record and half the next. At least in theory.

Now, I've rolled this around in my brain for quite a while. Thought about synchronizing clocks, but too unreliable. Thought about setting a "flag" bit in the PLC telling OPC to "come and get it", but that's not true to the spirit of asynch was trying to achieve. Also thought about some additional buffering scheme, but since everything depends on 60-second time frames that just moves the problem to the last entry in the buffer.

Ye cats, I'm confuzzled. And I know I can't be the first person to run into this sort of bufferring issue. So what sorts of magic have you PLC wizards used in the past to overcome this obstacle?

Thanks!

TM

I've had exactly that problem.

1. Yes you must use at least two separate data buffers. One being updated by the PLC. The other read from by the "other" end (here your OPC client).

2. How to know that the OPC has read the last data ?
Answer: Put a telegram counter in the data area in the PLC.
Let the OPC client copy that counter and send it back to the PLC when it has finished reading the data. Obviously the OPC client must send it back to another address than the one it has read from.
The data has been read by the OPC client when the two count values match.

3. In addition to the above, you can arrange a life-bit between the two. This is another counter that the OPC server must monitor. Again it writes the count value back to the PLC when done at another address. Rather than wait 60 seconds each time, the OPC server must read/write as fast as possible. In the PLC you arrange a timeout alarm. This can be set at say 5 seconds. You can than flag an alarm lamp/horn.

JesperMP said:

I've had exactly that problem.
1. Yes you must use at least two separate data buffers. One being updated by the PLC. The other read from by the "other" end (here your OPC client).

Click to expand...

Two? Is Variable A = 100 Variable B =0
Copy A => B A and B = value 100

OPC read variable A and HMI(PLC) read varible B.

Why? Have conflict..., what problem read sometime one variable.

For reply item 2: Make checksum, and read sometime last 2 algarism.If is swap, have change.

I am guessing that the 11 integers that Timothy must read every 60 seconds "hangs" together in some way.
By reading the whole thing one one go they dont get mixed up.

Another reason could be that Timothy has a slow online connection, and reading everything in one big packet rather than 11 small is a way to squeze more data out of the thing.

Maybe Timothy would eleborate ?

edit: dandrade, if Timothy would use the checksum to know when data was read, what if there is two identical datas in a row ?

Good asks, it caught.Two in one.

It depends on start, refresh. Can be trigger of calculates of checksum, to each request of reading.

Not to generate trafic (to transmit), if the data do not modify.

Only Timothy knows,

but if it is for example production data:
How many items of type x produced, how many type y produced etc.,
And if the production is constant or nearly constant then there will be duplicate datas sooner or later.

If the application allows it, I strongly suggest a watchdog type of continous data transfer (my point 3).