Laimis

It does help, thanks. One of my problems is trying to understand more than is needed to make work done. I have made call to subroutines unconditional, leaving timers at the top, but returning immediately after if it is "not the right time" for this subroutine to run. Should be a nice compromise. Thanks again.

Thanks for the answer. Sure it is not hard to test, but that is the point - if I test it now and find out how it behaves then I can build my application around that behavior and it will work - now. But since this behavior is not documented then it may work differently in another PLC (mine is V120-22) or in next firmware update and may break the functionality - would be a hell to remember and debug. Of course it is possible to run timer unconditionally in some other subroutine (works fine), but that requires some compromise on the logical layout of program structure. I try to move all closely-related functionality in a single subroutine and not scatter it around - it would help to understand the program better few years down the road. This subroutine happens to be conditional as it is run depending on current "recipe" of hardware configuration - I also try to make program universal across different hardware options - makes it harder to write, but considerably easies version control. So you basically say that timers are decremented by SI0 everytime the timer coil is encountered by a scan? What if I include this same coil several times in a scan? Would it count quicker than normal?

Suppose I place TD coil for 10 seconds in a conditional subroutine that is called once a second (by another timer or asynchronous event). Q1. Will TD decrement or will it be reset (by the system) due to not being updated every scan cycle? Q2. If it will decrement - will it actually last exactly 10 seconds or there would be a (significant) timing error due to subroutine not being called majority of the time and TD not getting many chances to decrement? Thanks.

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

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?