Issue How to correctly configure Live Alarm Printer filtering in Sigma to ensure appropriate alarm printing behavior. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause The configuration of alarm printer filters in Sigma can be misunderstood, leading to incorrect or incomplete alarm printing. Only one filter can be selected per function per printer, which may limit flexibility if not properly set up. Resolution To configure Live Alarm Printer filtering in Sigma: Access Printer Filters: Open Sigma Alarm Manager. Navigate to Configure > Printer Filters. Create Filters: Create up to two filters: One for “Filter Alarms to Printer”. One for “Filter Alarms to print now”. Note: Depending on site requirements, only one filter may be necessary. Assign Filters to Printer: Go to Configure > Live Printers. Select a Live Alarm Printer from the list. Assign the appropriate filters: Filter Alarms to Printer. Filter Alarms to print now. Repeat for Additional Printers: If multiple printers are used for live alarms, repeat the above steps. Ensure the correct printer is selected before assigning filters.

Issue The power supply unit in a UNCX96 controller requires replacement of its internal power supply filter due to failure or degradation. Product Line Satchwell BAS & Sigma Environment Sigma & BAS UNCX96 controller Cause The power supply filter within the controller’s PSU may degrade over time due to age, electrical stress, or environmental conditions. This can lead to: Electrical noise interference Reduced power quality Potential controller instability or failure Resolution Replace with Approved Component The only approved replacement part is: Tyco-Corcom Type 2VK1 Power Supply Filter Ordering Information: Supplier: RS Components Order Code: 2509234656 ⚠️ Important: Do not substitute with a “near equivalent.” Use only the specified part to maintain compliance with safety and performance standards. Reference Documentation Tyco-Corcom Type 2VK1 Data Sheet (PDF)

Issue Sigma fails to communicate properly when installed on a PC where the Windows Firewall is enabled. This affects both Sigma Server and Sigma Client installations, resulting in loss of communication with controllers or other Sigma components. Product Line Satchwell BAS & Sigma Environment Sigma Server Sigma Client Cause Sigma requires specific TCP and UDP ports to be open for communication. On systems where the firewall is enabled (especially on corporate networks), these ports may be blocked by default. This prevents Sigma components from exchanging data, leading to communication failures. Resolution Step 1: Allow Sigma Through the Firewall Prompt (Client Only) On first launch of SigmaClient, Windows may prompt to allow the application through the firewall. Click “Allow access” when prompted. Step 2: Manually Create Firewall Rules (All Systems) Perform the following steps on both the Sigma Server and all Sigma Client PCs: Open Windows Firewall with Advanced Security: Go to Control Panel > Windows Defender Firewall > Advanced Settings Or search for “Windows Defender Firewall with Advanced Security” in the Start menu Create Inbound Rules: Click Inbound Rules > New Rule Select Port, then click Next Choose UDP, enter port: 49152 , click Next Select Allow the connection, click Next Choose applicable profiles (Domain, Private, Public), click Next Name the rule (e.g., Sigma UDP 49152 ), click Finish Repeat the process for the following TCP ports: TCP 8080 (used for Sigma web services or diagnostics) TCP 3614 (used for Sigma communication) (Optional) If using custom ports, repeat the steps above with those port numbers. Step 3: Verify Communication Restart the Sigma Server and Clients. Confirm that communication with controllers and other Sigma components is restored.

