How do you feel about this article? Help us to provide better content for you.
Thank you! Your feedback has been received.
There was a problem submitting your feedback, please try again later.
What do you think of this article?
A first look at the Barth lococube DMA-15 CAN display, including a quick CAN bus primer and a usage example.
Human-Machine Interfaces (HMIs) are a common component found in control panels that provide a touch-screen interface and also often local processing/control. These are frequently quite costly, large and can have complex programming requirements. Smaller PLC systems meanwhile tend to miss out on having a HMI option, which Barth have addressed with their DMA-15 CAN display.
The Barth lococube CAN Displayis a small, 2.4 inch diagonal touch screen HMI that features a CAN bus interface for connecting to a Barth lococube PLC. As CAN interfaces are widely found, the display could also be used with other devices.
- A 2.4” colour touchscreen display with a resolution of 320x240 pixels
- LED backlight
- Screen design templates can be selected over the CAN interface
- Open-source programming is possible through the use of the ISP header and the KEIL® μVision® Software Suite to produce more complex display arrangements
- Small form factor of only 69x50mm
- A wide-range power supply input from 7-32Vdc
- Rear mounting that avoids having visible screw heads on the front panel
The included rear-mounting bracket provides screw fixings to secure the HMI without visible fasteners, as well as mounting a Barth lococube PLC. This provides a tidy interface and control solution.
A resistive touch screen allows for user input; in this application, a capacitive touchscreen would not work well due to the lack of response to gloves or in wet conditions — particularly important as Barth sells a waterproofing gasket that affords IP65 protection once installed into a suitable enclosure.
Software support is provided through the drag-and-drop miCon-L programming environment (also used for Barth PLCs) or through native C programming with the use of an inexpensive ST-Link programmer connected to the ISP header.
If using the miCon-L environment, a number of standard templates are available that are selected through the CAN bus interface. Barth provides an example of using the display from an STG-800 PLC that we will explore shortly.
A Quick CAN Primer
CAN is a robust interface bus designed by Robert Bosch GmbH, primarily for use in vehicles and to tolerate the challenging electrical environment.
Development work started in 1983, with the initial protocol released three years later at the Society of Automotive Engineers (SAE) conference. Intel was the first company to release a CAN controller in 1987 and shortly followed by Philips, with Mercedes-Benz being the first manufacturer to release a car utilising the bus for control in 1991.
EE JRW, CC BY-SA 4.0, via Wikimedia Commons
Similar to RS485, CAN utilises a differential multi-master serial bus. A termination resistor of 120 ohms is required at either end of the bus; this stops signal reflections and serves to return the bus to a recessive state (a binary one) where the voltage on CAN high is less than or equal to CAN low. A dominant state (binary zero) is expressed by CAN high being greater than CAN low — this is done by the transceiver actively driving the bus, compared to the termination resistors passively pulling the bus together. Active termination circuits are also described in the ISO11783 standard that enables hot-plugging of a CAN bus network.
Having these voltage levels means a CAN bus utilises differential wired AND logic, meaning that nodes that have a lower ID number take priority on the bus. CAN controllers are commonly employed (either as separate integrated circuits, or on-die circuits within microcontrollers) that handle bus arbitration — if two nodes transmit at the same time and one sees a zero on the bus it will stop transmitting and retry after six bit clocks have passed from the end of the message.
A number of CAN standards exist, starting with the original specification all the way through to CAN 2.0 published in 1991 — this incorporates two parts, A and B, which is the standard format with 11-bit identifiers and an extended format with a 29-bit identifier respectively. Further standards were released that include specifications for a physical layer for high-speed and low-speed, fault-tolerant CAN.
2012 saw the introduction of the CAN FD 1.0 standard, which allowed for a flexible data rate with a different frame format and increased bit rates after arbitration — all whilst retaining compatibility with existing CAN 2.0 networks.
Using the Display Example
Barth provides multiple examples of using the display. The first example allows for up to 256 different parameters with 54 different units to be shown. This is set by the template in the firmware running within the display; to change the template to support more variables and different units the C source code must be modified.
Other examples are provided that include displaying multiple values with buttons, showing four different values, setting the screen colour and a numeric keyboard demo. Documentation is provided with each of the examples that details what data to send over the CAN bus, and a breakdown of the purpose of each byte.
We’ll focus on the first example that displays a single parameter, then modify it to control an output based upon on-screen button presses.
The provided macro block encompasses a number of function blocks including CAN controller initialisation at a bitrate of 250kbps, a transmit block that takes a number of variables and sends them as a suitably formatted CAN message and finally, a receive block that, in combination with four AND function blocks, decodes button presses into a number of single bit signals.
The program itself contains a number of switches that can be clicked in the miCon-L application. These toggle items are visible on the display. Three parameters are available to control the displayed value, parameter number and unit.
To indicate the state of the four touchscreen buttons, a series of indicators are present with an off-delay timer to prolong the time period that the indicator is illuminated.
With some additional function blocks, we can control an output based on the amount of times a button is pressed. This increments, decrements or resets a counter block which is then compared with a fixed value, fed through an AND block, then connected to the status LED to enable or disable the blinking.
With some further work and macro block creation a powerful parameter-driven system could be created that can not only display a number of parameters but allow for control over a number of outputs for interacting with a system. As the template supports controlling which on-screen buttons are displayed, read-only parameters could have the “ESC” and “OK” buttons hidden away, whereas editable parameters could utilise a blinking button to show when they’re being changed.
For example, an engine control system could be built that interacts with control components over the CAN bus interface as well as using digital inputs and outputs for other controls. Tuning parameters could be entered using the touch-screen display in combination with viewing operational parameters such as speed, power output, pressures and temperatures. Further customisation of the user interface could be done by modifying the display source code to add graphs, gauges and other visualisation styles.
In this article we’ve taken a look at the Barth DMA-15 CAN bus display that is perfectly matched for use with Barth lococube PLCs, as well as other CAN-enabled systems. We took a look at the hardware specifications, had a quick rundown of the CAN bus interface and then examined, modified and tested an example to control an output from the HMI.