All pages
Powered by GitBook
1 of 13

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

Loading...

How to use DIO

Applicable to: K300 / K700 series systems

This article provides specific examples for the K300 and K700 systems. Other models may not be compatible with the exact software packages used. Check out the available documentation directly on your system’s Support page. Checkout the newer generation of the K300 and K700 systems here:

What is DIO?

DIO, or Digital Input/Output, is a simple form of interface used in a wide range of systems to effectively relay digital signals from sensors, transducers and mechanical equipment to other electrical circuits and devices.

Sometimes referred to as General Purpose Input/Output (GPIO), DIO utilizes a logic signal to transfer information. Unlike an analog signal which might be comprised of varying voltages, the digital signals used by DIO have two possible values and are generally represented as either OFF or ON. Think of analog signals as those you might use a knob or dial to set, while digital signals would most often be controlled by a switch. This makes it ideal for sensing switch contacts, reacting to motion sensors, limit switches, operator buttons or machinery status indicators. It can also be used to control indicator lights, small relays or PLCs within equipment.

Read more about DIO basics on our blog.

Tutorial

Prerequisites

Install and the .

This tutorial will outline a quick and simple test for the Karbon K300 and K700 series’ Digital I/O. We’ll wire the DIO port and run a simple python script to control an LED during a button press event on an input pin

The Karbon Digital I/O port is not powered and will need to have power supplied to the port. The DIO port is able to handle 5-36VDC on the K300 and 5-48VDC on the K700.

For this tutorial we’ll borrow the USB port’s 5V and GND pins and splice a spare USB cable for use in the DIO port.

Once the power is supplied to the DIO port we’ll need to wire up our input. Since the Input of the DIO are pulled high when floating, we’ll wire an input to ground so that pressing the button will pull the input low.

We’ll wire up an LED to output 3 and to the supplied 5V. NOTE: most LEDs will need to have a resistor in line from the power rail to limit the current supplied to the LED. check the details of the current limits of the LED you are using.

To validate the input is working, the can be run to monitor the behavior of the inputs and outputs.

