€ 150,00 net (plus VAT 19% i and shipping)
Controller and ModbusTCP gateway module for the gpio.NET system with 128 MB on-board RAM and 512 MB on-board flash. Suitable for distributed IO and as stand-alone control unit.
The gpio.ipCore is the interface to taskit's Modbus based IO modules. It provides ModbusTCP, a generic REST interface, ready to use scripting languages and a fast, lightweight database. All this accessible via standard protocols!
Using the database, scripts and the easy extendable REST interface, you can build self-contained, independent systems without need for an external control unit such as a PC. When talking to other machines, gpio.ipCore can exchange script controlled variables. This can be compact status information based on multiple sensor values or simple triggers received from the outside world that result in a more complex compound of instructions.
For system configuration, log in via SSH using taskit as password for root. Just type ssh firstname.lastname@example.org into a unix-like shell or use putty under windows. In order to get the name resolution work, install Avahi or Bonjour mDNS service.
The web interface consists of the homepage which can be freely designed and the expandable REST interface. You can change the content by replacing the files in /var/ipcore/webpage.
A requested URL is handled the following manner:
- prefix gpio/ is handled by a Modbus-REST bridge
- prefix shared/ is handled by the Redis-REST bridge
- all other URLs refer to the content of the /var/ipcore/webpage directory
A common set of script languages is supported by gpio.ipCore. It comprises LUA, NodeJS, Python and Python3. Scripts can be put into subdirectories of /var/ipcore/.
Scripts are intended to automate the access to connected Modbus devices through the MBTCP server running on the ipCore. They can read/write arbitrary keys from the database to do M2M communications or to interact with a user interface. Modbus and Redis bindings for those languages come pre-installed.
The database serves as generic key-value store. There is almost no limitation on the names of keys. Values are supposed to be strings holding either simple data or complex JSON objects.
Any key xxx stored in the database is addressable as shared/xxx. See redis.io for details.