Oliver Barrett

Hello Mark, I found my Railroad Interlocking Controller file in the same General category as before, thanks for replying. Best regards, Oliver

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

Hello Michael et. al., Much appreciate your hard work, especially all your data recovery efforts. I gather that restoration of the code repository contents is still ongoing (I'm particularly interested in the General category)? Thanks again! Oliver Barrett

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

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