RailQuik can be downloaded here .

As I'd mentioned previously, I developed RailQuik primarily for my own use.  While I wanted to share it with others, given my limited hobby time and lack of Access experience, I didn't put a lot of time into making it easily configurable for others through the use of variables.  Other users may add that functionality down the road, but for now, tailoring RQ to your own needs will require a number of simple manual updates.  None of it is difficult, even for those who lack Access experience.  I was completely new to Access when I started RQ, so I have no doubt that subsequent users can easily modify what I've done.    

Below is an outline of the changes necessary to adapt RQ for your own use.  Don't let the size of the list scare you, because each change is simple, e.g. updating "IAIS" references from my prototype to your own road's reporting marks.  

Please note:  Nearly all updates listed below will be accomplished in Access by right-clicking on the particular object (table, query, form, report, etc.) in the navigation bar on the left and clicking on Design View.  In addition to that step, the other major thing to remember is related to forms (screens) that have fields with drop-down lists.  To update the values displayed in those lists, once you're in Design View, if the Property Sheet isn't visible to the right, right click on the screen and click on Properties.  Click on the field whose drop-down list values you wish to modify.  In the Property Sheet, click on the Data tab, and in the Row Source field, you'll see a list of valid values for that field's drop-down.  

Overview
1. I STRONGLY suggest you play around with RailQuik using my *existing* Shipments, Roster, and ShipmentCar data before changing anything.  Getting familiar with what RQ does today will be a great help going forward as you modify it for your own needs.     

2. RQ user Bob Burke recently pointed out that Access has a "Find & Replace" function on the Home tab.  This can be used to update data values, but apparently not field names.  Its best to replace one occurrence at a time in case there is another use for the word you are trying to replace.  Just keep clicking Replace.       

3. Change "IAIS" references to your railroad     

4. Change "BICB" references to symbol of a train inbound from staging.  You can simply replicate queries, reports, forms, drop-down field value references, etc. for other inbound trains.  However, if modeling something more complex that my prototype's one-inbound, one-outbound daily operations scheme, I'd recommend instead updating RQ to make the inbound symbol a variable, allowing you to re-use the same queries, reports, forms, etc. for all inbound trains.  RQ handles my prototype's scenario just fine as-is, so I didn't take it any further for my own needs, but it would definitely serve as a solid platform for doing so.  Hopefully any users who pursue that will share their work with the RQ Yahoo group for use by others.  If they do so, I just ask that it remain freeware.     

5. Change "CBBI" references to symbol of a train outbound from an on-layout yard to staging.  As with the BICB references, you can simply replicate what I've done, or you can update it to make it configurable.    

Tables 
The table-specific notes below are intended to reflect those changes that are necessary to adapt the table *structure* to your needs.  However, the *data* for all tables will also have to be updated for your layout.      

1. BOIchgCars     
2. BuggyHoppersHancock - Elevator/industry name to be replaced if applicable.     
3. BuggyHoppersHarlan - Elevator/industry name to be replaced if applicable.     
4. BuggyHoppersWestPlains - Elevator/industry name to be replaced if applicable.     
5. HopperOrderHancock - IAISCars, BNSFCars, KCSCars field names.  Elevator/industry name to be replaced if applicable.     
6. HopperOrderHarlan - IAISCars, BNSFCars, KCSCars field names.  Elevator/industry name to be replaced if applicable.     
7. HopperOrderWestPlains - IAISCars, BNSFCars, KCSCars field names.  Elevator/industry name to be replaced if applicable.     
8. IDOrder - ID values from "ID" field in forms, sorted and numbered in timetable order.     
9. RejectedHoppersAdair - Elevator/industry name to be replaced if applicable.     
10. RejectedHoppersHancock - Elevator/industry name to be replaced if applicable.     
11. RejectedHoppersHarlan - Elevator/industry name to be replaced if applicable.     
12. RejectedHoppersWestPlains - Elevator/industry name to be replaced if applicable.     
13. RoadUnitsToShop - Unit numbers and shop locations to be updated for your layout.     
14. Roster - One record for every car on your roster.     
15. ShipmentCar - One record for every Shipment/Car relationship on your layout.     
16. Shipments - One record for every Shipment on your layout.     
17. StationOrder - Station values from "Station" field in forms, sorted and numbered in order of appearance.     
18. TotalQty - Sum of Qty field values from Shipments table.    

No updates are necessary for the following tables:      

1. RandCars     
2. RandRoster     
3. Seq     
4. SeqMaster    

Queries      
- BICBGrpStationMinBlockQuery - Update "BICB" in filename and criteria check to the symbol of an inbound (i.e. from staging) manifest on your layout.  Replicate this query for other inbound manifest symbols as needed.     

