Understanding how rotated constants work in coding and when to use them. Applicable to most PM8 design modules.
Rotated constants refer to the mechanism where a number of positions in the cylinder that are used for coding (for a particular designation or level of keying) and out of those positions, fewer are used at any time, and then every possible combination of which positions are used is generated to produce multiple code-pages. In the PM8 coding tree you will see that those code pages are combined to make all the codes accessible.
After a system had been manufactured, it is important that any further expansion produces compatible codes, not codes that interchange with existing cylinders. So for example you produce a system with 2 positions in the cylinder being used for generating change keys under each master, then at a later time you need more codes than are available from those 2 positions. If you were to alter the code progression to use 3 positions all being progressed for change keys, you would generate different codes to which the previously used codes would be sub-masters. In this scenario, instead of progressing 3 positions you would generate the additional codes by introducing the third position as a rotated constant.
Using rotated constants to produce compatible codes for an existing system is arguably the most important reason for using rotated constants.
When you use rotated constants to generate codes, the result is fewer master pins (or master discs depending on the locking product) used to assemble the cylinder and the upshot of this is a more secure cylinder.
Under particular conditions, using rotated constants will produce more codes than progressing the same number of positions without using rotated constants. There are two things that contribute to this:
The math behind it (Permutations and combinations) is somewhat complicated but the almost universal rule is this:
When you use more positions for a purpose or designation (e.g. Change keys) than the number of codes produced from each individual position, then the introduction of a rotated constant will yield more codes.
You cannot extrapolate the same simple logic for the second rotated constant - it is more complex than that unfortunately!
For this example we want to demonstrate the principles of rotated constants without writing out thousands of codes, so let us imagine a lock system with 5 positions, and the possible depths are only 1, 2, 3. We are going to ignore any rules such as maximum alike codes.
Note there are 3 positions progressed, each with a "C" designation.
The generated codes are: 11111, 11131, 11311, 11331, 13111, 13131, 13311, 13331
2 depths out of each position (because our lock system has depths 1,2,3 available) with 3 positions progressed at the same time making the total number of codes (2x2x2) = 8
Let's now make the same example, but this time change the
designation to use 2 progressed positions and 1 rotated constant (2 positions progressed over 3 positions). The rotated position is shown using a lower case character.
The generation of codes effectively uses the following 3 designation combinations to generate 3 sets of codes:
The designation combinations generated: -CC-- -C-C- --CC-
Now each of those designation combinations is used to generated codes like this:
The generated codes are: 11121, 11321 12111, 12311
The generated codes are: 11211, 11231, 12211, 12231
The generated codes are: 13111, 13131, 13311, 13331
2 depths out of each position (because our lock system has depths 1,2,3 available) with 2 positions progressed at the same time (because there were 2 capital "C" designations), but also 3 different progressions making the total number of codes (2x2) + (2x2) + (2x2) = 12 codes
In this example there were more codes generated with a rotated constant when just 3 positions were used. This a much lower threshold that you would normally see, and the reason as we pointed out at the start is because this imaginary lock system uses just 3 depths so that the number of codes generated in the example would be manageable.