0. TL;DR

In my TESmart HKS402 KVM-based home setup, a newly added 4K monitor began falling back to 1080p @ 60 Hz after a few days, giving me headaches on my daily driver: an Intel NUC with a relatively modest internal GPU.

The most surprising discovery was how critical timing becomes in what appears to be a straightforward dual-monitor setup. The interaction between KVM behavior, monitor firmware, GPU detection logic, and OS configuration created a fragile system that only behaved consistently when precisely tuned.

It turns out that signal order, wake-up timing, and handshake behavior matter just as much as raw hardware capabilities. When both monitors are connected through the KVM, the secondary FullHD monitor often responds faster to HDMI probes, causing the system to prioritize it at boot.

This timing discrepancy explains the observed fallback behavior: the GPU allocates bandwidth for the first detected display, potentially leaving insufficient headroom for the main 4k monitor to initialize at its native 4K resolution.

Here the key steps I took to resolve the issue:

• Set the main 4k monitor (a PA279CRV) to a fixed HDMI input (e.g. HDMI2)
• Set the secondary FullHD monitor (a PA248CRV) in source auto-select mode: This introduced a natural delay in EDID response, helping prioritize the primary display during the handshake process.
• Apply the desired refresh rate manually in Windows settings. Took me some attempts to reset the settings, e.g. deleting the EDID with CRU.exe, and powercycling every device and making direct cable connections with the NUC to get a “fresh” EDID readout, only to indroduce the KVM back into the setup later.

1. Intro – The Setup That Should Have Worked

The test environment consisted of an Intel NUC system equipped with dual HDMI outputs, connected to two ASUS monitors via an HKS402 HDMI/USB KVM switch. The primary monitor, an ASUS PA279CRV, supports 4K resolution and was intended to operate in landscape mode. The secondary monitor, an ASUS PA248CRV, supports a native resolution of 1920×1200 and was configured in portrait orientation.

The objective was to establish a stable dual-monitor configuration where the PA279CRV consistently initialized as the primary display at 3840×2160 resolution, preferably running at 29.97 Hz to remain within the HDMI 2.0 bandwidth constraints imposed by the NUC’s integrated graphics. The KVM was used to facilitate seamless input and peripheral sharing between systems, without sacrificing display quality or configuration stability.

2. The Mystery – Wake-Up Timing and Display Downgrades

During initial testing, the dual-monitor setup produced inconsistent results across system reboots. In several cases, the primary monitor, PA279CRV, failed to initialize at the expected 3840×2160 resolution and instead defaulted to 1920×1080 at 60 Hz. These incidents occurred despite Custom Resolution Utility (CRU) being configured to prioritize a 29.97 Hz refresh rate for bandwidth conservation.

In addition to resolution downgrades, the display ordering within Windows occasionally shifted, with the secondary monitor PA248CRV appearing as the primary display. These irregularities suggested that either the operating system or the integrated GPU was responding to timing variations in monitor availability or EDID detection, rather than honoring CRU-defined preferences.

Attempts to resolve the issue through static configuration alone proved unreliable, prompting a more detailed investigation into timing, cabling, and monitor response behavior.

3. The Investigation – Reproducing, Ruling Out, Rewiring

The troubleshooting process involved a systematic series of tests to isolate variables influencing the inconsistent display behavior. A number of assumptions were evaluated, and multiple configurations were trialed to pinpoint the source of the issue.

Initial steps included enforcing a 29.97 Hz refresh rate at 3840×2160 using Custom Resolution Utility (CRU) and validating that only the desired detailed resolutions and extension blocks were defined. Despite these measures, the system occasionally reverted to a lower resolution during boot.

A simplified test setup was created by removing the secondary display and observing behavior with only the PA279CRV connected directly via HDMI. In this state, the expected resolution and refresh rate consistently applied, suggesting interference only occurred in the dual-monitor configuration or through the KVM.

Several key paths were explored:

• Rebooting with direct cables versus routing through the KVM
• Testing multiple HDMI cables and ports to eliminate signal quality issues
• Power-cycling the KVM and displays to reset potential EDID memory states
• Switching BIOS primary display from DisplayPort to HDMI
• Verifying that fast boot was disabled to allow proper EDID negotiation during POST
• Locking the input on PA279CRV to HDMI2 while allowing PA248CRV to remain in source auto-select mode

