I'm going to share with the Tridium/MPX community the script blocks that I'm
in the process of testing, using the scripts i was tinkering with back in 2015.
These are not Schneider Electric sanctioned blocks. They were 100% functional
in EBO back in 2015 and I'll be seeing how the Tridium/MPX process handles them.
I'm providing these as a way for those people not comfortable in general with script
programming to have as much block usage as possible ahead of time before
the new SE wiresheet blocks are available to us. In the end, it looks like the Schneider
Wiresheet creates a large "mega-script" encompassing all of their blocks from the
wiresheet to keep the amount of script program objects being loaded into the MPX
to a minimum. Being that the blocks i'm showing you are individual scripts...if you
brought in 100 objects, then you'd have 100 scripts being downloaded. Schneider
is going to have a palette of their own script blocks that "code together" in a particular
way so they flow on one script. The blocks i'm showing you won't be involved with
that process. They'd remain as separate entities.
Back in 2015, it was becoming apparent that WPTech wasn't going to always
be applicable for programming jobs if an AS-P had modules or if there weren't
any MNB controllers on the job either. I had two options due to nobody else being
scripters or anybody feeling comfortable even attempting it. Choice1 was to get
the AS-P function (xenta) blocks into a format that looked like WPTech blocks
by using HFBs, or Choice2 was to create script blocks that you combine
together. For our techs, choice1 was going to be the clear winner. While
creating the WPTech function blocks, I also dabbled in the scripting choice
as a side project because you just never know when it would come in handy.
Currently in the wiresheet:
Most blocks will be inherent what the intent is, but some are made different for a
reason. The LOGIC and MATH blocks are all encompassing, kind of similar to
NW8000. The LoopLarge block was a PID created for full educational use. It has
the normal PI you'd expect plus derivative, error checking for settings, a ramp
function, feedback in the case of overrides, enable/disable, block update times,
diagnostics of key variables, and maximum documentation. The LoopMedium was
a loop created for normal "PI" usage with a ramp function, feedback, enable/disable,
block update times, along with basic documentation. The LoopSmall was the smallest
possible "PI" loop of our format that could function and had no added features. The
StringExperiment block was to demonstrate working with strings and various syntaxes.
It was also used to parse words in a sentence or a sequence of numbers. When it
comes across a "space" it breaks that section off and indexes it.
I've brought in the scripts shown in the picture and they all compile. After a
"download all" each one but 2 show they're humming along. The 2 will show an
E right off the bat because the MATH block is expecting a public numeric value
for the number of inputs the block will use and instead shows a "null". Once the
public numeric is manually given a value, then the E line will clear out within 30
secs. In EBO, a public numerics value would have been saved along with the
EBO export. Bringing it in fresh like this from a notepad document, it would be
null. I should have had a line to account for this back in 2015, but back then i
wasn't planning for a Tridium MPX need for them in 2020. The StringExperiment
block is the other one but don't worry about that one for the time being.
How to experiment with them:
After you've pasted the one you're interested in, into the script editor, and have
compiled to make sure it works, be sure to set the initial data types for each of
the inputs and outputs to the relevant types you need such as boolean or integer
or keep it as float. It appears that the integer setting isn't working in the script
editor at the moment, but that's what you'd normally do. After you've compiled,
sent to station, sent to controller, performed a download all....the blocks should
be usable. I know several of the blocks need a public numeric set after the
block is first created, similar to a configuration setting or setpt. If something
doesn't work (such as what i'm seeing with digital values not being seen in
scripts in one of the posts i made....and also publlic numerics not holding
their values in another post), don't be too concerned at the moment.
I'll be going through the blocks in the coming days and reporting what i see
happening. These are mainly to help the people with Block Programming
experience have block choices in advance to connect Inputs/Outputs, test
logic, and get comfortable with the wiresheet and config folder setup
before the Schneider Blocks come out.
Additional post for "Function Script" Blocks
Jim, Thanks for the contribution of all this work. I will do some testing with these today
Just to let you and all Beta participants know, the Phase II wire sheet programming palette of objects, very similar to what you have done, is moving forward nicely
Update for the Tridium-MPX community:
After performing some testing with various blocks today, there's a few other
posts I've made regarding issues i'm seeing with binary values and public
numerics, along with demonstrating the issue with a picture of the wiresheet
for some of the block connections.
So far, some items to watch out for are:
1) Incoming binary points to the script block will freeze up the block
display, but the script inside (actually inside the MPX) will still work.
2) To un-freeze the block, attach an analog value to the location that
had the binary value attached.
3) To use a digital input that the script is intending to have... link an analog
value to it and use 0 for OFF and any number greater than 0 for ON.
4) Public numerics don't seem to be holding their values... so to get around
that, the next best choice is to link an external analog value to the spot where
the public numeric is located on the block.
5) LonLinks may randomly appear as you add and delete blocks from your
In the next few pictures , I'll be showing some examples of what the previous
issues from above entail, while also showing the LOGIC and MATH block since
it was a combo block more similar to NW8000. Some other new posts concerning
issues are uitilizing the TSTAT, SELECT, and DualDelay to demonstrate the examples,
but i'll paste them here as well.
Demonstrating a workaround in needing an external object to set the Public Numeric:
Demonstating that a Binary Value is being seen as Null at the script block
Demonstrating how the binary value is freezing up the script object. If using an
Analog value in the place of a Binary value, it works fine.
LOGIC and MATH blocks connected up, but keeping in mind the problem items from above
and using Analogs where needed in the place of digitals and public numerics.
Here's a couple more uses:
In case if anyone was wondering why i also had a PulseGenerator in the blocks, it was
to test the CountUp and CountDown in a more automatic way.
The nice thing about public numerics would be that the "reset" items could actually be changed
from inside of the block to save wiresheet real estate by using less blocks if it ends up being a
usable feature. It could just be the block by itself connected to the block before it and after it.
The large loop block (Codename: Goliath) in action:
Updating every 5 seconds
SpaceTemp = 75 deg
SpaceSetpt = 70 deg
Error = 5 deg
Kp (Gain) = 5
Ki = .1
What we see from script block with Tridium polling time delay
Proportion Total = (SignalPropWithK) = 25%
Integration Total = (SignalIntegWithK) = 8.96% and rising
Derivative Total = (SignalDerivWithK) = 0
LoopOutput = 33.96%
What we see from LoopOutput Analog Value with Tridium polling time delay
Analog Value Polled output = 34.17%
Thank you for sharing your Script version of WPT blocks. I plan on doing some testing with them as well.
@Jim_Okapal I think your work and history portion is proof that we have provided the right feedback to product management for quite sometime. Thank you for sharing your library of objects it looks like this is a great start. Once again thank you for all your feedback.
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!