Issue A Sigma Programmable Object must detect changes in the state of multiple Digital Inputs (DIs), trigger an external alarm via a Digital Output (DO), and then reset itself to detect subsequent changes—even if the triggering DI remains active. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause The programmable object is configured to monitor several digital input points. When any of these points change state (e.g., from OFF to ON), the object must activate an external alarm via a digital output. However, to ensure it can detect future state changes on the same input, the object must reset its internal state after a defined period—even if the input remains ON. Resolution Use a programmable object with logic that: Monitors multiple digital input points (e.g., points 33, 35, 36, 37). Increments a counter ( XINT ) for each input that is ON. Compares the current count ( XINT ) with the previous count ( YINT ). If a new change is detected ( XINT > YINT ), it: Updates YINT Starts a 60-second timer Triggers an alarm (priority can be adjusted) If no new changes are detected and the timer expires, it resets YINT to 0, allowing the object to detect future changes. Sample Code: 10 XINT = 0 20 IF POINT 0|33 ON THEN XINT = XINT + 1 30 IF POINT 0|35 ON THEN XINT = XINT + 1 40 IF POINT 0|36 ON THEN XINT = XINT + 1 50 IF POINT 0|37 ON THEN XINT = XINT + 1 60 IF XINT > YINT THEN GOTO 100 70 IF TIME LEFT THEN GOTO 120 80 IF XINT = 0 THEN YINT = 0 90 RETURN FALSE "reset" 100 YINT = XINT 110 SET TIMER 60 120 ALARM 1 130 RETURN TRUE "Alarm" Notes: Timer duration (Line 110) and alarm priority (Line 120) can be customized. Additional DI points can be added by replicating the logic in lines 20–50.

Issue Recipients receive a message from the Remote Alarm Manager (RAM) indicating that an alarm has been inactivated, even though no manual action was taken to clear the alarm. Product Line Satchwell MicroNet, Satchwell Sigma, TAC Vista Environment Remote Alarm Manager version 1.2 Cause The Remote Alarm Manager is designed to automatically send an inactivation message after a fixed period if an alarm remains active but is not retransmitted. By default, this period is three days, and the message is sent at midnight to the on-call recipient. This behavior is part of the system’s design to prevent stale alarms from remaining indefinitely without notification. Resolution This is expected behavior and not a fault. To manage or modify this behavior: Understand the default configuration: RAM sends inactivation messages after 3 days of no retransmission. This helps ensure recipients are aware that the alarm is no longer considered active. Adjust the inactivation timer if needed: The default 3-day period can be changed in the RAM configuration settings. Consult the Remote Alarm Manager documentation or configuration interface to modify this value. Review alarm retransmission settings: Ensure alarms are configured to retransmit if they remain active and require ongoing attention.

Issue After upgrading from Sigma Version 4.07 to Version 4.08, only the default SIGMA USER is available when logging into the system. All previously configured users and groups are missing. Product Line Satchwell BAS & Sigma Environment Sigma Server Cause During the installation of Sigma 4.08, there is an option to start the Sigma server immediately after installation. If this option is selected during an upgrade, the system creates a new GenCnfEx.rec file containing only the default user. This overwrites the existing user configuration and results in the loss of all previous user and group data. Resolution To preserve existing user and group configurations during the upgrade: Do not start SigmaSvr immediately after installation. Ensure the checkbox to start the server post-install is unticked. Run the upgrade program manually after installation completes. Start SigmaSvr only after the upgrade program has successfully run. If the GenCnfEx.rec file has already been created in error: Stop SigmaSvr. Delete the newly created GenCnfEx.rec file. Ensure the GenCnf.rec file from Version 4.07 is present in the data folder. Re-run the upgrade program to correctly generate the new GenCnfEx.rec file with all server details and user information.

Issue How to configure a single RAM engine to monitor and manage alarms from multiple building automation systems across a site. Product Line Satchwell MicroNet, Satchwell Sigma, TAC Vista Environment Remote Alarm Manager Cause Some sites operate multiple BMS platforms concurrently. Rather than deploying separate RAM engines for each system, a centralized approach using one RAM engine can streamline alarm management and reduce system complexity. Resolution To configure RAM to monitor multiple systems from a single engine: Install RAM on the Master System Choose a primary system (e.g., Sigma) to host the RAM engine. Follow the installation and configuration steps outlined in the RAM Engineering Guide. Configure Alarm Actions Set up alarm actions on the master system (e.g., Sigma) to handle events from remote systems. Integrate Remote Systems Connect additional systems (e.g., BAS2800+, Micronet, Vista) to the master RAM engine. Ensure communication paths and alarm routing are correctly configured. Test and Validate Confirm that alarms from all connected systems are received and processed by the master RAM engine. Monitor for any communication or processing issues.