Some approaches proved ineffective. For example:

• CRU sort order did not influence the default resolution selected by Windows
• Deleting all 60 Hz entries in CRU did not reliably force 29.97 Hz unless selected manually in the Windows GUI
• BIOS display port priority changes did not prevent fallback behavior when both displays were active

Collectively, these steps clarified that resolution fallback and display reordering were linked more to EDID availability timing than to configuration alone, setting the stage for deeper insights into the role of hardware timing and KVM behavior.

4. Findings – What Actually Happens

Analysis of the testing revealed that the KVM switch introduces a non-negligible delay in EDID signaling, which can interfere with the GPU’s display initialization sequence. When both monitors are connected through the KVM, the PA248CRV often responds faster to HDMI probes, causing the system to prioritize it during boot.

This timing discrepancy explains the observed fallback behavior: the GPU allocates bandwidth for the first detected display, potentially leaving insufficient headroom for the PA279CRV to initialize at its native 4K resolution. As a result, the main display is occasionally downgraded to 1920×1080 at 60 Hz.

Other key findings include:

• Windows defaults to the fastest responding monitor if no explicit primary display is remembered.
• CRU-defined modes are only applied if the associated resolution is already selected or confirmed via the Windows display settings GUI.
• Once a custom refresh rate (e.g., 29.97 Hz) is manually applied through the GUI, Windows tends to retain it across reboots—unless EDID detection order shifts again.
• The physical state of the monitors (e.g., powered off, source cycling) significantly impacts which EDIDs are processed first.
• Fixing the PA279CRV input to HDMI2 and allowing PA248CRV to scan inputs helped preserve correct initialization order.

5. Mitigations – What Works Reliably

Several actions were found to stabilize the configuration and ensure consistent initialization of the primary display at the desired resolution and refresh rate.

• Ensure that the 4k monitor is connected to the “main” NUC output: This model has 1 HDMI and 1 DisplayPort output. The HDMI output is the primary one, so the 4k monitor should be connected to that one.

• Set the main monitor (PA279CRV) to a fixed HDMI input: Disabling automatic input detection on the main monitor reduced EDID delay and ensured faster response during system boot.

• Leave the secondary monitor (PA248CRV) in source auto-select mode: This introduced a natural delay in EDID response, helping prioritize the primary display during the handshake process.

• Apply the desired refresh rate manually in Windows settings: While CRU made the custom mode available, Windows required manual confirmation to consistently apply it on subsequent reboots.

• Use CRU to expose only necessary resolutions: Removing higher refresh rate entries (e.g., 60 Hz) reduced the risk of fallback modes being auto-selected.

• Power-cycle the KVM and maintain stable cable connections: Ensuring the KVM remained powered and the display path unaltered helped preserve EDID consistency between reboots.

• Disable Fast Boot in BIOS: This allowed the GPU sufficient time to read complete EDID data from all connected displays during POST.

• Set BIOS primary display to HDMI: This aligned the firmware preference with the actual cabling and usage scenario, improving display initialization order.

Together, these mitigations established a reliable dual-monitor configuration where the primary monitor retained its intended resolution and refresh rate, even with the additional complexity introduced by the KVM switch.

6. Conclusion – What Surprised Me

The most surprising discovery was how critical timing became in what initially appeared to be a straightforward display setup. The interaction between KVM behavior, monitor firmware, GPU detection logic, and operating system configuration created a fragile system that responded inconsistently unless precisely tuned.

While the KVM switch was expected to serve only as a passive HDMI relay, it significantly influenced EDID propagation timing. In combination with differences in monitor wake-up behavior and input scanning modes, this created a race condition that affected which display was initialized first and how resolution and refresh rates were applied.

Custom Resolution Utility (CRU) proved indispensable for exposing custom refresh rates, but ultimately, these settings were only effective if the GPU received complete and timely EDID data. Manual intervention within Windows remained necessary to reliably select and retain the preferred display configuration.

