HMI Display Definition

This MotoHawk™ block allows a Display of an HMI (Human Machine Interface) to be defined. HMI Screens are shown on a Display.

Block ID

HMI Display Defn




Block Parameters

Parameter Field Values Comments/Description
Name Single quote enclosed alpha-numeric text The name given to the Display that other related blocks would reference
Resource Drop Down Select the display resource supported by the selected Target from the drop down. If the drop down only lists (None) then the selected Target does not support HMI Display functionality.
Reference Task Name to use by the display Single quote enclosed alpha-numeric text The name of the task that will execute the CPU work associated with supporting the display, including its refresh.

A HMI Display that requires its objects to be manipulated from a single thread must, outside of startup, house blocks that access HMI Objects within a trigger (e.g. Comment Event Trigger that is executing in the referenced task.
Refresh period (ms) Integer The approximate rate that the display will be refreshed.
Display Render Memory (%) Spin Box The HMI Display requires a buffer that can be used by the graphics driver to render a portion of the display. This attribute defines what percentage of the display could be represented in the render buffer at any instance in time. If the display of a particular resolution requires 16k of memory to support the displayed image and the render buffer was specified to be 50% then a total of 24k of memory (16k + 8k) would be required to support display refresh. If then render percentage was only 25% then only 20k of memory is required.

Why not always make it small then? Say 20% is in use, which effectively breaks the display into 5 bands. If a particular graphics manipulation was such that the underlying image invalidated portions of the two bands then the rendering process would need to be broken into two updates. The buffer is used by the driver to render the first portion of the image and the display is then updated. Then the driver detects that it is not done and renders the second portion and the screen is updated again. There is a finite time between the two updates, which may result in a discontinuity ("Banding") in what is being displayed.

Why not always make it 100% then? Using 100% protects against "banding", but it consumes a lot of memory. If the things that are changing on the display are localized to smaller regions then using something less than 100% will give the same perceived performance, yet will use less memory.

Multi-threaded Access Handling Dropdown This option is only visible when multithreaded access needs to be considered by the underyling graphics driver. Many graphics drivers require singularly threaded access. (i.e. all graphics operations should occur in the same thread). However MotoHawk™ applications are multi-threaded, which makes it easy to access a HMI Object from multiple threads at the same time. This options allows how such accesses should be managed.

Select Detect to have the driver populate code that will detect if a HMI Object is accessed from a task that is not the task referenced by the display (StartUp execution is excluded). The call into the driver will still be made when the Detect option is in use.

Select the Prevent option to prevent the call from executing if a multi-threaded access violation is detected. This can give the appearance that a particular function isn't working if the block has been located in an inappropriate trigger.

Select the Ignore option to ignore multi-threaded access violations. This will save some CPU at the cost of losing the detection/prevention operations. This option may make sense if the application has had review and is known to be singularly threaded.

Expose Multi-threaded Access Violations to Instrumentation Checkbox The multi-threaded access violation detection code can expose variables to instrumentation that reveal what objects have suffered an access violation. Only visible when a detection scheme has been selected.
Instrumentation Access Level Dropdown Defines the access level of any variables exposed
Instrumentation Group Single quote enclosed alphanumeric Defines the instrumentation group that will be associated to any variables exposed to instrumentation.