Issue Clarification is needed on how data is transferred between Sigma Clients (Remote and Web) and the Sigma Server, including ports used and encryption methods. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause Sigma uses proprietary communication methods between clients and the server. Understanding the ports and encryption mechanisms is essential for secure deployment, firewall configuration, and troubleshooting. Resolution   Data transfer between Sigma Clients and the Sigma Server involves the following: Communication Ports TCP Port 3614: Used for general data transfer (e.g., index files, point files, logs, alarms). HTTP Port 8080: Used for web-based communication. Also handles keep-alive messages from clients. This port is configurable via SetupSvr located in C:\Sigma\Bin . Encryption Details Passwords: Encrypted during transmission. Transferred via TCP using ports 8080 and 3614. Usernames: Not encrypted during transmission. Data Security While data is not encrypted end-to-end, Sigma uses a proprietary method for data handling. For enhanced security, consider network-level protections (e.g., VPN, firewall rules). Additional Reference See related article: Sigma Username and Password Encryption for deeper insight into credential handling.

Issue In Sigma, a client needs to be removed from the registered clients list, but the system does not allow deletion through the standard interface. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause The client is likely cross-referenced in one or more of the following: Routesets: The client may be part of a defined communication path. Sigma Servers: The client may be linked to a server configuration. These cross-references prevent deletion to maintain system integrity. Resolution To safely delete the client: Check Routeset References Navigate to: System Setup → Controller Items → Routesets Ensure the client is not referenced in any routeset. Check Sigma Server Associations Navigate to: System Setup → Clients Confirm the client is not linked to any Sigma server. Once all references are removed, the client can be deleted from the list.

Issue There are no built-in tools or utilities available in Sigma to merge lookup table files from multiple sites into a single unified file. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause When consolidating multiple Sigma sites into one, each site may have its own set of lookup tables. Sigma does not provide a native method to merge these tables, requiring manual intervention to avoid data loss or corruption. Resolution To manually merge lookup tables from multiple Sigma sites: Export Lookup Tables from Each Site Open the lookup tables for Site 2, 3, 4, etc. Use the Copy button to copy the data from each required table. Use a Text Editor Paste the copied data into a text editor (e.g., Notepad). Repeat for all tables from each site. Prepare the Final Lookup Table File Open the lookup table for Site 1 (the target site). Create a new table for each merged entry. Copy and paste the data from the text editor into the new table. Important Formatting Notes Start pasting from a vacant line below the last entry to ensure the final line is imported correctly. Avoid blank lines above the data, as this can corrupt the top field. Resolve Conflicts If any tables have conflicting lookup table numbers, assign a new number. Update all associated points to reference the new lookup table number.

Issue Communication with a Sigma controller via its LAN connection is not possible when connected through another controller’s service port. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause When the Sigma system is incomplete or lacks access to a Sigma server: Messages generated by controllers cannot be delivered to the server These messages accumulate in the Alarm Buffers This buildup can block communication between controllers Resolution If the system will operate without a Sigma server, apply the following recommendations: Avoid programming object alarms Do not configure system logging Avoid configuring global objects unless full controller access is guaranteed Create an archive of the controller for backup If the system will be offline for less than 5 days, use Set Controller Mode: Navigate to: System Diagnostics → Options → Set Controller Mode Select the functions to inhibit Set the duration (up to 7200 minutes)

Issue A control object in Sigma is showing WUH (Wind Up Inhibit) as the Reason for State (RFS), but this attribute is not visible or editable in the Object Editor. Product Line Satchwell BAS & Sigma Environment Satchwell BAS & Sigma Cause In legacy BAS systems, Wind Up Inhibit (WUH) was used to prevent integral control action from continuing when the plant was off. During upgrades from BAS to Sigma, this attribute may persist in the control object but is no longer supported or visible in Sigma’s Object Editor. As a result, Sigma or EBO may still display WUH as the RFS, even though it cannot be modified or removed through standard editing. Resolution To resolve the issue: Record the control object’s parameters (e.g., setpoints, PID values, alarm settings). Delete the affected control object from Sigma. Recreate the control object manually in Sigma. Restore the previously recorded parameters to the new object. This process removes the legacy WUH reference and ensures the control object behaves as expected in Sigma.