The lesson for similar dual-monitor environments—especially when bandwidth is constrained—is that signal order, wake-up timing, and handshake behavior matter as much as the raw capabilities of the hardware. A configuration that fails under default behavior can become reliable with deliberate timing offsets and clear input priorities.

This investigation highlights how nuanced low-level display negotiation can be, particularly in mixed setups involving KVMs or multiple high-resolution monitors. Ensuring stability often depends on understanding the interplay between physical hardware timing and software-level policy decisions.

Appendix: Hardware Used

• Intel NUC 11ATKC4 w/ Celeron N5105, 1x HDMI output, 1x DisplayPort output
• ASUS PA279CRV (4K, HDMI2 input, source fixed)
• ASUS PA248CRV (FHD, rotated, source auto-detect)
• KVM Switch: HKS402 HDMI 2.0, USB switching
• Software: CRU 1.5.2, Intel Graphics Command Center, Windows 11

UiPath workflows, defined in .xaml files, can often appear complex and daunting to interpret directly. By transforming these files into pseudocode, you can simplify their logic, making workflows more accessible and easier to document. This post explores a systematic method to parse XAML files and convert them into structured pseudocode, including activity annotations as comments for clarity.

Why Transform XAML Files?

1. Readability: Pseudocode provides a simplified, human-readable representation of workflows.
2. Documentation: Useful for process documentation and sharing workflow logic with non-technical stakeholders.
3. Debugging: Helps in understanding workflow execution flow for debugging or optimization.
4. Learning: Enables new developers to quickly grasp the logic without diving into UiPath Studio.

Example: InjectInProcessQueue.xaml

Let’s walk through an example. Below is the pseudocode representation of the InjectInProcessQueue.xaml file. This file processes email messages, builds a queue, and adds items to it. We include annotations from the XAML file as comments.

Generated Pseudocode

// Sequence: Inject In Process Queue
Sequence "Inject In Process Queue":
    // Log message at the beginning of the process
    Log Message (Level: INFO): "Going to build and fill an in-process queue"

    // Initialize the InProcessQueue
    Assign:
        To: out_InProcessQueue
        Value: New Queue<QueueItem>()

    // For Each: Process each mail in MailmessagesIncoming
    For Each mail in in_MailmessagesIncoming:
        // Annotation: each mail, if it has a Message-ID, that is used as QueueItem.Reference and added to the in-process queue.
        If (mail.Headers.Get("Message-ID") IsNot Nothing) Then:
            // Sequence: Add InProcessQueueItem
            Sequence "AddInProcessQueueItem":
                // Annotation: Initializes InProcessQueueItem by variable scope
                Variable InProcessQueueItem = New QueueItem With {
                    .SpecificContent = New Dictionary(Of String, Object) From {
                        {"foo", "bar"}
                    }
                }

                // Assign the Message-ID to the QueueItem Reference
                Assign:
                    To: InProcessQueueItem.Reference
                    Value: mail.Headers.Get("Message-ID")

                // Add specific content values for the mail
                // Annotation: MailMessage_MessageId, MailMessage_Subject, MailMessage_Body, MailMessage_From, MailMessage_To, MailMessage_Date, etc.
                Multiple Assign SpecificContent:
                    - MailMessage_Subject = mail.Subject
                    - MailMessage_Body = mail.Body
                    - MailMessage_From = mail.From.Address
                    - MailMessage_To = mail.To
                    - MailMessage_Date = mail.Headers.Get("Date")

                // Add the QueueItem to the InProcessQueue
                Invoke Method "Queue.Enqueue":
                    TargetObject: out_InProcessQueue
                    Argument: InProcessQueueItem

    // Log message at the end of the process
    Log Message (Level: TRACE): "Finished building and filling an in-process queue"

The Transformation Process

1. Parsing the XAML File

The XAML file is parsed as an XML document, allowing us to traverse its structure. Each activity is represented as an XML tag, and we extract:

• The activity type (e.g., Sequence, If, ForEach).
• Relevant attributes (e.g., DisplayName, Condition, Arguments).
• Annotations (sap2010:Annotation.AnnotationText) for context.

2. Building a Logical Hierarchy

UiPath workflows are structured hierarchically:

