logging realtime value in 100ms

[jstolaruk]

To increase throughput, only log tag changes instead of their static value every time period.

 

[moosty]

Logging tag changes decreases the amount of stored data, it is a very good idea. However if your sampling period is more than 100 miliseconds, you may not catch some changes in data.

I think you need to buffer sampled data in PLC.

 

[zova]

I have a project that requires me to read 50 tags from a s7 400 plc under 100ms and log them. I dont belive that wonderware (or any HMI) can read and update values under about a sec. An OPC server can handle this kind of job ? Or what would u suggest. Thx...

"50 tags per 100ms should be read from PLC and updated to a database" - I don't believe that is trivial issue too, but if

"540 tags per 1000ms should be read from PLC and updated to a database" - the problem can be solved easily.

Whence I took superfluous 40 tags? This is time in format DATE_AND_TIME, one for each group consisting from 50 tags (group is UDT). UDTs should be updated cyclically in PLC, in 100 ms basis, but they should be read out from PLC all together in 1s basis.

I think moosty wished tell this.

 

[surferb]

100 ms with a PC and OPC server is possible, but not trivial. In fact, you should hit your ceiling closer to 50ms - of course, this depends on the OPC servers implementation. Ensure that you're doing array reads. As mentioned earlier, you'll be subject to network delay - that's where a cache comes in.

 

[moosty]

zova: "I think moosty wished tell this." Exactly. And I agree with using DATE_AND_TIME or an extra tag as an array pointer to state which tag was last refreshed by PLC. DATE_AND_TIME is safer.

surferb: "As mentioned earlier, you'll be subject to network delay - that's where a cache comes in." Exactly. Caching the data in PLC will be safer against network delays and instability caused by multitask management of PC operating system.

 

[seppoalanen]

Hi all,

I have a project that requires me to read 50 tags from a s7 400 plc under 100ms and log them. I dont belive that wonderware (or any HMI) can read and update values under about a sec. An OPC server can handle this kind of job ? Or what would u suggest. Thx...

Why all 50, why not only changed data?
OPC is for lazy people and slow for polling.
PLC can send message when needed f.e. with TCP/IP-connection. In PC have handler for the gate NNNN. Handler forward messages to SQL-Server.

 

[surferb]

Agreed - why not trap whatever it is you're looking for. I can think of few cases where the data logging goal isn't one of the following over a sustained time period:

1. Overall trend to view on a graph
2. Relative extrema (mins, max), rapidly changing values, or specific "target" values
3. Boolean alerts/alarms, which could be based on complex conditions
4. Basic aggregate statistical information (averages, std deviation, etc)
5. Some sort of regulatory requirement

Every one of these could be accomplished without logging data eve ry 100ms. I can imagine two examples of why you might have to log fast. One is if your process is extremely rapid, like modeling explosions, in which case you probably wouldn't log the data for very long. The other is if you're doing some sort of intense statistical analysis on all the data, in which case "running calculations" or short logging periods would likely be sufficient.

Do you intend on looking at 5 million points in a spreadsheet? Why else would anyone actually need to log that much data so rapidly? (Not a rhetorical question).

Why all 50, why not only changed data?

 

[zova]

to surferb:

You have sense, but for level of PLC-SCADA, this sense is, kindly speaking, too political. The discussion of job goals comes to sad end.

 

[surferb]

I would love to get specific - if OP tells us what he's working on. You're right - otherwise this conversation has become pointless.

to surferb:

You have sense, but for level of PLC-SCADA, this sense is, kindly speaking, too political. The discussion of job goals comes to sad end.