SMTuner Setup Depends on Project Match and Plant Response

SMTuner runs on a separate controller and communicates with the ventilation-unit controller over Modbus; successful tuning depends on a compatible project/controller combination and a plant response the identification algorithm can detect. Commission the communication path first, then check the selected loop, operating conditions, and output limits before accepting coefficients.

Separate the tuner project from the ventilation project

SMTuner is loaded onto a controller separate from the controller running the ventilation-unit project. A Pixel-12xx was identified as a low-cost choice, but a Pixel used for this program needs a memory module. The tuner controller acts as the Modbus master; the ventilation-unit controller supplies the process data and receives the tuning interaction.

This arrangement also lets a technician take a tuning controller from one site to another. Leaving it separate avoids reserving the ventilation controller's resources for a tool used mainly during commissioning and can leave Modbus variables available for SCADA after tuning. Those are reasons to choose the arrangement, not prerequisites for the tuning algorithm itself.

The SMTuner project offered for saving was described as the same fixed project, not a project automatically bound to the most recently created SMConstructor application. Keep the process project and the tuner project distinct in the commissioning record.

1. Check: the tuner application is loaded on its own controller, and if that controller is a Pixel, its memory module is installed.
2. Check: the ventilation application remains on the target controller and the intended Modbus connection between the two controllers is identified.

Match the tuner build to the target controller

Project compatibility depends on using the tuner from the SMConstructor generation that created the ventilation project. For example, when asked whether SMTuner v0-99/b1 could understand a project created in SMConstructor v1-31 for an SMH 2Gi, the stated decision rule was to use the tuner from the same Constructor version as the project. That pairing was described as the guarantee of understanding; do not substitute a tuner build just because its file loads.

Controller hardware also matters. An SMH2010 variant whose modification code ended in 1 reported a load interruption stating that master requests were configured on the current operating port. The reported requirement for loading the SMTuner project onto an SMH2010 was a modification code ending in 2 or 3. Read the complete modification code before troubleshooting the communications cable: a port-role or hardware-variant mismatch will not be corrected by changing Modbus wiring.

Pixel support was presented as the straightforward low-cost arrangement, while broader controller support was described generally. Use the exact target model and its modification code as the decision point rather than extrapolating from another controller family.

1. Check: the tuner build comes from the same SMConstructor version used to create the target project.
2. Check: for an SMH2010, the modification code ends in 2 or 3; a unit ending in 1 matches the reported load-failure condition.

Commission the RS-485 Modbus path

RS-485 is the direct, known connection path for this tuner. In the cited SMConstructor 0.99/1.00 arrangement, the tuner automatically searched Modbus addresses 0..10 at 115200 baud. Treat those as settings for that described generation, not universal values for every tuner build. Confirm the target project's communication configuration before applying them to a different build.

A successful physical connection does not prove that the Modbus master can reach the intended controller. Confirm that the selected serial port is the one wired to the target, the target has a unique address inside the scan range, and the target's serial settings match the tuner. If the automatic scan finds no controller, check those settings and port assignment before changing the control loop or tuning parameters.

An FMR-3030 COM2 port was described as communicating only with the FMR itself, even though its manual identifies an external-master use for that port in another context. In the reported Pixel-2511 plus FMR-3030 configuration, that port could not serve the tuner-to-ventilation-controller Modbus link. Select a port that actually exposes the target controller to the tuner master.

1. Check: for the cited Constructor 0.99/1.00 setup, the scan covers addresses 0..10 at 115200 baud.
2. Check: the target ventilation controller appears in the scan at its configured address; if it does not, verify port ownership, address, and serial settings before proceeding.
3. Check: an FMR-3030 COM2 connection is not being treated as an external tuner path when it is assigned to the FMR itself.

Route Ethernet requests to the correct Modbus slave

The Ethernet instructions were described as inconsistent: a quick-start claim of Ethernet support was challenged, while a working approach was to reconfigure the slave path rather than leave the slaves on the serial port. For Ethernet, move the slave definitions from the COM port to Ethernet, then configure the first slave with the target controller's correct IP address and Modbus address. The forwarding path must agree with the target's actual network configuration.