• Activities are nested, reflecting their order and dependencies.
• Pseudocode preserves this hierarchy using indentation.

3. Translating Activities

Each activity is mapped to a corresponding pseudocode construct:

• Sequence → A block of steps.
• If → Conditional statements (If ... Then ... Else).
• ForEach → Loops iterating over collections.
• Assign → Variable assignments.
• InvokeWorkflowFile → Function calls with input and output arguments.
• LogMessage → Log statements.

4. Integrating Annotations

Annotations are extracted and inserted as comments above relevant pseudocode lines. These provide valuable context about the workflow’s purpose.

Why Include Annotations?

Annotations are vital for understanding the logic and intent behind each step. For example:

• Annotation: “Initializes InProcessQueueItem by variable scope”
• Pseudocode Context: This comment clarifies why a variable is initialized.

Annotations turn technical details into meaningful explanations.

Challenges in the Transformation

1. Deep Nesting: Complex workflows with deeply nested activities require careful recursive traversal.

2. Custom Activities: Handling custom or rare activities requires fallback mechanisms to represent them generically.

3. Balancing Detail and Simplicity: The goal is to keep pseudocode readable while retaining essential logic.

Final Thoughts

Transforming UiPath XAML files into pseudocode bridges the gap between technical workflows and high-level understanding. By including annotations and presenting a clean, structured representation, you can make workflows easier to read, debug, and document.

Whether you’re sharing your workflow logic with a team or improving your process documentation, this approach ensures clarity and consistency.

When working on Jekyll plugins, a common requirement is to include a demo site for testing and showcasing functionality. This demo site often resides in a subdirectory (e.g., ./demo) with its own Gemfile, distinct from the plugin’s root Gemfile. Ensuring commands like bundle install and jekyll build execute correctly in this subdirectory while integrating seamlessly into a Rake-based workflow can be challenging, especially on cross-platform setups.

Problem: Subdirectory Context in Rake Tasks

Directly invoking commands like cd demo && bundle install in Rake tasks doesn’t reliably handle environment configurations. Specifically:

• Bundler Context: Commands may still use the root Gemfile.
• Environment Isolation: Switching directories alone doesn’t guarantee the correct environment is loaded, especially on Windows systems.

Solution: Explicit Environment Configuration

By explicitly setting the BUNDLE_GEMFILE environment variable, we can ensure Bundler uses the correct Gemfile for the subdirectory. A helper method centralizes this logic:

def safely_in_demo_dir
  demo_dir = File.join(Dir.pwd, "demo")
  raise "Demo directory not found: #{demo_dir}" unless Dir.exist?(demo_dir)

  ENV['BUNDLE_GEMFILE'] = File.join(demo_dir, "Gemfile")

  Dir.chdir(demo_dir) do
    yield
  end
ensure
  ENV.delete('BUNDLE_GEMFILE')
end

Implementation in Rake Tasks

The helper method integrates seamlessly into tasks:

namespace :demo do
  desc "Build the Jekyll demo site"
  task :build do
    safely_in_demo_dir do
      sh "bundle install"
      sh "bundle exec jekyll build"
    end
  end

  desc "Serve the Jekyll demo site locally"
  task :serve do
    safely_in_demo_dir do
      sh "bundle install"
      sh "bundle exec jekyll serve"
    end
  end
end

Key Benefits

1. Environment Isolation: Ensures all commands execute in the context of the ./demo directory.
2. Cross-Platform Compatibility: Works reliably across Unix-like systems and Windows.
3. Reuse: Centralizes directory handling logic to minimize duplication.

Hyperdeck Shuttle HD HDMI out: HDMI Audio exctrator SD card slot: SD card with playout footage

HDMI Audio exctrator Power: 5V USB HDMI in: Hyperdeck Shuttle HD audio out 3.5mm: TRS cable 1m

Blackmagic ATEM Mini Pro ISO USB out: laptop with Zoom HDMI in 1: HDMI Splitter B HDMI in 2: HDMI matrix HDMI in 3: HDMI Splitter A HDMI in 4: HDMI Audio exctrator

Laptop: Main display: Zoom call HDMI out: HDMI Splitter USB C:

HDMI Splitter A: HDMI out 1: Blackmagic ATEM Mini Pro ISO HDMI out 2: Wacom One pen display

HDMI Splitter B: HDMI in: camera HDMI out 1: USB HDMI Adapter HDMI out 2: Blackmagic ATEM Mini Pro ISO

playout: Rodcaster in 2: line level, unmuted, fader up Rodecaster Pro ii Chat Fader: unmuted, fader up Zoom: Share Advanced Second camera, no sound, optimized for video if possible Zoom: optionally original sound on ATEM Mini: playout from green to red Shuttle: clip on, stop on, mov selected, press playout

https://docs.uipath.com/sdk/other/latest/developer-guide/creating-activities-with-code

choco install visualstudio2022community --package-parameters "--add Microsoft.VisualStudio.Workload.ManagedDesktop --add Microsoft.VisualStudio.Workload.NetWeb --add Microsoft.VisualStudio.Workload.VisualStudioExtension"
choco install dotnet-6.0-sdk
choco install dotnet-6.0-runtime
choco install nuget.commandline

Development Settings: Visual C# or General Development

official feed

https://github.com/UiPath/Community.Activities/tree/develop/Activities/Templates/UiPath.Activities.Template/VisualStudio

https://docs.uipath.com/sdk/other/latest/developer-guide/building-workflow-analyzer-rules

When building custom rules, target the .NET version depending on the version of Studio and the project compatibility:

Studio 2021.4 and earlier: .NET Framework 4.6.1. Studio 2021.10.6 and later: .NET Framework 4.6.1 for Windows-legacy projects, .NET 6 for Windows and cross-platform projects.

Validate

dotnet --list-sdks

Decisions

targetFramework: Windows only?

solutions

Class Library (.NET Framework) C# Windows .NET 6.0

• System.Exception: These are unexpected errors (e.g., network issues, null references).
• BusinessRuleException: These represent logical or business-specific validation errors (e.g., data inconsistencies).

With the ReFramework’s top-level error handling, exceptions thrown by activities do bubble up and are captured. So, why would you still consider using Try-Catch blocks within specific workflow segments? Here are key reasons:

1. Localized Error Handling and Recovery

• If you have specific steps where certain errors are expected or manageable, a Try-Catch block allows you to handle those errors locally, without allowing them to bubble up and trigger a full transaction retry or transition to a new state.
• For instance, you might expect occasional network timeouts when connecting to a database or web API. With a Try-Catch, you could log the error and retry the operation locally rather than failing the entire transaction.
• This localized handling is beneficial when errors are recoverable without needing to go back to the start of the ReFramework process.

2. Customized Logging and Information Capture

• The ReFramework does provide logging, but Try-Catch blocks within specific activities allow for more granular logs and context-specific information.
• You can capture additional details about the error’s context (like the email ID being processed or the specific data item) and log those details right in the Catch block. This can make debugging much easier when reviewing logs.

3. Conditional Continuation or Skip Logic

• In some cases, you may want to skip a specific item and continue with the next one in a loop rather than failing the entire transaction. For example, when processing a list of emails, if one email is corrupt or missing data, a Try-Catch around that email processing step allows you to skip just that email and continue with the rest.
• Without a Try-Catch, any error would bubble up, potentially causing the whole batch to fail or requiring the entire transaction to restart.

4. Selective Retries within the Activity

• As previously discussed, you can implement manual retry logic with a loop combined with a Try-Catch block for specific actions prone to transient errors.
• This allows you to retry certain actions (e.g., fetching emails from a server) before deciding to let the error bubble up, which can improve the robustness of activities that rely on external systems. This is especially useful for transient errors where a retry is often successful, such as network timeouts.

5. Preventing Unnecessary Transaction Retries or Failures

• If certain errors are not critical, handling them locally prevents them from bubbling up and causing an unnecessary transaction retry in the ReFramework.
• For example, if you’re reading data from an optional source (like an API that might occasionally fail) but can still continue with partial data, handling this locally avoids triggering a larger error flow.

Summary

