Racks Load Report

Reports ››
Parent Previous Next

Rack Loadout Reports

  1. In VSD, Open a project
  2. Open a script.  This turns on the Script Reports
  3. Open the Script Reports and press the "Racks" button

  4. This takes a copy of the Script you have open and copies it to a new DB with the same name, but with the ".rld" extension.  This is the RackLoadout database.  This is now opened up and placed in a grid sorted by position and caliber.  Rackable words are applied to each cue to determine if it is a rackable cue.  Then if a Rack Info database is open it is applied to the cues.  The match is made using several criteria listed in "Rack Loadout: How Cues are matched up to Racks".  If a matching rack with empty tubes is found, the rack name is place in the Rack Name column of the cue.  If no match can be found for a rackable cue the word "<<NOMATCH>>" is placed in the Rack Name and it is highlighted Red.  If a match is found, but all instances of that rack are full, the rack name will be set, but no Rack Instance will be set and it is highlighted Yellow.

  1. The rackable match words can be edited from the menus using Edit->Edit Rack Match...

  2. This brings up the Rack Matching Types dialog

  1. Add/Edit/Delete words from these two lists.  The two lists are applied as follows:
  2. This list is saved in the AppData folder in a .ini like file and are reused for each project.  There are only one set of rackable type words.
  3. Now it is time to add a rack database to our project.  Do this by using the menu Edit->Edit Rack Info DB...
  4. This brings up the Edit Rack Info dialog

  1. At first it will be empty and you will need to enter the information for each of the rack types you have.  

Pressing the DONE button will save your database.  The Open button will let you open another Rack inventory database.  In this way you can have several independent databases, but you can only use one at a time.

  1. Your grid can be printed out (same as any of the grids in VSD) using the menu Print->Print Rack Loadout.
  2. Now that you have all of your cues and racked matched up, it is time to Export  this to a Rack Loadout Report.  Do this using the menu File->Export Rack Loadout (.xls).

  1. This will generate a .xls file that has been sorted by POS, CAL and RACK NAME and tallies up the QTY from each cue of this type.  Note that if you have a rack with multiple instances in MAGAZINE, the INST column will have which instance this cue is in
  2. Any given rack instance can only be in one POS so in this example for POS1, this is one cue in one tube and that is all that will be put in this rack.   Below is a fuller example for POS2

  1. White are rackable cues that are in a rack
  2. Gray are non-rackable cues
  3. Yellow are rackable cues for which a matching rack was found, but there were no empty tubes available.
  4. Red are rackable cues for which no matching rack could be found
  5. Total Qty is 'how full is this rack'.  We visually indicate how full it is by color from Red (0% full) to Green (100% full).  This makes for a quick way to see how optimally the racks have been used.

Rack Loadout: How Cues are matched up to Racks

After a cue has been determined to be rackable, a series of matching rules are applied to try to place this cue into a rack.  As mentioned earlier, for a cue to be rackable it must have a POS value, it must have a CAL value and it must have some correct value in either ANGLE or TILT.

The restrictions for the cue ANGLE or TILT values are as follows:

  1. If ANGLE is non-blank, then it is used.  Otherwise the value in TILT is used.
  2. The value of ANGLE can specify a rack name and that will be the priority when placing this cue.  However, if all instances of the rack specified are full, then regular rules for rack matching are applied
  3. The value of ANGLE (or TILT) can be a single angle such as "90"
  4. The value of ANGLE (or TILT) can be hyphen separated such as "45-90-135" for a fan.  For this cue to be placed into a rack, that rack must have a row with at least 45-90-135 angles based on an exact match or wildcard usage.
  5. In all cases, the QTY column must accurately reflect how much product (and therefore how many tubes) are required.  For example in the above fan, then QTY would be 3.

When rack matching starts, we sort the script by POS value.  This groups the cues by the POS they are at.  We then take each cue at that position and try to find a matching rack.  If a match is found and that rack is empty it is assigned to that POS.  A rack can only be in one POS, so if a different POS also needs this type of rack, it will require a new instance of this rack.  The Rack Info DB MAGAZINE value tells us how many instances of this rack we have to spread around the different positions.

