iSMA_IO - Problems with the module

Issue:

Problem with starting or running of the iSMA_IO JAR module.

Possible causes and solutions:

The set value in the AnalogOutput component does not comply with the value stored in the Out slot, as well as the measured voltage value at the terminals with a multimeter

After setting the voltage value in the inX slot of AnalogOutput component, the value shown in the Out slot is different, and the voltage measured with a multimeter shows yet another value.

Solution:

The described behavior is due to an incorrect Linear Conversion setting in the AnalogOutput component. The value specified in the inX slot is converted using the Scale and Offset values and sent to the driver. The driver then takes this value and limits it (the voltage cannot be less than 0 V and more than 10 V), then sends it to the converter. Finally, the Out slot displays the value that the transmitter has scaled according to the Linear Conversion setting.
Therefore, the scale and offset values should be corrected so that the values entered after scaling do not go beyond the 0-10 V DC range. If the values of the inX and Out slots are equal to each other, it means that the scaling has been correctly set for the current operating point.

Incorrect reading of PT1000 sensor

When a PT1000 universal sensor is connected to any input, and then the UniversalInput component is configured to the same channel and the PT1000 characteristics are set, the value shown does not correspond to reality.

Solution:

Make sure that the Resolution slot is set to 16 bit, as PT1000 sensors require this setting.

Missing gc5LibDevice license component

Occasionally, the iSMA_IO does not work, because the license is missing the gc5LibDevice license component.

Solution:

Try to re-download the license from niagara-central.com as a file and install it in platform -> License Manager or, in the same tool, try to download a new license file through it, and then reboot the station.
Order the free (for MAC36NL drivers) gc5LibDevice component from niagara-central.com, then update the license on the driver.

MAC36NL-RS - no operation of RS485 port on COM2 extension

At times, the COM2 extension does not work properly on the MAC36NL-RS. Switching the network to COM1 and rewiring the RS485 bus to COM1 causes the circuit to work correctly:

Solution:

Verify that COM2 is not already occupied by another RS485 driver (such as ModbusAsyncNetwork or BACnet MstpPort).
Possibly, the COM2 port has been burned out through misconnection or the wrong extension was installed at the factory - in either case, COM2 will not work properly.

Incorrect responses from devices with different addresses

The iSMA_IO module in the Application Director returns errors as the following:

CODE

SEVERE [09:35:18 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 20
SEVERE [09:35:18 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 7
SEVERE [09:35:20 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 20
SEVERE [09:35:22 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 20
SEVERE [09:35:23 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 20
SEVERE [09:35:24 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 20
SEVERE [09:35:25 28-Feb-24 CET][iSMA_IO:PollingThread] Bad response number 2 from device with address 1

It is caused by a bug found in the iSMA_IO version 2.1.0.0 and lower.

Solution:

The solution is one of the following options:

Upgrade iSMA_IO to version 2.2.0.3 or later,
Reduce the polling frequency (Polling) of the I/O components of the iSMA_IO module using TuningPolicy.

External access to the driver

After installing the module, the following set of logs appears in the Application Director every time the station is started:

CODE

INFO [09:35:18 28-Feb-24 CET][sys] Additional permission found for module <file:/opt/niagara/modules/iSMA_IO-rt.jar>:
Type: NETWORK_COMMUNICATION
 Purpose: Outside access for Driver
 Parameters: [ Host: * | Ports: * | Type: all | Proxy Selector: null | Get Network Information: null | SSL Sockets: null ]
 Risk Level: MODERATE

The message results from the module's permissions programmed in iSMA_IO:

The problem was highlighted by increasing the default security level in Niagara 4.12.2.16.

Solution:

The solution is one of the following:

Reduce the security level to low in the system.properties file in the Defaults folder;
- Open the platform -> File Transfer Client location, and then add a folder named defaults in the main location of the driver.

Then, find the system.properties file in the SysHome folder of Niagara and copy it to the newly created location on the driver.
Finally, find the line of code responsible for the security level (niagara.moduleVerificationMode), uncomment it (remove the #), and set the security level as low.
Use of the iSMA_IO module in a version higher than 2.4.2.0, where NETWORK_COMMUNICATION permissions have been reduced to the minimum necessary.
Use of Niagara version 4.11.2.16 or lower.

When the station is restarted, the UI input changes state for a while

After connecting the UI input to an NC contact, which does not change state, and then rebooting the station, then when starting the station again, the input reads the open state for a moment affecting the logic being executed.

Solution:

The solution may be to use the BooleanLatch component from the kitControl palette right after the UniversalInput component. After rebooting, for a moment when the UI does not read the correct value from the input, the BooleanLatch component will continue to hold the previous value for logic. After a few milliseconds, the value in the UniversalInput component will be updated and logic will be executed based on the correct value. This will prevent the logic to be executed from the start when the input state has not changed, but only a station restart has occurred.