This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
c_niagara:headpage [2022/02/25 21:28] – mk | c_niagara:headpage [2022/02/25 22:17] (current) – mk | ||
---|---|---|---|
Line 12: | Line 12: | ||
[[https:// | [[https:// | ||
- | Niagara has in my opinion | + | Niagara has in my opinion |
* First, controlling output and input points (IO), which in turn can control all kind of actuators, motors or sensors. | * First, controlling output and input points (IO), which in turn can control all kind of actuators, motors or sensors. | ||
* Second, integration of pretty much any network (Driver) or system you can imagine. My personal favorites being Bacnet, Modbus. But can also do more exotic things like MQTT. | * Second, integration of pretty much any network (Driver) or system you can imagine. My personal favorites being Bacnet, Modbus. But can also do more exotic things like MQTT. | ||
+ | * Freely programmable using functions blocks or java code. | ||
+ | * Presentations from a webserver (Any framework installation contains build in web server) | ||
==== Licensing ==== | ==== Licensing ==== | ||
Line 33: | Line 35: | ||
It comes with a pre ordered amount of points, usually cheaper then buying points afterwards. | It comes with a pre ordered amount of points, usually cheaper then buying points afterwards. | ||
But here you get the Host ID from controller, and use it to order extra points if needed, after purchase, the extra license is fetched from the licensing server. | But here you get the Host ID from controller, and use it to order extra points if needed, after purchase, the extra license is fetched from the licensing server. | ||
+ | Points in controllers don't count on supervisors too, you only pay once! | ||
Common for all customer licenses is that after purchase, it is bound to that specific Host Id. I've never seen a license being moved. | Common for all customer licenses is that after purchase, it is bound to that specific Host Id. I've never seen a license being moved. | ||
Workbench license can be moved to a new PC, but it's not something you do for fun. | Workbench license can be moved to a new PC, but it's not something you do for fun. | ||
+ | |||
+ | ==== System overview ==== | ||
+ | |||
+ | A typical office customer setup would be comprised of the following: | ||
+ | |||
+ | * Supervisor (PC or Controller) | ||
+ | * Main controllers (1 pr floor typically) | ||
+ | * IO Room controllers connected to main controllers (1 pr 1-2 room) | ||
+ | * Airhandling unit with integrated controller connected to supervisor or main controller | ||
+ | * Airhandling unit with direct IO controllers from a main controller or dedicated controller. | ||
+ | * Any integration from light or other, connected to main controller or supervisor. | ||
+ | |||
+ | All network connections is preferred to be TCP/IP but serial 2 wire connections is widely used too. | ||
+ | |||
+ | Best practice is to keep as much programming and calendars as local as possible. Meaning, if you can keep a 0 point supervisor, it's preferred. | ||
+ | Also, direct signal transfer from controller to controller is preferred. | ||
+ | This way, if supervisor restarts, controllers keep running their programs. | ||
+ | |||
+ | The supervisor is then used for collecting alarms, history data and proxy points from controllers, | ||
+ | |||
+ | {{: | ||
+ | |||
+ | ==== Framework breakdown ==== | ||
+ | |||
+ | Framework runs as a 2 part deal, a platform and a station. | ||
+ | |||
+ | === Platform === | ||
+ | The platform is running either on a unix based controller or windows based PC, and can best be compared to "a firmware" | ||
+ | It contains settings for TCP/IP and licensing. | ||
+ | It also contains systems to copy stations and control start/stop of these. | ||
+ | |||
+ | == Platform tree structure example == | ||
+ | See below image of a standard platform setup | ||
+ | {{ : | ||
+ | |||
+ | === Station === | ||
+ | |||
+ | It's where all the magic happens! | ||
+ | It it build up like a tree structure. | ||
+ | First comes | ||
+ | |||
+ | * Alarms | ||
+ | * Config | ||
+ | * Files | ||
+ | * Hierarchy | ||
+ | * History | ||
+ | |||
+ | == Alarms == | ||
+ | Shortcut to alarm section, with views and database maintenance. | ||
+ | |||
+ | == Config == | ||
+ | Where all primary programming is located, it also contains Services, Drivers and Apps. | ||
+ | |||
+ | Services | ||
+ | Contains alarm handling, user services, web and the internally used fox servers | ||
+ | and other primary backend systems. | ||
+ | If you want a primary function to work, this is where to locate and install it. | ||
+ | |||
+ | Drivers | ||
+ | Contains programming part of the station, including Bacnet and Modbus drivers, | ||
+ | but this is also where you create your programming, | ||
+ | in separate folders or directly inside the drivers network. | ||
+ | A folder contains multiple view options like property sheet or wire sheet. | ||
+ | They also supports a custom view (Px view), meaning to show website animations. | ||
+ | |||
+ | Apps | ||
+ | I actually don't know what this is for? | ||
+ | |||
+ | == Files == | ||
+ | Is the local file storage, it contains images, px files (website animations) or other files used. | ||
+ | |||
+ | == Hierarchy == | ||
+ | One of the newer functions, used to dynamically build a tree structure for your site, and to allow easier navigation. | ||
+ | In my opinion it's not " | ||
+ | The hierarchy is build using tags on folders and points, they can be direct or implied. | ||
+ | What is needed to make it really nice is implied relations and better interaction with objects. | ||
+ | |||
+ | == History == | ||
+ | Contains all your history files and the ability to run database maintenance. | ||
+ | |||
+ | == Station tree structure example == | ||
+ | {{: | ||
+ | |||
+ | ==== Workbench breakdown ==== | ||
+ | |||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
~~DISCUSSION~~ | ~~DISCUSSION~~ |