The values of the cue CAL and ANGLE (or TILT) are looked at during this matching process.  We try several times to find the best match between the cue and the racks.  For each of the 'best match' comparisons we look at every rack in our inventory.  Racks are ignored for several reasons like it has been made unavailable, it is RESERVE, it is already in a POS that is not ours or they are already full.  We start with the most strict matching criteria and keep loosening the criteria until we have a match or can't find any rack in inventory that will do.  If we find at least one rack in inventory that would have worked, but was not available to us, we mark that cue with that rack name but leave the Instance blank.  This way you know what we felt was the best match so you may add to the Rack Info DB MAGAZINE value.  If we were unable to find any racks that match our cue CAL and ANGLE we mark that cue with <<NOMATCH>> rack name.

The order of the match criteria is:

  1. The cue's ANGLE column has a RackName in it.  If we have a rack who's name exactly matches the name in the ANGLE column we just use it if it is available and not full.  If we can't find the name or all instances of that rack are unavailable we continue.  The Rack Info DB has a column called RESERVE that if set to YES, reserves this rack type for only exact name matches.  If the RESERVE is set to NO, then it will also be used by CAL/ANGLE matching.
  2. We look for an exact match of the CAL and ANGLE values to the rack CAL and ANGLES values.  So for example of CAL was "30" and ANGLE was "90" we must find a rack that has CAL and ANGLES of "30" and "90" respectively.  If the CAL is "20" and the ANGLE is "15-30-45" we must have a rack with the CAL of "30" and the exact ANGLES of "15-30-45".  If no exact match is found we continue.
  3. We look for a wildcard match of CAL and an exact match of ANGLE.  This would be a rack who's CAL value is a list (like "20-40-60") or a range (like "20*60").  If our CAL matches one of the values in the list or falls within the specified range we check ANGLE for an exact match. If no match is found we continue.
  4. We look for an exact match of CAL and a wildcard match of ANGLE.  This would be a rack who's CAL value is exactly a match, but the ANGLE value finds a wild card match.  So for example if the with a cue CAL of "20" and an ANGLE of "45" if we find a rack with CAL of "20" and ANGLES of "30-45-90" it would match as there is a "45" spot in the row of angles.  We would also match on a rack with a CAL of "20" and ANGLES of "10*80" as 45 falls within the range of 10 to 80 degrees. If no match is found we continue.
  5. Finally we look for a wildcard match of CAL and a wildcard match of ANGLES.  This is as wide open of a match as we can make looking for any possible rack to put this cue into.

Once a matching rack is found, we check to see if there are enough tubes available in this rack based on the cues QTY value.  If there are, we use this rack.  If not, we continue either finding another instance of this rack or looking for another rack type that matches.

Let's take a look at a very simple Script and a limited Rack Info DB and see how matching would work.

Our Rack Info DB:

Our Script in the Rack Loadout form:

  1. This cue is not RACKABLE (based on our Rack Match word lists) so no rack was assigned.
  2. Here the CAL is "20" and the ANGLE is "90" and that is an exact match of the rack named "rack3"
  3. Here we have CAL of both "50" and "20" with a mix of ANGLES of "90" and "60-90-120" (from TILT).  The first cue of this set went to "rack6" because of the wildcard for CAL.  Then the next cue goes to "rack6" rather than the exact match in "rack3" because we have changed POS and we only had one "rack3" (now in POS1).  The next best match that has an instance available is "rack6".  We also matched a CAL of "20" and ANGLE of 60-90-120 to the wildcard in both CAL and ANGLES that "rack6" has.
  4. When we change POS, we have to leave behind any racks assigned there, even if there were available spots.
  5. The rack name "rack4" was giving for this cue and that is the rack given (see #7)
  6. These cues are rackable, but due to the "45" angle we can't put them into any rack.  Notice that our Rack Info DB doesn't include any racks with an ANGLES of 45 or a list or range including 45.
  7. Here we have tried to assign this cue to "rack4", but we don't have any available instance of "rack4" to put into this POS.

So looking at  our Rack Info DB and the Rack Load script we can see how the rules for matching get applied.

Created with the Personal Edition of HelpNDoc: Full-featured multi-format Help generator