Jump to content

Oliver Barrett

Members
  • Posts

    6
  • Joined

  • Last visited

Posts posted by Oliver Barrett

  1. index.php?app=downloads&module=display&section=screenshot&id=76

    Name: Railroad Interlocking Controller

    Submitter: LAVA 1.0 Content

    Submitted: 04 Jul 2009

    Category: General

    LabVIEW Version: 8.6

    Version: 1.0.0

    License Type: GNU Public

    Potentially make this available on the VI Package Network?: Undecided

    Copyright © 2009, Oliver Barrett

    All rights reserved.

    Author:

    Oliver Barrett

    --see readme file for contact information

    www.linkedin.com/in/orbarrett

    Description:

    THE APPLICATION CONTROLS A SIMULATED RAILROAD INTERLOCKING CONSISTING OF PASSENGER STATION TRACKS, A GRADE CROSSING BETWEEN TWO RAILROADS AND A RAILROAD SWING BRIDGE.

    All switches and track signals are controlled for the purpose of safely lining one train movement through interlocking at a time. Simulated occupancy of each track section by a train movement is displayed.

    Interlocking operator can select the following functions from the application screen:

    1. Line a selected track switch for movement into or out of the passenger station siding tracks.

    2. Line one of five preconfigured interlocking configurations (eastbound, westbound, northbound, southbound or Stop), in preparation for a simulated movement in the same direction (movement will wait outside interlocking limits if configuration at Stop).

    3. Select a movement direction and initiate a simulated train movement through interlocking.

    A simulated movement (begun by clicking on the Initiate button) will not proceed completely through the interlocking unless the latter is configured for the same direction as the direction of movement. Such a movement may progress partway until it encounters a red signal and will then stop. It may be restarted by first lining the interlocking for the proper direction and then clicking on Initiate again.

    Track signal indications will update in real-time to reflect occupancy condition (unless overriden by current interlocking configuration). The indicator for an occupied track section appears orange, otherwise green.

    Each signal indicates PROCEED (green) or STOP (red). One or more signals will be forced to display STOP as part of a preconfigured interlocking movement direction (irrespective of track occupancy).

    LABVIEW STRUCTURE

    The application uses a Producer-Consumer (Events) design pattern. The interlocking function requests are handled by the producer loop, with separate consumer loops for lining a siding switch, configuring an interlocking direction and initiating a simulated train movement. A separate display loop executes in parallel.

    Separate queues are used to pass operator requests for lining a track switch, configuring an interlocking direction and selecting a direction for simulated train movement, using a different enum typedef for each. State machine design patterns are used within the track switch lining, interlocking configuration and interlocking movement subVIs.

    Four functional global variables are used for all state data involving track occupancy, switch and bridge states, signal override states (the latter used for lining a given interlocking direction) and current relative movement location/movement direction.

    The display loop is initialized by a notifier at the beginning of application execution and runs in parallel to continuously update track occupancy display along with switch and bridge states and all signal indications reflecting interlocking conditions.

    SubVIs are used in the display loop to read the binary state word supplied by the functional global variables associated with the track occupancy states, switch/bridge position states and signal override states.

    Dependencies:

    None.

    Change Log:

    1.0.0: Initial release of the code.

    Click here to download this file

  2. Hello all,

    Thank you for the the replies. I'm actually storing a composite binary code to store the signal states in a functional global already, which helps. I thought of using the phantom cluster approach, but I expect that the cluster border (even if transparent) would have to be expanded to cover a large area of the front panel where my indicators are placed. Since I actually have three groups of indicators that cover different functional purposes, their cluster boundaries would have to overlap, don't know whether that would be an issue.

    I'll think about this approach further though.

    Regards,

    Oliver

  3. Hello all:

    This is my first forum post. I have a large number of Boolean indicators on the front panel of my application that simulates railroad movements and signalling on a track diagram. I want to have these indicators contained within an array so that I can write Boolean state info to each indicator without a lot of block diagram wiring, but don't know how to do this when the indicators are dispersed at various locations around the front panel (vs. adding an indicator to a rectangular array "container" in the usual way when the front panel objects are built).

    I would much appreciate any suggestions you may have.

    Thanks!

    Oliver Barrett

    CLAD

    www.linkedin.com/in/orbarrett

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.