BROWSE BY TECHNOLOGY



RTC SUPPLEMENTS


TECHNOLOGY IN SYSTEMS

Graphics for Advanced Applications

Making Machine Control Implementation Accessible to Product Developers

In the real world where time is money and systems are becoming more complex, product developers are looking to the controller vendor for more out of the box functionality to help speed up time to market. This is all the more pressing now that control designs often include a graphical human-to-machine interface (HMI).

BY DAVID STONIER-GIBSON, CEO, SPLAT CONTROLS

  • Page 1 of 1
    Bookmark and Share

Article Media

Designing an effective and affordable control system for a “machine” whether it be an air conditioner, a spa bath, or a turnstile that is to be manufactured in quantity presents lots of challenges. For the controller to do a good job, it must react predictably to real-time events as well as do many things at once, without faltering. It usually needs state awareness, so it can respond in the context of past events. It must tolerate sensor faults and operator mistakes without becoming dangerous. And it must continue to operate 24/7/365 in the face of sometimes unanticipated events. Last, but not least, users need it to be easy and intuitive to operate, and that often means it needs a slick user interface.

Bottom line: We expect the reliability, dependability, and usability of something even as humble as a dishwasher to exceed by far what we have regretfully come to accept as normal on our desktop computers.

But despite all of these demands on and intricacies of a control system, controls are often implemented by product developers who have little relevant training or understanding of the deeper issues of control systems. Certainly, they are experts in the functionality of the product they are designing, but that expertise often does not extend to the electronic controls. This dilemma has only increased with the advent of ultra-cheap embedded computer boards with cutie-pie names, which place significant computing power, but not understanding, within grasp of developers working on products slated for quantity production.

How then to make a controller system that can be incorporated into a machine design by application domain experts and maximize the chances of a successful outcome?

One early effort in that direction, in the industrial automation domain, was the venerable PLC (see “In the Beginning was the PLC,” p.xx). The PLC was however never intended as an embedded controller for individual products made in quantity. Attempts to leverage PLC technology into true embedded controls applications often makes for a poor fit and expensive hardware over-design. It also does nothing to help the expert in the domain of the end product.

Let’s explore then the various attributes and design strategies for an embedded controller system that enables a domain expert to leverage his expertise and implement a successful machine controller.

Guidelines along the Path

In computer programming languages like C/C++, the very first step is the time-honored “Hello World” program. In controls programming, the equivalent involves a real-world outcome like a flashing LED or clicking relay. When you un-box your first sample controller, the time spent simply getting a flashing light or clicking relay should be a short but excellent investment. If you have to spend hours and hours of hands-off study before getting a gratifyingly observable — or audible — result, you may abandon the project before it is even started properly. So aim for that tiny initial step to familiarize yourself with the product and its tools.

The clickety-clack relay is the first small step, and a significant one. But it is not the last. The golden rule of a successful control implementation is to keep on taking only small steps. This applies from everything as basic as ensuring the sensors are all wired to the correct inputs in the prototype before attempting to test a program using them, to building up your program step by step, module by module. This is where you will get the benefit of a control product whose support tools support interactive I/O testing and modular programming. Break your program down into small, manageable chunks along functional lines. For example, the modules in a coffee machine might be “boiler control”, “grinder”, “reservoir monitor”, “brew sequencer”, and “user interface”. Good choices in this system partitioning or “factoring” will put you in good stead later, so invest time in this critical planning stage.

A lot goes on in a controller. Much, though, is just drudge housekeeping work such as initializing the processor hardware, which has nothing to do with the actual application. There is also a layer of activities that are fundamental to practically all controller applications, such as contact de-bounce, pulse counting and timing, and driving expansion modules and displays. Selecting a control system that quietly takes care of these under the hood, leaves you free to concentrate on the logic of the final control function, slashing possibly days of learning off your time to market.

The 500-pound gorilla, though, is multitasking. Practically every embedded control application needs it. Yet in most controller products, and programming languages, multitasking requires a bolt-on Real Time Operating System (RTOS), separate from the controller hardware and the programming language. Picking the best RTOS is difficult, and really does require a high degree of expertise, so the consequences of a bad choice can be dire. The hazards that can arise in multitasking systems, such as resource locks and priority inversions, can be extremely subtle and often not strike until well after a product has been in service for some time. The result is costly recalls and possibly a complete program re-write — existential threats to start-ups and even small, established companies. Very few off the shelf controllers include an integral multitasking system, let alone one that is easy to learn, easy to use and hazard proof.

What happens if you get stuck and need some assistance? Selecting a controller vendor with proven one-on-one application support and one who allows you access to knowledgeable and experienced engineers, can make all the difference to the success of your product development.

Good support goes much deeper than just helping resolve sticking points. When the vendor’s engineers bring extensive experience to the table, they can often suggest innovative solutions. This could be a better way to structure the program, or a cheaper way of providing the needed sensors or actuators.

