I think a few of you probably knew this was coming after the first script block post.....
Function Script Blocks: (The Continuum Strikes Back):
Functions are used to "off port" alot of the repetitive coding in the main
script or throughout the whole controller. As the previous "Script Blocks
post" had demonstrated, some blocks can take a lot of code. If you have
to use the same blocks several, if not dozens of times in a controller, it can
take up quite a bit of memory. Blocks such as Loops, Resets, Delays, Filters,
and Tstats can be used over and over in the same script itself... along with other
scripts in the same controller. Tstats are usually so small anyway that they may
or may not require functions, but if you can save a couple lines of coding for
i2/b3 controllers, in which the cost savings are cumulative.....it can be a pretty
big deal so that you can squeeze in a few more items in a sequence of operation.
Attached are the functions themselves, along with the "Calling Program". The
Calling Program contains the setup of the variables along with the single line
that calls the function to do what it needs to do. Normally a few setup variables
in the main script and the single function call line is all you need. The calling
program in this case is self sustaining for individual use.
An obvious question that may be asked is....the function block and calling program
are taking up a lot of room on the wiresheet. We want a single block to work with
and not two. What happens here is that the main program will contain the
various function call lines similar to a sequence of operation and then will reference
the attached functions. So if you needed several loops, tstats, filters, and delays
all in one script...you'd have the one main script and linked to the outside would
be the various types of functions you need. The function could be used dozens
of times in the same script and only one function attachment is needed per type
I have a sneaking suspicion that the Schneider wiresheet block objects will become
a series of calling lines when compiled and will become one object. On the outside
of this compiled singular object will have all the functions attached to it We'll see what
To test them, follow the same set of steps as in the other post to create the "Calling
Object". To create the function.. bring in the function object, paste the code, compile,
save to controller, save to device, download all. Make sure to connect the "function"
to the main calling script as seen in the picture...along with any of the typical inputs/
setpts/etc that you need.
A nice thing i noticed was that if you disconnect the function from the main
calling block, then the program will show it's halted....if you connect it
back up, the script will start running again on its own without needing to
restart or perform another "download all". Very Nice Indeed!
I've only tested the Tstat script at the moment and it worked ok. All the other
ones were 100% functional (pun?) in EBO. So Enjoy
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!