Issue Installing the Sigma IC-Gen on unsupported OS PlatformsCustomers need to run the Sigma IC-Gen OPC software on Windows 7 64-bit systems, which are not officially supported platforms for this application. Product Line Satchwell BAS & Sigma Environment Sigma IC-Gen and Windows 7 Cause Many sites already have IC-Gen installed, but their PCs/servers are being upgraded. Supported operating systems for Sigma IC-Gen are no longer readily available, prompting the need to test compatibility with Windows 7 64-bit. Resolution Basic testing was conducted to evaluate IC-Gen OPC functionality on Windows 7 64-bit. Key findings include: Installation: The software installs successfully into default directories without errors. Running as a Service: SigmaSvr can run as a service. No taskbar icon is displayed, making it difficult to monitor IC status. IC status can still be viewed from the main Sigma server. Recommended Operation: Run SigmaSvr as an application instead of a service. Refer to the guide: Running Sigma Server as an Application. Shutdown Behavior: The application cannot be closed normally. Use Task Manager → End Task to terminate the program. Functionality Tested: OPC simulator used to generate IO object values. Program objects, alarms, and logging were configured and worked as expected. Limitations: The configuration is not officially supported. Only basic functionality was tested. No capacity or performance testing was performed.

Issue When running SigUpgrade at Sigma Release 4.08, a DeviceCnf.rec file originally created in Release 4.04 fails to upgrade correctly. The file remains in the 4.04 format and is not updated to 4.08. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause In some cases, Sigma 4.04 incorrectly tags newly created DeviceCnf.rec files as "Version 0" instead of the expected "Version 1". This version mismatch prevents direct upgrading to Sigma 4.08. Resolution To successfully upgrade the DeviceCnf.rec file to Sigma 4.08: Perform an intermediate upgrade using one of the following Sigma releases: Release 4.05 – Build 3.42.34 Release 4.05 SP1 – Build 3.42.43 Release 4.05 SP2 – Build 3.42.48 Release 4.05 SEB – Build 3.43.18 Release 4.06 – Build 3.44.14 Release 4.06 SP1 – Build 3.44.16 or 3.44.18 Release 4.07 – Build 3.45.48 Release 4.07 SP1 – Build 3.45.51 Release 4.07 SP2 – Build 3.45.58 Then upgrade to Sigma 4.08.57 using SigUpgrade. This staged upgrade process ensures the DeviceCnf.rec file is correctly versioned and compatible with Sigma 4.08.

Issue ModBMS fails to connect to the Sigma server, displaying the error: "Not monitoring, DDE not init" This prevents ModBMS from polling data from Sigma. Product Line Satchwell BAS & Sigma Environment Sigma ModBMS Cause ModBMS relies on Dynamic Data Exchange (DDE) to communicate with Sigma. Modern Windows operating systems (Windows 7 and later) have deprecated or limited support for legacy DDE services. If the Sigma background process ( SigTop.exe ) is not running, ModBMS cannot initiate DDE communication, resulting in the error. Resolution To restore ModBMS functionality across supported operating systems: Ensure SigTop.exe is running: Navigate to C:\Sigma\Bin\SigTop.exe Create a shortcut and run it manually if not auto-started. Automate startup: Add the shortcut to the Windows Startup folder: Press Win + R , type shell:startup , and place the shortcut there. Verify polling: Once SigTop.exe is running, ModBMS should begin polling Sigma successfully.

Issue Sigma data files from one computer are being opened on another computer with a different Sigma version, potentially causing system instability or data corruption. Product Line Satchwell BAS & Sigma Environment Satchwell Sigma Cause Sigma data files are version-dependent. When a specific Sigma version is installed, only data files created or used with that same version should be accessed. Copying the entire Sigma folder from one version to another may appear to work but can introduce hidden issues due to background tasks and version mismatches. Resolution   Do not copy the entire Sigma folder from one version to another system. Avoid restoring files that were accessed on a different Sigma version back onto the customer’s machine. Use virtual machines to host different Sigma versions if multiple versions are needed for support or testing. Refer to the article “How to Identify the Sigma Version Installed on a Computer” for guidance on matching release and build numbers.

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.