- BICBQuery - Update "BICB" in filename and criteria check to the symbol of an inbound (i.e. from staging) manifest on your layout.  Replicate this query for other inbound manifest symbols as needed.     

- CarQueryCBSW - Update "CBSW" in filename to symbol of your yard job, and update Roster.Station criteria to the station value of your yard, if you care to have separate yard reports for yard and road crews.  Update Roster.Track criteria check, replacing "CBBI" with the symbol(s) of your outbound manifest(s).  You may wish to replicate this query to allow for multiple yard jobs or industrial zones.     

- CarQueryRoad - Update Roster.Station criteria to the values of stations served by road jobs.  You may wish to replicate this query to allow for multiple local "zones".     

- CBBIGrpStationMinSeqQuery - Update "CBBI" in filename and Roster.Track criteria with the symbol(s) of your outbound manifest(s).  You may wish to replicate this query to allow for multiple manifests.     

- CBBIQuery - Update "CBBI" in filename and Roster.Track criteria with the symbol(s) of your outbound manifest(s).  Update CBBIGrpStationMinSeqQuery.MinSeq reference to instead use your updated query above.  You may wish to replicate this query to allow for multiple manifests.     

- CBBITonnageForecast - Update "CBBI" in filename with the symbol(s) of your outbound manifest(s).  Update Roster.ID criteria to check for values of off-layout stations to which you're routing cars.  This query provides tonnage data on all cars leaving the yard on this particular manifest, plus those that are due to be pulled along the way for routing in the same direction.     

- IchgQuery - Update Shipments.IBOrigin criteria to the values of the railroads with which your layout interchanges.     

- QueryBOIchgCars - Update "Int((2)*Rnd()+1)", altering "2" to the number of records you choose to have in the BOIchgCars table.  The presence of two records equates to a 50% chance of a single inbound interchange car being marked Bad Order out of the entire session's interchanges (one B/O record in BOIchgCars, one "good" one), NOT a 50% chance of _each_ interchanged car being B/O  Four records equates to a 25% chance (one B/O, three good), 10 records to a 10% chance (one B/O, 9 good), etc.    

Like QueryBOIchgCars, each of the following Buggy, HopperOrder, Rejected, and RoadUnitsToShop queries use a similar algorithm against their respective table to ensure the generation of the various conditions according to prototype ratios.  "N" in "Int((N)*Rnd()+1)" for each query always equates to the number of records in the corresponding table, so if you alter the probabilty of a particular event by adjusting the number of records, be sure you update the respective query's formula to match.   

Buggy, HopperOrder, and Rejected queries will have to be updated to reflect elevator/industry names for your layout.   

While some of the events I'm generating are specific to grain elevators, many could be applied to any industry.  The same basic logic could be applied to the generation of virtually any event.  Just be sure you update macDSShiftTurnover with the appropriate queries so all can be generated at once by clicking on "6 Dispatcher's Shift Turnover".   

Buggy hoppers in the queries below are those that have already been loaded at the elevator, but then the contents fail quality tests.  These cars have to either remain at the elevator so they can be dumped after other loads are pulled, or else they're shipped to an alternate cosignee if a buyer can be found to use the grain for non-human consumption, e.g. cattle feed.      
- QueryBuggyHoppersHancock     
- QueryBuggyHoppersHarlan     
- QueryBuggyHoppersWestPlains  

Due to the way my prototype fills covered hopper orders, I'm choosing to handle them with the following three queries, outside of the normal car order generation, instead just generating events that tell me how many cars the elevators wants from each supplying railroad.  There are just too many interesting wrinkles in empty covered hopper routing to accurately cover them all with automated generation, and many of those wrinkles require human interaction, adding a lot of interest to the process.  For example, empty IAIS covered hoppers (called "dispos" because the exact elevator to load them hasn't been determined, meaning they're "open disposition") could move onto the layout from the BNSF interchange at Council Bluffs, on a westbound IAIS train coming from staging, or they could already be on the layout, tied down in a siding pending elevator orders.  It's up to the Trainmaster (me) to determine how he'll fulfill an elevator's order, as well as determining where to store any additional inbound hoppers until more orders arrive.   

Once hopper orders are generated and the source(s) of those hoppers is determined, I just hand-write their quantity in on the appropriate interchange, train, and/or yard report.  For example, insteads of listing 10 specific car numbers, I write "10 dispos".  Or, if hoppers are BNSF or KCS cars, I write in "0-10 KCS hoppers" (zero loads/10 empties), for example, as might be done on the prototype when last-minute changes were made.      

- QueryHopperOrderHancock     
- QueryHopperOrderHarlan     
- QueryHopperOrderWestPlains  

