Rebar detailing continues to be one of the more painstaking and error-prone stages in the concrete design process. While it might not receive the same level of attention as structural modelling or analysis, its importance cannot be overstated. Even if a concrete structure is impeccably designed, inaccuracies in the rebar detailing phase can lead to serious problems. These may range from avoidable delays on-site to more severe consequences like compromised structural integrity. The impact of a simple oversight can be disproportionate to the scale of the error, and we’ve seen real-world examples that highlight just how critical accurate detailing is. One such case involved a scaling issue during detailing that resulted in bars being delivered at 300 mm lengths instead of the intended 3000 mm—a fundamental and costly mistake caused by a minor setting being off.

At Micrographics, we recently explored a particular concern raised by a user regarding the way Probar 2D calculates the cut length for Shape Code 81 reinforcement bars. Initially, we approached this with a healthy degree of scepticism, expecting to find a bug or miscalculation within Probar 2D itself. To get to the bottom of the issue, we undertook a detailed and repetitive testing process, manually working through a variety of scenarios and matching the results against independent hand calculations. The aim was simple: identify whether the discrepancy was coming from the software or from elsewhere.

Using Probar 2D as our base platform, we created a wide range of geometries within which we placed Shape Code 81 bars, varying both their dimensions and diameters. We then recorded the cut lengths generated by the software and compared them with what our own calculations yielded. Oddly, in some cases the numbers lined up perfectly, while in others they diverged slightly. The pattern wasn’t immediately obvious, and we were left scratching our heads about why the inconsistency appeared to be size-dependent.

This prompted us to take a more manual approach. We exploded the Shape Code 81 bars within AutoCAD and measured the centreline lengths directly. That was when the underlying issue became apparent. The problem wasn’t with Probar 2D at all; it was with how the radius used in the formula was being understood.

There are, in fact, two different types of radii that should be considered depending on the context. First is the standard radius value (r), which is sourced from tabulated data for Mild Steel and High Yield Steel, and which depends on both the material type and bar diameter. This radius remains constant for a given bar diameter and steel grade, regardless of how the bar is shaped. The second, less commonly considered, is a geometry-specific radius (R). This is influenced by the actual physical configuration of the bar—the spatial arrangement it takes within a structural element. As the shape of the bar changes, this geometric radius (R) changes too, even if the diameter stays the same.

Once we understood the distinction and confirmed that Probar 2D was using the geometric radius (R) rather than the standard tabulated radius (r), everything clicked into place. The program had been calculating the cut lengths correctly all along. Our initial suspicions had been misplaced. The confusion stemmed not from the software, but from the SANS 282:2011 code itself.

According to the code’s cut length formula for Shape Code 81, the radius (r) is prescribed—explicitly referring to the tabulated standard value. However, in reality, for this particular shape code and the way it functions in detailing software and geometry, it should clearly be using the geometric radius (R). This appears to be a mistake within the standard itself, not an interpretation issue or an optional variation.

A note in the code—“For larger radii, see 4.2.5, note to table 5 and refer to shape code 99”—refers to a 200 mm radius limit and how to proceed if this limit is exceeded. However, this doesn’t address the core problem. What’s more troubling is that this inconsistency doesn’t seem isolated to Shape Code 81. Upon reviewing other shape codes, it appears that the same oversight may have been carried over across multiple entries. In some cases, such as Shape Code 51, the code does correctly indicate the use of the geometry-specific radius (R), which suggests that the code’s authors were aware of the distinction. But the application isn’t consistent.

For experienced detailers, it’s often possible to instinctively know when to apply the correct radius type, especially when working with these codes regularly. However, the possibility for error increases under pressure or when less experienced technicians are involved. Relying on intuition isn’t a sustainable or fail-safe approach. For this reason, we would strongly recommend adjusting your internal calculations or software interpretations to ensure the correct radius is being used, even if the code stipulates otherwise.

While the numerical difference in bar lengths may not always be significant, the accumulated impact of such discrepancies—especially on large or complex projects—can be problematic. More importantly, even a small mistake can raise questions or cause delays on site, and that’s something every project team wants to avoid. In a discipline where millimetres matter, clarity and accuracy in the standards we follow are not optional—they’re essential.