Script runs faster in runtime version of Wonderware InTouch

krishna431

Member
Join Date
Jan 2017
Location
New York
Posts
32
Hello all,
I have programmed a script in InTouch which will increment a value (lets say "tag1") from 0 to 10000 within a given interval. This interval is user definable at run time. For example, if I set the interval as 10 minutes, tag1 will increment in such a way that the value of tag1 will be 10000 on the 10 minute mark. I have run this script several times with different time intervals and have had successful executions of the script each time.
Now when I publish this application and run it with the Run Time version of InTouch (which is on a server VM) the script somehow runs faster. Again taking the same example of 10 minutes, the value of tag1 reaches 10000 at 8 minutes and 20 seconds. If I set the interval at 5 minutes, the script will be complete in 4 minutes and 10 seconds.
Does anyone know what could be causing this discrepancy?
 
i know its not the answer to the question "why is this happening", but if what you say is correct you can do a work around by setting the 10 minute timer to 12 minutes (if my math is correct), and the script should execute in 10 minutes instead of 12. in seconds.... 600/500 = x/600.
 
do you get the same time with the 15 minute timer? I think this something similar to rpi time on generic ethernet modules where it rounded to the highest bit(example 225 went up to 255)
 
InTouch is single threaded process, so the difference you see could be the difference in CPUs between your development machine and your run time server. I would suggest using a condition script and a while true or while false so you can dictate the time interval between execution of your script.
 
So I tried testing the application again using a 12 minute interval as well as a 15 minute interval. Now I'm really confused because both times I'm getting 8 minutes and 20 seconds like I did when I set the 10 minute interval.

My question to undr_the_table : how can I avoid this rounding to the highest bit if that is the case?

Question to mort81 : can you explain what you mean? I am running this script as a conditional script right now. I have a tag which is always set to 1, and the script will run only when this tag is 1, hence running all the time.
 
So I tried testing the application again using a 12 minute interval as well as a 15 minute interval. Now I'm really confused because both times I'm getting 8 minutes and 20 seconds like I did when I set the 10 minute interval.

My question to undr_the_table : how can I avoid this rounding to the highest bit if that is the case?

Question to mort81 : can you explain what you mean? I am running this script as a conditional script right now. I have a tag which is always set to 1, and the script will run only when this tag is 1, hence running all the time.

If you are running a Conditional Script without a condition, then it will run as fast as possible. Why don't you run a Data Change Script on $Second or $Minute instead to increment your timer?
 
Hello all,
I have programmed a script in InTouch which will increment a value (lets say "tag1") from 0 to 10000 within a given interval.

It would be a whole lot easier to troubleshoot your problem if you posted your script, and the conditions that executes it, rather than just describing your script.
 
I've pasted the script I've been testing below. The goal is to have the tag "TrialTag" increase from 0 to 10000 in a cycle.
The rate at which the tag will increment will be different within different values of TrialTag. From 2500 - 7500, the tag will increment by the value "TrialInc". For values outside this range, the tag will increment by "TrialInc2".
Here, intervals "TrialInt" and "TrialInt2" are the user defined which causes the value of TrialTag will increase at a slower/faster rate.
The script right now runs every 100ms. The first two lines of the script indicates this in the equation (1*1000.00)/(2.00*TrialInt). If the script were to run less frequently, say every 500ms, the equation would become (5*1000.00)/(2.00*TrialInt).


Code:
TrialInc = (1*1000.00)/(2.00*TrialInt);
TrialInc2 = (1*1000.00)/(2.00*TrialInt2);


    IF TrialTag < 2500  OR TrialTag > 7500 THEN
        TrialTag = TrialTag + TrialInc;
        IF (TrialTag >= 10000) THEN
            TrialTag = 0;
        ENDIF;
    ENDIF;
    IF TrialTag >= 2500  AND TrialTag <= 7500 THEN 
        TrialTag = TrialTag + TrialInc2;
    ENDIF;

I hope I explained this clearly enough. Let me know if you guys have more questions.
 
If you use a "While True" vs "On True" in a condition script, intouch gives you the ability to set the time interval of how often the script executes. Or you could use the system clock and use data change scripts as well as Bit mentioned. You have a few options. But as proof asks, how do you know you are getting 100ms now? Perhaps some screen shots of your condition script window are in order to help you further.
 