Rejected hoppers are those that, after spotting to the elevator, were found to have some mechanical defect that prevented their use - often faulty gates.  These cars are routed to the RIP track at Council Bluffs for repair, and after repair must then be routed back to the elevator for loading.  My queries for rejected hoppers include those from the off-layout elevator at Adair, as rejected hoppers from there move to and from the Council Bluffs RIP on manifest trains.       

- QueryRejectedHoppersAdair     
- QueryRejectedHoppersHancock     
- QueryRejectedHoppersHarlan     
- QueryRejectedHoppersWestPlains  

This query determines any road units that must be added to a Council Bluffs-bound train, in addition to those needed to move the tonnage, for attention by the shop there.      

QueryRoadUnitsToShop  

SeqTruncCarID - This query controls the overall number of cars generated per op session.  Update ">Int(8 * Rnd() + 26)", altering "8" to the result of "upperbound - lowerbound + 1", where "upperbound" is the maximum number of cars you want RQ to generate per op session and "lowerbound" is the minimum number, and altering "26" to that same minimum number.   

No updates are necessary for the following queries:      
- Car Query     
- CarFormQuery     
- CreateSeq     
- LEQuery     
- LocoFormQuery     
- MakeRandCars     
- RandRstrAppCars     
- RandRstrGetMaxModRand     
- RandRstrUpdtModRand     
- RosterStatusHoldtoOB     
- RosterStatusIBtoAvail     
- RosterStatusIBtoHold     
- RosterStatusOBtoAvail     
- RosterUpdtSelected     
- RosterUpModRand     
- SeqAppCarID     
- ShipmentsUpdtFactor     
- ShipmentsUpdtTtlQty     
- StatusAvail     
- StatusHold     
- StatusIB     
- StatusOB     
- StatusOOS     
- UpdtLocoSeq  

Forms 
Multiple "IAIS" references throughout on individual form/screens.  MainMenu references to IAIS-specific train symbols will have to be updated with your own.  All forms containing Track, Station, Block To, ID, or Commodity must have their associated drop-down values modified to fit your needs.      
- AboutRQ     
- AvailCars     
- Car     
- InboundCars     
- Locomotive     
- MainMenu     
- OnSpotCars     
- OOSCars     
- OutboundCars  

Reports 
"IAIS", train symbol, location, and date references will have to be updated throughout the following reports.      

- CBBITonnageForecast     
- IchgReport     
- TrainListBICB     
- TrainListCBBI     
- YardReportCBSW     
- YardReportRoad  

Macros      
- macCBBIQuery - Update train symbol references for outbound trains.     
- macDSShiftTurnover - Update individual query references to generate all desired events.  

No updates are necessary for the following macros:      
- macSelectCars     
- macUpdtRoster  


Configuration 
Below is a field-by-field guide to configuring the three primary tables used in RQ: Shipments, Roster, and ShipmentCar.   


SHIPMENT - Contains one record for every origin/destination pair.      

Shipment - Unique shipment identifier     

IBOrigin - Inbound Origin, i.e. the train symbol or interchange railroad from from which this move originates.  First six records in my sample file are for power on the inbound train, allowing up to six locomotives to appear properly in the train list.  More "ENGINE" records can be added as needed.  Please note, the "inbound" label for this and the next several fields refers to movements that are inbound from staging or interchange to the visible portion of the layout, though they may also continue through as bridge moves to an interchange on the other end of the railroad.  Outbound moves are those that are originating on the visible portion of the layout and moving to staging or interchange.     

Block - Block ID to allow cars to appear properly blocked in train lists, or to cause cars that likely would be grouped together in an interchange cut (e.g. cars from the same shipper to multiple IAIS cosignees) to appear together in the interchange report.  For interchange cars, i.e. those with an IBOrigin value of a railroad reporting mark, the sequence of the Block values is random, since aside from the aforementioned grouping, the cars will be as well.     

IBLE - Load/Empty indicator for the inbound leg of this shipment.     

IBBlockTo - Block To value for the inbound leg of this shipment.  This is the customer or railroad to which the movement is destined.     IBID - The station identifier of the customer or railroad specified in IBBlockTo.     

IBCommodity - The Commodity value for the inbound leg of this shipment.     

IBBO - The Bad Order value for the inbound leg of this shipment.     

OBLE - Load/Empty indicator for the outbound leg of this shipment.     

OBBlockTo - Block To value for the outbound leg of this shipment.  This is the shipper or railroad to which the movement is returning.     

OBID - The station identifier of the shipper or railroad specified in OBBlockTo.     

OBCommodity - The Commodity value for the outbound leg of this shipment.     

