Monday, August 1, 2005

IDES Pop Machine Version 2

Pop Machine Circuit

Details on IDES software - Master Unit - Slave Unit - Software that communicates with Pop Machine
Legal.gml - Model of Pop Machine for import to IDES
Plant.gml - Model of Pop Machine for import to IDES
See Also: IDES Pop Machine Version 1

Let there exist a very simple pop machine designed according to the following specification. The machine will accept only one form of currency, which we will call a token. The machine will dispense only one form of pop which we will call pop. The machine can contain zero, one, two, or three pops. A technician can refill the machine, bringing the current number of pops to three. The machine has memory and keeps track of the current number of credits. Credits are tokens that have been inserted into the machine, but not spent. When a pop is dispensed by the machine, the current number of credits is decremented by three unless the current number of credits was less than three in which case the credit total is unchanged. This undesirable behaviour (pop dispensed, but credits not decremented) is called lost pop. Finally, the machine can be reset, which sets the current number of credits to zero and the current number of pops to three.

Circuti Diagram

The machine also communicates with a controller. The machine notifies the controller of the events listed in the legend below:


This FSM represents the plant. Obviously, considerable detail is hidden, such as the exact number of credits in the machine. T and R are uncontrollable events while P, P+ and L are controllable. Imagine the following mechanism: when the user presses the request pop button, it is physically connected to the pop exit slot, and it opens (releasing one pop) as long as a little metal pin isn't blocking the slot. All our controller can do is control this little pin, and hence it can prevent the dispensing of a pop.


The legal language is simply the plant minus the L events. A valid supervisor equals the legal language, and L(S/G) also equals the legal language. The device has been programmed to only allow a requested event (such as L) if the software echoes the event. Consequently, if we run a software trace with L(S/G) we see the controlled behaviour in the plant. Meaning, if we open the plant in the IDES software and run a trace then pops will be dispensed by the hardware even if there are insufficient credits, but if we open L(S/G) in the IDES software and run a trace then the pops will only be dispensed if there are sufficient credits.


I don't feel that I've demonstrated anything particularly useful, but this is my first realization of a controller acting on a plant in the classical way.

I've used two pic16f84 microcontrollers. The chip beside the LCD functions as a slave unit and only controls the LCD. It receives two byte packages from the master unit via serial communication and updates the LCD accordingly. The master chip handles the "Insert Token" button, the "Request Pop" button and the "Pop Delivery" LED. It also sends notification of events to the PC via an rs232 connection at the bottom left of the circuit, and commands the slave chip to update the LCD via rs232 over the two green wires at the centre of the circuit. The red toggle switches allow isolation for programming in place. The two bundles of wires exiting the circuit at the left are for programming in place. The green wire mess on the slave circuit where the red toggle switches would be is simply a hardwired version of the toggle switches in the "normal" configuration. Note that the master chip can command the slave chip to display the startup logo on the LCD, but the resetting prompt only appears on the LCD when the slave chip has been physically reset via its button. Also note that the capacitors for the master chip's clock circuit are missing only because I ran out. Technically, the circuit shouldn't work without them.

The slave unit code is written in C and compiled using PICC LITE. It is available for download as and contains the following files:

  • main.c : The main program. It includes the pinout for the 16f84 and comments on the serial connection.
  • lcd.c : The LCD routines. It includes the pinout for the LCD and all lcd related code. This code depends on delay.c
  • rs232.c : The rs232 routines. These are used only for serial communications with the master pic. This code depends on delay.c
  • delay.c : Simple delay routines.
  • delay.h : The header file for delay.c
  • MAIN.HEX : The compiled code.

The master unit code is written in assembly and compiled using MPASMWin. It is available for download as and contains the following files: Note that discussion of serial cable connections (for the PC connection) are included in the rs232.c file from the package, and that documentation is not include here, although it certainly applies.

  • main.asm : The main program. The pinout is not included, but should be obvious from circuit photo. All pin references are done using EQU, so the "equates" section at the top of the code should suffice as a pinout specification.
  • : The generic include file that specifies equates for basic register names, etc.
  • main.LST : The listing file generated at compile time.
  • main.HEX : The compiled code.

The plant and legal fsm models demonstrate the interface between the IDES hardware and software. When connected, the software can both trace and control the hardware. It is files for the plant and legal models are available as plant.gml and legal.gml Just in case the software is greatly modified in the future the installation zip used at the time of this writing is available as

{ "loggedin": false, "owner": false, "avatar": "", "render": "nothing", "trackingID": "UA-36983794-1", "description": "", "page": { "blogIds": [ 240 ] }, "domain": "", "base": "\/michael", "url": "https:\/\/\/michael\/", "frameworkFiles": "https:\/\/\/michael\/_framework\/_files.4\/", "commonFiles": "https:\/\/\/michael\/_common\/_files.3\/", "mediaFiles": "https:\/\/\/michael\/media\/_files.3\/", "tmdbUrl": "http:\/\/\/", "tmdbPoster": "http:\/\/\/t\/p\/w342" }