In one failed setup, two Pixel25 controllers were connected by a cross-cable and had IP addresses 192.168.1.12 and 192.168.1.4. The tuner also had COM1 controllers 0–10 forwarded to NetPort with addresses in the 192.168.1.1–192.168.1.11 range. Link and activity indicators were lit, but the tuner still could not see the ventilation controller. Those indicator states show Ethernet link/activity; they do not verify that the Modbus slave mapping, destination IP, and Modbus address are correct. Do not copy that address range as a template without checking the actual routing setup.

1. Check: all intended slave entries are assigned to the Ethernet path, not left on the COM port.
2. Check: the first slave entry contains the target controller's actual IP address and Modbus address, and the tuner detects that slave end to end.
3. Check: lit Link/Act indicators are not treated as a pass unless the Modbus target is also visible to SMTuner.

Identify the tuned channel and the displayed sensor

Confirm which regulation channel SMTuner exposes before starting. In a project with an electric heater and a fan controlled by temperature, the tuner exposed the heater channel but not the fan channel. The explanation given was that the heating characteristics in that arrangement were too nonlinear and could be unpredictable for reliable identification; factory fan coefficients were said to work in most cases. This is a project-specific limitation, not evidence that every fan-temperature loop can or cannot be tuned.

Distinguish the selected tuning target from the live sensor shown on the display. During a test where the return sensor was selected, the screen continued to show the duct sensor. That display was intended to let the operator watch for possible duct overcooling; it did not mean the return channel was necessarily the one being tuned. Verify the selected channel in the menu and observe the relevant live trend separately.

The final coefficient screen was reported without a clear device name. Record the channel and sensor with the resulting values as soon as each run ends. Do not rely on remembering the target after leaving a long-running test unattended.

1. Check: the intended control channel is available in SMTuner; if it is absent, confirm whether the project intentionally excludes it rather than changing an unrelated communication setting.
2. Check: the selected target sensor is recorded separately from the sensor shown on the live display; the duct reading remains visible when needed to monitor overcooling.
3. Check: the commissioning record identifies the tuned channel beside each coefficient set.

Qualify the plant response before starting a run

Autotuning estimates loop behavior from the observed process response. Slow thermal processes, weak temperature changes, noisy measurement, large transport delays, and nonlinear valves can obscure the response features the algorithm needs. A long elapsed runtime does not prove the algorithm is still gathering useful data. One description put an individual measurement cycle at roughly ten minutes, but reports of much longer runs were attributed to conditions where temperature-response inflections were too gradual for the algorithm to identify reliably.

Do not try to stretch a failed run by increasing a configured delay. Delays were described as allowing up to 9999 minutes, but the stated limitation was the algorithm's inability to detect very weak temperature changes, not an insufficient delay setting. A run that continues for hours, returns the valve to its starting point, or repeatedly fails to settle on coefficients calls for a process-condition check.

Check the actuator-to-temperature response manually before starting. In one water-coil case, a valve opening of 20% produced a duct temperature of 24.6 °C; a temperature at a higher opening had not yet been measured. The recommendation was to tune while the valve operates in its upper half, because the lower end often offers too little useful response. Manually move the valve toward the middle of its range and measure the duct temperature, then assess whether the plant has a distinct, repeatable response. Also confirm the water circuit is hydraulically balanced and does not produce erratic “kicking” as the controller moves the valve.

If response is too weak or the test stalls, adjust the operating condition or setpoint and measure again rather than letting the tuner cycle indefinitely. A water-cooling application was suggested as possible but still needing a test; successful results on a heating coil do not establish performance on a cooling loop.

1. Check: the valve produces a clear, repeatable temperature change in the operating region selected for tuning, preferably the upper half of travel.
2. Check: hydraulic behavior is stable and the temperature trend is not dominated by noise, an unbalanced circuit, or a response too gradual to identify.
3. Check: a run that remains active for hours is treated as a failed-condition diagnostic, not as proof that the expected tuning time is hours.

Set safe output bounds for high-power heaters

The reported tuner exposed a user-set lower output limit while keeping the upper output limit at 100%. A lower bound cannot cap the maximum command. That matters when an electric heater has enough capacity to create a very large discharge-air temperature rise: one described case involved outdoor air at -20 °C and a heater capable of producing approximately 80–100 K temperature rise, yielding an outlet temperature in the +60 to +80 °C range.

