Home
Partners |
History |
Articles
tinyFBD software concepts
This short article is dedicated to explaining the structure of tinyFBD software and functions of its components:
The installation package consists of:
-
The setup/management application Setup.exe;
-
The environment application FBDEnvironment.exe;
-
A number of library (name.fbl) and LNS plugin (name.exe) pairs;
- A number of Lonworks device interface and application files.
Setup application
The setup application runs first time right after the unpacking of installation package contents. Setup installs itself, the environment and libraries, supplied with the installation package. Then setup application registers the libraries and their corresponding LNS plugins in Windows registry.
At last, it allows the user to manage the libraries (register additional libs, or deregister already installed).
After finishing installation the setup application starts to behave as library/plugin management tool. It can be launched with a programs menu link, and when launched it shows the management dialog.
For default, the setup application will search for new libraries in a tinyFBD\Libs folder. But the user can choose additional paths to search.
Uninstallation of the software is carried out by setup.exe, which is started from Windows control panel.
Environment
The environment component is a standalone application, used for creating FBD diagrams, managing FBD project files, and translating them into executable code (compiling). This code is not a set of Neuron Chip commands, it is interpreted by a FBD virtual machine core (FBD runtime), which is loaded into Neuron Chip as an application.
The FBD project file has an .fbp extension. The compiled diagram has .fbc extension. The compiled diagrams can be downloaded by library LNS plugins to an FBD-enabled device for execution.
Also the environment is invoked by a library LNS plugin when a debug session starts.
Libraries
Library file has .fbl extension. The libraries are linked to the environment application during execution time (late linking) to serve as functional blocks provider. This allows the same environment to work with any number of device runtime applications.
The library file is always accompanied by the .exe file that has the same filename. This file is actually an LNS Plugin ActiveX, that is used to manipulate FBD enabled lonworks device from director application, such as Echelon's LonMaker. The plugin must reside in the same directory as library file and runtime application and interface files, to be automatically managed by the setup.
To register a new library within the system you must copy the corresponding library (.fbl) and plugin (.exe) files to tinyFBD\Libs or custom folder, and register it with Library Management Tool from programs\tinyFBD menu. If you copied the files to tinyFBD\Libs then the setup will find them automatically and prompt for installation. Otherwise, you must show the path to the custom folder to the setup program.
The library plugin will register automatically on library registration, and will become available for commands registration inside you Lon network designs. In LonMaker it is situated in 'LonMaker/Network Properties/Plugin registration' menu.
To deregister the library just run the setup and choose the registered libraries to deregister.
Device applications (FBD runtimes) and interfaces
The runtime application and interface are stored in tinyFBD\Libs. Actually, the library related files, that must be put in one folder, are:
-
The library itself, .fbl extension
-
The LNS Plugin, .exe extension
-
Runtime application interface files .xif, .xfb extensions
-
Runtime application code files .apb, .nxe extensions
Before loading FBC into device, the user must create the device template and load the device with runtime application. Also the template can be created by the library LNS plugin automatically - before registering itself it looks to \Libs folder for .xif and .xfb files with matching ProgID.
The device application and interface files are closely related to libraries. The device application code (FBD runtime) has a ProgID, that matches the ProgID of a library and LNS plugin. So it is impossible to load and run the FBD, compiled for device with different ProgID.
back to contents
tinyFBD licensing
The approach to licensing is very clear. The software tools and libraries are provided for free, and can be downloaded from this site or from sites of our partners. The lincensing is per-node, so to use the FBD virtual machine on any supported controller - special unlock code must be used. Without this code the software is in demo-mode and will switch itself off after 1 hour of functioning.
To obtain the unlock codes you must pay per-node fee. To do this, you must fill out a special online form, where you will be asked to upload a file with Neuron ID's and node types you would like to activate. Then you will be taken to a secure moneybookers.com internet site for conducting payment. Very soon after payment you'll receive the letter with lists of unlock codes for your nodes.
To simplify the generation of the Neuron ID's list please consider using Echelon LNS Report Generator. You just need to configure it so only information on appDevices of your lon network is generated.
When you have received the list of 4-byte unlock codes, to activate the device just put these 4-bytes to location string property of device (HEX mode) and add 2 zero bytes on the right to justify the whole location string to 6-byte length. Device is fully functional!
Remember, that if you want to backup the unlock codes - just generate the same report again after unlocking all the devices - location strings will be contained there.
We store the unlocked Neuron ID's in a database, so if you have lost the once purchased keys - just query us with the list of Neuron ID's.
Press here to go to the online order form.
back to contents
Building automation
This article is about the proven concept of building
automation systems.
In building automation we can split the whole automation system in a
building or a group of buildings in few separate levels:
- Monitoring station
- Network Infrastructure
- Local automation subsystems
The lowest level is formed by local automation
subsystems, which correspond to separate technical units in a building,
for example air handling units, fancoils, pumps, heat centers etc.
The proven approach to local automation systems is to use standard (not
addressable) sensors and actuators with free-programmable networked
automation controllers, which have standard inputs and outputs for
connection to sensors and actuators. This approach is most effective
because for the means of reliability the control cabinets must be
placed nearby to the corresponding units, and most of cabling to the
sensors can be made with lower cost (not twisted-pair) short cables.
Also the standard, non-addressable sensors and actuators still cost 3-5
times cheaper than sensors with integrated CPU. (Although the new
‘Pyxos’ Technology by Echelon may change the situation in the nearest
future.) Anyway, the local control system is in charge of optimal unit
control, and for doing all emergency stops and alarms to protect the
equipment from being damaged from wrong functioning.
The middle level is a network infrastructure with cabling, routers, terminators etc, which is needed for exchange of information among the subsystems and between the subsystems and monitoring level. As a rule, the local subsystems must keep their functioning even if the network breaks. We can only allow them to be somewhat less efficient, but still working.
The top level – is the monitoring level, most integral, as it collects all the information from the networked automation systems, and less responsible, because there is a demand that the local automation systems must keep functioning without degrading the quality of control even if monitoring stops. To satisfy this demand any control algorithms are never placed on monitoring level, leaving these functions to the local automation. The monitoring level usually serves for presentation of the collected information to a human-operator, for datalogging and alarming.
Control network technology
Of course, here we are talking about LonWorks. Being
absolutely determined and standardized, it is also able to be expanded.
It feels that after 10 years passed there is still no adequate
competitor for this technical marvel on market. Lonworks allows to easy
create flexible and large networks, Lontalk protocol packets are
carried by a number of physical media; or tunneled by Ethernet and
Internet protocols.
On the other hand, let’s express some criticism.
The Neuron Chip has architecture of a Fort machine. The Fort language
was born from a very smart concept of a stack-oriented language, in the
pre-RISK CPU era. But then, the Fort interpreter was the only mean of
non-assembly programming of low-end CISK CPUs, because it was extremely
fast and very small. But programming with Fort had many disadvantages
in comparison to C. It was not so easy to write the expressions because
of ‘backward’ notation, the programmer had to control the right
flushing of stacks all the time, or stack overflow occurred. So, after
creating the Neuron Chip as a Fort machine Echelon decided to make a C
compiler for it, making the whole thing less effective. There is still
a market demand for powerful (and affordable) CPU’s with LonWorks
interface. Nowadays there is a number of system-on chip CPU’s with RISK
architecture (for instance – ARM32), the LonTalk protocol is published,
and nothing stops people from porting LonTalk there. There are examples
(see Loytec),
of a CPUs with number of interfaces, including Ethernet and LonWorks.
Management level
The Echelon LNS runs under Microsoft Windows WIN32 and provides API, COM and Automation servers for network management and HMI applications. LNS Client can be connected to LNS server via IP. Also Echelon provides Java SDK for LNS.
There is a Microsoft COM - based technology, called OPC, which purpose is to provide standard interfaces for real-time monitoring. A number of companies provide OPC 2.0 servers for Lonworks, and a number of SCADA systems support OPC 2.0 specifications, including data access, historical and trending services. To read more about the OPC standard see OPC Foundation site.
back to contents