Issue Sigma controllers, including DNNs and ARCnet sub-LANs, are not communicating with the Sigma server. Communication appears to be completely blocked or intermittent. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause Communications with the Sigma controllers are not possible because the Windows Firewall is blocking messages. The Windows Firewall on the Sigma server is blocking UDP traffic required for communication with Sigma controllers and DNNs. Specifically, the firewall is preventing: UDP port 49152, used by Sigma UDP port 520, used by the RIP Listener service This results in the Sigma server being unable to communicate with devices on ARCnet or Ethernet subnets via DNNs. Resolution Step 1: Verify Communication Temporarily disable the Windows Firewall on the Sigma server. Check if communication with Sigma controllers and DNNs is restored. If communication resumes, the firewall is the likely cause. Step 2: Configure Windows Firewall Exceptions Open Windows Firewall Settings. Navigate to the Exceptions tab (or Allow an app or feature through Windows Firewall in newer versions). Click Add Port: Name: Sigma Port Number: 49152 Protocol: UDP Click OK Click Add Port again: Name: RIP Port Number: 520 Protocol: UDP Click **OK` Ensure both exceptions are enabled. Re-enable the Windows Firewall and test Sigma communications. Step 3: Alternative – Persistent Routing If your system uses persistent routes instead of RIP Listener, refer to the article: Persistent Routing on the Sigma Server

Issue Excessive nuisance alarms are being received at the Sigma server, leading to system performance degradation and slow response times. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause The Sigma system may be overwhelmed by unnecessary or misconfigured alarms, resulting in high volumes of data being broadcast across the network. This can lead to: Increased CPU and memory usage on the Sigma server Delays in alarm processing and display Difficulty identifying critical alarms due to noise Resolution 1. Use the Sigma Statistical Analyser Tool (SSAT) The SSAT is designed to help visualize and analyze alarm and controller data to identify performance bottlenecks and excessive alarm generation. Download SSAT Resources: SSAT Release Note (PDF) SSAT Tool for Excel 2003 (ZIP).zip) SSAT Tool for Excel 2007+ (ZIP).zip) 2. Analyze Alarm Data Import Sigma alarm logs into the SSAT Excel tool. Review the following visualizations: Pie Chart of Alarm Types: Understand the distribution of alarm categories. Alarm Count Chart: Identify peak alarm periods. Alarm Count List: Pinpoint devices or points generating excessive alarms. 3. Optimize Alarm Configuration Use insights from SSAT to: Adjust alarm thresholds and deadbands. Disable or reclassify non-critical alarms. Review and streamline alarm routing configurations. 4. Monitor Communication Statistics Use Sigma’s Comms Stats to identify controllers with high communication retries or failures. Investigate and resolve underlying network or configuration issues.

Issue When a BAS animation is assigned to an object and the graphic is run in Sigma, the animation does not move or rotate as expected. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Graphics Cause The issue occurs because a legacy BAS animation file has been used in a Sigma graphic. These animations are not natively compatible with Sigma’s animation engine unless properly configured. Specifically, the animation properties such as Frames Across and Number of Frames may not be correctly set, preventing the animation from rendering dynamically. 🔍 Note: If you're using a native Sigma animation, refer to the related article: Sigma Animations are not moving in Sigma Graphics Resolution Step 1: Identify the Animation File Locate the animation file in: C:\Sigma\Data\Graphics\Animations\Legacy\BAS Step 2: Inspect the Animation Open the animation file (e.g., ANI153 ) using Microsoft Paint. Determine: Frames Across (number of frames horizontally) Number of Rows (vertical frames) Step 3: Update Animation Properties Open the Properties page of the animation in Sigma. Set the following values: Frames Across = number of horizontal frames (e.g., 4) Num Frames = total frames (calculated as rows × frames across) Example For animation file ANI153 : If there are 4 frames across and 1 row: Frames Across = 4 Num Frames = 4 By correctly configuring the animation properties, legacy BAS animations can be made to function properly within Sigma graphics.

Issue One or more Sigma controllers are observed to warmstart or reset at regular intervals, typically every 5 minutes. This behavior is often seen after a site has been upgraded from a BAS 2800+ system to Sigma. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause The issue is typically caused by device number conflicts or legacy configuration remnants from the previous BAS 2800+ system: Device Number Conflicts: In BAS 2800+, terminals and outstations could share the same device number (e.g., T1 and OSN1).  In Sigma, each device (server, controller, DNN) must have a unique node number. If alarm routing or file requests are still directed to a now-conflicting device number, the Sigma controller may receive unexpected or invalid messages, causing it to reset. Refer to Node reset messages are received at regular time intervals after a BAS 2800+ to Sigma upgrade Legacy operlist.txt Files: Old BAS-format operlist.txt files may contain invalid entries (e.g., references to ROUTESET.REC , LOOKOSN.REC , PNTFLE.REC ) that are no longer valid in Sigma. These files can trigger file requests that the controller cannot process, leading to resets. Incorrect Server Number Assignments: Controllers may have default or backup server numbers that conflict with existing controller node numbers. Logging Server Conflicts: Logging datasets may be configured with a server number that matches a controller, causing communication errors. Resolution 1. Check Alarm Routing Use SigView to search for alarm routing destinations (R1–R4) that match controller node numbers. Update any incorrect references (e.g., T1 pointing to OSN1) to valid, non-conflicting destinations. 2. Validate and Update operlist.txt Files Ensure all operlist.txt files are in the correct Sigma format. Remove any legacy BAS entries such as: 1 C:\\Bas\\Data\\OSN2\\ROUTESET.REC ROUTESET.REC 1 C:\\Bas\\Data\\OSN2\\LOOKOSN.REC LOOKOSN.REC 1 C:\\Bas\\Data\\OSN2\\PNTFLE.REC PNTFLE.REC Replace with a dummy file if necessary: ;This is a dummy OPERLIST.TXT (Ensure a carriage return/line feed is present after the line.) If needed, delete the existing operlist.txt file and perform a download to the controller—Sigma will auto-generate a valid dummy file. 3. Verify Server Number Assignments Use Diagnostics > View Comms Stats to ensure no controller has a default or backup server number that matches another controller’s node number. 4. Check Logging Server Configuration Use Diagnostics > View Logging Servers to confirm that logging datasets are not assigned to a server number that conflicts with any controller. 5. Perform Network Packet Analysis (if needed) If the issue persists: Disconnect the controller and connect a laptop with the same IP address. Use Wireshark with an Ethernet hub to capture traffic. Apply a filter such as: ip.dst == 192.168.2.1 (Replace with the actual controller IP address.) Look for packets requesting files like LOOKOSN.REC from the controller. Identify the source IP of these requests and inspect its configuration using SigView.  

Issue The Sigma client displays delayed updates for Modbus device values. The data refresh rate on the Sigma interface is significantly slower than the actual rate of change on the Modbus devices. Product Line Satchwell BAS & Sigma Environment Sigma IC Modbus Cause The Modbus protocol is inherently a polling-based protocol, and the default configuration of the IC3 Modbus controller may not be optimized for high-speed data acquisition. Additionally, physical layer issues or inappropriate parameter settings (e.g., baud rate, retry intervals) can further degrade performance. Resolution To improve data update rates, consider the following adjustments: 1. Verify Physical Layer Integrity Ensure RS-485/RS-232 wiring is correct and robust. Refer to the article: “Investigating Modbus devices shown as offline in Sigma” for guidance. Note: Communication failures and retries reduce overall polling efficiency. 2. Optimize Gateway.txt Parameters Make the following changes cautiously, as overly aggressive settings may cause communication failures: a) Increase Baud Rate Default: 1200 bps → Recommended: 9600 bps (if supported by the Modbus device and network quality is good) b) Adjust Retry and Timing Parameters RTU Message Separation Time: Increase from 18 to ≥200 ms Retry Check Period: Set to 1 second Number of Retries: Set to 3 Device Reset Interval: 0x01 Device Down Interval: 0x01 (equivalent to 60 seconds) c) Reduce Delay Between Polls In the mapping table, the 5th field controls the delay before polling the same device again. Example: 31,2,3,0, 1 ,0x0007,0,0,1 d) Read Consecutive Registers The 6th field in the mapping table defines how many consecutive registers to read. Increase up to 7 if both Modbus and Sigma object addresses are sequential. Example: 38,2,3,7,1, 4 ,0,0,1 ; Reads 4 consecutive registers starting at 40008 3. Modify Sigma Object Settings (Display Optimization) These changes do not affect Modbus polling but improve how quickly values appear in Sigma graphics: a) Adjust Scan Priority Lower the scan priority number for critical objects to increase their polling frequency. b) Set Appropriate Tolerance Values Especially important for Graphic, Dynaview, and Actipane displays. Match the tolerance to the expected value change to ensure updates are triggered. Refer to Sigma Graphic Only Updates When First Opened or Some Graphic Data Values Do Not Update

Issue Users need to configure Sigma to print live alarms to one or more network printers, filtered by alarm priority. There is confusion around how to properly set up printer filters and assign them to specific printers. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause Live alarm printing in Sigma requires both printer filters and printer routing to be configured correctly. Misconfiguration or lack of understanding of these two components can result in alarms not printing or being routed incorrectly. Resolution Step 1: Configure Printer Filters Open the System Alarm Manager window. Navigate to Configure > Printer Filters. Create filters based on alarm priorities or other criteria. Example filters: P1 Alarms Only – Priority 1 alarms P2 Alarms Only – Priority 2 alarms P3 Alarms Only – Priority 3 alarms All Alarms – All priorities Step 2: Set Up Live Alarm Printer Routing In the System Alarm Manager, go to Configure > Live Printer. Enable the desired printer(s) by checking the corresponding box. Assign filters to each printer: Select a printer from the list. Choose the filter(s) to apply. Click OK to save. Examples: Single Printer Setup: Enable printer Xerox03. Assign the All Alarms filter. Result: All alarms print to Xerox03. Multiple Printer Setup: Enable printers Xerox01, Xerox02, and Xerox03. Assign: Priority 1 alarms → Xerox01 Priority 2 alarms → Xerox02 Priority 3 alarms → Xerox03 ⚠️ Note: Each printer can only be assigned one filter. To send multiple priorities to a single printer, create a new filter that includes all desired priorities. For further details, refer to the following resources: Sigma Help File: Sections on Filter Configuration and Printer Configuration Attachments: SigmaHelp About Filter Configuration.pdf SigmaHelp About Printer Configuration.pdf SigmaHelp.zip

Issue After making changes to the LON network or resetting the IC LON controller’s daughter card, communication through the IC LON controller stops. Affected IC LON objects begin displaying default values, and some third-party LON devices (e.g., those connected via LonMaker) also show default values. Product Line Satchwell BAS & Sigma Environment Sigma IC3-Lon LonMaker for Windows v3.1 Cause The SNVT bindings between the IC3-LON controller and other LON network devices have been broken. This can occur due to: Resetting the IC-LON daughter card Changes made to the LON network topology Third-party tools (e.g., LonMaker) modifying the network without re-synchronization IC3-LON controller entering an “application-less” state Resolution To restore communication: Rebind SNVTs Open the original LonMaker drawing. Select Menu > LonMaker > Resynchronize. Enable the following options: Re-commission controllers Use Reference Shapes Complete the wizard to re-sync the network. Upload Configuration After successful re-commissioning, upload and save the NvConfig file from the IC3-LON controller to the Sigma server. If Re-commissioning Fails If the IC3-LON controller reports “Application-less”, the LON daughter card may require a hardware reset. Refer to the article: “Sigma LON card is applicationless and cannot be reset by IC3-LON controller” for recovery steps.

Issue Modbus devices integrated via the Sigma IC3-Modbus interface are reported as offline, preventing data exchange and system monitoring. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Sigma IC/IC-3 Modbus Cause The communication failure between the IC3-Modbus and Modbus devices can be attributed to one or more of the following: Incorrect wiring (e.g., 4-wire used instead of 2-wire RS-485) Faulty or misconfigured communication cabling Incorrect or mismatched Modbus parameters in Gateway.txt Invalid Modbus register addresses or device IDs Faulty Modbus devices Improper cable shielding or excessive cable length Absence of communication activity from the IC3-Modbus Resolution Follow these steps to systematically diagnose and resolve the issue: Verify Communication Type Ensure all devices are configured for 2-wire RS-485, as IC3-Modbus supports only this mode. Check Physical Layer Confirm correct wiring and that the RS-485 LAN is continuous and not exceeding 1200 meters. Use Belden 8762 or equivalent cable with proper shielding. Maintain 300 mm separation from other electrical services. Ground the cable shield at one end only; the other end should be isolated. In noisy environments, consider adding a 1 µF capacitor between the isolated shield and ground. Validate Configuration Review and edit the Gateway.txt file to ensure communication parameters (baud rate, parity, stop bits, etc.) match the Modbus devices.  Add at least one object for the Modbus device closest to the IC3-Modbus. Download the updated Gateway.txt to the IC3-Modbus and perform a warm start. Observe Communication LEDs TXD LED flashing indicates the IC3-Modbus is transmitting. Alternating TXD/RXD flashing suggests normal communication. No TXD activity implies a misconfigured Gateway.txt . Refer to IC or Gateway Returning Default Values – Modbus, SNP, Unifact TXD active but no RXD may indicate: Broken or miswired communication cable Incorrect device address Invalid register address Faulty Modbus device Use Diagnostic Tools Modbus Simulator: Connect directly to the Modbus device using an RS232/RS485 converter to verify register responses. PocketTerminal32: Monitor Modbus traffic by connecting in parallel to the RS-485 network. Use “Display Hex” mode to inspect request/response frames. Example Modbus message: Request: 110300660001992BFD Reply: 110302142B3698 Request: 11 : Device address 03 : Function code 0066 : Register address 0001 : Number of registers 992BFD : CRC Response: 11 : Device address 03 : Function code 02 : Number of bytes of data 142B : Data 3698 : CRC Download Tools PocketTerminal32.zip

Issue Sigma graphics either update only when first opened or only some graphic data values continue to update, while others remain static. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Graphics Cause Sigma graphic updates are governed by the tolerance setting on each Sigma object. This setting determines the threshold for value changes that trigger an update from the controller to the server. If the tolerance is set too high, minor changes in values may not be transmitted, resulting in graphics that appear static or partially updated. Resolution To ensure regular and accurate updates of Sigma graphics: Review and adjust the tolerance settings on the relevant Sigma objects using the Sigma Object Editor. Download the updated object configuration to the controller. Restart the graphic to apply the changes. Best Practice Guidelines for Tolerance Settings: Temperature objects: Set tolerance to 0.05 to reflect changes of 0.1°C. Change of state (binary) objects: Set tolerance to 0.5 to reflect true/false (1/0) changes. Pressure sensors (e.g., measuring in hundreds of Pascals): Use a higher tolerance (e.g., 10) to avoid excessive updates due to rapid fluctuations. ⚠️ Note: Setting the tolerance too low may cause excessive communication traffic, potentially impacting controller performance. Bulk Update Option: To apply tolerance changes across multiple Sigma objects, use the Sigma Tolerance Utility: Download: Sigma Tolerance Utility - Support Tool Version 2.1.zip

Issue Clarification is needed regarding which communication protocols and hardware interfaces are supported when using VisiSat software on Windows 7 operating systems. Product Line Satchwell MicroNet Environment Satchwell VisiSat Windows 7 32/64 bit Cause There is ambiguity around the compatibility of various communication protocols and hardware interfaces with VisiSat when installed on Windows 7 systems. Additionally, some legacy hardware components are no longer supported or available. Resolution The following communication options are supported for VisiSat on Windows 7: SNP Protocol Via computer’s native RS232 port Via USB to RS232 converter Via PCMCIA to RS232 converter Via ExpressCard to RS232 converter IP tunneling through Xenta 555/731 or AS/AS-P LAN network Remote site connection NCP Protocol Via computer’s native RS232 port Via USB to RS232 converter Via PCMCIA to RS232 converter Via ExpressCard to RS232 converter IP tunneling through LAN network Remote site connection ARCnet Protocol Via RS232 port connected through a null modem cable to a MicroNet Interface Unit (MN50-MI-ARC) Via PCI120U-485 PCI card (no longer manufactured) Note: USB22 Series (USB to ARCnet adapters) are not supported with VisiSat IP tunneling through LAN network Remote site connection LON Protocol Not supported on Windows 7 (both 32-bit and 64-bit)

Issue Understand methods for integrating Security Expert with Active Directory for creation and management of Operators and Users. Product Line EcoStruxure Security Expert Environment Security Expert Active Directory SX-AD-OPR SX-AD-USR SX-DB-SYNC PowerShell Cause Security Expert Active Directory Integration provides synchronization and authentication for Active Directory users enabling organizations to leverage on the user management and security policies that Active Directory provides. This article looks at the details between each integration option. Resolution There are four options for Active Directory Integration. 1. Default Windows Authentication option. This allows for logging in to Security Expert with the Windows User account credentials which could include AD users if on a Domain. Operator object must be created in Security Expert and configuration of windows authentication option has some specific steps to be followed for it to work. Unable to login to Security Expert using Windows Authentication Remember to use syntax "<domain>\<username>" for the username when configuring the Operator for a Windows user ON a  Domain. Remember to use syntax "<computername>\<username>" for the username when configuring the Operator for a Windows user that is NOT on a Domain. No extra license is required for this. 2. SX-AD-OPR : License for adding Security Expert Operators from AD. Security Expert Operators will need to be added manually using the following steps: Navigate to Operators and click Add. Check the Windows Authentication box. Click the ellipsis adjacent to the User Name. Use the Active Directory Users window to search for the AD credentials you wish to use. Once the Operator has been added, you may check the Windows Authentication option when logging in. 3. SX-AD-USR : License for adding Security Expert Users from AD. This will allow an active directory domain windows group to be periodically polled for updates that will in turn update the Users in Security Expert. Individual options for importing users, disabling user if AD user is disabled, disabling user if AD user is deleted. Only user names are imported, other than this only action can be disabling of users in Security Expert. No other details can be updated or added. See application note AN-141 Security Expert LDAP User Import Configuration. 4. SX-DB-SYNC : Data Sync Service with Powershell script. Powershell script pulls user details out of AD and writes to a CSV file that the Data Sync Service then imports into Security Expert. Can perform more functions than SX-AD-USR as any attribute from AD users can be mapped to any attribute in Security Expert users. Will require powershell experience as the sample script may need to be modified. See SEC-APP-03-1.0 – SX AD integration using PowerShell for a sample script and in-depth details on how to configure this solution for importing User data. See Security Expert Data Sync Service for details on setting up and using the Data Sync Service.

Issue Clarification is needed on how to correctly wire and connect Micronet LCDs to various Satchwell MicroNet controllers.  Product Line Satchwell MicroNet Environment Micronet LCD / Micronet 50 series LCD Micronet 300 / 350 series controllers Micronet 440 / 450 series controllers Micronet 500 / 550 series controllers Micronet 620 / 650 series controllers Cause Micronet LCDs have multiple wiring and connection options depending on: The specific controller model in use Communication type (e.g., direct, networked) Installation method (e.g., panel mount, wall mount) This variability can lead to confusion or miswiring during installation or maintenance. Resolution Refer to the Micronet LCD Connections document (updated July 2012), which provides a comprehensive summary of connection options for Micronet LCDs across different controller models. 📎 Attachment: MN LCD connections (updated July 2012).pdf This document includes: Wiring diagrams Supported controller models Communication interface details Installation best practices Ensure that: The correct controller model is identified before wiring Communication settings (e.g., bit switch configurations) are verified Power supply requirements (e.g., 24VDC) are met

Issue Attempts to download images or object files to UNC532 controllers only partially complete and then fail. This behavior is often observed in the Sigma debug window. Product Line Satchwell BAS & Sigma Environment Sigma UNC532 Cause The UNC532 controller has limited processing capability. When global data broadcast rates are high (e.g., 600 broadcasts per minute), the controller may experience communication timeouts during file transfers. This results in incomplete downloads. Resolution To diagnose and mitigate the issue: Check Global Broadcast Rates Use Wireshark to trace Ethernet backbone communications. Refer to the article: Using Wireshark to Analyse Communications on an Ethernet Network. Reduce Global Data Load If analysis confirms excessive broadcast traffic, consider: Segmenting the network Reducing unnecessary global points Optimizing controller configurations

Issue Alarms generated by Sigma controllers are not being received or displayed at the Sigma server. Product Line Satchwell BAS & Sigma Environment Sigma software - All versions Cause Although the controller successfully generates alarms, they are not transmitted to the Sigma server. This is often due to misconfiguration or network communication issues. Evidence of alarms pending transmission can be seen using the Comms Stats request, which may show a backlog in the Alarm Buffers. The screen shot below indicates that the "Alarm buffers" have 21 alarms waiting for transmission. Resolution To diagnose and resolve the issue, follow these steps: Verify Alarm Generation Use the Comms Stats request from the Sigma server to confirm that alarms are present in the controller’s buffer. Check Client Configuration Ensure the Sigma client (local or remote) is correctly configured. Refer to the article: “Alarms are not displayed in the Sigma local or remote client Alarm Manager window”. Validate Server Configuration In System Setup > Networks and Devices, confirm that the Sigma server is properly defined. Confirm IP Address Settings Ensure the Sigma server’s IP address matches the configuration in Network Connections. Inspect Alarm Routing Upload an object with an alarm from the controller and check the Routing Page. Ensure there are no references to “T”, which was used in BAS2800+ but is not valid in Sigma. Check Network Health Collaborate with your IT department to confirm there are no network issues (e.g., firewall blocks, routing problems, or IP conflicts).

Issue An Analogue Input (AI) point configured for a 0–10V signal in Sigma or BAS may display a default or erroneous value when the input voltage exceeds 10V DC. Product Line Satchwell BAS & Sigma Environment Satchwell BAS & Sigma Cause Sigma AI points are designed to operate within a 0–10V DC range. If the connected sensor or device outputs a voltage greater than 10V, the system interprets this as an out-of-range condition, causing the AI point to revert to its default value. This behavior is commonly observed with certain sensors (e.g., SHD100 / SHD101 Humidity Sensors) that can output voltages above 10V, especially under specific environmental conditions. Resolution To prevent out-of-range values and ensure accurate readings, consider the following mitigation strategies: 1. Voltage Clamping Using a Zener Diode Component: Zener Diode (e.g., 9.1V rating) Installation: Can be installed at the sensor end (preferred for ease) or at the controller input. Operation: Limits the input voltage to the Zener’s breakdown voltage (e.g., 9.1V). Any voltage above this threshold is clamped, preventing overvoltage conditions. Note: Typically, a series resistor is used with Zener diodes. However, if the sensor has high impedance, the current is minimal, and a resistor may not be necessary. Diagram: 2. Series Diode Voltage Drop Component: Standard Diode (e.g., 1N4001) Installation: Connect in series with the sensor’s output signal to the controller. Operation: Introduces a voltage drop (~0.6V), effectively reducing the input voltage. Requires a revised lookup table to compensate for the voltage drop. Example: 10V input becomes 9.4V at the controller. 3. Limiting Actuator Feedback Voltage Scenario: When feedback is sourced from an actuator. Solution: Restrict actuator output to a maximum of 9.5V. Ensures feedback signal remains within acceptable range. Caution: May slightly reduce valve/system performance if the actuator controls a mechanical device like a valve. Additional Notes Always verify the sensor’s output characteristics before integration. Consider using lookup tables to calibrate and correct voltage offsets introduced by diodes. For humidity sensors like SHD100/101, refer to their datasheets for voltage output behavior under varying humidity levels.

Issue Fault Finding on an IC-SNP / IC3-SNP and associated IAC controllers. Product Line Satchwell BAS & Sigma Environment IC-SNP IC3-SNP IAC controllers Cause Communication faults on the SubLAN may be caused by: Cause Description Incorrect LAN Termination Missing or improperly placed 120-ohm resistors can cause signal reflections and data corruption. Biasing Misconfiguration Bias jumper not set to “D” (Full Biasing) can result in unstable idle voltage levels. Faulty Controller Driver A single IAC controller with a failed RS-485 driver can hold the RX line low, blocking communication. Corrupted gateway.txt Entries Invalid or misconfigured entries can prevent the IC-SNP from initializing communication properly. Physical Layer Issues Damaged cables, poor connections, or incorrect wiring can interrupt signal transmission. Power Supply Problems Inadequate or unstable power to controllers can cause intermittent or complete communication loss. IC-SNP Hardware Failure Internal faults in the IC-SNP or IC3-SNP can prevent proper LAN operation. Excessive LAN Length or Load Too many devices or long cable runs without repeaters can degrade signal quality. Environmental Interference Electrical noise from nearby equipment can disrupt RS-485 signals. Resolution 1. Use of Alarm Manager Access via Sigma default/backup server. Review system messages (priorities 22–30) for controller-specific errors. Look for messages like “Unable to Communicate with Controller ???”. 2. Troubleshooting gateway.txt File Symptoms: “Unable to open gateway.txt file” error. Steps: Start with a minimal gateway.txt (1–2 entries). Use a known-good version from Exchange-On-Line. If errors persist: Remove all entries except one. Download and warm-start the controller. Gradually reintroduce entries to isolate the faulty line. 3. Controller Not Responding Single Controller: Check local communication using Visisat and LIB-4-485. Verify LAN wiring and power supply. Multiple Controllers: Indicates partial or full SubLAN failure. Begin investigation at the IC-SNP. 4. IC-SNP Hardware Checks Component Expected Behavior Bias Jumper Set to D (Full Biasing) Termination 120-ohm resistors at both ends Channel 2 TX LED Flashes after warm-start (gateway.txt processing) Channel 2 RX LED Flashes if receiving replies RX LED Permanently On: Indicates a faulty IAC controller driver disrupting LAN comms. 5. IC-SNP Retry Mechanism Retries each controller 3 times before marking offline. Sends error to Alarm Manager. Retries offline controllers every 30 minutes (on the hour and half-hour). 6. Binary Chop Method for LAN Isolation Purpose: Efficiently isolate faulty segments or controllers. Steps: Identify LAN midpoint. Disconnect twisted pair at nearest controller. Observe RX LED behavior: LED Off: Fault lies beyond midpoint. LED On: Fault lies before midpoint. Repeat by halving LAN again (25% or 75%) until fault is found. 7. Voltage Testing Guidelines Use a DC voltmeter to measure: Measurement Expected Voltage +ve to 0V ~2.5 V –ve to 0V ~0.15 V +ve to –ve ~2.31 V Note: Negative voltages suggest LAN faults. Compare readings across segments to identify anomalies. 8. RX LED Not Flashing at All Possible Causes: Faulty IC-SNP Faulty SubLAN Faulty Controllers Steps: Disconnect LAN after first controller. Warm-start IC-SNP. Observe RX LED: If flashing resumes, use binary chop to isolate fault. If not, test cable and controller individually. 9. Cable Testing Procedure Disconnect both ends and separate cores. Measure resistance: Between cores: ∞ Each core to earth: ∞ Short cores at one end. Measure resistance at other end: Between cores: ~0 Ω Each core to earth: ∞ 10. Controller Testing Use LIB-4-485 and Visisat Engineering software. Confirm controller responds to direct communication. Final Steps: Once faults are resolved: Download full gateway.txt. Warm-start IC-SNP. Monitor Alarm Manager for new errors.

Issue After upgrading from BAS 2800+ to Sigma, the Sigma server receives recurring node reset messages. Product Line Satchwell BAS & Sigma Environment Sigma software - all releases. Sigma firmware - all versions. Cause In the legacy BAS 2800+ system, Controllers and Terminals could share the same device numbers. Sigma, however, requires unique device numbers for all nodes. If a controller configuration inadvertently retains a reference to a terminal (with a reused device number), the controller may attempt to send messages to that device. If the referenced device is actually another controller, it will reset upon receiving unexpected messages. Resolution To identify the source of the reset messages, use one of the following methods: Method 1: Using SigView Open SigView and display all object data for the controller experiencing resets. Search for entries referencing the resetting node number, such as: T(<resetting node number>) Investigate any such references and correct the configuration. Method 2: Using Wireshark Disconnect the affected controller from the network. Connect a laptop configured with the same IP address as the controller. Run Wireshark to capture network traffic for a duration longer than the reset interval. Filter the capture to show only messages sent to the IP address of the resetting node. Identify the source IP address of these messages. Use SigView to inspect the configuration of the source controller. Example: A Wireshark trace filtered by Source IP Address can help pinpoint the origin of the problematic messages. Additional Resources Using Wireshark to Analyse Communications on an Ethernet Network