It is very tempting to always want the highest possible speed, the largest possible memory, and the latest operating system. That’s what impresses colleagues and garners headlines. Yet the cost of those fashion items is often complexity and its attendant dangers. A spa bath doesn’t need a 1GHz processor on a 12-layer board and 1-microsecond response time. What it really needs is to work reliably and to be competitively priced. A product development has a much better chance of success if the emphasis is on a controller with robust I/O circuitry and a safe programming environment, rather than impressive headline specs.

The SPLat Controls product is a range of board level embedded controllers and add-on boards that was designed from the ground up to be accessible to end-product developers. A novice can write useful programs for simple time- and event-triggered sequences after a couple of hours study using a simplified instruction set called FastTrack. Many SPLat customers have brought successful products to market using nothing more than FastTrack. One small step up the concept ladder from FastTrack is the tightly coupled cooperative multitasking system MultiTrack, which introduces just two more instructions. MultiTrack allows up to 64 concurrent tasks in a simple round-robin sequence that is comfortably free of the hazards of priorities and pre-emption.

FastTracking Results

Many controllers, even today in the era of IoT and M2M, still perform nothing more than simple sequences, perhaps timed or governed by external events (inputs). SPLat’s FastTrack instruction subset was designed just for such cases, and is used in hundreds of machine designs around the world. FastTrack was inspired by a customer’s program that was simply waiting for an input, turning on some outputs in sequence for preset times, then going back to wait for a new input. FastTrack consists of just 14 instructions, and can be learned by a novice in a couple of hours. Here is the whole list:

On 5    Turn output 5 on

Off Actuator    Turn the output named “Actuator” off

Pause 37567    Pause the program that many 10mS intervals

GoTo LineName    Jump elsewhere in the program

WaitOn 5    Wait for input 5 to come on

WaitOff 5    Wait for input 5 to turn off

WaitOnT 5,3456    Wait for input 5 to come on, but with a timeout

WaitOffT 5,3456    Wait for input 5 to turn off, but with a timeout

GoIfT LineName    Test if WaitOnT/WaitOffT timed out, jump accordingly

GoIfF LineName    Test if WaitOnT/WaitOffT timed out, jump accordingly

GoIfInOn 5,LineName    Conditional jump based on an input state

GoIfInOff 5,LineName    Conditional jump based on an input state

SetMem 15,100    Set memory (RAM) location 15 to 100

DecMGoIfNZ 15,LineName    Decrement memory, conditionally jump (loop counter)

 

The Pause and Wait instructions are blocking. But if used in a MultiTrack task, they block only the task they are part of.

The SPLat system provides not only conventional programming tools, but also tools that reflect the real world and facilitate target machine interaction (Figure 1). A minimal flashing LED program, the “Hello World” of embedded controls, is easily understood when the language is transparent and the development environment provides a representation of the real world inputs and outputs. The I/O display also allows direct interaction with a connected controller board — click an output (LED) on the computer and the corresponding physical output will toggle on/off. Turn on a physical input pin, and the on-screen representation (DIP switch) will follow.

The SPLat system is built around a proprietary language, optimized for embedded control and accessibility. The language uses a virtual machine (VM), which trades speed for comfort. It allows a lot of functionality to be hidden under the hood, completely transparent to the application programmer. Inputs are de-bounced, floating point divide by zero doesn’t lead to a crash. Fatal runtime errors, including stuck loops, are intercepted with a predictable behaviour, and the multitasking “just is”. Many other under the hood services encompass serial communications — including Modbus — timers and event counting.

Most embedded control systems need to somehow or other cope with states during machine operation — responding to current events in the context of past history. The most successful paradigm for handling states is the Finite State Machine (FSM). An example of an FSM programming tool is Tabula (Figure 2), which allows an FSM to be expressed as a table that the programmer can interactively step through to verify its behavior.

The maker of, say, a beer bottling and capping machine understands bottling machines, and will embody that understanding in the controls he designs. Conveying the subtleties of bottling beer to a programmer who knows nothing about bottling machines can be just as difficult as the other way around.

Simon Ross, founder of start-up MicroBrewTech in New Zealand, had exposure to a mix of programming languages, including PLC ladder language, before he started developing his bottling machine for microbreweries (Figure 3). Thanks to the accessibility of the SPLat system, he was able to quickly develop a sophisticated multi-tasking controller with color touchscreen using a beta prototype of SPLat’s HMI430 controller/touch screen combo product. Simon’s preference for the SPLat stems from his observation that, “With SPLat I can make a change and know it will work. In ladder, I have to go back down several layers to raw relays and timers, and it becomes that much harder to know for sure that it will immediately do what I want.” With proper support and a safe programming platform, it is possible to enable the real domain expert to take the lead on the control component.

Figure 3
Using a SPLat HMI430, a sophisticated controller with color touchscreen for this beer bottling machine was developed by the machine’s actual designer rather than by a programmer with no knowledge of beer bottling

SPLat Controls
Seaford, Victoria, Australia
+61 3 9773 5082
www.splatco.com