This audio was created using Microsoft Azure Speech Services
An HMI or Touch Panel is possibly the most aesthetic device in a factory because it has animation capabilities and seems inviting for a user to discover it; in contrast with a PLC or a Field Device which looks like it’s best never fiddled with for no reason. HMIs are supposed to be easy to navigate, quickly understandable, show lots of data and yet have very few controls on it – so as not to confuse the user. Just like how we expect an application on our smartphones to be intuitive and efficient, the same goes for the HMI as well.
Panel designers are the ones who design projects specific to the customer. They understand the control system entirely and set the connections between the devices and the HMI. Panel designers are proficient at designing projects with the requirements mentioned above. After all, the end user is an operator who is running the entire show – a wrong click or confusing graphics could even lead to fatal accidents. You might be wondering by now why I’m discussing panel designing when the topic clearly mentions scripts. A lot of these animations, graphics and value updates that we see on the screens are basically scripts running on the HMI. Scripts are extremely powerful and can do many tasks like showing alarms when a value crosses it’s range, duplicating the conveyer belt movement on the screen as animations, automatically changing values of devices depending on other inputs, connecting to the web, etc. You can imagine by now how massive the “code base” must be of an HMI project.
In legacy HMI softwares, the most common way of configuring scripts is by using scripting language like Java, JavaScript, VB, etc. There’s a list of trigger events to choose from like touch inputs, value change, etc and a way to configure scripts for each of these triggers. We get access to objects like variables, graphical objects, alarms, recipe objects, etc in the script area to read or write the values to them.
Panel designers are thus, characteristically expected to know one or more of the scripting languages. Most of the advanced designers have been working with many softwares and have thus picked up several of these languages like VB, Java Script, etc. As you can imagine the logic of the code is somewhat language agnostic – meaning a programmer can do an operation irrespective of the syntax rules of languages. Of course, some languages have special capabilities but discounting that, the logic is what is key in this scenario, not so much the language. If such is the case why do we restrict the capabilities of writing script only to a few panel designers? Any designer who has a clear idea on the expectations and the logic should be able to use scripts and enhance their project without having to learn syntax of multiple script languages.
This concept is called Visual Programming which allows a programmer to create programs by manipulating graphical objects rather than typing textual commands. Now that we’ve established that we just need logic to write scripts, we need to find the right tool. Google has provided us just that (obviously) – Blockly is a library which can be used in an app to extend the capabilities to represent code concepts like variables, logic expressions, loops, etc. using interlocking, graphical blocks.
Image source https://developers.google.com/blockly/
I’ll circle back to our discussion about Panel Designers who use scripts to create animations and logic to make HMI Projects which are then used by our customers who could be OEMs, Manufacturing units, Production lines, etc. If we provide the feature of Visual Programming to Panel Designers and System Integrators, this could mean increase in reach of customers because we can offer our HMI software not just to specialized designers. At the time of maintenance, it would be easier and faster to fix a project which has blocks as it can be fixed by anyone who knows the logic.
Of course, the use of blocks could be daunting for some, especially when it comes to simple logic which is typically two lines of code, could take maybe 15 clicks when programmed visually. Especially for advanced designers, they wouldn’t prefer to use visual programming as it inhibits their skills and efficiency. Therefore, I think the sweet spot would be to provide both the features for our HMI designers and gain on the advantages of both.