Hello all,
I have programmed a script in InTouch which will increment a value (lets say "tag1") from 0 to 10000 within a given interval. This interval is user definable at run time. For example, if I set the interval as 10 minutes, tag1 will increment in such a way that the value of tag1 will be 10000 on the 10 minute mark. I have run this script several times with different time intervals and have had successful executions of the script each time.
Now when I publish this application and run it with the Run Time version of InTouch (which is on a server VM) the script somehow runs faster. Again taking the same example of 10 minutes, the value of tag1 reaches 10000 at 8 minutes and 20 seconds. If I set the interval at 5 minutes, the script will be complete in 4 minutes and 10 seconds.
Does anyone know what could be causing this discrepancy?

I'm kind of curious as to how you ran the script for testing without using InTouch runtime.
 
@mort81, To answer your question, YES I am using a conditional script which is running every 100ms "While True". I have not attached a screenshot because there are a few lines of code which are not relevant to this specific functionality and I didn't want to confuse anyone.

@Bit, I have the development version of InTouch, with runtime on my work computer. Once I have the application running the way I want it, I publish it and run it on a server which only has the Run Time environment. It is on this runtime environment that I am having this issue.
 
@mort81, To answer your question, YES I am using a conditional script which is running every 100ms "While True". I have not attached a screenshot because there are a few lines of code which are not relevant to this specific functionality and I didn't want to confuse anyone.

@Bit, I have the development version of InTouch, with runtime on my work computer. Once I have the application running the way I want it, I publish it and run it on a server which only has the Run Time environment. It is on this runtime environment that I am having this issue.

What values are you using for TrialInt and TrialInt2?

I replicated the script on a blank InTouch app, and I can get close to 10,000 counts in 10 seconds with TrialInt set to 6 and TrialInt2 set to 5, but it's not repeatable. Repeatability would probably only become worse if the script was running in a large application.

What are you attempting to do here? Create a ramp?
 
Hi Bit,
Its hard to explain what the application's end result is. It is similar to a ramp, but it goes back to zero at the highest value, like a saw-tooth wave. Suffice to say I need the TrialTag value to increment at different rates based on a given time frame (interval), essentially.
TrialTag will increment by TrialInc when its within the 2500 - 7500 range. It will increment by TrialInc2 when its outside this range.
Basically if TrialInt is 10s and TrialInt2 is 20s then the entire cycle will take 30s. The value of TrialTag will increase from 2500 to 7500 in 10s. It will take 20s for it to go from 7501 back to 2499.
Here, TrialTag is I/O Real, TrialInt and TrialInt2 are Memory Real, and TrialInt and TrialInt2 are Memory Integer.
Does that help?
 
Hi Bit,
Its hard to explain what the application's end result is. It is similar to a ramp, but it goes back to zero at the highest value, like a saw-tooth wave. Suffice to say I need the TrialTag value to increment at different rates based on a given time frame (interval), essentially.
TrialTag will increment by TrialInc when its within the 2500 - 7500 range. It will increment by TrialInc2 when its outside this range.
Basically if TrialInt is 10s and TrialInt2 is 20s then the entire cycle will take 30s. The value of TrialTag will increase from 2500 to 7500 in 10s. It will take 20s for it to go from 7501 back to 2499.
Here, TrialTag is I/O Real, TrialInt and TrialInt2 are Memory Real, and TrialInt and TrialInt2 are Memory Integer.
Does that help?

Oh, I understood what you were doing, I just didn't know why. As I said, I ran your script in an InTouch application. It was not repeatable. I got a slightly different result each time I ran the script for exactly 10 seconds. It's obvious to me that InTouch scripts can't be relied upon to adhere to a very tight time base tolerance. Perhaps this functionality is something that could be better achieved within a PLC, rather than within HMI scripting?
 

Similar Topics

Hello, I am learning to create shapes and VB Scripts in HMIWeb Display Builder. I wanted to change color of my rounded rectangle by script. I...
Replies
0
Views
94
Hello, I have a quick question. I have been using scripts to change the color of buttons. The reason, I am usually using multiple hmiruntime.tags...
Replies
1
Views
91
Hi All, I'm keep getting double quotes in between selections rather than the beginning and the end. Here's the script and please help to find...
Replies
7
Views
796
Dear guys, I am not a programmer but I can do simple things myself. I'm stuck with the following. if I want to extract a value from my rx3i...
Replies
46
Views
4,728
Hi guys, I'm busy on the migration of old 3G/RS232 modems to 4-5G / Ethernet modems on about 200 pumping stations across the country. To...
Replies
0
Views
431
Back
Top Bottom