Running the karbon tool with the `op dio-state’ will print out what the input and output states are. The output bit order is I0 I1 I2 I3 O0 O1 O2 O3 Since we have the button wired to Input 3 we should expect 11110000 and then 11100000 when the command is ran while the button is pressed.

Now that that input can be read from the MCU, the output portion can be configured.

We can run a python script that will react to Input 3 being pulled low with the button press and set output 3 to high and turn the LED on.

Save the following script as dio.py and run it with the command python3 dio.py

Running the script will show configuration info and then print out information when the button is pressed and depressed.

The button press will set input 3 to high, triggering the python script to set output 3 high and turn on the LED.

import pykarbon.terminal as pkt 

def callback_fn(arg):
    if arg[3] == '0': #check if 3rd item from popdata() is 0
        print("DI 3 --> LOW ", arg)
        return True #return True to dev.set_do. sets output high
    else: #if 3rd item from popdat() is anything other than 0
        print("DI 3 --> HIGH", arg) 
        return False #return Flase to set_do. sets output low

i = 0

with pkt.Session() as dev:
    dev.update_info(print_info=True) # Update and print configuration info

    dev.set_do(0, False) # Set digital output zero low

    while True: #create loop that runs forever
        line = dev.popdata() #popdata will print out data in the queue
        if line: 
            dev.set_do(0, callback_fn(line)) #returns data from queue as argument for use by callback_fn
Python3
Pykarbon library
karbon CLI utility

More

Cincoze URM01 Rackmount Adapter Installation

Installation Guide for Cincoze URM01 rackmount adapter kit (8.4" to 21.5" Panel PCs)

Installation Guide:

Cincoze Rack Mounting Kit - Installation Guide.pdf
PDF · 404KB
Open

How to Generate an Online Quote

A guide for creating a product quote from the OnLogic website.

At OnLogic, we aim to provide the tools you need to move your projects forward efficiently. Whether you are an existing customer looking to expedite procurement or a new visitor to the OnLogic website who needs a formal document for budget approval, you can generate a professional quote directly through our website.

Step 1: Configure your solution

Navigate to the product page of the system that meets your requirements. Scroll to the Configure & Buy section to select your specific components, including processor, memory, storage, and operating system.

Once your configuration is complete, click the Add to Cart button in the summary box.

Step 2: Initiate the quote process

After adding the items to your cart, you will be redirected to the Shopping Cart page. Take a moment to review your selected components and adjust system quantity if desired. To generate a quote document instead of checking out, locate the Order Summary box on the right and click the orange outlined Get Quote button.

Step 3: Enter your details

You may sign in to your OnLogic account to use saved addresses, or select Continue as Guest to proceed without logging in.

To ensure your quote is accurate and reaches the right person, complete the following sections:

  • Email Confirmation: Enter the address where you would like to receive the PDF quote.

  • Shipping Information: Provide the delivery address. This allows our system to calculate regional taxes and shipping rates.

  • Shipping Method: Select your preferred shipping speed.

Review your information and click Generate Quote. A confirmation screen will appear with your unique quote reference number.

Your formal PDF quote will be delivered to your inbox, typically within 10 minutes.

When you are ready to proceed with your order, simply open your quote email and click the View Cart button. This will automatically reload your exact configuration onto our website, allowing you to complete your purchase.

If you prefer you may also contact your dedicated account manager or our technical sales team to finalize your order. Please note: orders placed through our sales team do not qualify for free shipping.

  • Pricing and Availability: Because market prices for components like RAM and storage can be volatile, online quotes do not lock in pricing or stock. We recommend completing your order promptly to ensure the best pricing and availability.

  • Free Shipping: While many online orders qualify for free shipping, this option is only available during checkout. If your final online purchase meets the criteria for free shipping, it will be applied during the final checkout process.

  • Volume Discounts: This tool provides our standard retail pricing. If your project requires volume-specific discounts, please use the Request Volume Quote link on the product page or contact our technical sales team directly to discuss your requirements.

System Serial Number Retrieval

How to locate your system's serial number via physical labels or software commands

Serial Number Retrieval

Physical Label

The OnLogic serial number can be found on a label applied to the bottom of the system, or the rear of the display for Panel PCs. Our serial numbers will begin with U or E, followed by 6 digits.

Since 2018, OnLogic has written the serial number of the system into the SMBIOS data on all products except for Raspberry Pi systems (i.e the Factor Series). This means that the serial number can be retrieved without physically looking at the unit. This can be useful if the system is deployed in the field or mounted in an enclosure.

*Note that the Factor Series systems (FR201 and FR202) do not have a BIOS or SMBIOS, and do not support the below software commands. The systems’ serial number need to be identified via the physical label on the bottom of the case.

Windows

Open CMD from the start menu and run the following commands. One of them should return the correct serial.

WMIC BIOS get serialnumber
WMIC baseboard get serialnumber

Linux

Run the following commands in terminal.

Barrel Jack Zip Tie Use

How to use the barrel jack retention ziptie

Instructions:

  • Prepare Knockout: Use a screwdriver to push out the designated knockout (typically marked with a padlock symbol). Ensure the piece is removed from the system.

  • Insert Zip Tie: Push the retaining zip tie (from accessory kit) into the hole, ribbed side facing upward.

  • Attach Clip: Attach the clip to the power supply's cable.

  • Secure Cable: Thread the zip tie through the clip's hole and snug it into place.

OnLogic Warranty Repair Process

This guide outlines the steps for returning your OnLogic system for warranty repair.

Contact our Technical Support team via phone or email, providing your system's serial number (starts with U or E, followed by 6 digits) and details of the issue. We may offer remote troubleshooting or ask for more information.

  • United States:

    • (802) 861 – 2300

Payment Method: Choose your intended payment type. This selection is for quoting accuracy and does not charge your account or represent a commitment to purchase.

Step 4: Finalize and receive your quote

Moving from quote to order

Important considerations

dmidecode -s system-serial-number
cat /sys/devices/virtual/dmi/id/product_serial

support@onlogic.com

  • The Netherlands:

    • +31 88 5200 702

    • support@onlogic.eu

  • If a return is necessary, we will issue an RMA number and shipping details. An RMA number is required for all returns. Customers are responsible for shipping costs and bear the risk of loss for returned items.

    • Packaging: Original packaging is ideal (required for refunds). Otherwise, use your own packaging, ensuring at least 2 inches of padding on all sides. Avoid airbags and packing peanuts. Place bare components (e.g., motherboards, RAM) in static-safe bags.

    Upon arrival at OnLogic, repairs are typically completed within 5 business days.

    We will:

    1. Attempt to reproduce the reported issue.

    2. Use diagnostic tools to identify the root cause.

    3. Replace faulty hardware (if applicable) and re-test.

      • Note: The HDD/SSD may be erased during troubleshooting.

    4. Perform the same thorough production test run on new units to ensure full functionality.

    A repair summary detailing our findings and the repairs made will be sent to you and enclosed with the returned system.

    • Failed components are tracked internally for quality improvement and supplier follow-up.

    1. Initiate Support Request

    2. System Return (RMA)

    3. Repair & Diagnostics

    4. Repair Summary & Return

    AWS Kinesis Video Streams Integration (Axial Edge Server)

    Deploying the OnLogic Axial Edge Server with Intel 13th Gen Core i Processors and Intel Arc dGPU for video streaming to AWS Kinesis Video Streams

    1- Overview

    The OnLogic Axial Edge Server for KVS is designed to simplify the challenges of video streaming for edge to cloud inference applications. By using OnLogic’s 1U Axial Edge Server powered by Intel 13th Gen Core i Processors and Intel Arc discrete GPU, you can leverage edge processing to supercharge your vision applications. The OnLogic Axial Edge Server for KVS is tested for compatibility with KVS to easily integrate into existing KVS workflows.

    Solution Reference Architecture

    2- Hardware

    Information

    A full range of resources are available for your OnLogic Axial Edge Server for KVS within the AC101 Product Documentation Page.

    Package Contents

    Each OnLogic AC101 includes the computer itself, depending on chosen accessories the following may be included. Accessories may be purchased separately on onlogic.com where stated.

    • Mounting hardware for rack deployments or wall mounting hardware.

    • C13 to AC Outlet Power Cables (Selection available for US/EU/UK)

    While the configuration is selectable by the user, the reference platform tested contained the following specifications. System requirements will depend on # of streams, local storage requirements, stream specifications (frame rate/resolution/etc.)

    CPU: i7-13700E | GPU: Intel Arc Pro A60 | RAM: 16GB | Storage 128GB | Ubuntu 22.04 LTS

    OnLogic Axial Edge Server for KVS is designed to integrate with existing and new video streaming applications and are only a part of the solution. The following items are required to take advantage of the solution:

    • IP Capable Video Cameras (RTSP)

    • Edge networking equipment capable of providing video streams to the AC101. The AC101 is equipped with 10GbE and 1GbE LAN. For multi-stream deployments a network switch is recommended.

    • Users may opt to use integrated storage on AC101 if chosen for Offline video storage, however users may also want to consider on-site NAS if consuming large amounts of data. Full specifications on in-server storage options can be found on the AC101 product page.

    The following uses files available from OnLogic Support team. Please use the available download link, this also includes sample video files (.mp4) for ease of use. The solution can run either on CPU or GPU. Files are included for both.

    1. On CPU host, install Docker: https://docs.docker.com/engine/install/ubuntu/ .

      1. Perform post-install steps so you do not need to run Docker with `sudo `

    2. Copy *Dockerfile*, *build.sh*, *run.sh*, *C0012_1080p25.mp4* to CPU host

    For in-depth support on the OnLogic AC101, you can visit the .

    1. Your system will come equipped with either a single or redundant power supply along with AC power cables. You will need to plug either a single or both (redundant only) AC power cables into the system in order to power on the system.

    2. In order to set up the system you’ll need a keyboard, mouse, and display in order to perform the first time setup. Start the system by pressing the power button (if you selected auto-power on your system will start when plugged in).

    3. Install Ubuntu 22.04 LTS or your operating system of choice (If you have chose not to have OnLogic pre-install it)

    • Ensure you are using a PC that is rated for your environment: operating temperature, input voltage, shock, vibration

    • Ensure to adhere to any certification requirements for IT equipment: Class 1 Division 2, UL Requirements, etc.

    • Ensure systems are installed properly following instruction materials when installing into racks or secured using wall mount.

    Users that have appropriate expertise should expect device setup to take less than 30 minutes for your device to be ready to connect to your AWS KVS instance depending on network availability.

    As the solution does not include any production environments in AWS cloud as such the user is responsible for setup, deployment, and maintenance of their AWS applications and following AWS best practices to ensure operational excellence and security. OnLogic Axial Edge Server for KVS can be used in any AWS Region or Availability Zone that supports KVS. Please ensure to adhere to any importation requirements if deploying outside the United States or European Union as there may be additional regulatory requirements for IT equipment.

    To learn more about AWS Kinesis Video Streams, see and .

    OnLogic does not offer technical support for software issues related to AWS services. Contact your technology integration resources or partner to help resolve software issues. For answers to common questions and preliminary troubleshooting, please browse our comprehensive support site.

    For Hardware support you can contact the OnLogic support team at or 802-214-7565 ext. 2 (8:30 AM to 5:00 PM EST). For responses via email and voicemail we strive to respond the same business day. If received after normal business hours we will respond in the order that they were received. Once an RMA is received normal turnaround when parts are available is 5 business days

    All OnLogic systems come with a standard 2 year warranty (unless otherwise stated). For additional information the following resources are available:

    Document Version
    Date
    Changes

    Microcontroller (MCU) Usage

    Applicable to: K300 / K700 series systems

    Karbon K300 and K700 series computers have an internal microcontroller (MCU) that manages features like DIO, CAN, Ignition sensing, and more. This microcontroller can be managed by sending commands to two virtual serial ports from the operating system.

    This article will outline several methods for interfacing with the system’s MCU. It also provides a complete list of the exact command strings supported by the microcontroller.

    Note: We recommend making sure your before trying any of the below.

    The Karbon command line utility is a straightforward method for managing all core microcontroller functionality. You can download the utility for, and use it to communicate directly with the onboard MCU.

    Serial Port Setup & Communication

    Set up, test, and establish serial communication between devices on Windows and Linux, including loopback testing and pinout verification.

    Begin Basic setup by determining the pinout of the devices that will be connected.

    In this example we will connect a K300 running Ubuntu to another K300 running Windows 10.

    Using the K300 Manual, we can determine that the Transmit (Tx) pin is 2, the Receive (Rx) pin is 3 and the Ground (GND) pin is 5.

    Before connecting the two devices we can run a loopback test to determine the address of the physical port we are using.

    This can be done using a COM loop back device, or by using jumper cables to connect the Tx pin to Rx pin and the GND pin to a ground source. Please note it is best practice to use another COM port’s GND pin to ground the port running the loop back test. In a pinch, the COM port’s shield can be used, but it is not guaranteed to be a viable ground point and may result in communication issues.

    User provided edge AI inference application. The user should be able to optimize using the Intel OpenVINO toolkit to take full advantage of hardware.

  • Edge to Cloud networking to AWS Cloud. The reference architecture for the solution recommends a 5G Modem, but hardwired connectivity is also sufficient.

  • User maintained AWS EC2 instances for KVS and storage platform of their choice such as S3 Buckets.

  • execute “build.sh” to start building the docker container
  • When Docker build is complete, open up the “run.sh”, enter AWS credentials values for environmental variables `AWS_ACCESS_KEY_ID`, `AWS_SECRET_ACCESS_KEY` and `AWS_DEFAULT_REGION` fields.

  • Update the `-w` to your desired working directory. This will be the directory the Docker container will be in when launched

  • Enter the Docker container by executing `run.sh`

  • CPU ONLY: Launch the demo with the command `/opt/demo/kvsWebrtcClientMasterGstSample Intel-DLStreamer-Ch` where `kvsWebrtcClientMasterGstSample` is the AWS KVS WebRTC C SDK demo application and `Intel-DLStreamer-Ch` is the WebRTC Signaling channel name.

  • Launch a web brower on the local host or remote platform and enter the following address: https://awslabs.github.io/amazon-kinesis-video-streams-webrtc-sdk-js/examples/index.html. Make sure the enter the correct AWS region, Access key and Secret key. The channel name will be `Intel-DLStreamer-Ch`.

  • Follow the instructions outlined in section 3 (Deployment Setup).

    Ensure installation technicians are properly trained in setting up devices on site
  • Prototype before field installation of larger deployments

  • 1.0

    11.18.24

    Initial Release

    User Provided Items

    3- Deployment Setup

    Host Setup

    4- Edge Server Setup

    Device Setup

    Deployment Best Practices

    5- About Kinesis Video Streams

    6- Troubleshooting

    7- Revision History

    https://docs.docker.com/engine/install/linux-postinstall/
    Product Documentation Page
    Kinesis Video Streams: How it Works
    Getting started with Amazon Kinesis Video Streams
    support@onlogic.com
    Warranty Information
    OnLogic Terms and Conditions

    Windows

    Linux

    > karbon.exe op version

    $ sudo ./karbon op version

    Complete instructions on using the utility are included as part of the download package. This utility may also be used to update the microcontroller’s firmware version.

    The Pykarbon module provides a set of tools for interfacing with the hardware devices on OnLogic’s ‘Karbon’ series industrial PCs. These interfaces include the onboard CAN bus, Digital IO, and other hardware devices.

    The goal of the Pykarbon package is to provide a simple, powerful base platform that will allow users to quickly and easily integrate a Karbon into their own application.

    The tools in the Pykarbon package are designed to work with the Karbon series rugged industrial computers; this will not work for more generalized systems.

    Pykarbon offers a number of tools for automating and using Karbon series hardware interfaces. These include:

    • CAN and DIO background data monitoring

    • Exporting logged data to .csv

    • Registering and making functions calls based on these bus events:

      • CAN data IDs

      • Digital Input Events

      • DIO Bus States

    • Automated CAN message response to registered IDs

    • Automated setting of Digital Output states

    • Automatic CAN baudrate detection

    • Updating user configuration information:

      • Ignition sense enable/disable

      • Power timing configurations

    • Firmware update

    You will need to install Python 3 prior to following this guide.

    To get started with Pykarbon, follow these steps:

    1. Open up a terminal and run:

    1. Launch a python shell with:

    1. In the python shell, import pykarbon with:

    1. And finally create a control object using:

    1. If all went well, you should now be ready to control a variety of systems, but for now let’s just print out some configuration information:

    1. And close our session:

    After the initial setup, visit our Pykarbon Github page to begin using the Pykarbon module for your Karbon series rugged PC.

    • Download and install the latest version of the PuTTY tool. Download Link

    • Open device manager and look for the USB serial devices.

    • Note their COM numbers, typically 4 and 5.

    • Open PuTTY and configure these options

    1. Select the serial option

    2. Change the COM number to match device manager, typically COM4

    3. Click on default settings

    4. Click Save

    5. Click open

    This configures PuTTY to automatically choose the correct options next time you run it.

    • Type config and press enter. The terminal should respond by printing out the current configuration. You may then enter commands from the next section.

    • If config does not work, try using the other COM port number from device manager.

    • Install PuTTY

    Note: If installing from a live CD, you will need to enable the multiverse/universe repositories

    • Run PuTTY as root

    • Set the options shown

    1. Select the serial option

    2. Change the COM device to ttyACM1

    3. Click on default settings

    4. Click Save

    5. Click open

    This configures PuTTY to automatically choose the correct options next time you run it.

    • Type config and press enter. The terminal should respond by printing out the current configuration. You may then enter commands from the next section.

    • If config does not work, try using other com ports from /dev

    The serial terminal can report various system information to the host. This covers firmware version and build date, alongside physical and electrical status information. For instance, the K700 can report the current system input voltage, internal temperature, and internal humidity.

    The available information is system dependent, and is not unified across all Karbon systems.

    Commands for reporting this information include:

    The Karbon series has several configuration options that effect system behavior. These primarily include automotive features, like ignition sensing and battery drain protection.

    The system can store up to four different configurations, one of which will be loaded as default when the system is first powered on. This allows for temporarily disabling automotive features, like low voltage shutdown. The active configuration may be cycled by pressing the settings switch.

    The available commands for controlling system configurations include:

    Several configuration parameters may also be set. They include:

    1. Baudrate

      • Recommended baud rate: 9600

      • Note: Because the Karbon series operates using a virtual serial port, it is able to support a broad range of baud rates. It is not required to operate the serial interface at the recommended rate.

    2. Flow Control

      • XON/XOFF

    3. Command Format

      • Commands are expected to be sent by line instead of by character, such that each command requires a single transaction. Line terminating characters will be ignored. The system is not sensitive to CRLF vs LF termination.

    4. Received Data Format

      • Each line of returned data will be “/n/r” terminated

    Commands sent to the Karbon computer should be in all lower case, and transmitted to the Serial Terminal port in a single transaction. Commands are not sensitive to line termination.\

    An error response will be sent if an unsupported command is sent or if the command is transmitted with the wrong number of accompanying arguments. \

    Some CAN configuration settings, alongside limited CAN messaging are supported through the Karbon Serial Interface. Sending complex messages, and receiving data, is handled by the dedicated CAN virtual serial port. More information is available in the CAN Bus FAQ.

    Note: The CAN device is not internally terminated; a properly terminated cable or bus is required for correct CAN operation.

    The commands available through the serial terminal include:

    Controlling the Karbon Digital IO (DIO) is handled entirely through the serial terminal interface. The DIO state may be read, and output states may be set. Additionally, when an input changes state, that event will be passed to the serial terminal.

    More information is available in the DIO FAQ.

    Note: The digital io is isolated, and requires external power for proper operation. The system manual has additional information on these electrical characteristics.

    The commands available through the serial terminal interface include:

    Optional Methods:

    1– Karbon Command Line Utility

    microcontroller firmware is up to date
    Windows or Linux systems here
    pip install pykarbon
    python
    import pykarbon.pykarbon as pk
    dev = pk.Karbon()
    dev.show_info()
    dev.close()
    version
      Description:
          Reports the firmware version number and build date.
    
          Uses the format: < version | date >
      Parameters:
          -
      Example:
          version
    status
      Description:
          Reports the firmware version number and system dependent status
          information. 
      Parameters:
          -
      Example:
          status
    get-voltage
      Description:
          Reports the current system input voltage.
    
          This command is currently only available on the K700.
      Parameters:
          -
      Example:
          get-voltage
    config
      Description:
          Reports the current microcontroller configuration settings.
      Parameters:
          -
      Example:
          config
    save-config
      Description:
          Saves any changes made. 
          This is a required step or any changes will revert after reboot. 
    user-config [config-number]
      Description:
          Sets the currently active user configuration.
      Parameters:
          config-number --> The configuration number: 1 - 4
      Example:
          user-config 2
    set ignition-sense [enable]
      Description:
          Enables or disables ignition sensing. The system will turn on when
          the ignition pin goes high, and power off if the pin falls for more
          than the specified shutdown-timer.
    
          This is achieved by emulating a front power button press, and can be
          interrupt by the OS. Therefore, after the hard-off timer has expired,
          the system will force a power down. 
      Parameters:
          enable --> Enable or disable: 'on' or 'off'
      Example:
          set ignition-sense off
    set startup-timer [time]
      Description:
          Sets the delay before the system powers on after detecting ignition.
      Parameters:
          time --> Time delay in seconds: 0 - 9999 (s)
      Example:
          set startup-timer 15
    set shutdown-voltage [volts]
      Description:
          Designed to protect automotive systems from battery drain, the system
          will turn off the input voltage drops below this level for more than
          the specified shutdown-timer.
    
          This is achieved by emulating a front power button press, and can be
          interrupt by the OS. Therefore, after the hard-off timer has expired,
          the system will force a power down.
    
          Setting this voltage to a value of '6' or less disables the feature.
      Parameters:
          volts --> The low voltage shutdown level: 0 - Max System Voltage (V)
              On the K700 this value may be a float (12.5, 19.2) but is 
              required to be an int (12, 19) on the K300. 
    
              Floating point shutdown voltages will be added to the K300 as
              part of a future firmware update.
      Example:
          set shutdown-voltage 12
    set hotplug [enable]
      Description:
          Enables or disables display port hotplug detection.
    
          Disabling hotplug detection will keep displays from re-arranging if a
          monitor goes down. When disabled, the host will assume that all
          displays are always connected. 
      Parameters:
          enable --> Enable or disable: 'on' or 'off'
      Example:
          set hotplug on
    set shutdown-timer [time]
      Description:
          Sets the delay before the system powers off after ignition falls or
          the system voltage drops below the safe level.
      Parameters:
           time --> Time delay in seconds: 0 - 9999 (s) 
      Example:
          set shutdown-timer 20
    set hard-off-timer [time]
      Description:
          Sets the delay until the system forces a power off after ignition
          falls or the system voltage drops below a safe level.  
      Parameters:
           time --> Time delay in seconds: 0 - 9999 (s)
      Example:
          set hard-off-timer 150
    set boot-config [true | false]
      Description:
          Determines which user configuration is loaded when the system is
          first connected to AC power. Only one configuration may have this
          value set as true.
    
          By default, user configuration one is loaded at boot.
      Parameters:
          true | false: If the config is loaded at boot: 'true' or 'false'
      Example:
          set boot-config true
    set low-power-mode [on | off]
      Description:
          Enable or disable entering low power mode (ERP mode), after the system has been shutdown. On K700 systems, when both this feature and ignition-sense are enabled, the system will enter a 'very low power mode' and will only wake via ignition events.
      Parameters:
          on | off: If the system will enter low power mode: 'on' or 'off'
      Example:
          set low-power-mode on
    can-message [id] [data]
      Description:
          Formats and sends a standard can data frame.
      Parameters:
          id   --> The message id. A three character hex string (1 - 7FF)
          data --> Data to transmit: A sixteen character hex string.
      Example:
          can-message 123 1122334455667788
    can-autobaud
      Description:
          Attempts to detect the baudrate and propagation delay of the bus.
          This is achieved by sending messages with the id 7FF, and may not
          work in every possible configuration.
    
          To maintain a detected baudrate across hard power cycles, please see
          the 'save-config' terminal command.
      Parameters:
          -
      Example:
          can-autobaud
    set can-baudrate [baud]
      Description:
          Sets the baudrate for CAN bus communication.
    
          To maintain a set baudrate across hard power cycles, please see the
          'save-config' terminal command.
      Parameters:
          baud --> The system baudrate, in thousands: 100 - 1000 (k)
      Example:
          set can-baudrate 1000
    dio-state
      Description:
          Reports the current logical states of the digital inputs/outputs.
          This is represented by eight characters, each a '1' or '0'.
          
          The bit order is: I0 - I1 - I2 - I3 - O0 - O1 - O2 - O3
          Where 'I' is a digital input and 'O' is a digital output.
    
          For example: 10010110
      Parameters:
          -
      Example:
          dio-state
    set-do [value]
      Description:
          Sets the output state of the four digital outputs.
      Parameters:
          value --> A four character string of '1', '-' or '0'.
              A '1' or '0' will set the output to the corresponding state,
              while a '-' will not change the sate of the matching output pin.
      Example:
          set-do 0--1
    set dio-power-switch [enable]
      Description:
          When enabled, any of the front digital inputs can be used to power
          the system on. Once the system is powered on, they will behave as a
          typical digital input.
      Parameters:
          enable --> Enable or disable: 'on' or 'off'
      Example:
          set dio-power-switch on

    2– Pykarbon

    What is the Pykarbon Module?

    What can the Pykarbon Module do?

    Setting Up the Pykarbon Module

    3– Serial Interface

    Connecting from Windows

    Connecting from Ubuntu Linux

    Serial Commands

    Serial Commands – System Information

    Serial Commands – System Configuration

    Serial Interface Technical Details – Connection Specs

    Serial Commands – CAN Bus

    Serial Commands – Digital IO

    Once the loop back is made, PuTTY can be used to send simple communication over the port to determine how the physical port enumerates in the OS.

    Using Putty open up a COM port and type in the terminal window.

    • Your keystrokes should print out in the terminal window. If they do not, use PuTTY to open up another COM port number

    • This tells us that the COM port our loop back is plugged in to is “COM1” in the Operating System.

    In Linux download and install PuTTY. You may need to run PuTTY with elevated privileges. Open up a /dev/ttyS0 port and begin typing in the terminal window.

    sudo apt install putty sudo putty

    • Your keystrokes should type out in the window. If they do not, run putty with a different /dev/ttyS address. Try 1 or 2

    • This determines the port we have our loopback plugged in to is at /dev/ttyS_

    When connecting to a device it’s important to verify pinout between devices against the pinout of the cable in use.

    Using the pinout of the two devices, verify that the cable is connecting Tx to Rx and also connecting ground.

    • This example is using jumper cables to show the pinout connection between devices

    Once the cable pinout is verified and the cable is connected to both devices, PuTTY can be used to send information over the port.

    It’s important that the following settings between both devices match. If the settings differ between devices, the data sent will have errors on the receiving device.

    Baud Rate

    Data Bits

    Stop Bits

    Parity and Flow control are optional settings.

    In Ubuntu we can use PuTTY to open up the /dev/ttyS0 device path we ran the loopback test on.

    also take note of the serial configuration of this PuTTY serial session.

    Opening PuTTY the com port we ran the loop back test on can be opened and the settings can be checked to make sure they match the configuration of the Ubuntu system’s COM settings.

    Once the PuTTY terminal is open on both systems, data can now be sent between devices.

    On the Windows PuTTY terminal, keystrokes will appear in the Linux PuTTY terminal.

    On the Linux PuTTY Terminal, keystrokes will appear in the Windows PuTTY terminal

    Although this example used 2 K300 systems, the overall principals apply for setup and troubleshooting any serial communication line.

    • Determining software port to use for specific physical port

    • Ensuring port works with loop back

    • Determining pinout of port

    • Ensuring cable’s pinout matches device’s pinout and Tx pins are going to Rx pins between devices

    • Ensuring communication settings between devices match.

    Basic RS-232 Setup

    Windows

    Linux

    Communication between devices

    Device settings

    COM Setup (Linux)

    COM Setup (Windows)

    Sending data between devices

    Conclusion

    Optimizing Touchscreen HMIs for Industrial Workloads

    HMI touchscreen optimization for industrial applications.

    For industrial applications, touchscreen HMIs (Human Machine Interfaces) are very popular, allowing operators to interact with computerized systems without the need for a keyboard and mouse. This reduces space needs and allows systems to be directly mounted to electrical enclosures & kiosks. However, application development, design, and integration for HMI touchscreens differs from desktop and mobile use-cases. This application note will explain how to develop, design, and optimize the user experience with touchscreen HMIs across Windows and Linux distributions.

    If you’d like to know more about selecting the right type touchscreen for your application, look at reading our blog post, 7 Step Process to Selecting an Industrial Panel PCs. This application note assumes you are already familiar with the differences between capacitive and resistive screens.

    Basic Touch Functionality & OS Specific Considerations

    Modern operating systems are equipped to handle touch inputs out of the box. For comparison, Windows 11 Pro, Ubuntu 22.04, and Ubuntu 24.04 operating systems were tested for functionality consistency with OnLogic’s Tacton Panel PC platform. Basic functionality consists of:

    • A single press of the screen will act as a left mouse button click

    • Holding down a finger to the screen will act as the right mouse button click.

    • Multi-touch gestures depend on the operating system and will only be consistent with capacitive screens.

    As touchscreens have been around for a long time, some users need functionality consistent for their legacy applications to work properly, particularly those based on Windows Vista that utilize a resistive stylus. Some of these applications operated based on a “click” actuation once a pen was removed from the screen. In order to replicate this functionality with a modern touchscreen we will need to use an utility to emulate it. has been tested by OnLogic for use with Tacton’s resistive for those users that need to emulate legacy applications.

    While holding down a touch will pull up the right click menu, this does not work on files on the GNOME desktop environment. In all other cases such as taskbar and in application it will work correctly. This can sometimes be addressed by enabling Click Assist in the Accessibility settings to simulate a secondary click, however this did not work consistently across all distributions and screen types. However, as we will discuss further on, it is best to not utilize right click when possible for ease of use.

    When inputs are needed from users that would otherwise use a keyboard, an OSK can be used to create a virtual keyboard that users can interface with using the touchscreen. When enabled the keyboard will show up when clicking into a text or numerical entry box. Both Windows and Linux distros offer a default OSK, but may require some setup depending on the application.

    Somewhat confusingly, Windows offers both a standard OSK and a touch keyboard. Both options pop out as a window when needed, but the touch keyboard (shown above) offers much more flexibility and responsiveness in terms of customizing size and position. It is best to use the touch keyboard option when possible. Additionally, with Windows 11, an icon can be added to the taskbar to allow for the keyboard to be turned on and off manually if desired. To use properly, ensure the standard OSK is turned off in the keyboard section of the Accessibility Menu & touch keyboard is turned on (Time & Language > Typing) and added to the taskbar (Personalization > Taskbar).

    The OSK can be enabled in the accessibility system menu under the typing section. It will pop-up from the bottom of the screen occupying about ⅓ of the screen space and can be manually brought up by swiping from the bottom of the screen (PCAP Only). This can present challenges as input boxes can become blocked by the OSK window.

    GNOME Default On-Screen Keyboard

    Customization can be tricky, depending on the particular distribution. Most modern distributions (18.04+) use Wayland as a replacement for X11 window system protocol. This means that older tools that utilize x11 will not work with modern distributions when trying to deploy system-wide. It’s important to consider how inputs will be made if the default OSK can’t be used.

    Direct Application Integration

    Consider implementing the OSK directly into our application using compatible components or tools. For example, with Inductive Automation’s Perspective SCADA visualization tool, there are already pre-built keyboard and numpad components available for integration natively into projects. If developing an application from the ground-up, consider what your UI toolkit offers, such as QT6’s virtual keyboard.

    GNOME Extensions

    If we want to integrate outside of individual applications, there are other tools available through GNOME Extensions such as TouchX which adds a dedicated OSK button to the top taskbar, or GSJOSK, which offers a pop-out OSK however your mileage may vary as GSJOSK and other non-standard OSKs. In our testing, it did not work in full screen for browser sessions. OSK dependencies can vary greatly, so direct application integration is preferable.

    When a system is panel mounted be sure to consider how to wake the system from standby/suspend state. While Windows 11 supports “Touch on Wake” natively, the same option is not present for the default Ubuntu 22.04/24.04 environment or within Windows 10. One obvious solution is to disable sleep/suspend in the power settings of your operating systems, however the Tacton platform offers some alternative hardware features that can help, regardless of the Windows or Linux environment.

    • Infrared Proximity Wake – allows the embedded IR sensor to wake the system from sleep based on user proximity. The distance is enabled and customized via the LPMCU CLI tool.

    • Remote Power Switch – A physical power button can be cabled out from the integrated DIO (Pin 1-2). A simple momentary switch will allow you to wake the computer.

    Based on the touch interactions we reviewed above, applications for touchscreens need to be built in a manner that allows users to easily interact with on-screen resources. This means that not all functions that worked on a desktop as a physical button are best used for touchscreen HMIs. We should follow similar best practices to mobile application design in terms of simplicity, ease of use, and consistency. This guide is not designed to be a complete overview of HMI design best practices, but please consider the following concepts specific to touch interactions.

    • Stick to single touch (i.e. left click) for use where possible. This will provide the most consistent experience. Since our fleet of devices may be heterogeneous, building applications that work well for all types of screens is ideal.

    • Minimize components that require movement such as swiping, sliders, etc.

    • Do not use a touchscreen for momentary i.e. “jog” buttons for communicating with a PLC. These are not consistent and cause a value to get “stuck” in a state. Consider using timers, automating actions, or keeping these as physical buttons next to the panel.

    • Using an OSK with a resistive screen is time consuming and should be avoided when possible.

    • Typing repeatedly on a touchscreen is time consuming. Barcodes, ID scanners, RF devices, and other input devices will automate data collection.

    • Gestures can be helpful, but should not be relied upon. Build straightforward navigation with buttons that allow easy navigation. The exception being applications that need to zoom, such as integration with Google Maps or OpenStreetMaps can benefit greatly from gesture support.

    • Utilizing “Kiosk Mode” or auto-launch applications in full-screen during boot. This will minimize operator confusion and limit access to unapproved applications. IT best practices for locking down workstations should also be implemented.

    Edge AI Container Deployment with Ansible

    Deploying AI Vision Application Containers at the edge using Ansible Automation Platform on OnLogic HX401 and AC101 systems

    Application Overview

    In the rapidly evolving landscape of edge computing, efficient device management and orchestration are paramount. This application note explores the use of the Ansible Automation Platform to streamline the deployment of edge AI applications. By leveraging Ansible’s capabilities, we demonstrate a robust and repeatable method for deploying and managing complex edge infrastructures. This approach addresses the challenges of scalability, heterogeneity, and rapid deployment inherent in edge environments. Through detailed instructions and practical examples, this guide empowers technical professionals to effectively harness automation, optimize resource utilization, and accelerate the delivery of cutting-edge AI solutions at the edge.

    Demo Application: “OnLogos”

    For this example note, we’ll be showcasing an AI demo application that can detect “OnLogic” logos. This demo application is written in Python and uses a USB camera with a YOLO object detection model that has been trained on a custom dataset to detect the OnLogic logo in its various forms. The processed image frames are then sent to an RTSP server in order to view the live camera feed. Both the server and client of our application are packaged into Podman containers, and hosted via private registry.

    Hardware Selection & Setup

    HX401

    For the edge device deployment, the Helix 401 (HX401) industrial computer was selected for its small form factor and performance. The Intel® 12th Generation Alder Lake-P SoC makes it an excellent choice for Edge AI applications.

    AC101

    Additionally, in this example, the edge server is used for hosting the RTSP server that our edge endpoints connect to, in order to provide a live view of what the HX401 was seeing from the attached USB camera.

    • Intel Core i9-13900E

    • 64GB (2x 32GB) ECC DDR5 4800 MHz Memory

    • 960GB Micron NVMe SSD

    • Nvidia RTX A4000

    • Intel Core i7-1240PE

    • 32GB (2x16GB) DDR5 4800 MHz Memory

    • 128GB Transcend NVMe SSD

    • Red Hat Enterprise Linux 8.8 with Podman installed

    • 1GbE Port 1: DHCP, Connected to Internet (for Ansible Automation Connectivity)

    • 1GbE Port 2: Static IP (10.10.15.1, Connected to HX401)

    Red Hat provides a along with installation instructions to set up an ansible automation platform server with (you guessed it) an Ansible Playbook. Ansible Automation Platform can be deployed either in the cloud, or on premises depending on your organization’s infrastructure. In this case, Ansible Automation Platform was deployed on premises on another AC101 we had in the office.

    To start off, the first thing required is to import an automation project within the Ansible Automation Platform. The procedure noted below will step through this process.

    1. Login to the Ansible Automation Platform web console.

    2. Navigate to the “Projects” page.

    3. Create a new project, providing a name and optional description.

    4. In the project configuration, select the Git repository option and input the Git repository URL, specifying the branch and path if needed.

    5. In the example shown, a GitLab HTTPS deploy token is appended to the front of the URL for authentication to an internal GitLab server.

    6. Save the project configuration and initiate the sync process to pull in the content from the Git repository. Verify the successful import of playbooks and roles within the Ansible Automation Platform interface.

    Ansible Automation Platform provides a centralized and secure way to manage credentials, such as usernames and passwords, necessary for accessing target systems. In this case, Linux PAM credentials, required for SSH and sudo access to the devices, are the relevant credentials that need to be added to the interface.

    1. Navigate to the “Inventories” section.

    2. Click “Add” and click on the “Inventories” tab in the main navigation menu. This will take you to the inventories management page.

    Within the inventory, you’ll need to define hosts (individual machines or servers) and groups (collections of hosts).

    1. Add hosts by specifying their IP addresses or hostnames. For this case, two inventories are being created, one for the HX401, and one for the AC101.

    Variables can be assigned at several different levels (host, group, inventory, etc.). In this application, variables are being assigned at the inventory level, as there are two discrete inventories for the edge device and RTSP server.

    Review the created inventory to ensure all hosts and groups are accurately defined. There are built-in tools to test the connectivity and configuration of the hosts within the inventory.

    Job templates serve as blueprints for job execution, encapsulating the details of playbooks, inventories, and job options.

    1. Navigate to the “Templates” section, and select “Add Job Template” under the “Add” dropdown.

    2. Fill in the required information, including a name and description. Specify the playbook that the template will execute, and designate the target hosts by choosing an inventory source. Customize the job template further by configuring options such as credentials, project settings, and runtime parameters, then click save. The completed job template should now encapsulate all the necessary details for executing the automation task in a repeatable manner.

    After running the jobs, the application should now be exposing an RTSP stream at the location specified in the job template:

    From our AC101 platform, we can ensure that the AI vision application container was deployed to the HX401 by attempting to open the RTSP video stream. To do so, we can use the popular VLC media player application to open the video stream as follows:

    1. Open VLC media player and navigate to Media, the select Open Network Stream

    2. Input your RTSP URL into the open field, e.g rtsp://<hostname-or-ip-here>:8554

    3. Next, press the Play button, and the RTSP stream should open.

    Confirming our application is loaded on the HX401, here is a view of the stream from VLC, demonstrating that both the RTSP container and the vision application have deployed successfully!

    Interested in exploring how the Ansible Automation Platform can transform your edge AI deployments? Contact the OnLogic team today or visit www.onlogic.com/ai.

    RAID Setup - K700 & HX500/600

    Applicable to: Karbon 700 & Helix Series

    Note that only SATA drives (M.2 or 2.5″) can be used in RAID on these platforms. This is due to Intel chipset limitations.

    RAID (Redundant Array of Independent Disks) is a technology used to stitch multiple storage drives together into a single volume for a variety of purposes. The Intel chipsets on OnLogic’s Helix and Karbon 700 platforms feature Intel Rapid Storage Technology (RST), an integrated firmware-level RAID utility for SATA disks.

    Note: Intel RST on the Helix platform is only supported in Windows; Linux users will need to use a dedicated hardware RAID solution or a software-level RAID utility such as mdadm.

    Because the RAID volumes are maintained at the firmware level, the disks in an array do not need to match perfectly. However, the timing parameters of all disks in a certain array, such as write speed, will be slowed down by the chipset to the lowest value among those disks. For example, an M.2 SATA III SSD may have slightly faster read and write speeds than a similar 2.5” SATA III SSD. If these two disks are stitched together in an array, the M.2 SSD’s timing parameters will be slowed to match the 2.5” SSD.

    Low battery shutdown voltage
  • Etc.

  • Space buttons and size appropriately to make them easy to interact with.

    Legacy Windows stylus applications:

    Right Click on Linux GNOME Desktop:

    On-Screen Keyboard (OSK) & OS Specific Considerations

    Windows – OSK vs. Touch Keyboard:

    Linux OSK & Implementation

    Wake-on-Touch

    Application Best Practices

    Touch Events

    OSK

    Gestures

    Other

    EETI’s eGalaxTouch Windows utility

    Red Hat Enterprise Linux 9.2 with Podman installed

    Hardware Specs

    AC101

    HX401

    Network Configuration

    Getting Started with Ansible Automation Platform

    Platform Installation

    Project Import (from Git Repository)

    Add Credentials

    Create Inventories

    Define Hosts

    Assign Variables

    Job Template Creation

    Deploy Application

    Deployment Verification

    Axial AC101
    deployment planning guide
    On the Karbon 700 platform, the two cabled SATA connections can be configured in RAID arrays. Karbon 700 supports RAID 0, 1, and Recovery arrays.

    On the Helix platform, the M.2 B-Key, M.2 M-Key, and both cabled SATA connections can be configured in RAID arrays. Helix supports RAID 0, 1, 5, 10, and Recovery arrays.

    Different types of RAID arrays are referred to as “levels”. Each level has unique characteristics that provide benefits in one form or another. Different RAID levels have different applications, so be sure to pick the correct one for your use case.

    RAID 0 (Striped): In a RAID 0 array, data written to the volume is split between two or more disks. Each disk’s storage space is divided into blocks, the size of which can be set by the user. When writing data to the volume, the SATA controller will rotate block-by-block between the disks. This methodology can provide noticeable improvements to read and write speeds; however, if one disk in a RAID 0 array fails, the data on the entire volume will be lost.

    RAID 1 (Mirrored): In a RAID 1 array, the SATA controller mirrors all data between two or more disks. The primary benefit of this methodology is that if a drive in the array is disconnected or fails altogether, the volume will continue to function as normal. If an OS is installed on the volume, it will not be interrupted by a failing drive. A drive can then be reconnected or replaced, at which time the SATA controller will rebuild the volume (note that the rebuild process can take several hours or even days for larger volumes). This RAID configuration has no noticeable effect on write speeds but typically improves read speeds, as the system can read from multiple disks simultaneously.

    RAID 5 (Striped with Parity): A RAID 5 array functions similarly to a RAID 0 array in that it stripes data across multiple disks; however, for each set of blocks, it also writes a block of parity data that can be used to recover a block on another disk if it loses that data. Thus, you can achieve some of the performance gains of a RAID 0 array while being able to withstand a single disk failure. This methodology requires at least three disks.

    RAID 10 (Striped and Mirrored): A RAID 10 array combines two RAID 1 arrays in a RAID 0 array. This allows you to achieve the performance gains of a RAID 0 array while still maintaining the fault tolerance of a RAID 1 array. Data is striped between the two RAID 1 volumes, which are able to withstand and rebuild after a failed disk. This methodology requires at least four disks. This RAID level is also sometimes referred to as RAID 1+0.

    Recovery: Intel Rapid Recovery Technology creates a special RAID 1 array where instead of two equivalent disks, one disk is designated the “primary” and the other the “secondary”. Data is written to the primary drive, then copied to the secondary drive as a backup. This allows you to decide if you would like the mirroring to occur continuously or only on request; in addition, the time it takes to rebuild the array after a disk failure is decreased. However, the read speed improvements of a typical RAID 1 array are not seen here, as the SATA controller will typically only read from the primary drive. Note: Creating a new RAID array will erase all filesystems and data on all the disks used.

    • Begin by powering on the system and immediately press the Del key a few times to access the menu

    • Using the arrow keys, navigate down to “Setup Utility” and press enter

    • From the “Advanced” tab, open the PCH-IO” Configuration” menu

    • Open the “SATA And RST Configuration” submenu

    • Change the SATA Mode Selection to “Intel RST”

    • Press F10 to save changes & exit.

    • Press Del at boot again to access the main menu.

    • From the main menu, select “Device Management”. You will be greeted with the Device Manager options pictured below. Select “Intel(R) Rapid Storage Technology” to continue.

    The following menu will give you the option to specify the name of your RAID volume, the RAID level of the configuration, and which disks will become part of the array. Begin by specifying the name of the volume if desired and selecting a RAID Level.

    Then, select which SATA disks will be used to create the array. Note that any disks being used in a different RAID array will not be selectable. If you are creating an array with the RAID level “Recovery”, you will need to select which drive is the master (M) and which is the slave (R).

    For RAID 0, 5, and 10 configurations, you can specify the strip size if desired. The strip size options vary depending on the RAID level of the configuration. In addition, you can set the capacity of the volume if you would like it smaller than the maximum available. If you are creating a “Recovery” array, you can also select if the slave drive is synchronized with the master continuously or only on request.

    Select “Create Volume” to return to the Device Manager menu. You should now see your new volume listed in the menu; hit F10 to save your new settings and Escape to return to the main BIOS menu.

    Your RAID array is now created and ready for use.

    In addition to using the Device Management menu in the BIOS, you can also configure and monitor RAID arrays from Windows using the Intel Rapid Storage Technology desktop application. The installer for the application can be found on the Helix Product Documentation Pages ( or ) The application allows you to create, monitor, and delete RAID arrays from the OS level.


    These instructions will guide you through enabling the legacy RAID menu for operating systems that may not work with the UEFI version. The RST instructions above should be used whenever possible.

    • Begin by powering on the Karbon 700 and immediately press the Del key a few times to access the menu

    • Using the arrow keys, navigate down to “Setup Utility” and press enter

    • From the “Advanced” tab, open the PCH-IO” Configuration” menu

    • Open the “SATA And RST Configuration” submenu

    • Change the SATA Mode Selection to “Intel RST”

    • Press ESC 3 times to go back to the main menu

    • Next, navigate over to the Boot tab and change the Boot Type to Legacy

    • Exit Saving Changes

    • The K700 will now reboot. As soon as it does, hold the Control key and tap “I” until you see the Intel Rapid Storage Technology menu

    • Select option 1 from the menu

    • Use the tab key to navigate and the up/down arrows to change options.

    • A RAID1 configuration is shown

    • Tab down to “Create Volume” and press enter

    • You will be taken back to the main screen and your new RAID volume will be visible.

    • Select option 6 to Exit, and then press Control-Alt-Del to restart

    • You will now toggle the boot mode back to UEFI

    • Press Del at reboot to access the menu

    • Open the Setup Utility

    • Change the boot mode back to UEFI

    • Finally, Exit Saving Changes

    Your RAID volume is now ready to use.

    Overview

    RAID Levels

    Intel RST RAID Management

    Enabling Rapid Storage Technology

    Intel(R) Rapid Storage Technology Menu

    Creating a New RAID Array

    Intel RST Control (Windows)

    Legacy method

    HX300
    HX500 & HX600