Before a test, calculate the likely discharge temperature from the measured inlet temperature and the actual heater response. Check the heater's independent high-temperature protection and the ventilation unit's operating limits. Do not assume that a lower output setting prevents a full-scale command if the tuner can still drive the output to 100%. If the test requires limiting the upper command and the tuner does not provide that limit, do not start an uncontrolled test on a heater that can exceed the permitted temperature.

The lower limit remains useful for preventing operation below a required minimum output, but it is not a substitute for an upper cap or a high-limit device. Monitor the duct temperature during the test, particularly as the output increases.

1. Check: the configured lower output limit matches the intended minimum, and the operator recognizes that the maximum remains 100%.
2. Check: measured inlet temperature plus the observed heater rise remains below the equipment's permitted discharge temperature; independent high-limit protection is available and active.
3. Check: the duct-temperature reading stays within the intended limit as the tuner changes the output.

Interpret PI coefficients in the target regulator

Reported tuning runs returned D=0.0. The interpretation given was that the calculated coefficients were intended for a PI regulator and that derivative action should be added by manual judgment if the application needs it. Do not infer that a zero derivative term is a failed calculation; first identify the tuner output and regulator form.

The algorithm was described as independent of the specific regulator type in its first approximation, while the conversion formula was adapted to the my_pid regulator series. That distinction matters because the same displayed P and I numbers can have different effects if the target block uses a different equation or scaling. A discussion raised two forms, Y=K*(e+(1/Ti)*INT(edt)) and Y=K*e+(1/Ti)*INT(edt); do not assume the returned values map identically between them. Inspect the target regulator's equation and parameter scaling, then enter the values using that block's documented convention.

Observed result	Reported values	Commissioning meaning
Three water-heating tuning runs under different start conditions	P=18.77, I=42.06, D=0.0; P=19.11, I=58.6, D=0.0; P=19.36, I=49.5, D=0.0	Similar P values did not eliminate variation in I; retain each run's sensor, start condition, and channel record.
A separate reported test on a slow, high-inertia air-handling unit	Autotune around P=5, I=50; manual settings around P=50–55, I=100–120	The autotuned response showed a large startup drop, reaching the antifreeze thermostat trip; manual settings then held near setpoint with an approximately 1 °C startup drop and slow oscillation around ±0.5 °C.

The second case involved three filters, a water cooler, a sound attenuator, high thermal inertia, slow response to valve movement, sensor noise, and a nonlinear three-way ball valve. Those characteristics can make the apparent end of the response front difficult to identify. Treat the reported coefficients as case results, not presets for another installation; compare repeat runs and inspect the process trend before deciding whether they are usable.

1. Check: the controller's regulator type, equation, and P/I scaling match the conversion expected for the target block.
2. Check: the entered derivative term is understood; a returned D=0.0 is treated as PI output unless the target regulator has a separate derivative requirement.
3. Check: repeated coefficients are judged with the associated trend and startup behavior, not accepted solely because the values appear similar.

Verify the tuned loop through a complete startup

Coefficient entry is not the commissioning finish. The reported risk appeared at startup from a heating or warm-up state, when the first approach to setpoint produced a large temperature drop and could trip antifreeze protection. Test the selected coefficients through the actual operating transition, not only after the loop has settled.

Trend the command, selected control sensor, duct temperature, and setpoint together. Use the live duct reading as an independent check against overcooling even when the return sensor is the selected target. Observe the first approach to setpoint, steady-state cycling, and any protective trip. If the initial excursion is unacceptable, stop the test, review the output envelope and sensor response, and retune only after restoring safe, repeatable plant conditions.

Keep a commissioning record that ties the parameter set to the controller, SMConstructor project version, tuned channel, selected sensor, startup condition, and test result. This record prevents coefficients from being applied to a different loop or regulator scale.

1. Check: the tuner finds the intended controller and channel, and the entered P/I/D values match the recorded tuner result and target regulator convention.
2. Check: during a complete startup, the process reaches setpoint without an unacceptable temperature excursion or protective trip; the duct trend remains within the installation's limits.
3. Check: at steady state, the measured response is stable enough for the application, and the final record identifies the controller, project version, channel, sensor, coefficients, and observed startup/settled behavior.

FAQ