OBBO - The Bad Order value for the outbound leg of this shipment.     

Qty - Number of cars that moved in this shipment on the prototype.  I started out using the exact figures from the IAIS, but later found that I had to normalize these figures to account for the fact that my roster is smaller than the prototype's.  Before normalization, the most common moves had so many cars that they were always chosen first, leaving no room for the less common moves to ever appear.  I reduced the Qty values for the most common moves across the board so that they're still higher than the less common moves, keeping the ratios accurate, but not so high as to overshadow everything else.     

TotalQty - Total number of all cars that moved in all shipments on the prototype.     

Factor - The Qty value divided by TotalQty, giving a frequency indicator that, during car order generation, is multiplied times a random number generated for each car to determine the car orders to generate.     

Haz - Hazardous materials flag.  Since hazardous movements retain their hazmat notation whether loaded or empty, this flag applies to both the inbound and outbound legs of this move.     

Mandatory - Flag indicating that the movement is mandatory (i.e. that a car order will always be generated), overriding the Factor/random number generation mentioned above.       

Move - Move description.  Not used, but handy for testing.  



ROSTER - Contains one record for every car and locomotive on the layout.      

IDCar - Unique car identifier.     

Initial - Reporting mark initial.     

Number - Reporting mark number.     

Status - Indicator of the car's current status.  Set by RailQuik.  Valid values are:  
0 = Available  
1 = Inbound  
2 = On spot  
3 = Outbound      

AssignedShipment - Shipment ID (from the Shipments table) for the shipment to which this car is currently assigned.  Set by RailQuik.     

ModRand - Factor from Shipments table multiplied times a random number generated for this car.  Cars with the highest ModRand value are chosen for car order generation.  Set by RailQuik.     

Ignore - Flag indicating that this car is to remain in its current Status until the Ignore flag is un-checked.     

Kind - Car type identifier     

Pool - ID allowing cars of a particular assignment to be grouped together for easier configuration.     

Station - For cars currently on the visible portion of the layout, the Station at which this car is currently spotted.  Set using the Inbound/On Spot/Outbound car tracing functions (Main Menu options 11-13).     

Track - For cars currently on the visible portion of the layout, the Track on which this car is currently spotted.  Set using the Inbound/On Spot/Outbound car tracing functions (Main Menu options 11-13).     

Seq - For cars currently on the visible portion of the layout, the sequence number of this car compared to other cars on the same track.  Set using the Inbound/On Spot/Outbound car tracing functions (Main Menu options 11-13).     

Instr - Any special switching instructions that are to appear for this car on the train list.  Set using the Online Inventory car tracing function (Main Menu option 10).     

BlockTo - Block To value for the car's current routing.  This is the customer, shipper, or railroad to which the movement is currently destined.  Set by RailQuik.     

ID - The station identifier of the customer, shipper, or railroad specified in BlockTo.  Set by RailQuik.     

Commodity - The Commodity value for the current leg of this shipment.  Set by RailQuik.     

Haz - Hazardous materials flag for the current leg of this shipment.  Set by RailQuik.     

LE - Load/Empty indicator of the current leg of this shipment.  Set by RailQuik.     

BO - The Bad Order flag of the current leg of this shipment.  Set by RailQuik.     

Length - Length of this car.     TonsEmpty - Weight of this car in tons when empty.     

TonsLoaded - Weight of this car in tons when loaded.  For locomotive records in the Roster table, this field is used to contain the unit's tonnage rating.  



SHIPMENTCAR​ - Contains one record for every shipment/car relationship.  So if a particular car is used by three shippers, it'll have three ShipmentCar records.      

- Shipment - Shipment identifier from the Shipments table.     
- IDCar - Car identifier from the Roster table     
- Initial - Reporting mark initial.  Not used, but handy for testing.     
- Number - Reporting mark number.  Not used, but handy for testing.     
- Move - Move description.  Not used, but handy for testing.     
- IBOrigin - Source of this move.  Not used, but handy for testing.  

First Session "Priming"
Because the very first run of RQ will have your entire rolling stock roster available for selection (whereas subsequent runs will only have a portion of the roster, since other cars will be spotted on the layout), you may find that too many inbound cars are selected for some customers.  The easiest way to deal with that is to perform the following priming steps:  

1. Generate your first session 
2. Update all those inbound cars to On Spot 
3. Select Ignore on those that'll be spotted to your customers 
4. Update On Spot cars to Outbound 
5. Update Outbound to Available 
6. Un-select Ignore on those cars where Ignore was selected earlier 
7. Hand-place those cars on the appropriate spurs 
8. Update On Spot cars to Outbound 
9. Generate your second session  

