Scripting point running all on its own?
-
Got another one for you: This is Mango V4.5:
It looks some of our scripted data points are running despite not having anything set to make them run. There's a a lot of backstory on this- Originally, I wanted something to run every 10 minutes- Thus, I set up a scripted data source to run every 10 minutes.
This data source does some things, and then sets another point (which is used by the next "step" in the process) to do more calculating; That data point is set in that script to "update context" in the next script.
Correct my understanding here, but, for the sake of this post:
"Updates context" in the world of mango scripting / metapoint means "If this value updates, run this thing. If this value doesn't update, no need to run this thing", according to the setting of the "context update event" box in the data source (update, logged, or change). If you don't have any points selected to "update context" in the points in the script, then that drop down doesn't have any effect; Is that right?"polling" in the world of Mango scripting means "Do this thing based time settings, either every XX minutes or as a cron pattern"
If you do polling and have "updates context" points selected, then it should do both (run on the Polling time and run when the point updates within the script).
What I have are points that run with no context and no polling enabled. My original script should run every ten minutes- meaning, every 10 minutes, the script should run, do some stuff, and use the set directive to make the next "step" work in this set of chained calculations. That original scripted point should then wait 10 minutes before Doing Thing again, and restarting the process.
Our little thing is working, but it's running continuously, and doesn't seem to care about the settings of the "polling" box (currently set to off, but the script is still running) or the "updates context" checkboxes in the data points in the script (all are "unchecked").
I've noticed this quite a lot in behaviors in my scripting: I generally thought that the script would run under the conditions above (timers, based on CRON or the time setting) and / or the "updates context" next to the points in the script, as informed by the "context update event".
It appears that the scripts are running effectively continuously: This means that in practice (regardless of the settings I have for "polling" or "context updates") I need to bracket my code with "If (somedatapoint.value == true {stuff}" to keep things from updating on their own.
So what am I missing here? I want this thing to run every 10 minutes, let the cycle complete, then stop and wait for the cron (or timer setting) to restart the task 10 minutes later. Instead, it's just looping through endlessly, as if I had "updates context" selected for all the datpoints in the scripted data source.
I've attached a screen grab of one of the points in question- What setting here would indicate to you that this should run effectively constantly?
The script in that scripted point is running, and appears to be updating as if any point updates, despite none of them being checked to "update context". Have I been using "update context" wrong the whole time so far?
If so, how do I get a Mango scripted data point to run, then just sit there and do nothing until the next 10 minute interval elapses. I thought that's what "polling enabled" with either "update period" or "cron pattern" would do?
-
@Turbo I suspect that you have configured the data source in a cyclical manner.
Does the data source have its own internal points?
Are you updating those points in the script ?
and do they re-update the context ?I created a scripting data source with a 15second polling interval and confirmed it only ran with 15 seconds.
I then created a point in the data source with update context checked my script just toggled the test point :
And this caused the scripting data source to execute continously.testPoint.set(!testPoint.value)
-
@CraigWeb Yup. Thanks for getting back to me.
I actually have (6) Scripts running in a loop: I'm doing it this way because I'm working around the fact that I can't (seem) to get the raw serial data source to work in Mango V4.5 (no RX under any circumstances, near as I can tell). So, I'm using TCP <-> GPIB, then using the Raw TCP driver to talk to that, which works well. However, there's lots of random delays needed to make this work, since we're sending SCPI commands and polling big arrays back out of our equipment, which has a very non-standard and irregular lag. This means I need to use the Raw TCP source using the timeout (rather than the EOL marker, since not al SCPI commands return values with known terminations). This means I had to break my script into into (6) scripts instead, basically:
The first script sets up the sourcemeter for measuring something
Second one takes a measurement
Third one parses that result and calculates some more stuff
Fourth programs the sourcemeter for the next measurement and sets it to run
Fifth one reads the raw data out of the instrument and calculates a bunch of stuff
Sixth one stores those values into points.The handling of one to the next is done via "update context" points (that are internal points in the first script and refernced in the other scripts) and lots of RuntimeManager.sleep() style things within the scripts to give the RAW tcp points time to get data back so it's available on the next step in the script.
@CraigWeb said in Scripting point running all on its own?:
Does the data source have its own internal points?
yes- Quite a lot
Are you updating those points in the script ?
Yes- We read value from the raw TCP source, do some calcs to it, and store those in the internal scripted points. But those point are not read again in that same script
and do they re-update the context?
No: This is why I busted my original script out into (six) steps, to avoid writing (and reading) points within the same script, since I noticed this created odd behaviors (using point.set(value) then using point.value() doesn't seem to work consistently within the same context- I ended up having to do this because of the timing issues with the raw TCP point depending on timeouts to get responses back).Thus, I use point.set(value) in one script. Then I use that value in the next script which is set to execute "context update" on a boolean point that exists only to pass control from one script to the next script.
Originally, I had this written in a single script, but that failed because I wasn't able to wait on the TCP/IP readbacks from the raw TCP point using our instrument. So I broke it out into blocks, to make that work, and then ended up passing control from one script to the next using "supervisor" points (internal points to the "supervisory" script) that just exist to trigger a context update on the next script.
The behavior you described that causes the script to execute continuously; Is this by design? If so, can you explain how that works?
-
The behavior you described that causes the script to execute continuously; Is this by design? If so, can you explain how that works?
The data source can either execute on an interval defined by the polling period or a context update from either an external point or an internal point. Both external points and internal points can be configured to trigger the script by checking the update context box. but if an internal point is configured to update the context and that point itself is updated by the script then there will be a cyclical situation. So the solution is to make sure that any point that the script affects does not have the "updates context" check box checked.
Kind of difficult for me to follow and understand your 6 chained scripts, to be honest, but the first step is to make sure that you don't have a situation as I mentioned above.