Whether you’re already familiar with SVG structure or you’ve never seen the hmi-bind: before, this article unpacks the details you need to know, You can check out introductory article about SVG. Let’s dive in.
Extension
In order to manipulate the properties of SVG elements in real time. Siemens has come up with some add-on for the SVG format.
WinCC requires additional details to render an SVG graphic dynamically. To achieve this, WinCC employs a specific format known as "SVGHMI" which encapsulates the required information. To be recognized by SIMATIC WinCC as a dynamic SVG, files must bear the ".SVGHMI" extension.
SVGHMI files are not compatible with standard SVG graphic editors in full functionality.
Enhancements have been incorporated to enable the dynamism of SVGHMI objects. One such extension involves the utilization of the "hmi" namespace, encompassing user-defined elements and attributes.
Namespaces
In Scalable Vector Graphics (SVG), namespaces play a crucial role in organizing and categorizing elements within an XML-based document. SVG utilizes namespaces to define and distinguish various sets of elements and attributes, facilitating the integration of external specifications and extensions. These namespaces, identified by prefixes like "svg," "xlink," and user-defined prefixes, help prevent naming conflicts and enhance document clarity. For instance, the "svg" namespace encapsulates core SVG elements, while the "xlink" namespace is employed for linking attributes. Additionally, users can introduce custom namespaces to extend SVG functionality, introducing logic or data bindings. The use of namespaces in SVG promotes modularity, interoperability, and the incorporation of diverse specifications, contributing to the extensibility and adaptability of SVG documents across different applications and environments.
In order for WinCC Unified to successfully detect svghmi file as a dynamic widget in it must be connected namespaces.
- hmi: This namespace encompasses user-defined elements and attributes, often involving logic.
- hmi-bind: This namespace facilitates the addition of expressions and specifies data bindings. The specific attribute names following the prefix are undefined, allowing the placement of any valid SVG attribute.
Dig deeper
A specific declaration must precede each SVGHMI object document:
<!DOCTYPE svg PUBLIC "-//SIEMENS//DTD SVG 1.0 TIA-HMI//EN" "http://tia.siemens.com/graphics/svg/1.8/dtd/svg18-hmi.dtd">
The SVGHMI file necessitates the specification of the SVG namespace, adhering to the W3C standards, on the root SVG element:
<svg version="1.1"
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
// specific wincc namespaces
xmlns:hmi="http://svg.siemens.com/hmi/"
xmlns:hmi-bind="http://svg.siemens.com/hmi/bind/"
xmlns:hmi-bind--xlink="http://svg.siemens.com/hmi/bind/xlink/"
xmlns:hmi-element="http://svg.siemens.com/hmi/element/"
xmlns:hmi-feature="http://svg.siemens.com/hmi/feature/"
xmlns:hmi-event="http://svg.siemens.com/hmi/event/"
>
To maintain functionality and compliance with the SVG specification, all additional XML elements and attributes are prefixed with specific namespaces:
- hmi: This namespace encompasses user-defined elements and attributes, often involving logic.
- hmi-bind: This namespace facilitates the addition of expressions and specifies data bindings. The specific attribute names following the prefix are undefined, allowing the placement of any valid SVG attribute.
- hmi:self: This namespace defines the interface between dynamic SVG and TIA Portal.
- hmi:localdef: This namespace is used to define auxiliary variables within the dynamic SVG.
It is crucial to note that while namespaces are chosen by the user in XML, the specified URL only serves to identify the namespace. The value of the URL is inconsequential; however, the namespace names (i.e., hmi, hmi-bind, etc.) are fixed and must not be altered.
The complete document header for an SVGHMI object should adhere to the following structure.
<!DOCTYPE svg PUBLIC "-//SIEMENS//DTD SVG 1.0 TIA-HMI//EN" "http://tia.siemens.com/graphics/svg/1.4/dtd/svg14-hmi.dtd">
<svg
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns:hmi="http://svg.siemens.com/hmi/"
xmlns:hmi-bind="http://svg.siemens.com/hmi/bind/"
xmlns:hmi-bind--xlink="http://svg.siemens.com/hmi/bind/xlink/"
xmlns:hmi-element="http://svg.siemens.com/hmi/element/"
xmlns:hmi-feature="http://svg.siemens.com/hmi/feature/"
xmlns:hmi-event="http://svg.siemens.com/hmi/event/"
viewBox="0 0 100 100"
preserveAspectRatio="none"
>
Additionally, for an initial aspect ratio, the viewbox size must be adjusted to match the object to be displayed. If a fixed aspect ratio is not desired, specifying the graphic size through width and height parameters is sufficient.
Then the content of the file itself is located. But first in this list should be described the interface of the widget. It looks like this:
<hmi:self type="Widget" name="extended.Example" displayName="Example" version="1.2.0" performanceClass="L" >
<hmi:paramDef name="Direction" type="boolean" default="true" />
<hmi:paramDef name="Color" type="HmiColor" default="0xFFFFFFFF" />
</hmi:self>
<hmi:self> describes the widget interface. The "Type="widget" attribute indicates that the graphic is suitable for placement within an HmiCustomWidgetContainer, serving as the default for dynamic SVGs. Notably, "displayName" and "name" represent unique name describing the assigned dynamic SVG. The "name" attribute is prefixed with "extended.".
The version of the dynamic SVG can be explicitly defined using the "version" parameter. In the context of WinCC, an interface for the dynamic SVG is outlined within the "hmi:paramDef" section. The "name" attribute, can be chosen freely. Additionally, the "default" attribute specifies the value displayed for the interface if it is not interconnected on the HMI side.
The local variables section may also be located below. It should be in the <defs> element.
<defs>
<hmi:localDef name="Local_1" type="HmiColor" hmi-bind:value="{{ ParamProps.Color_1 }}"/>
<hmi:localDef name="Local_2" type="boolean" hmi-bind:value="{{ ParamProps.Input }}"/>
</defs>
"name" and "type" of local variables behave the same as in the interface. "hmi-bind:value" specifies how the value of the local variable is to be calculated.
And below can be placed various graphic elements such as rectangles, circles, elipses and so on. At the moment not all available items are supported. Only the following SVG elements are allowed for the SVGHMI objects.
SIMATIC WinCC Unified Supported items
# | Element | Description |
---|---|---|
1 | used to draw circles based on a center point and a radius | |
2 | A clipping path restricts the region to which paint can be applied. Conceptually, parts of the drawing that lie outside of the region bounded by the clipping path are not drawn. | |
3 | used to store graphical objects that will be used at a later time. Objects created inside a <defs> element are not rendered directly. To display them you have to reference them (with a <use> element for example). | |
4 | used to create ellipses based on a center coordinate, and both their x and y radius | |
6 | SVG filter element changes colors based on a transformation matrix. Every pixel's color value [R,G,B,A] is matrix multiplied by a 5 by 5 color matrix to create new color [R',G',B',A'] | |
7 | filter primitive performs the combination of two input images pixel-wise in image space using one of the Porter-Duff compositing operations: over, in, atop, out, xor, lighter, or arithmetic | |
8 | filter primitive blurs the input image by the amount specified in stdDeviation, which defines the bell-curve | |
9 | filter primitive allows to offset the input image. The input image as a whole is offset by the values specified in the dx and dy attributes | |
5 | defines a custom filter effect by grouping atomic filter primitives. It is never rendered itself, but must be used by the filter attribute on SVG elements | |
10 | container used to group other SVG elements | |
11 | includes images inside SVG documents. It can display raster image files or other SVG files | |
12 | basic shape used to create a line connecting two points | |
13 | lets authors define linear gradients to apply to other SVG elements | |
15 | defines a graphic used for drawing arrowheads or polymarkers on a given <path>, <line>, <polyline> or <polygon> element. | |
14 | defines an alpha mask for compositing the current object into the background. A mask is used/referenced using the mask property | |
16 | generic element to define a shape. All the basic shapes can be created with a path element. | |
17 | defines a graphics object which can be redrawn at repeated x- and y-coordinate intervals ("tiled") to cover an area | |
18 | defines a closed shape consisting of a set of connected straight line segments. The last point is connected to the first point | |
19 | basic shape that creates straight lines connecting several points. Typically a polyline is used to create open shapes as the last point doesn't have to be connected to the first point | |
20 | lets authors define radial gradients that can be applied to fill or stroke of graphical elements | |
21 | draws rectangles, defined by their position, width, and height. The rectangles may have their corners rounded | |
22 | container that defines a new coordinate system and viewport. It is used as the outermost element of SVG documents, but it can also be used to embed an SVG fragment inside an SVG or HTML document | |
23 | used to define graphical template objects which can be instantiated by a <use> element | |
24 | draws a graphics element consisting of text. It's possible to apply a gradient, pattern, clipping path, mask, or filter to <text>, like any other SVG graphics element | |
25 | The textual content for a <text> SVG element can be either character data directly embedded within the <text> element or the character data content of a referenced element, where the referencing is specified with a <tref> element | |
26 | defines a subtext within a <text> element or another <tspan> element. It allows for adjustment of the style and/or position of that subtext as needed | |
27 | takes nodes from within the SVG document, and duplicates them somewhere else. The effect is the same as if the nodes were deeply cloned into a non-exposed DOM, then pasted where the use element is |
The differences from regular SVG are not very big, but they are significant. And if you are manually redoing the file, errors are very possible. This is why we have developed a . It adds all the necessary namespaces, parameters, converts unsupported elements and attributes to allowable for WinCC Unified, as well as much more about its settings can be read .
to be Continued...