Patent Application
20150309774
1. Field of the Invention
The present invention relates to a method of changing objects for use in a screen of a human-machine interface device of a programmable system. It also relates to a programmable computer device for changing an object for use in a display system of a human-machine interface device for a programmable system, and to a computer program, possibly one recorded on a recording medium, for running on a programmable computer device for changing an object for use in a display screen of a human-machine interface device of a programmable system.
2. Summary of the Prior Art
It is common for a programmable system, such as one involving one or more programmable logic controllers which control other elements of the system, itself to be controlled via a human-machine interface device (hereinafter referred to as an ‘HMI device’, and the term HMI will be used generally for any human-machine interface), which allows a user to interact with the programmable system e.g. by touching a touch screen of the human-machine interface device, or by otherwise acting on that screen to trigger responses. In order for such interactions to occur, the screen of the HMI device must be programmed to show appropriate images.
Such screen images are created from one or more image structures, which are generally known as “objects”. Each object may contain display parts, parts by which the user can interact with the object, such as press buttons and the like, and textual information to guide the user. Whilst the screen of the HMI device may display only one such object, it is common for the screen image to contain multiple objects, arranged in a way which enables the user best to interact with the HMI device, and hence the programmable system. Indeed, it is often the case that the HMI device will contain multiple screen images, with different objects in them, to allow different users to interact in different ways with the HMI device. For example, the screen image which is presented to someone whose sole job is to operate the programmable system may be different from the screen needed by someone who has the job of maintenance or repair of the programmable system, and an administrator of the program system may have yet another screen.
Thus, in practice, objects for use in the screen images may be stored in a library, or a series of screen structures for generating images, each containing one or more objects, may be stored in that library. The term ‘screen structure’ is used here to indicate an assembly of one or more objects, and possibly other items such as text or images, in a data structure which, when displayed on the screen of e.g. an HMI device, will cause the assembly to be displayed in a way determined by the person who created the screen structure.
In principle, the creation of an object for use in such a HMI device requires complex programming. Whilst there may be programming tools involving program elements to create the objects, the objects have to be put together in an appropriate arrangement, the various operations linked, and the appropriate scripts, etc. written in order successfully to create the object. Thus, the creation of a library of objects or screen structures incorporating such objects for an HMI device may involve considerable effort and skill.
Moreover, in the operation of a programmable system, it is often the case that new objects and or new screen structures have to be created, when the functions carried out by the programmable system are expanded or otherwise changed. In principle, when that happens, a skilled programmer needs to create a new object, or a new screen structure incorporating a new object or objects. The burden of revision of the programmable system is thus increased.
U.S. Pat. No. 7,324,856 disclosed an arrangement which sought to simplify such creation of new objects, by proposing that existing objects were modified to create new objects. The use of such existing objects to create new objects will hereinafter be referred to as “re-use” of objects. In U.S. Pat. No. 7,324,856, it was proposed that a HMI analyser was able to analyse existing objects, to generate a HMI code which could then be edited for subsequent use. Nevertheless, the programmer re-using the object has still to be able to understand and use HMI code that was generated.
U.S. Pat. No. 7,324,856 also mentioned that the HMI object editor could present a template with modifiable fields that define parameters of an object. The aim of such a template was to facilitate object editing by a less skilled programmer. However, no details of such arrangements were discussed in U.S. Pat. No. 7,324,856.
At its most general, the present invention proposes that whether or not a property or properties of an object for use in a screen of a human machine interface device is to have the corresponding variable quantity is re-assignable (i.e. can be changed by a subsequent programmer) is determined by a setting operation carried out by the programmer who initially creates that property or properties of the object. Information is stored which identifies those properties for which the corresponding variable quantity is re-assignable. Then, when the object is retrieved by a subsequent programmer, a record of which properties are re-assignable is also retrieved, and that information used to display to the subsequent programmer which properties have their corresponding variable quantity re-assignable.
Thus, when the object is created, the creator programmer determines which properties of the object may be changed (reassigned) and the information about this is then displayed to a subsequent programmer who retrieves the object. Thus, the subsequent programmer knows which properties of the object are re-assignable, and which are not, due to the setting operation carried out by the creator programmer.
Thus, according to a first aspect, the present invention may provide a method of changing an object for use in a display screen of a human-machine interface device of a programmable system, comprising the steps of:
In one alternative, the setting operation involves presenting a list of candidate ones of the properties of the object, and setting amongst those candidate ones of properties, the property or properties for which the corresponding variable quantity is re-assignable. In this arrangement, the program which the creator programmer uses to determine which property or properties may be changed and which cannot is based on a candidate list.
In such a case, the list of candidate ones of said properties of said object for which the corresponding variable quantity is settable to be re-assignable may be displayed together with check boxes associated with said candidate ones of said properties, the checking of one of said check boxes identifying the corresponding one of the candidate ones of said properties which are re-assignable, thereby to set the property or properties for which the corresponding variable quantity is re-assignable.
However, there are other possible setting operations to determine which property or a properties of the object has the corresponding variable quantity re-assignable. For example, and depending on the programming language used, the setting operation may comprise setting the variable quantity as a global variable. A global variable is one that is accessible in every scope (unless shadowed). The scope here is the context within the program in which the variable is valid and can be used. Variable shadowing occurs when a variable declared within a certain scope has a same name in a variable declared in a broad scope.
In such an arrangement, the fact that the variable quantity is a global variable enables a subsequent programmer to vary it. Quantities which are not set as global variables cannot be varied by a subsequent programmer.
In such arrangements, based on candidate's lists, global variables, or in other ways, it is convenient for the subsequent programmer if the property or properties for which the corresponding variable quantity is re-assignable are displayed in a template. The template will be derived using the association record that was created when the object was created.
Preferably, when the creator programmer determines which property or properties have variable quantities which can be reassigned, the creator programmer may set representative names for the corresponding variable quantities.
Once a new object has been created, by reassigning the variable quantity associated with the property or a property of the object, the object may be transferred to the memory of the human-machine interface device as part of a screen structure. Indeed, it is usual for objects to be stored as part of the screen structure in the library. Then, an initial screen structure is stored in the library when said object is stored in said library, the initial screen structure containing said object is retrieved from the library when at least one object is retrieved from said library, and prior to the transferring, the new object replaces the object in said initial screen structure, thereby to form the screen structure which is transferred.
Preferably, of the new object to the human-machine interface device, prior to transferring to the human-machine interface device, the screen structure incorporating the new object may be stored in the library.
It may be noted that a screen structure may involve a plurality of objects, each comprising an assembly of properties of the corresponding objects.
In a second aspect, the present invention may provide a programmable computer device for changing an object for use in a display screen of a human-machine interface device of a programmable system, the computer device having a processor and a memory, the processor being arranged to:
In a third aspect, the present invention may provide a computer program which, when run on a programmable computer device for changing an object for use in a display screen of a human-machine interface of a programmable system, causes the computer device to carry out the steps of:
That program may be recorded on a recording medium.
Embodiments of the invention will now be described in detail, by way of example, with reference to the accompanying drawings, in which:
a and 2b show displays which may be used in the present invention to display different properties of the object of
As previously discussed, where a programmable system is to be controlled by a HMI device, the HMI device will have a screen via which the user interacts with the device. The image on that screen (which is formed from a “screen structure”) is made up of one or more objects, i.e. image components which together define a part of the screen image with which the user interacts, and possibly other image elements such as text and/or images.
Thus, if the radio button 14, responding to quantity “5” is selected by the user, and the addition button 12 pressed, the value shown in the display part will be incremented by “5”, and this change will trigger a corresponding change in the programmable device controlled by the HMI device so that the quantity represented by the value shown in the display part 11 is also incremented by “5”. Others of the radio buttons 14 can be selected to change the value at a different rate, and the value can be decreased by the quantity indicated by the selected radio button 14 by use of the subtraction button 13. The object 10 shown in
However, the creation of even such an apparently simple object is not straight forward. Even if the programming tools for the HMI device include program elements to create the display part 11, the addition and subtraction buttons 12, 13 and the radio buttons 14, it is necessary for the programmer creating the object to assemble them appropriately, and to associate the various parts of the object 10, so that they perform their desired function when the object is operated by the user. In practice, the relationships needed for such assembly and association need to be determined by the programmer using a suitable scripting program, or other arrangements for creating objects for use in a HMI device, and this process requires a considerable level of programming skill. If a new object is needed, and has to be created from scratch, an inexperienced programmer cannot carry out the work needed.
Moreover, in practice, objects such as the object 10 shown in
If the programmable system is to have a new function, or it to permit one or more types of user to interact with it in different ways, two or more screen structures may need to be created. However, in some cases, the changes needed are relatively small. Therefore, it is desirable some times to use one or more existing objects, and indeed existing screen structures, but to re-use those objects or screen structures for a different purpose. The re-use effectively creates a new object and/or screen structure.
For example, there may be a wish to change object 10, so that it enables change of the programmable system so that the value shown in display part 11 is changed to change the quantity represented from one parameter to another. For example, if the object 10 is initially set-up so that the value shown in display part 11 corresponds to a temperature in some part of the programmable system, it may be desirable to use the same object 10 to control e.g. a pressure at another part of the programmable system. Thus, it is desirable to be able to change the parameter corresponding to the value shown in display part 11 from one parameter to another.
However, with existing systems, either this change has to be done by an experienced programmer, or there is a risk that an inexperienced programmer will accidentally alter some other part of the object 10. As mentioned before, the programming involved in the creation of the object 10 is complicated.
In this embodiment of the present invention, objects such as object 10 have, when they are created, a table or other list of the properties of the object for which the corresponding properties are capable of being re-assigned. Of course, there may be some properties which are incapable of being re-assigned, and such properties need not be indicated at this stage.
However, the intention is that the programmer who creates the object is presented with candidate properties for re-assignment. The creator programmer thus can select from those candidate properties those which a subsequent programmer is allowed to re-assign and which may not be re-assigned (and so are fixed by the creator programmer). That selection thus determines the ways in which the object may be re-used. Thus, when the object 10 is created, the creator determines how a subsequent programmer may re-use that object. For example, to take the object 10 shown in
Then, if another programmer wishes to re-use the object 10, he will be presented with information which showed how the object can be re-used, and the limitations on the modifications possible. For example, the programmer wishing to re-use the object may be presented with a template which shows the property or properties that may be re-assigned. It may also show properties which cannot be re-assigned, but this is not essential.
When the programmer wishing to re-use the object 10 retrieves that object, either individually from a program library or as part of a screen structure, the template will be shown at the same time. The template indicates to the programmer seeking to re-use the object 10 which properties of the object are re-assignable (i.e. which can be changed). Other properties of the object may also be displayed, but the programmer will know that they cannot be changed.
a) shows a display which a programmer creating the object 10 may use to select the property or properties of the object which may be re-assigned when the object 10 is re-used.
Various variables associated with the object 10 are listed, each with a select button 20. A name, referred to herein as a “representative name” but also referred to as a nickname or argument name, may be associated with a variable name. The variables shown in
Each radio button has its scripting program (which is not shown in the drawings) to set a value of “Unit_value” in
Thus, by operating the select buttons 20, the programmer who creates the object may select which properties of that object may be re-assigned. For example, if he selects the button 20 on line 21 only, a subsequent programmer will be able to re-assign the object 10 to a different quantity, but will not be able to change any of the other quantities, such as the quantities represented by the radio buttons 14. Similarly, if the creator selects the buttons for lines 22 to 25, but not any of the other buttons, a subsequent programmer will be able to change the values represented by the radio buttons 14, but not otherwise change the object, including being unable to change the quantity represented by the value shown in display part 11. The creator of the object 10 thus selects in advance which properties of the object 10 may have the corresponding quantity changed (i.e. the property be re-assigned).
Thus this embodiment proposes that, when an object is stored, an association record is also stored which indicates the property or properties of the object which are re-assignable and which are fixed. The creator programmer of the object determines the association record by selecting the re-assignable property or properties from candidate properties.
When a subsequent programmer retrieves the object 10 for re-use, the display shown in
When a subsequent programmer re-uses the object 10, the display shown in
The programmer re-using the object thus is presented clearly with information that enables them to tell which properties of the object 10 can be re-assigned, and which cannot. This system enables the programmer re-using the object 10 to have a lower programming skill than the programmer who creates the object 10, but still be able to re-use the object by re-assigning the properties of the object which the creator has determined are available to be changed. The creator restricts the properties which can be changed, thereby limiting the ways that the object 10 may be re-used.
In the arrangements described above, the programmer who creates the object selects which properties of the object have variable quantities that may be re-assignable using template illustrated in the display of
In practice, the display of a HMI device may show many objects, which are generally stored in the library. Indeed, it is usual for one or more objects to be assembled into a screen structure, and multiple screen structures stored in a library. That library may be stored in a memory of the HMI device itself, but it is more usual for the library to be stored in a separate computer device, such as a PC, and for only the screen structures which the HMI device needs for its current operation be copied from the library to the memory for display by the display of the HMI device.
Thus, a subsequent programmer may retrieve one of the screen structures from the library, and re-use one or more of the objects in that screen structure for a different purpose, by re-assigning the property of the object to a different parameter effectively, a new object, and hence a new screen structure, is created and then transferred to the HMI device and also optionally stored in the library. Of course, it is also possible that when an object is re-used, the new object thus created is stored separately in the library.
A subsequent programmer may re-use an object independently of a screen structure or may extract an object from a screen structure for re-use, and may combine a plurality of re-used objects into a new screen structure.
An example of a programmable system involving a HMI device is shown in
Different users may require different screen structures, to permit them to carry out different functions on the system (e.g. operation, repair, or administration) and each of the screen structures may involve one or more objects.
Programming of a library of screen structure for use in the HMI display device 106 is carried out in a separate computer, such as a PC 110, that may be connected to the HMI display device 106. Initially, an experienced programmer may create multiple objects for the HMI device display 106, and assemble those objects into the appropriate screen structures that will be needed. Those screen structures may be stored in a library of screen structures, one or more of which screen structures is then transferred from the PC 110 to the HMI display device 106, e.g. via connection 111. The PC 110 will normally be pre-programmed with an appropriate tool program, from e.g. a disc 112.
Suppose now that a subsequent programmer wants to re-assign one or more objects of one or more of the screen structures stored in the HMI display device 106. In such circumstances, the library of screen structures retrieved at the PC. One or more of the objects may then be re-used, as described previously, to create a new screen structure containing that new object. The screen structure is then added to the library, and transferred back to the HMI display device 106 for subsequent use by re-connecting the PC to the HMI device.
It should be noted that, in the creation of a new screen structure, an existing screen structure in the library may be retrieved and one or more objects of that screen structure re-used, with other elements (includes other objects) of that screen structure unchanged. The existing screen structure is thus itself retrieved. Even if only a small unit of an existing screen structure is re-used, a new screen structure is created.
In practice, the screen structures stored in the library may be stored as source lists which are compiled into screen structures for display on the HMI device 106 when the screen structure is transferred to the HMI device 106.
The creator programmer then selects amongst the boxes 20 in
Similarly,
Thus, with the present invention, a first programmer may create complex objects and pre-determine which properties of those objects may be re-assigned. Other properties are then fixed. When a subsequent programmer, who may be less experienced, then wants to re-use the object, that programmer is presented with information from a template created from an association record set at the time when the object was created, and stored in a way linked to the object, to display to that subsequent programmer which properties of the object may be re-assigned. When those properties are re-assigned, a new object is created and may be stored in e.g. the library of objects from which the object originally came. As mentioned, objects may be stored or grouped together in screen structures.
Furthermore, when an object is created, the programmer creating the object is presented with a list of candidate properties of the object which are available for re-assignment to allow the creator programmer easily to select the property or properties which a subsequent programmer is allowed to re-assign. This simplifies the selection process for the creator programmer.
| Number | Date | Country | Kind |
|---|---|---|---|
| 1221317.9 | Nov 2012 | GB | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/GB2013/053107 | 11/25/2013 | WO | 00 |