Using Try-Catch blocks in specific parts of a workflow within the ReFramework can provide more granular control, localized recovery, custom logging, and conditional continuation. While the ReFramework will handle errors that bubble up, adding Try-Catch blocks in critical segments offers additional resilience, especially for errors that can be handled without escalating to the ReFramework’s top-level error handling.

1. Functionality Implemented in Orchestrator

Orchestrator provides several high-level functionalities for managing queues and transactions, including:

• Queue Management:
  • Orchestrator allows users to create and configure queues, where each queue holds a list of items (transactions) to be processed by robots.
  • Within Orchestrator, queues can have retry policies, SLA deadlines, priorities, and can be monitored for completion, errors, and throughput.
• Transaction Handling:
  • Orchestrator automatically tracks the status of each transaction item in a queue. Statuses include New, In Progress, Successful, Failed, and Abandoned.
  • Orchestrator also handles retry logic if configured, so items that encounter System.Exception errors can be automatically retried without additional logic in the workflow.
• Logging and Analytics:
  • Each transaction’s outcome (success or failure) is logged in Orchestrator, allowing users to view detailed reports and analyze process performance.
  • Orchestrator logs each error message and allows filtering and exporting of transaction records for reporting and analysis.

• Error Handling:

  • Orchestrator differentiates between Application/System Exceptions (e.g., network errors) and BusinessRuleExceptions (e.g., data validation issues), allowing developers to configure separate handling and retry strategies for Application/System Exceptions.
• Scalability and Parallel Processing:
  • Queues in Orchestrator support distributed processing, enabling multiple robots to work on the same queue and process items in parallel. This allows for greater scalability and improved processing efficiency.

In summary, Orchestrator manages the overall lifecycle, logging, and retry policies of queue items at a high level, as well as the status of each transaction item.

2. Data Types and Methods/Properties in UiPath

Within UiPath workflows, specific data types and methods are used to interact with Orchestrator queues. Key data types include:

• QueueItem:

  • QueueItem is the main data type used to represent individual items retrieved from an Orchestrator queue.
  • Properties:
    • SpecificContent: A Dictionary(Of String, Object) that holds the main data payload of the transaction item. This property is used to access custom fields within each transaction (e.g., "InvoiceNumber", "Amount").
    • Output: Another dictionary used to store the results or outputs of the transaction that can be pushed back to Orchestrator.
    • Progress: A string property that represents the current progress status of the transaction. This can be updated throughout the processing of an item.
    • Status: Indicates the current status of the QueueItem in Orchestrator (e.g., New, InProgress, Successful), but it is read-only in the UiPath workflow. The status is managed by Orchestrator itself.
  • Methods:
    • SetTransactionStatus: Allows the robot to set the outcome of the transaction (Success, Fail with Application Exception, or Fail with BusinessRuleException) and mark it appropriately in Orchestrator.

• Orchestrator API Methods for Queue Items:

  • Get Transaction Item: Retrieves the next available QueueItem from the specified queue in Orchestrator. This method is used in the Get Transaction Data state in ReFramework.
  • Add Queue Item: Adds a new item to an Orchestrator queue. This is used in processes where robots need to create new work items dynamically.
  • Set Transaction Status: Updates the status of a QueueItem after processing it. This method can set a transaction to Successful, Failed (with either System.Exception or BusinessRuleException).

• DataRow as an Alternative:

  • In cases where processes use Excel files, databases, or data tables as transaction sources instead of Orchestrator queues, a DataRow can represent each transaction item.
  • Properties:
    • Item(columnName): Accesses a specific column value within the row, which is similar to accessing SpecificContent in a QueueItem.
    • Table: References the DataTable that the DataRow belongs to, useful for relational operations within in-memory data.
  • DataRow is typically processed similarly to QueueItem within the ReFramework, although without Orchestrator’s automatic status handling and retry features.

Differences between Orchestrator Functionality and UiPath Data Types

Error Handling in Orchestrator for Queue Items

In Orchestrator, error handling and retry logic for QueueItems works as follows:

