MAC36 - iSMA_IO - Problems with the module

Issue

Problem with starting or running of the iSMA_IO JAR module.

Possible causes and solutions

Value set in the AnalogOutput component does not comply with the value stored in the Out slot as well as the voltage value at the terminals measured 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.

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.

The below outline describes the process how the value set to the converter output is calculated:

S - scale value,
X - (non null) input (with the highest priority) value,
Y - real output value,
O - Out slot value.

Y and O values are calculated as follows (with hidden conversion of units from V to mV and from mV to V):

CODE

Y = MAX(0 mV, MIN(10 000, (X * 1000) / S))
O = Y * S / 1000

So if X == 10 V and S == 0,1 the following calculations will be applied:

CODE

Y = MAX(0 mV, MIN(10 000, (10 * 1 000) / 0,1))
Y = MAX(0 mV, MIN(10 000, 100 000)) //zadana wartość jest obcinana przez funkcję MIN
Y = MAX(0, 10 000)
Y = 10 000 mV //to jest wartość dla wyjścia AO

The Out slot value will be calculated as follows:

CODE

O = 10 000 * 0,1 / 1000
O = 1,0 V

Solution

Fix the scale and offset values so that the scaled values would not exceed the range of 0-10 V DC. If the inX and Out values are equal, it means that the scaling has been set correctly for the current operating mode.

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 this is required for PT1000.

Missing gc5LibDevice license component

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

Solution

Try to download the license again 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, and then perform a station reboot.
Order the free (for MAC36 controllers) gc5LibDevice component from niagara-central.com and update the license on the controller.

Information about exceeding the limit of points

In 2.1.0.0 version of the iSMA_IO module, there is a known bug, which causes displaying the license point limit overrun. If the cause is not the missing gc5LibDevice component in the GC5.license file, then it may just be an infected version of the iSMA_IO module.

Solution

In this case, install the iSMA_IO module version 2.1.1.0 or higher.

Input reading freezes and components do not update values

There is a known problem with iSMA_IO version 2.0.1.0, more specifically with the UniversalInput components. It occurs when the component is set as Input Type → Voltage and the default Facets (null) is changed:

Solution

In this case, install the iSMA_IO module version 2.1.0.0 or higher.

Wrong responses from devices with different addresses

In the Application Director, the iSMA_IO module records errors as below:

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

These are caused by a bug in the iSMA_IO version 2.1.0.0 and lower.

Solution

To solve the problem, follow one of the below paths:

Update the iSMA_IO module to the 2.2.0.3 version or higher,
Reduce the polling frequency of the I/O components of the iSMA_IO module using the 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 iSMA_IO module's programmed permissions:

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

Solution

There are three solutions to the problem:

Reduce the security level to low in the system.properties file in the Defaults folder:
- Open platform -> File Transfer Client and add the defaults folder in the main location of the controller:
- Find the system.properties in the SysHome folder of Niagara and copy it to the created defaults folder on the controller:
- Find a code line for security level (niagara.moduleVerificationMode), uncomment (remove #) and leave a low security level:
Using the iSMA_IO module in a version higher than 2.4.2.0, where NETWORK_COMMUNICATION permissions have been reduced to the minimum necessary.
Using Niagara version 4.11.2.16 or lower.

UI input changes state for a while after station reboot

When the UI input is connected to an NC contact, which does not change state, and then the station is restarted, then the input briefly reads an open state by which it affects the logic being executed.

Solution

The solution may be to use the BooleanLatch component from the kitControl palette right after the UniversalInput component. After restarting, 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, and after a few milliseconds the value in the UniversalInput component will be updated and logic will execute logic based on the correct value. This will prevent the logic to be executed from starting when the input state has not changed, but only the station restart has occurred.