Movement Controller

Woodgrove Digital Engineering P⁄L created a software package called “Movement Controller” for the automation of warehouse equipment, with particular emphasis on heavy-unit-load and carton conveyor systems, stacker cranes, pick-to-light systems, and palletisers.

The corner stone of this product is the “Conveyor PLC Code Generator” software package, which automatically produces full PLC ladder logic and Man-Machine interface software for heavy-unit-load conveyor systems.

The Man-Machine interface software integrates the control and supervision of the heavy-unit load conveyor system, stacker cranes, palletisers, carton conveyor system and pick-to-light system and may be extended to the many other systems constituting the automation of a warehouse.

What are the benefits?

Fast and accurate code generation, reducing, by over 90%, the programming and debugging time - generally what would normally take one person months to complete can now be accomplished in less than a day,
Quality control of the software is achieved through the automation of the writing of the software,
Software simulation is available for customer demonstrations when tendering and, subsequently, for testing the management information system interface,
Software is available for electrical commissioning from day one,
No delays or risks resulting from software,
Minimal cost impact from design changes.

How did it come about?

At Woodgrove Digital Engineering P⁄L, we have been programming PLCs for conveyor systems since 1985. We have developed a very robust approach to the problems of load tracking, exception reporting, safe and flexible integration of manual and automatic control, and the concise and secure communications to a supervisory computer.

The “Conveyor PLC Code Generator” is the embodiment of our experience in the programming of conveyor systems.

In 1985, I was asked to provide an interface between a Digital VAX minicomputer and the PLCs that were controlling the cranes and conveyors that comprised the automatic warehouse for Mobil Oil in Yarraville, Victoria. There was a team of programmers responsible for programming the VAX. They were uncomfortable with the task of communicating with the PLCs, so that task fell to me to accomplish with an IBM XT personal computer. I created the required program. It included a real-time, multitasking executive, based on one that I had previously written for my work in programming microprocessors. It also had a a multi-user database, which I developed specifically for this project (though it has evolved substantially since then). The software needed protocol drivers for the Allen-Bradley DF1 serial communications, and for the communications to the VAX. Then there was the application code to control where the cranes would locate their loads and so forth. Additionally, I provided diagnostic software to monitor the various serial communications links and to examine the data memory of the PLCs.

Subsequently, I was given the task of controlling the automatic warehouse for Mobil Oil in Wellington New Zealand, using an IBM-AT personal computer, but, this time, without the VAX; my personal computer did all the work. This was followed by several other similar projects, allowing me to develop the software further.

Then, one day my partner in Coromont Pty Limited got it into his head that he was going to produce heavy-unit-load conveyors, production-line style. I figured that those expected savings would have been minor, unless I also managed to produce the complementary software in a similar manner. It did not take me that long to figure out what I needed to write, and when I worked that out, it was daunting. So I split the task into pieces that would be useful to me even if I never completed the project.

The stages were:

I needed to write a compiler to generate PLC software from a series of high-level language files, some of which would be, ultimately, generated by software.
At this stage my software already had the ability to present the PLC program in ladder on its display, showing live data, for fault diagnosis. In case you are not familiar with "ladder", it is the most popular PLC programming style among electricians due to its direct analogy to relay logic.
Then I needed to write an emulator for the entire Allen-Bradley PLC-5 and SLC-500 instruction sets. This involved translating each of those instructions to 8086 assembler instructions (which still form the basis of all Intel microprocessors). This was further complicated by the need for using “fixups” in jump and call instructions. Then it would use that correspondence to read in the PLC program and translate it into 8086 instructions. In converting the Allen-Bradley PLC instrctions into the 8086 instructions, I kept a record of what the various 8086 registers had been loaded with, so as to avoid loading those registers with what they already contained.
The next stage was to generate the high-level language files, needed by the compiler, from a definition of the conveyor system that had been entered into the database (the one that I wrote back in 1985, which, by the way, seems to have been one of the only pieces of software to have anticipated the year 2000 😇). These high-level programs incorporated not only automatic control but full manual control down to the individual conveyor, allowing you to drive as many conveyors as you desired. This was a feature not allowed for in hand-written code of the time. I should explain that heavy-unit-load conveyor PLC software is very hard to write faultlessly, since every transfer must be written individually; no subroutines for common sequences of instructions, as they would make the ladder display incomprehensible. So the advantage of it being computer-generated is not only a time saver but also a huge step forward in the correctness of the code. Also, having the software computer-generated, allows you to put more thought into adding more advanced features to each transfer. It also allowed me to do thoughtful things like organise the transfers in a forward order and the conveyor drive outputs in the reverse order so that there'd be no glitch to the contactors as one transfer would end and the next begin (a glitch pointed out to me by one of the electricians with whom I was working). The conveyor PLC code generated also included a program file that would emulate the action of the field devices, so that, via the PLC emulation already developed, we could test the software against a full emulation of the plant.
Also, from the database-based definition of the conveyor system, I needed to generate the tables upon which the graphics are based. This was probably the hardest piece of software I ever wrote, as can be seen from the level of comments therein - more comment than code. What made it so complicated was the fact that multi-load conveyors were often longer than the length implied by the number of loads that it accommodates.
Then, of course, I needed to generate the man-machine interface from those tables. The man-machine interface also provided for the manual control of the conveyor system. Given that this is a multi-user system, I needed to give careful consideration to the application of manual control from multiple remote locations at the same time, which, I don't believe, any other package has done.
It soon became apparent that the work in entering the conveyor definition into the database could, itself be automated. Heavy-unit-load conveyor systems are, in my experience, always based on an orthogonal grid, with conveyors running in one of the four nominal directions, North, South, East, and West. It has a lot to do with the buildings housing them having square corners. So, by selecting the rear conveyor in each such string of conveyors, then entering the name of the conveyor to which it feeds, and so on, we could quickly enter the bulk of the definition of the system. You would then need to edit the database tables directly for those conveyors for which the default values were inappropriate.

