It is important to know the requirements of your target customer base. For a general purpose product this can be quite difficult. Some users will only be interested in monitoring inputs, be they digital or analogue. Others may be interested only in controlling outputs. Others again may have requirements for both input monitoring and output control.
Roy Schofield | Phaedrus Ltd
It has been said that product design is the art of compromise. Anyone who has worked in this field will acknowledge the truth of this statement. In this article I want to explore the design of a general purpose control product and explain the thought processes which led to the final design.
We have for many years manufactured the Netiom range of Ethernet products. During this time it became apparent that there was a demand for a range of products which would provide a greater range of flexibility. As the Netiom had a large continuing customer base it was decided that manufacture would continue without change and that a new range of products would be designed which would compliment it.
If we were designing for a specific application then the design process would be relatively straightforward. The number of inputs and outputs and their functionality would be fixed. It is then a matter of choosing the best methodology to achieve the design goals within the cost constraints.
For a general purpose device none of this is fixed and the first task is to decide the amount and configuration of I/O that can be provided without incurring undue cost. The greater the amount of I/O available the greater the number of users will be interested in the product. However there is one important rule: Whatever number you choose your first customer will need 1 more. Clearly you cannot please everyone and as I will explain pleasing some users may well displease others.
At this point it is important to know the requirements of your target customer base. For a general purpose product this can be quite difficult. Some users will only be interested in monitoring inputs, be they digital or analogue. Others may be interested only in controlling outputs. Others again may have requirements for both input monitoring and output control.
We have to consider the method of connecting to the device. Screw terminals are generally the preferred connection method as opposed to hard wired connectors. Hard wired connectors may be acceptable or even preferable in a factory environment, but on site wiring is generally more flexible with screw terminals. Many users like to have plug-in terminals as they are easier to access and in the event of a board failure it makes board replacement simpler.
Next we need to consider the electrical interface to the external equipment. Consider the digital inputs: These may be dry contacts such as switches or relays, they may be switched ground such as transistorised outputs or even switched power. Similarly with the digital outputs: Relays may be required or switched ground to drive external devices.
Here we have our first conflict. Obviously the more I/O that is provided the greater the cost. Screw terminal block, as well as being relatively expensive, particularly the plug-in type, also takes a lot of PCB real estate. This not only increases cost but also increases the cost of any housing being used. Thus if we allow for too much I/O then for some customers the size of the module may be too large to fit into their installation.
So let us define our I/O requirements. From experience we know that we can cover 90% plus of our customers requirements with 16 digital inputs, 16 digital outputs and 8 analogue inputs. Analogue outputs are occasionally requested but these tend to be for special applications and therefore were considered to be outside the scope of this product.
So how do we provide this functionality economically? As stated earlier I/O requirements vary considerably but it is quite unusual for all 40 I/O to be needed at the same time. Therefore is it possible to make the I/O multi-functional and allow the user to select the I/O type on a pin by pin basis. On the face of it this sounds like a good idea. However there are serious shortcomings to this approach. On the input side wires to the device can be 10's of metres in length often running close to other cabling which may be carrying noisy or high voltage. If these cables are directly connected to the processor without any means of protection at best it likely that we will get processor lock-ups or at worst electrical damage to the processor or the associated electronics.
On the output side a processor may be able to drive say an LED supplied off a low voltage supply but would be incapable of driving a standard relay. In any case to provide input protection and a decent output driver in one element would be costly. If the I/O was not properly configured by the user it could lead to damage to either the device itself or to external equipment. Therefore while attractive, this idea was discarded. A second option would be to include all the facilities in a single module. With some clever design this is possible albeit expensive. This option can quickly be discounted on two counts: Cost and size. We could reduce the cost to some extent by creating several different devices using the same PCB but sub-equipping by say producing an input only module and an output only module. However this does not in the end get over the size problem.
A third option would be to produce a range of products each optimised for its own level. This would be quite practical and it should be possible to select two or three I/O configurations and just stock those. There are a couple of drawbacks to this methodology though. This could not cover all the different I/O interfaces (relays etc.) without increasing the number of variants. Then there is stock holding: we would need to hold higher levels of stock because we would have several different devices. It is also less attractive to many users. Circumstances change over time and it may be necessary to expand the installation months or years after the initial install. If all the I/O was available this would reduce the possibility of having to change hardware at a latter time.
There are other problems to this approach. One thing as far as the hardware is concerned that we have not yet considered is the communication ports. For many applications we will need to communicate with some external equipment other than the general digital and analogue I/O. This may be USB, Ethernet, RS232 or the mobile phone network. If we now include these (in all combinations) in our calculation we would need to hold stock of up to 18 to 24 different items. Stock costs money and so it would increase the price of the product and at the same time, if we get the stock holding wrong, delay delivery to our customers.
So what was our final solution? We took a completely modular approach to the product. We first created the main control module. This contained the processor, USB connector plus the digital and analogue I/O circuits. We then added several auxiliary ports. All these ports were then made available via 10 way IDC headers.
We then created several I/O modules:
- 8 way input terminal.
- 8 way output terminal.
- 8 way analogue terminal.
- RS232 module.
- Ethernet module.
- 8 way relay module.
- 8 way opto input module.
- Mobile radio modem.
Each of these modules can be connected to the main board via a 10 way ribbon cable. In this way we are able to supply all the various requirements with just 8 different modules. The user wins as well. They need only buy the modules that they need for their application with the possibility of expansion at little cost.
There are some minor drawbacks. The user now needs to mount several modules instead of just a single one which would have been the case with some of the other solutions. However this is offset by the ability to mount the module in the most convenient arrangement for their installation. Another problem is customer understanding. This is quite a novel approach and for many the whole concept is not immediately apparent. But having said that those customers who have embraced the concept have been very positive.
Having designed the hardware and christened the range EMACSYS we now needed to address the functionality that we would provide. Clearly with this flexibility of hardware configuration there would be quite a number of potential applications. It would be nice if we could make the processor firmware modular as well as the hardware. However that proved to be impractical.
Therefore we made the decision to create several different but complete applications available for the product. Rather than offer these as separate shippable products we made them available for downloading to the module as required. We created a simple Windows application which would take the firmware hex file and program this into the device via the USB port. These we made available on the EMACSYS web site as free downloads. Most applications need to be configured in some way so each has its own Windows interface.
The range of applications developed so far is quite extensive. We have a number of Ethernet based applications including web servers, reporters SNMP and a sophisticated link system. We have control over text messages both in and out and a range of stand-alone control applications.
While this is a very flexible control system there are a myriad of different requirements needed for control applications. While we do offer a design service for bespoke applications this can be quite expensive for a one off application. Therefore we needed to add a method for the user to modify the firmware code at low cost. The code for our applications is written in C and it is possible to write your own code. However for most installers and users this is not an option as their skill lies elsewhere and they do not have the time to learn a complex high level language.
In response to this need we developed a very simple programming language BEPI (Basic EMACSYS Programmer’s Interface). This has been kept deliberately simple and while it does not have the sophistication of high level languages such as C it is capable of providing a high level of control over the I/O of the module. The overriding consideration in the design of BEPI was to make it as simple as possible to learn quickly.
Having developed the language we needed to design the compiler and debugger. We did not want to provide a complicated integrated design environment as this would require another layer of learning. We therefore opted to use a text editor to write the program and a separate application to compile, download and debug. All this is done using the USB port on the EMACSYS so no special hardware is required.
Finally we needed some method of allowing the user to interact with the BEPI processing so that they could control the program flow from for example a web page. To facilitate this we introduced the concept of virtual I/O. This has the same functionality as the physical I/O but is not directly connected to any. Both the user and the BEPI processing has access to these virtual I/O's and can therefore effectively talk to each other.
We now have a flexible low cost control system capable of being customised. Compromises have been made on the way and this as I have shown was inevitable. This system will not be suitable for those who need a basic control system with fixed functionality but for those who do need this level flexibility it should provide a good solution.
To see more details of the final product go to www.emacsys.com.
Roy Schofield is chief engineer at Phaedrus Ltd and is responsible for the design of a number of control and security products.
The content & opinions in this article are the author’s and do not necessarily represent the views of RoboticsTomorrow
Comments (0)
This post does not have any comments. Be the first to leave a comment below.
Featured Product