Hopefully the above info will get you started with RailQuik.  I'm sure there are things I've forgotten, but I just ask RQ users to bring them up on the Yahoo group so all users can benefit from the exchange.

RailQuik can be downloaded here .

As I'd mentioned previously, I developed RailQuik primarily for my own use. While I wanted to share it with others, given my limited hobby time and lack of Access experience, I didn't put a lot of time into making it easily configurable for others through the use of variables. Other users may add that functionality down the road, but for now, tailoring RQ to your own needs will require a number of simple manual updates. None of it is difficult, even for those who lack Access experience. I was completely new to Access when I started RQ, so I have no doubt that subsequent users can easily modify what I've done.

Below is an outline of the changes necessary to adapt RQ for your own use. Don't let the size of the list scare you, because each change is simple, e.g. updating "IAIS" references from my prototype to your own road's reporting marks.

Please note: Nearly all updates listed below will be accomplished in Access by right-clicking on the particular object (table, query, form, report, etc.) in the navigation bar on the left and clicking on Design View. In addition to that step, the other major thing to remember is related to forms (screens) that have fields with drop-down lists. To update the values displayed in those lists, once you're in Design View, if the Property Sheet isn't visible to the right, right click on the screen and click on Properties. Click on the field whose drop-down list values you wish to modify. In the Property Sheet, click on the Data tab, and in the Row Source field, you'll see a list of valid values for that field's drop-down.

Overview
1. I STRONGLY suggest you play around with RailQuik using my *existing* Shipments, Roster, and ShipmentCar data before changing anything. Getting familiar with what RQ does today will be a great help going forward as you modify it for your own needs.

2. RQ user Bob Burke recently pointed out that Access has a "Find & Replace" function on the Home tab. This can be used to update data values, but apparently not field names. Its best to replace one occurrence at a time in case there is another use for the word you are trying to replace. Just keep clicking Replace.

3. Change "IAIS" references to your railroad

4. Change "BICB" references to symbol of a train inbound from staging. You can simply replicate queries, reports, forms, drop-down field value references, etc. for other inbound trains. However, if modeling something more complex that my prototype's one-inbound, one-outbound daily operations scheme, I'd recommend instead updating RQ to make the inbound symbol a variable, allowing you to re-use the same queries, reports, forms, etc. for all inbound trains. RQ handles my prototype's scenario just fine as-is, so I didn't take it any further for my own needs, but it would definitely serve as a solid platform for doing so. Hopefully any users who pursue that will share their work with the RQ Yahoo group for use by others. If they do so, I just ask that it remain freeware.

5. Change "CBBI" references to symbol of a train outbound from an on-layout yard to staging. As with the BICB references, you can simply replicate what I've done, or you can update it to make it configurable.

Tables
The table-specific notes below are intended to reflect those changes that are necessary to adapt the table *structure* to your needs. However, the *data* for all tables will also have to be updated for your layout.

1. BOIchgCars
2. BuggyHoppersHancock - Elevator/industry name to be replaced if applicable.
3. BuggyHoppersHarlan - Elevator/industry name to be replaced if applicable.
4. BuggyHoppersWestPlains - Elevator/industry name to be replaced if applicable.
5. HopperOrderHancock - IAISCars, BNSFCars, KCSCars field names. Elevator/industry name to be replaced if applicable.
6. HopperOrderHarlan - IAISCars, BNSFCars, KCSCars field names. Elevator/industry name to be replaced if applicable.
7. HopperOrderWestPlains - IAISCars, BNSFCars, KCSCars field names. Elevator/industry name to be replaced if applicable.
8. IDOrder - ID values from "ID" field in forms, sorted and numbered in timetable order.
9. RejectedHoppersAdair - Elevator/industry name to be replaced if applicable.
10. RejectedHoppersHancock - Elevator/industry name to be replaced if applicable.
11. RejectedHoppersHarlan - Elevator/industry name to be replaced if applicable.
12. RejectedHoppersWestPlains - Elevator/industry name to be replaced if applicable.
13. RoadUnitsToShop - Unit numbers and shop locations to be updated for your layout.
14. Roster - One record for every car on your roster.
15. ShipmentCar - One record for every Shipment/Car relationship on your layout.
16. Shipments - One record for every Shipment on your layout.
17. StationOrder - Station values from "Station" field in forms, sorted and numbered in order of appearance.
18. TotalQty - Sum of Qty field values from Shipments table.

No updates are necessary for the following tables:

1. RandCars
2. RandRoster
3. Seq
4. SeqMaster

Queries
- BICBGrpStationMinBlockQuery - Update "BICB" in filename and criteria check to the symbol of an inbound (i.e. from staging) manifest on your layout. Replicate this query for other inbound manifest symbols as needed.

