Block examples (attachment) for WPTech/FB people

[Jim_Okapal]

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.  

History:

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.

Thanks

Additional post for "Function Script" Blocks

"Function" Script Block examples (attachment) for WPTech/FB people. 

[RandyDavis]

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

[Jim_Okapal]

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

wiresheet. "n:dataLink"

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.

[Jim_Okapal]

Here's a couple more uses:

CountUp, CountDown:

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.

Reset Block:

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.

[Jim_Okapal]

The large loop block (Codename: Goliath) in action:

Updating every 5 seconds

Direct Acting

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%

[Will_Workman]

Jim,

Thank you for sharing your Script version of WPT blocks.  I plan on doing some testing with them as well.

[Julio_Cortes]

@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.