I've got my laptop set up to run a station and playing around with the script editor.
1) You can add a script program and script function to the main MPX BACnet interface.
Shouldn't this generate an error? The programs won't open there, which I wouldn't expect
to open anyway. They open as expected if placed in the controllers.
2) Is there a plan for the Script Program and Script Function to have different looking icons
from the Tridium Config Icon. Ideally, there would be unique icons for everything.
3) Is there a plan for Scripts to be placed inside of folders? I tried it and no luck.
4) Should the "BacnetDevicesFolder" from the regular BACnet interface palette be allowed
to be imported inside of the MPXBacnetInterface? I got it to import. Doesn't allow anything
to imported inside it from MPX, but still thought i'd mention it. There's quite a few other objects
from the regular Bacnet interface palette that can be brought in. We'll probably need to know
what objects we should avoid using, or if the regular Bacnet Interface palette should be ignored
altogether when it's all said and done.
5) When the script editor detects a problem during the compile and references a line number,
I notice that the script window has no line numbers to help find the location. Is there a plan
to incorporate something like that? I double clicked the error message similar to Continuum
and it's just text in the compile window
6) Ok, this next one I could be doing completely wrong, but here's the scenario:
a) Bring in a script object
b) Add a few lines of code
c) Compile it, make sure there's no errors.
d) In the compile window, I see that it writes to "Result=C:\\Users\\jokapal\\Niagara4.8\\TAC\\MPX_Script\\Compiled\\ScriptCompilation_-1_-1.xml"
d) I then send to station only, not controller.
e) Bring in a new script object
f) Do exact same thing as above
g) I now find that both script objects have the same program I just wrote in the 2nd script.
h) It does this for functions as well. In fact, the current script program will overwrite all
other script programs and functions and vice versa. The last script you send to station
will overwrite everything.
I notice a few things.
It appears that all scripts are trying to reference the next 2 items in the properties
local:|file:^MPX_Script/Source/MPC 36 A/ScriptSource_-1_-1.txt
local:|file:^MPX_Script/Compiled/MPC 36 A/ScriptCompilation_-1_-1.xml
When a script is brought in, these have Null. As soon as you write to the station, they fill in
with the above paths. After that, all scripts and functions are bound to the hip after that.
My guess is that the "Scratchpad" needs to be unique for every script, and that's why
the scratchpad overwrites everything.
Am I doing it wrong?
@Jim_Okapal great feedback. Keep it coming!
For Item #1 about whether there should be an error in putting a config object in the wrong location,
I'm thinking more along the lines of some kind of popup message that you'd get by putting a tridium
object in the wrong spot that lets you know that it's either a location that won't work, or it's a location you'd
not want to put it into. For instance, the script program outside of a controller. Would a popup message be
helpful to the user in advance? The object won't work which is ok, but it's not immediately obvious it
doesn't work unless you click on it.
Item #6: Script programs and instance numbers
Makes sense about the two -1 values, but then that may open another can of worms.
If you get the instance numbers all done in advance and later change them, does the
compiled XML and TXT files follow suit along with the change?
Also, talking about setting up the instance numbers of the controller and objects inside them. The
controller is easy enough to change by clicking the Config block inside the controller object or clicking
the MPX Bacnet Network and clicking on the respective controller to change the Instance Number.
If you try to go into the properies of the actual controller, the number is greyed out, similar to Bacnet
jobs in the past. But to change the instance numbers of the objects, I usually had to do a discover of
the objects and then change the relevant information for each object in the list because the instance
numbers in the properties are grayed out as well. Is the Smartxip license feature the key to allowing you to do
this search because it currently seems unsearchable and maybe because of the licenses at the moment.
Would auto-creating the script instance numbers be a viable option similar to indexing for other objects
when programming in EBO? Needing to put in index numbers for everything might be a bit cumbersome
1. There probably should be an illegal parent error if the user tries to put a config object outside of the config folder. I know there is when you try to put a LON folder under a BACnet Interface lol. The interesting thing is that I can drop a generic AWS config object directly under the BACnet Interface without an error so this is not isolated to the MPX config objects. This is something we will bring up with Tridium as a potential defect.
6. I did some testing and changed the instance number of my Script Program from 11 to 12. I open it back up
the MPX Script Editor view and my program text was still there. When I compiled it again I got additional files under my Station/Files/MPX_Script/Compiled and /Source with the new instance number. I changed the instance number of my MPX from 100 to 900 and had the same results as changing the instance number of the Config object. Again the file names did not change until I pushed the Send to Station button.
A couple of points of interest:
I think one of the other problems I had earlier today was that I had a Script Program object
directly inside the controller and not under the Config Object. I could still open the
script, compile it, and everything. The only problem that i was finding at that point
was that I couldn't access the instance number through a manager of some type,
similar to changing it in a controller. Now that it's inside a Config Object, the instance
number is accessible.
Will's earlier message:
When you drag Config objects out of the palette to either the Config Manager view or the Wiresheet view, Niagara should automatically assign the next available instance number
It appears to always give me a -1 for any Config object I bring into the Config Manager. Would it be due
to offline programming? Would an online controller start incrementing the Instance?
Responding to 2 Methods to change device instance number:
For the 2 methods to change the Instance number of the device, I've sometimes had to pick or choose which one
to use depending if I had to change another feature in addition to the instance number.
The main BACnet network manager allows you to change Object ID, Network, Mac address, Enable/Disable,
COV. The config manager allows you to change the Object ID and poll frequency. Kind of had to pick my
method depending on the situation.
Trying to use any config object outside of the Config folder will cause issues for sure. Just like trying to use point objects outside of the Points folder will cause issues.
What do you mean by "offline programming"? Are you running a live Niagara station but without live controllers, or are you just editing the bog file? The point of offline engineering is that you will not have to have any BAS hardware to engineer a job. You will need to have the station running live on your laptop.
When I was working in an offline controller it was still giving me valid instance numbers for all new config objects. It was not setting them to -1.
If you still don't have your license updated with the smartxip feature, then that could be the cause of most of the weird things you are seeing.
It's a running Niagara station and editing an offline MPC-36A object.
This would be simulating our offline engineering practice.
Any new config objects are coming in as a -1 instance number. Since the
Smartxip feature isn't valid yet until we get the updated licenses from Tridium,
I'm assuming the same thing as you that this may be part of the problem.
Trying to use any config object outside of the Config folder will cause issues for sure.
Just like trying to use point objects outside of the Points folder will cause issues
Here's where part of the confusion can happen to people new to the MPX Interface.
In a points folder, it's a picture of 3 blue circles. Inside the folder are a different set
of pictured items but can also be different colors. Nearly every Tridium folder has
a unique picture. Inside the folder are objects that are similar in nature, but a different
looking picture than the parent folder.
The problem here is that the config folder and config objects are the same picture.
This would tend to make someone believe that they are brother/sister objects,
not parent/dependent objects.
In the case of the script object...it opens, compiles, and acts like it would work
outside of the Tridium Config folder assuming someone knows it was a folder to
begin with to enclose objects of the same picture which could be another folder
or object until you open it to find out.
You and I know what's what, but i'm just thinking of a new person working on it
for the first time.
The Config Icon that is used for MPX Config objects is the same Config Icon that is used with every other BACnet Config object in the generic BACnetAWS interfaces. Most people just have not used the config space before.
I agree that learning to use the Config space to program the MPX controllers and then moving to the Points space to integrate them in for graphics etc. will be something new for most people in the I/A Channel. We will need to make sure that part is well documented.
It sounds like you are requesting an enhancement to have unique objects for each type of MPX Config Object. If that is the case then please create a separate post and label it as "Feature". The the "Feature" label will be used kind of like the EBO Ideas section to suggest new features or enhancements to this project.
Brad got the smartxip licenses sent to us tonight and my laptop and jace are all set.
The -1 issue when bringing in the Config objects was due to the driver not being
activated by the license. It now increments the instance number with each object
brought in, starting with 11 and going up. Things are going alot smoother with the
activation. Script blocks creation process has a pattern to go from now.
This may be a good point to break off and make a synopsis post.
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!