- BICBQuery - Update "BICB" in filename and criteria check to the symbol of an inbound (i.e. from staging) manifest on your layout. Replicate this query for other inbound manifest symbols as needed.

- CarQueryCBSW - Update "CBSW" in filename to symbol of your yard job, and update Roster.Station criteria to the station value of your yard, if you care to have separate yard reports for yard and road crews. Update Roster.Track criteria check, replacing "CBBI" with the symbol(s) of your outbound manifest(s). You may wish to replicate this query to allow for multiple yard jobs or industrial zones.

- CarQueryRoad - Update Roster.Station criteria to the values of stations served by road jobs. You may wish to replicate this query to allow for multiple local "zones".

- CBBIGrpStationMinSeqQuery - Update "CBBI" in filename and Roster.Track criteria with the symbol(s) of your outbound manifest(s). You may wish to replicate this query to allow for multiple manifests.

- CBBIQuery - Update "CBBI" in filename and Roster.Track criteria with the symbol(s) of your outbound manifest(s). Update CBBIGrpStationMinSeqQuery.MinSeq reference to instead use your updated query above. You may wish to replicate this query to allow for multiple manifests.

- CBBITonnageForecast - Update "CBBI" in filename with the symbol(s) of your outbound manifest(s). Update Roster.ID criteria to check for values of off-layout stations to which you're routing cars. This query provides tonnage data on all cars leaving the yard on this particular manifest, plus those that are due to be pulled along the way for routing in the same direction.

- IchgQuery - Update Shipments.IBOrigin criteria to the values of the railroads with which your layout interchanges.

- QueryBOIchgCars - Update "Int((2)*Rnd()+1)", altering "2" to the number of records you choose to have in the BOIchgCars table. The presence of two records equates to a 50% chance of a single inbound interchange car being marked Bad Order out of the entire session's interchanges (one B/O record in BOIchgCars, one "good" one), NOT a 50% chance of _each_ interchanged car being B/O Four records equates to a 25% chance (one B/O, three good), 10 records to a 10% chance (one B/O, 9 good), etc.

Like QueryBOIchgCars, each of the following Buggy, HopperOrder, Rejected, and RoadUnitsToShop queries use a similar algorithm against their respective table to ensure the generation of the various conditions according to prototype ratios. "N" in "Int((N)*Rnd()+1)" for each query always equates to the number of records in the corresponding table, so if you alter the probabilty of a particular event by adjusting the number of records, be sure you update the respective query's formula to match.

Buggy, HopperOrder, and Rejected queries will have to be updated to reflect elevator/industry names for your layout.

While some of the events I'm generating are specific to grain elevators, many could be applied to any industry. The same basic logic could be applied to the generation of virtually any event. Just be sure you update macDSShiftTurnover with the appropriate queries so all can be generated at once by clicking on "6 Dispatcher's Shift Turnover".

Buggy hoppers in the queries below are those that have already been loaded at the elevator, but then the contents fail quality tests. These cars have to either remain at the elevator so they can be dumped after other loads are pulled, or else they're shipped to an alternate cosignee if a buyer can be found to use the grain for non-human consumption, e.g. cattle feed.
- QueryBuggyHoppersHancock
- QueryBuggyHoppersHarlan
- QueryBuggyHoppersWestPlains

Due to the way my prototype fills covered hopper orders, I'm choosing to handle them with the following three queries, outside of the normal car order generation, instead just generating events that tell me how many cars the elevators wants from each supplying railroad. There are just too many interesting wrinkles in empty covered hopper routing to accurately cover them all with automated generation, and many of those wrinkles require human interaction, adding a lot of interest to the process. For example, empty IAIS covered hoppers (called "dispos" because the exact elevator to load them hasn't been determined, meaning they're "open disposition") could move onto the layout from the BNSF interchange at Council Bluffs, on a westbound IAIS train coming from staging, or they could already be on the layout, tied down in a siding pending elevator orders. It's up to the Trainmaster (me) to determine how he'll fulfill an elevator's order, as well as determining where to store any additional inbound hoppers until more orders arrive.

Once hopper orders are generated and the source(s) of those hoppers is determined, I just hand-write their quantity in on the appropriate interchange, train, and/or yard report. For example, insteads of listing 10 specific car numbers, I write "10 dispos". Or, if hoppers are BNSF or KCS cars, I write in "0-10 KCS hoppers" (zero loads/10 empties), for example, as might be done on the prototype when last-minute changes were made.

- QueryHopperOrderHancock
- QueryHopperOrderHarlan
- QueryHopperOrderWestPlains

