UniOPC update rate strange behaviour

[Laimis]

Hello,

We noticed a generally slow and rather unpredictable update of SCADA variables in our application via UniOPC and now we are making some tests in our lab to determine cause.

We configure UniOPC for 3 PLC on a single com port (RS422 style with *R4 converter modules), and define a large number of variables for each of them on our SCADA. Some 50 to 100 variables for each PLC. That is more or less what our production application is.

Our goal is to achieve very high com port utilisation and in doing so - as fast refresh on variables as possible - something we are definitely not seeing in our production application. Since our RS232/422 modem has TX/RX LEDS we can observe activity visually. Polling sessions for each PLC and that number of variables are quite long and visual. And inconsistent.

We try to set various refresh rate (for example 1 or 3 seconds) and the speed to 9600 or 38400 and retries 1 or 3 - does not seem to affect result in a significant way.

First of all UniOPC refresh period SEEMS to affect the PAUSE or idle time between polling session and not the frequency of such sessions as is written in manual. Polling sessions last at least one second for each PLC and we safely can set the refresh interval to 0.1 seconds and the UniOPC does not seem to get any worse performance - such as overlapping of reading sessions as might be expected - just the pause between sessions increase or decrease accordingly.

The stange thing and the problem is that behaviour of UniOPC is not consistent. It would seem that the number of variables defined have a very strong effect on UniOPC polling behaviour. For example we define 300 (3x100) variables - we get "normal" polling session - all 3 PLC are cyclically polled, process repeats after refresh period. The variables seem to be correctly updated on SCADA every few seconds as is expected. .

If we try to delete (!) some SCADA variables very often we get "sporadic" sessions - like 2 PLCs polling, then some 10 seconds pause, then polling of third PLC and the like. Obviously we also get plenty of problems with SCADA variable display this way - they timeout and update more or less randomly every 20 to 100 seconds - that is probably the problem with our production application. The definition of PLC in UniOPC does not change when we try one or another SCADA applications, just the different number of variables are created by UniOPC (as expected)

We are quite new to Unitronic and OPC so maybe we are missing something obvious?

Any ideas somebody?

[Ofir]

Hi,

Usually in systems where you have many tags and the update rate is critical, We recommend using MODBUS instead of UniOPC since there are only 2 elements (PLC and SCADA) and not third element between them.

Most of SCADA systems support MODBUS driver and there should not be any problem to implement such connection. You will need only to set the PLC as MODBUS slave.

[Laimis]

Hello,

Yes, we already tried Modbus. It works MUCH quicker and fully predictably - basically we get all 300 variables from all 3 PLC at 38400 baud in under 1 second.

UniOPC has its uses. For one - you do not have to buy I/O server if using Wonderware, It is easier to develop as you do not have to define frames and work mapping frame offsets for each and every variable, but rather "use them directly" in SCADA. This saves developer time.

We do not found any document which would outline the limitations of UniOPC server so we know when to use it and when not to.

Likewise now we have another project with UniOPC via GPRS. There is just single PLC with very few variables. Now it works ok, but we have no idea how well would it scale once we have hundreds of PLCs connected via GPRS with hundreds of variables each.

If we find UniOPC scales badly then we will have to rewrite a significant portion of our application which defines all the variables in SCADA. hat would basically involve modification of live system with all the nice possibilities of human error while we transit from one communication mode to another.

Could you send any link where we can read MUCH more on the internals of your UniOPC server?

That is prec