I missed the cadence meeting today but saw the video. It's interesting what you noticed
about the tstat OutReverse not working. I'll attach screencaps below of what i saw, where it was
functioning ok with a single block brought into the wiresheet. I didn't experiment with multiple
tstat blocks at the same time since i was trying out each different type of block in an assembly line
I'll have to play around with it to see what breaks it. I usually found that i had to renew
the polling timer or make sure each output had a corresponding IO point linked up inside
the Virtual Script.
One thing that can really mess up a Functions use in general, is if there are multiple calling
programs going to a single function where the "Returned value" hasn't been addressed in
some way in the function. You'll get cross-contamination between calling programs if the
returned value hasn't been dealt with.
Numeric Input ValueEnab1,ValueEnab2
Numeric Output TestOut1,TestOut2
TestOut1 = CrossTalkFct(5,ValueEnab1)
TestOut2 = CrossTalkFct(10,ValueEnab2)
Arg 1 ValueIn
Arg 2 ValueEnab
If (ValueEnab = On) Then ValueOut = ValueIn
What will happen here is:
1) Both TestOut1 and TestOut2 will equal 5 if ValueEnab1 is ON and ValueEnab2 is OFF
2) Both TstatOut1 and TestOut2 will equal 10 if ValueEnab1 is OFF and ValueEnab2 is ON
3) TstatOut1 will equal 5 and TstatOut2 will equal 10 if both ValueEnab1 and ValueEnab2 are ON.
Notice the Cross Contamination?
The problem is that ValueEnab = Off isn't explicitly dealt with and the Returned ValueOut
is in a sort of limbo state. The next function call by the other calling program will write
it back to both calling programs. It's like the door is left open to any calling program
that has a returned value not explicitly dealt with.
I'll have to look over the MPX Tstat program to see if something like this is happening with multiiple
Tstat's brought out.
These are the screencaps of the MPX Thermostat block functioning with a single block:
Setting the space temp to 65 reverses the outputs.
I looked over the script and i think there may be a flaw.
If value coming into the calling programming is in between
(Setpt + Indiff/2) and (Setpt - Indif/2)..... the "Return OtptD"
will now have a contamination problem with multiple calling
programs calling it since OtptD isn't explicitely being dealt
with when the input is below the ">=" portion and above
the "<=" portion. OtptD is a dead value that can be changed
by an entirely different calling program.
Thanks Jim. I am an I/A guy so script /PE and I don't get along. I appreciate the feedback.
There "SHOULD" be a unique copy of the current state of the block stored in the calling program.
Based on what David and Randy showed during the call today, there is a bug where the calling program uses the same variable for multiple blocks. We will need to report that to Tridium.
They also define the function twice if there are two copies of the block on the wiresheet. Another bug to report.
Thanks for all your help with testing these builds.
Looks like the new Version #8 has fixed the duplicate Function declaration. I brought in
two TSTAT blocks and they're acting uniquely. There is one caveat though in relation to
what was brought up earlier. I'll show a screen cap demonstrating it.
In this example, the space temp and space setpts are all 70 when the block is created in EBO.
When scripts are first created, everything will normally (or in some cases "unfortunately") show
Null in the current status until there is some "Action" in the script line for that particular item. If the
script line that is currently in play doesn't deal with the variable in some way, at that particular
moment, it'll remain Null or some old value. This is actually an area of contention in diagnosing
EBO vs Continuum, where in Continuum all the I/O will be updated regardless. The local
variables inside the script would normally have been initialized to some value in an "Initialize"
line or else its the result of something in the script that will give it a value at the moment that it
In the case of Tridium and the Jace8000... will Null be an acceptable outcome in certain
situations or can it cause a problem? The calling program isn't initializing the Tstat_OutDir,
and the function doesn't deal with it until it's either above or below the deadband. If
Null will be considered OFF, then it would indirectly be ok. If not, it could be a problem.
Discuss challenges in energy and automation with 30,000+ experts and peers.
Find answers in 10,000+ support articles to help solve your product and business challenges.
Find peer based solutions to your questions. Provide answers for fellow community members!