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.  

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