After that initial stage, I continued the development of the product.

After completing the warehouse for P&O Cold Storage (now Americold), I decided to create a single document to describe the software for all my sites; I was tired of writing manuals for each site then trying to maintain them all as the software developed. I realised that this was not the best approach, as the manual would contain a lot of irrelevant and generalised information for each site. So, while P & O Cold Storage were digesting the manual that I'd given them, I was busily writing a word processor that would take source documents for the manuals and generate a set of site-specific manuals. By the time that P & O decided that they didn't like my manual, I had a new one to give them 😏. The word processor, originally, produced HP PCL output, but I have since upgraded it to generate RTF and HTML output.
Having created a word processor, I could now use that to produce the context-sensitive help for the software as well. The help provided on-line access to all three manuals associated with the system.
Up until now, this work had been based on MS-DOS. I felt it was time to embrace a more modern user interface, so I ported the software over to Linux, using X-Windows and Gtk+. It was this version of the software from which I developed the application for Joyce Foam. Subsequently, I approached News Limited with the view to retrofit the MS-DOS based systems that I had provided them with the Linux-based alternative. They told me that they only supported Microsoft Windows at their sites, so I then busied myself with the task of porting the software from Linux to Microsoft Windows. After updating their sites in Victoria, New South Wales, and Queensland, I approached Versacold (which was previously P & O Cold Storage and later to become Americold) with the offer to upgrade their site to Microsoft Windows. After I achieved that, I received a lot of flak from the operators who had come to love the old MS-DOS based product 😖. So, my next task was to provide an option to have the display emulate the MS-DOS version.
Then Direct Group asked me to add an HTTP interface to the software so that they could place orders from remote locations without the need for them to have the software installed on each computer that they wished to order from. It would have been relatively simple to just supply that one function, but, if you're going to do something, you may as well do it properly. The HTTP interface served HTML and other files from a subdirectory called "www" to the client. Such an interface is very limited, unless there is a way to add live plant data to those files, so the HTML files were written with PHP-style escapes that the software would look for and insert the live plant data. But inserting live data is one thing, but keeping it live is another, so, along with the HTML file I needed to deliver a Javascript file that would make AJAX calls to update itself with the live data. This extension has also been provided for each of the sites, other than Joyce Foam, where the computer has no Internet connection.
As I said, if you're going to do something, you may as well do it properly. The conveyor system diagram, which contains all the computer-generated graphics, was presented with text summary information, so there remained the task of presenting the graphic via HTTP. So, for that, I delivered a Javascript file, along with tables derived from the tables from which the normal graphics are generated. That Javascript file would build up, using SVG, the conveyor system diagram, then use AJAX instructions in order to maintain its display.
From the earliest version of my database software, I had provided the ability to restrict the display to showing only those records that shared the same value in their corresponding fields. This was sufficient for the needs of my customers, but for some time I had the notion of implementing a more complex query system. My original intention was to base it on PLC ladder, given the roots of the software, but, ultimately, I decided that it would be a lot easier, both for me and the user, to base it on the SQL WHERE and SET clauses.