Rejected hoppers are those that, after spotting to the elevator, were found to have some mechanical defect that prevented their use - often faulty gates. These cars are routed to the RIP track at Council Bluffs for repair, and after repair must then be routed back to the elevator for loading. My queries for rejected hoppers include those from the off-layout elevator at Adair, as rejected hoppers from there move to and from the Council Bluffs RIP on manifest trains.

- QueryRejectedHoppersAdair
- QueryRejectedHoppersHancock
- QueryRejectedHoppersHarlan
- QueryRejectedHoppersWestPlains

This query determines any road units that must be added to a Council Bluffs-bound train, in addition to those needed to move the tonnage, for attention by the shop there.

QueryRoadUnitsToShop

SeqTruncCarID - This query controls the overall number of cars generated per op session. Update ">Int(8 * Rnd() + 26)", altering "8" to the result of "upperbound - lowerbound + 1", where "upperbound" is the maximum number of cars you want RQ to generate per op session and "lowerbound" is the minimum number, and altering "26" to that same minimum number.

No updates are necessary for the following queries:
- Car Query
- CarFormQuery
- CreateSeq
- LEQuery
- LocoFormQuery
- MakeRandCars
- RandRstrAppCars
- RandRstrGetMaxModRand
- RandRstrUpdtModRand
- RosterStatusHoldtoOB
- RosterStatusIBtoAvail
- RosterStatusIBtoHold
- RosterStatusOBtoAvail
- RosterUpdtSelected
- RosterUpModRand
- SeqAppCarID
- ShipmentsUpdtFactor
- ShipmentsUpdtTtlQty
- StatusAvail
- StatusHold
- StatusIB
- StatusOB
- StatusOOS
- UpdtLocoSeq

Forms
Multiple "IAIS" references throughout on individual form/screens. MainMenu references to IAIS-specific train symbols will have to be updated with your own. All forms containing Track, Station, Block To, ID, or Commodity must have their associated drop-down values modified to fit your needs.
- AboutRQ
- AvailCars
- Car
- InboundCars
- Locomotive
- MainMenu
- OnSpotCars
- OOSCars
- OutboundCars

Reports
"IAIS", train symbol, location, and date references will have to be updated throughout the following reports.

- CBBITonnageForecast
- IchgReport
- TrainListBICB
- TrainListCBBI
- YardReportCBSW
- YardReportRoad

Macros
- macCBBIQuery - Update train symbol references for outbound trains.
- macDSShiftTurnover - Update individual query references to generate all desired events.

No updates are necessary for the following macros:
- macSelectCars
- macUpdtRoster


Configuration
Below is a field-by-field guide to configuring the three primary tables used in RQ: Shipments, Roster, and ShipmentCar.


SHIPMENT - Contains one record for every origin/destination pair.

Shipment - Unique shipment identifier

IBOrigin - Inbound Origin, i.e. the train symbol or interchange railroad from from which this move originates. First six records in my sample file are for power on the inbound train, allowing up to six locomotives to appear properly in the train list. More "ENGINE" records can be added as needed. Please note, the "inbound" label for this and the next several fields refers to movements that are inbound from staging or interchange to the visible portion of the layout, though they may also continue through as bridge moves to an interchange on the other end of the railroad. Outbound moves are those that are originating on the visible portion of the layout and moving to staging or interchange.

Block - Block ID to allow cars to appear properly blocked in train lists, or to cause cars that likely would be grouped together in an interchange cut (e.g. cars from the same shipper to multiple IAIS cosignees) to appear together in the interchange report. For interchange cars, i.e. those with an IBOrigin value of a railroad reporting mark, the sequence of the Block values is random, since aside from the aforementioned grouping, the cars will be as well.

IBLE - Load/Empty indicator for the inbound leg of this shipment.

IBBlockTo - Block To value for the inbound leg of this shipment. This is the customer or railroad to which the movement is destined. IBID - The station identifier of the customer or railroad specified in IBBlockTo.

IBCommodity - The Commodity value for the inbound leg of this shipment.

IBBO - The Bad Order value for the inbound leg of this shipment.

OBLE - Load/Empty indicator for the outbound leg of this shipment.

OBBlockTo - Block To value for the outbound leg of this shipment. This is the shipper or railroad to which the movement is returning.

OBID - The station identifier of the shipper or railroad specified in OBBlockTo.

OBCommodity - The Commodity value for the outbound leg of this shipment.

OBBO - The Bad Order value for the outbound leg of this shipment.

Qty - Number of cars that moved in this shipment on the prototype. I started out using the exact figures from the IAIS, but later found that I had to normalize these figures to account for the fact that my roster is smaller than the prototype's. Before normalization, the most common moves had so many cars that they were always chosen first, leaving no room for the less common moves to ever appear. I reduced the Qty values for the most common moves across the board so that they're still higher than the less common moves, keeping the ratios accurate, but not so high as to overshadow everything else.

