[00:00] In this video, we are going to explain how to create a new module instance. Once you have logged into the WebUI, go to Modules, under Config in the System section. Now, click on modules and create a new module. To make things easier, we recommend naming the instance in a similar way to the name of the module. In this case, we are going to call it Modbus Client. Once the instance has been given a name, select which type of module you want, in this case, it’s the Modbus Client. The following parameters must also be configured. Firstly, if this module uses data that is received remotely from other nodes via Links, the link can be paused while the module is not available in order to prevent any data loss. When paused, all data is stored locally in the remote nodes, providing these nodes have an enabled Store & Forward functionality.

[01:04] Once the connection is restored, data reception will automatically be resumed. In this particular example, it doesn’t make sense to enable this functionality, for two main reasons: first of all, due to the fact that the Modbus Client is a data acquisition module and therefore, doesn’t expose any data to third party applications by itself. Secondly, the Modbus protocol doesn’t provide time-stamped data. On the other hand, modules such as Historian, OPC UA Server, MQTT client, Derived Tags, Dnp Server, etc., can benefit from this feature. That being said, let’s leave it as disabled. Normally, modules like Historian, OPC UA server, derived tags, etc. can benefit from this functionality. On the other hand, we have the Auto-start parameter, which allows the module to automatically start whenever the system starts. We can also specify a delay (in milliseconds) for the system start. Finally, we have the Auto-Restart configuration, which allows users to configure whether or not the module should be restarted after a system failure and also provides the possibility of configuring a delay.

[02:04] Once we have configured all these parameters, let’s move on to the API configuration, where we can modify the communication settings between the module and N3uron’s bootstrap, which acts as a kind of orchestra conductor within N3uron. The API configuration settings include the following parameters. First, we have the Event rate, which determines the event exchange rate between bootstrap and the module. On the other hand, we have the Timeout, which is the maximum waiting time for a bootstrap response. For nodes handling a large number of tags, this timeout can be increased to avoid bootstrap communication timeouts. Finally, we have the keep-alive period, which specifies the time between consecutive keep-alive checks with bootstrap. When the module does not respond to keep-alive requests, bootstrap will automatically restart the module process. Once the API parameters are set, the configuration settings must be saved. Now, let’s configure the Logger, whose parameters define how the module registers its activity.

[03:03] First, we have the Enabled parameter. When enabled, the module sends logs to a text file located in the following path: /N3uron/log/. Next, we have the Level, which indicates the level of detail in the information sent to the log file. This ranges from the very basic Error level to the Trace Level, which records a lot of information about the module’s performance and is only recommended for troubleshooting. Finally, we can also customize the maximum number of days the log files will be kept on the disk for. Older log files are automatically deleted when they exceed the number of days specified in this field. The default value is seven days. And that’s it, our module is configured and ready to go.