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):
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:
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:
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:
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 the2.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:
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 thedefaults
folder in the main location of the controller:Find the
system.properties
in theSysHome
folder of Niagara and copy it to the createddefaults
folder on the controller:Find a code line for security level (
niagara.moduleVerificationMode
), uncomment (remove#
) and leave alow
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.