TotalQty - Total number of all cars that moved in all shipments on the prototype.

Factor - The Qty value divided by TotalQty, giving a frequency indicator that, during car order generation, is multiplied times a random number generated for each car to determine the car orders to generate.

Haz - Hazardous materials flag. Since hazardous movements retain their hazmat notation whether loaded or empty, this flag applies to both the inbound and outbound legs of this move.

Mandatory - Flag indicating that the movement is mandatory (i.e. that a car order will always be generated), overriding the Factor/random number generation mentioned above.

Move - Move description. Not used, but handy for testing.



ROSTER - Contains one record for every car and locomotive on the layout.

IDCar - Unique car identifier.

Initial - Reporting mark initial.

Number - Reporting mark number.

Status - Indicator of the car's current status. Set by RailQuik. Valid values are:
0 = Available
1 = Inbound
2 = On spot
3 = Outbound

AssignedShipment - Shipment ID (from the Shipments table) for the shipment to which this car is currently assigned. Set by RailQuik.

ModRand - Factor from Shipments table multiplied times a random number generated for this car. Cars with the highest ModRand value are chosen for car order generation. Set by RailQuik.

Ignore - Flag indicating that this car is to remain in its current Status until the Ignore flag is un-checked.

Kind - Car type identifier

Pool - ID allowing cars of a particular assignment to be grouped together for easier configuration.

Station - For cars currently on the visible portion of the layout, the Station at which this car is currently spotted. Set using the Inbound/On Spot/Outbound car tracing functions (Main Menu options 11-13).

Track - For cars currently on the visible portion of the layout, the Track on which this car is currently spotted. Set using the Inbound/On Spot/Outbound car tracing functions (Main Menu options 11-13).

Seq - For cars currently on the visible portion of the layout, the sequence number of this car compared to other cars on the same track. Set using the Inbound/On Spot/Outbound car tracing functions (Main Menu options 11-13).

Instr - Any special switching instructions that are to appear for this car on the train list. Set using the Online Inventory car tracing function (Main Menu option 10).

BlockTo - Block To value for the car's current routing. This is the customer, shipper, or railroad to which the movement is currently destined. Set by RailQuik.

ID - The station identifier of the customer, shipper, or railroad specified in BlockTo. Set by RailQuik.

Commodity - The Commodity value for the current leg of this shipment. Set by RailQuik.

Haz - Hazardous materials flag for the current leg of this shipment. Set by RailQuik.

LE - Load/Empty indicator of the current leg of this shipment. Set by RailQuik.

BO - The Bad Order flag of the current leg of this shipment. Set by RailQuik.

Length - Length of this car. TonsEmpty - Weight of this car in tons when empty.

TonsLoaded - Weight of this car in tons when loaded. For locomotive records in the Roster table, this field is used to contain the unit's tonnage rating.



SHIPMENTCAR​ - Contains one record for every shipment/car relationship. So if a particular car is used by three shippers, it'll have three ShipmentCar records.

- Shipment - Shipment identifier from the Shipments table.
- IDCar - Car identifier from the Roster table
- Initial - Reporting mark initial. Not used, but handy for testing.
- Number - Reporting mark number. Not used, but handy for testing.
- Move - Move description. Not used, but handy for testing.
- IBOrigin - Source of this move. Not used, but handy for testing.

First Session "Priming"
Because the very first run of RQ will have your entire rolling stock roster available for selection (whereas subsequent runs will only have a portion of the roster, since other cars will be spotted on the layout), you may find that too many inbound cars are selected for some customers. The easiest way to deal with that is to perform the following priming steps:

1. Generate your first session
2. Update all those inbound cars to On Spot
3. Select Ignore on those that'll be spotted to your customers
4. Update On Spot cars to Outbound
5. Update Outbound to Available
6. Un-select Ignore on those cars where Ignore was selected earlier
7. Hand-place those cars on the appropriate spurs
8. Update On Spot cars to Outbound
9. Generate your second session

Hopefully the above info will get you started with RailQuik. I'm sure there are things I've forgotten, but I just ask RQ users to bring them up on the Yahoo group so all users can benefit from the exchange.


By: Joe Atkinson
1 image in this album.
[Login]
All images on this site are copyrighted by their respective creators, and used with permission.
All Iowa Interstate logos and trademarks are property of Iowa Interstate Railroad, Ltd. and Railroad Development Corporation.
Questions? Comments? Please email us at contact@iaisrailfans.org
  Last modified on February 26, 2020 at 20:22.