How efficient is the runScript() expression language function? I have two different ways of running some Jython code every 100 ms on a very slow embedded system, so it could be important. Also it’s not just one tag, it’s a number of different tags on several screens. I can either put the code into a runScript() function and display the result, or put the code into a global timer timer event script running at the same rate, with the result going into a client tag and display the client tag. Is there any difference in how fast the same code will run in a global event script versus a runScript() function that calls a function in a script module? It seems like the runScript() would take more cpu since it takes a string which it then has to recompile every scan cycle.
Interesting question.
The runScript() expression is quite efficient. It does not re-compile the jython call every poll cycle. It only will re-compile it if that string has changed (unlikely, unless you’re passing parameters in that change frequently)
That said, I think running 20 different runScript expressions will be slightly less efficient than running 1 global timer script that updates 20 client tags. Whether or not it matters depends on how many tags we’re talking about here. Without running a specific test, I can’t speculate as to how much more efficient the global timer script method would be.
Out of curiosity, how is this data being gathered? Where does it come from?
Most of them are showing timer values coming from various events out of a PLC. A door opens or closes, a push-arm activates, a batch is started or stopped, a switch activates, a burner comes on, etc. They want to see how much time passes between related events in a rather complex way. And we often want to display it as H:MM:SS.S down to the tenth of a second which means it has to go fast. When the computer slows down, it shows up rather well since you can see the tenths of a second skip sometimes. So I want to optimize it as well as I can to minimize that skipping. Anything having to do with tenths of a second I’m doing on client tags to make it smoother so I don’t need to scan those over the network at that high speed.
Sorry to press, but exactly how does a python script get values out of a PLC?
I’m using fpmi.tag.getTagValue() and fpmi.tag.writeToTag(). I hope that’s the preferred method.
I figured you might have that optimization for runScript(), so I was careful to make sure the string is static. For instance, instead of passing in a value using a concatenated string, I instead pass a static tag name, and inside the script use fpmi.tag.getTagValue() to get the value.
–Oh, yes when I wrote above “out of a PLC” that really means “make a SQLTag that refers to an OPC address that’s coming from a PLC”. heh
Ok, now I’m getting the picture. So my question is - Are your calculatinos too complex to simply subscribe directly to the tags, and use expression-based DB Tags for your calculations?
Yes, I need Jython code to do it. Jython is the saving grace that makes everything possible. In expression language I can’t subtract two Date values and then format the result to whatever I need it to be, using as many variables as I need, like I can in Jython. The expression language to me only makes things more complicated because I have to remember two different syntaxes. If everything was in Jython, FactoryPMI as a whole would be much simpler and easier to use.
It seems unfortunate you guys are doing a lot of work to put a whole lot of functionality into the expression language, yet it will never have as much functionality as Jython does for free. So why not just have everything in Jython? It’s funny that I knew nothing about Python coming into this project and now I’m all, “put Jython everywhere!” heh
Heh, I like that, “Jython is the saving grace that makes everything possible”
I have to disagree about your gripe about the expression language, however. You’ve got to understand, there is a big difference between a programming language (like Python) and an expression language. Expressions evaluate to a value. They have no side effects. In stricter terms, the expression language is a declarative language, while Python is an imperitive language. An imperitive language wouldn’t really fit where the expression language is used.
The expression language barely has any “syntax” to speak of! Its main construct, the bound property/tag expression, would be awkward at best in Jython. These bound expressions bind in as event listeners on their targets, eliminating the need for polling, making expressions extremely efficient for what they do. The runScript expression is obviously in violation of this rule, but it has its purpose.
We put work into the expression language because it can do things so much more simply than they are done in Python. Look at expressions like getBit, binEnum, lookup, dateArithmetic, etc. Implementing stuff like this in Python would be really demanding for many of our users, who do not take to scripting quite as well as you have. And besides - the runScript() expression bridges the two worlds anyhow.
I think we’ll have to agree to disagree. That said, I do sympathize with your apparent “language fatigue” - expression, Python, and SQL - its a lot to learn, we know. 
Well put Carl. So what about an expression language subtraction operator (or function) for dates?
maybe dateDiff(date1, date2, [opt_format])
That was already suggested somewhere earlier this week, and has already been implemented for the upcoming release… should be available tomorrow or friday.