Just starting

[marian_modern-s]

Hello, I'm new here!

Not much useful to add, other than a few opening remarks...

I've loaded the modules, installed the Script Compiler, configured WorkBench and started a station. I've configured the MPX BACnet network and added and offline device (we don't have an MPX controller yet).

I've read most of Jim's awesome posts and gleamed some clues (such as setting non "-1" instance numbers for devices so that compiled scripts and files don't get overridden when you don't expect it to), and then downloaded his generously posted blocks, both to see/learn Script (this is new to us, coming from the IA side), and to see the general idea of how the process goes.

I've made a Script Program and Script Function in which I've pasted Jim's code, compiled, sent to station...now I'm scratching my head on how to test this with values without having an MPX live....I'm sure it's obvious, but I can't see it. Standard Niagara blocks don't work as the error is that bindings can't be made to objects that aren't descendants of BBacnetObject. Do I have to create "input" objects and then link those to Niagara objects or set their default/fallback somehow?

A couple of things right off the bat:

- Pleeeeeease add support for sub-folders in the Config space of the devices. Organization will become a mess in any controller that needs any sort of medium to complex sequence. It would also be nice, I think, to be able to separate things like physical points from processing and then if special features (alarms, schedule, trending) is required elsewhere...

- Nomenclature of "Repair Hosting"...I realize this is likely a holdover from EBO, but just because the controller isn't set to belong to the JACE it doesn't mean the hosting is "broken". The problem with the word "repair" is that it would only trigger someone to do the thing if something doesn't work...so first it will not be done, until hopefully it reports that it's broken, and then do it. I don't know what would be better, although I can suggest things like "Claim Controller", "Attach", "Adopt", "Pair", "Sync to JACE"....etc

- the file names generated should include the station name OR even better to go into a subfolder of the related folder (Compiled, Logs, Source) with the station name. I foresee saving these, as well as not wanting to have them replaced when a station with the same MPX network instance number would overwrite them. Not knowing what the way forward will be to create a library of re-usable scripts, right now I'm imagining we'll have a "tools" station that we can share among our workstations with all the bits we make ourselves to use from. We wouldn't want to lose something in there or a live station simply by compiling a library object or a station object of the same instance combination by accident.

[Jim_Okapal]

Wow, for just starting out you're really far along for not having

a controller hooked up at this time.  For the first few days, there  

wasn't a SmartxIP license activation available to us, so  I was

mainly going through the palette objects offline, seeing if items

and all the setups are there that i'm used to seeing in EBO, etc. 

The script editor testing was initially done offline in my case, and

you're really far along there too.    My next step at that point 

was in initializing an MPC-36A because there was nothing else

i could do in preparation before seeing if things "light up" for the 

Schneider objects, script blocks, and seeing things work.  

It's looking like you're at the point to needing the controller online

to put all the objects into for testing out.  Since you've gone through

all the posts, you're way ahead of the game and that should help

tremendously.

To answer your question about linking Niagara points up to the

Schneider points, what will happen is that after you download

the scripts into the MPX controller, BACnet objects will be created

at that time.  You'll then discover the controller, bring in the bacnet

objects and then use those objects for your normal Tridium integration

to graphics, trends, and everything else.  Think of the Schneider side

as Workplace Tech and mainly a programming tool.  The discover of

the MPX is like discovering an MNB-1000 and then going from there.

Hope it helps!

[marian_modern-s]

Thanks for the vote of confidence, Jim!

The SmartX controllers are brand new to us, so I have no EBO knowledge or SmartX knowledge to transfer. On the other hand, Niagara and MNBs I've got in spades, so the environment is comfortable and your analogy applicable 🙂

For testing the programs, I wanted to know if there's a way to test without being hooked up to a live controller. It's not that I want to test the whole controller, but the actual script bits...there's got to be a way to test that, no? I understand that in WPT you must connect to a controller to test, but that was 200x...now it's 2020 heh

[Jim_Okapal]

The controller is where all the action will be happening,

so you'll for sure be needing to have the controller "live". 

With those who know EBO, if they're interested in seeing how

the scripts work in general just for experimentation and

play around with them...the scripts can be pasted into an

AS-P script program object, an Enterprise Server script program

object, or a PCT (Project Configuration Tool) and run it that way,

you'll pretty much see what should happen inside the MPC

when it's live.  If you hook EBO points up to the inputs and

outputs of the block, you'll see the changes in status.   

In fact, due to the script editor in the Niagara MPX setup being

a down-scaled version of the EBO script editor, it's recommended

to initially create complicated scripts in EBO first and then copy them 

over to Niagara.