1. System.Exception (Application Exception):

   • When a System.Exception (or any other exception that’s not a BusinessRuleException) occurs during the processing of a QueueItem, Orchestrator can retry the transaction if retry logic is enabled for the queue.
   • Orchestrator’s Queue settings include an option to configure the number of retries for items that fail due to System.Exception.
   • If a System.Exception occurs and retries are enabled, Orchestrator will automatically create a new attempt for that transaction item after a specified interval. Each attempt is treated as a new QueueItem, but Orchestrator tracks the retry count.
   • The retry limit is configurable in Orchestrator’s Queue settings, allowing you to control how many times a failed transaction should be retried.

2. BusinessRuleException:

   • When a BusinessRuleException is thrown in the UiPath workflow, Orchestrator does not retry the item, regardless of the Queue’s retry settings.
   • A BusinessRuleException is treated as a non-retriable failure because it typically indicates a logical or data-related issue that cannot be resolved by simply retrying (e.g., missing required information, invalid data formats, or violated business rules).
   • In the ReFramework, BusinessRuleException is used to indicate that a transaction failed due to a predictable and irrecoverable condition, and retrying the item would not change the outcome.
   • Instead of retrying, Orchestrator will mark the QueueItem as Failed and log the BusinessRuleException details, allowing the item to be reviewed or handled later as needed.

Why This Distinction Matters

This distinction is important because it allows developers to classify errors based on their recoverability:

• System.Exceptions often represent transient or environmental issues (like network timeouts or file access errors), where a retry might succeed.
• BusinessRuleExceptions represent logical conditions or validation errors that are unlikely to change on a retry, making it more efficient to skip retries for these cases.

In summary, only System.Exception errors are eligible for retry in Orchestrator if configured. BusinessRuleException items are logged as failed without retry attempts, in alignment with their nature as non-recoverable errors.

Summary

• System.Exception: Orchestrator can automatically retry these exceptions if retries are enabled in the Queue settings.

• BusinessRuleException: Orchestrator does not retry items that fail due to BusinessRuleException. These are treated as final failures without retry.

• Orchestrator provides high-level management for the queue lifecycle, transaction status, error handling, retry logic, and logging.
• UiPath Data Types (QueueItem) provide access to the specific transaction data and allow local handling of item-specific operations but rely on Orchestrator for overarching control over the queue and item status.

These aspects work together to allow the ReFramework to handle large, distributed, and potentially error-prone processes in a reliable, manageable, and scalable way.

https://visualstudio.microsoft.com/visual-cpp-build-tools/

python -m venv O:\venv\audiovideo O:\venv\audiovideo\Scripts\Activate.ps1 O:\venv\audiovideo\Scripts\pip3.exe install pyatem O:\venv\audiovideo\Scripts\pip3.exe install streamdeck

1. Motherboard & BIOS Support: Enable WoL in BIOS/UEFI settings.
2. Network Interface Card (NIC) Support: NIC must support WoL; enable it in device properties.
3. Ethernet Connection: WoL typically requires a wired Ethernet connection.
4. Power Supply: System should provide standby power (S5 state) to the NIC.
5. Network Configuration: Correct MAC address, subnet, and port settings for the Wake-on-LAN packet.
6. Software: Tool to send the “magic packet” (e.g., Depicus, WakeMeOnLan).

Ensure proper configuration on the OS (e.g., Windows, Linux).

1. Enable WoL on Target Device:
   • Access BIOS or OS settings of the target device.
   • Enable “Wake on LAN” (WoL).
2. Install Required Package on OpenWRT:

   opkg update
   opkg install etherwake
   

3. Send WoL Packet from OpenWRT:

   etherwake -b <MAC_ADDRESS>
   

   Replace <MAC_ADDRESS> with the target device’s MAC address.

4. Automate WoL Using OpenWRT Web UI (Optional):
   • Go to System > Startup.
   • Add a new script to send WoL command on startup. Example:

     /usr/bin/etherwake -b <MAC_ADDRESS>
     

5. Ensure Network Setup:
   • Target device must be connected to the same subnet.
   • Proper forwarding/routing if WoL is sent across subnets.
6. Alternative: Web Interface WoL Plugin
   • Install luci-app-wol:

     opkg install luci-app-wol
     

   • Access via Services > Wake on LAN on the OpenWRT web UI.

To execute the etherwake command via SSH, you can set up an alias or use the ProxyCommand option in the .ssh/config file. Here’s how:

1. Edit .ssh/config:

   vim ~/.ssh/config
   

2. Add the Following Configuration:

   Host wol-alias
       HostName <OpenWRT_IP>
       User <OpenWRT_Username>
       RemoteCommand /usr/bin/etherwake -b <MAC_ADDRESS>
       ExitOnForwardFailure yes
   

3. Usage:

   ssh wol-alias
   

Explanation:

• Host wol-alias: Create a custom alias (wol-alias) for the command.
• HostName: IP address of your OpenWRT device.
• User: Username to log in to OpenWRT.
• RemoteCommand: Executes the etherwake command when you SSH into wol-alias.
• ExitOnForwardFailure: Ensures the session exits after the command runs.

Note: Replace <OpenWRT_IP>, <OpenWRT_Username>, and <MAC_ADDRESS> with actual values.

The Input-Processing-Output (IPO) Model is a foundational concept in computer science and software development. It describes the flow of data through a system, beginning with data input, followed by processing, and resulting in output. In this article, we’ll break down the IPO model, with a focus on where common programming methods such as getters and setters fit into the workflow.

IPO Model Overview

The IPO model outlines three key stages that data passes through:

1. Input: Data is collected and validated from various sources.
2. Processing: Collected data is transformed, computed, and prepared for output.
3. Output: Processed data is delivered, logged, and outputted to the relevant destination.

These stages can be further broken down into substeps, each critical for ensuring efficient and accurate data flow. The table below details the key steps in each stage, along with common naming conventions for functions that carry out these steps.

Visualizing the IPO Process

To further enhance understanding, we can represent the IPO model as a simple ASCII diagram, showing how data flows between Input, Processing, and Output, and indicating where getters and setters typically apply.

+----------------------------+      +----------------------------+      +----------------------------+
|          Input              |      |         Processing          |      |           Output            |
+----------------------------+      +----------------------------+      +----------------------------+
| 1.1 Data Collection         |----->| 2.1 Data Transformation     |----->| 3.1 Data Formatting         |
|   - Getter: get_user_data() |      |   - Setter: set_user_data() |      |   - format_output()         |
+----------------------------+      +----------------------------+      +----------------------------+
| 1.2 Data Validation         |----->| 2.2 Computation             |----->| 3.2 Output Delivery         |
|   - validate_data()         |      |   - compute_results()       |      |   - deliver_output()        |
+----------------------------+      +----------------------------+      +----------------------------+
| 1.3 Auth & Authorization    |----->| 2.3 Intermediate Storage    |----->| 3.3 Logging & Auditing      |
|   - authorize_user()        |      |   - store_temp_results()    |      |   - log_output()            |
+----------------------------+      +----------------------------+      +----------------------------+
| 1.4 Data Preprocessing      |----->| 2.4 Validate Processed Data |----->| 3.4 Feedback Collection     |
|   - Setter: preprocess_data |      |   - validate_output_data()  |      |   - collect_feedback()      |
+----------------------------+      +----------------------------+      +----------------------------+

                         (Getter: Retrieves data)                  (Setter: Modifies data)

In this diagram:

• The Input stage includes data collection and validation, where getters like get_user_data() retrieve data.
• The Processing stage includes data transformation and storage, where setters like set_user_data() modify data as it’s being processed.
• Finally, the Output stage formats and delivers the data, often logging and gathering feedback for continuous improvement.

Getters and Setters in the IPO Model

Getters and setters are fundamental in object-oriented programming and are used to access and modify object properties:

• Getters: These methods retrieve (or “get”) data from an object. For instance, in the Input phase, the method get_user_data() might be responsible for fetching user input from a form or database.
• Setters: These methods modify (or “set”) data within an object. During the Processing phase, set_user_data() could update the user information with computed or transformed values before proceeding to the output.

Conclusion

The IPO model provides a clear framework for understanding how data moves through a system, from input to processing to output. By breaking down each phase into substeps and applying modern development techniques such as getters and setters, developers can ensure efficient, secure, and scalable data handling in their applications.

For more detailed breakdowns and examples, be sure to explore related posts on object-oriented programming patterns and best practices for data handling.