Class SprogCommandStation

All Implemented Interfaces:
PropertyChangeListener, Runnable, EventListener, CommandStation, SprogListener

public class SprogCommandStation
extends Object
implements CommandStation, SprogListener, Runnable, PropertyChangeListener
Control a collection of slots, acting as a soft command station for SPROG

A SlotListener can register to hear changes. By registering here, the SlotListener is saying that it wants to be notified of a change in any slot. Alternately, the SlotListener can register with some specific slot, done via the SprogSlot object itself.

This Programmer implementation is single-user only. It's not clear whether the command stations can have multiple programming requests outstanding (e.g. service mode and ops mode, or two ops mode) at the same time, but this code definitely can't.

Updated by Andrew Berridge, January 2010 - state management code now safer, uses enum, etc. Amalgamated with Sprog Slot Manager into a single class - reduces code duplication.

Updated by Andrew Crosland February 2012 to allow slots to hold 28 step speed packets

Re-written by Andrew Crosland to send the next packet as soon as a reply is notified. This removes a race between the old state machine running before the traffic controller despatches a reply, missing the opportunity to send a new packet to the layout until the next JVM time slot, which can be 15ms on Windows platforms.

May-17 Moved status reply handling to the slot monitor. Monitor messages from other sources and suppress messages from here to prevent queueing messages in the traffic controller.

Jan-18 Re-written again due to threading issues. Previous changes removed activity from the slot thread, which could result in loading the swing thread to the extent that the gui becomes very slow to respond. Moved status message generation to the slot monitor. Interact with power control as a way to allow the user to recover after a timeout error due to loss of communication with the hardware.