Blender can't recognize rotational value which is larger than 180 degrees in Euler(when rotational value goes over 180 degrees it starts with -180 degrees) and it causes problems for my armature.
Outputting a rotational difference to some value in a transformation constraint will not solve your problem, because:
A rotational difference cannot see rotations larger than 180 degrees. This isn't a bug, or a failing of Blender, it's just the way it works. 180 degrees is the biggest difference in rotation possible. Think about rotating a bone 180 degrees in any axis (but let's exclude Y for intuition's sake): it doesn't matter how you get there, by X or Z or by some mix; and there's no reason to prefer any particular Y rotation, they're all equally valid and "rotationally-close" because you could get there by rotating in an entire circle of axes. And, any other rotation will end up with something that is rotationally-closer to our original state.
A transformation constraint does not see rotations outside of the -180, 180 range anyways. No constraints see rotations outside of this range. (The only way to see rotations outside that range would be to limit to local rotation.)
I believe that this is probably one of them pesky X-Y problems. Y will not solve problem X. If you have some demonstration of the problem as well as an inconvenient solution to that problem, it'd be helpful to share a file, and then maybe we can offer a more convenient solution that matches the solution you have.
But, if the problem is really that you want a transformation that reads a local space rotation value outside of the -180, 180 range, you can do so by using a single-property type value (by right clicking in a rotational transform field and "copy as new driver" then "paste as new driver"); and, if you want a rotational difference that does something when inputs are outside of the -180, 180 range, you could consider creating a driver that outputted rotational difference + floor(abs(x%pi)/2) + floor(abs(y%pi)/2) + floor(abs(z%pi)/2). But even that's not right. The very concept of rotational difference through greater than 180 degrees is not something that makes any sense. What's closer to no rotation, XYZ 180, 360, 360 or 0, 540, -180? They're the same orientation, but the sum of the raw numbers are very different, and the sums of the absolutes are very different: XYZ 180 0 0 is the same as 0 180 180. (Which of those has a greater rotational difference?) Euler angles just don't work that way. They cannot be translated raw into rotational differences, not honestly, not accurately, and the only source you might have for angles outside of -180,180 are Euler values.
Edit: Okay, you could have rotational differences from quaternions (as Blender handles them, signed W) of up to 720 degrees, and that would be a valid, signed rotational diffference. But not more than that. I'm afraid I wouldn't know how to do that myself though.
Edit 2: Let's look at the file you've offered.
There are really only two important bones. Chest_child, which is unparented, copies world location and rotation from Chest that is, potentially, in any orientation (its target is locked in all but X, but inheriting ultimately from root which is unlocked.) It is a ZYX Euler, important because we're using constraints and drivers with auto-euler and default order.
Chest_child is apparently used only as a measuring device for Pendant. Pendant, which is parented to Chest but doesn't inherit rotation from it, uses Chest_child's local rotation as the input to multiple transformation constraints. Because of this, we're basically measuring the pose space rotation of Chest, offset by 90 degrees. It is also a ZYX Euler.
I'm not sure what the goal of all of the transformation constraints are. They lead to interpolation errors in the file already when we rotate outside of the -90, 90 range, let alone past the -180,180 range. (Note that this is pretty common when using Euler-based constraints: they alias after 90 degrees, so they're not wise to use on angles that are going to be outside of that range; since it's unpredictable what world angles are going to be, they're unwise to use in world space, period.)
As we linearly rotate root from 0 to 180 degrees in world Z, we get a sharp discontinuity as the Eulers alias (just past 90 degrees, between frames 17 and 18.)
I'm not sure exactly what problem these constraints are designed to address. But I don't think they're really addressing that problem correctly. We don't even want to ask, "How to make this convenient?" until we answer affirmatively, "Does this actually do what we want it to do?"
Now, let's just take a moment to show that nothing you're doing here is reacting to anything outside the -180, 180 range. We'll give the chest 720 degrees of rotation and apply visual transform to Chest_child:
The rotation is a tiny precision error. The copy rotation constraint cannot tell the difference between 720 degrees and 0 degrees. Since the rotation of Chest_child is what drives everything else, nothing else can tell the difference either. But let's also look at one of your drivers, edit it a bit, and read off the value:
I've changed the driver to just output our variable straight. See the driver value? It is 0. A transform channel variable cannot see rotation outside of -180,180 either. (A "single property" type driver can see your raw transform, and so could read 720 degrees from Chest. But Chest_child has a raw transform of 0.)
Finally, let's go to a transformation constraint:
I've muted all other transformation constraints and set this one to target Chest directly, to map 0-720 degrees onto 0-180 degrees. But there is no effect-- again, our visual transform gives us only a precision error. The transformation constraint, asked to evaluate the local rotation of Chest (which is 720 degrees in the transform field, as shown on the graph editor), evaluates it as 0 degrees.
Now, if I try to use my head rather than your file to figure out what you want, I would find a very, very different solution. It seems to me that you want a pendant that moves a bit with the chest, but not fully with the chest, and you don't want to use physics to do this. That's not a great idea, because the whole reason pendants don't fully follow the chest or neck is because 1) they collide with other things and 2) they have inertia. Rigging is never going to do anything to simulate that-- we need physics, or some recreation of physics in geometry nodes, to do anything remotely like that.
But if I understood that, and just wanted something, regardless of how wrong it was, I would probably make a bone with an armature constraint, inheriting equally from head and chest, and then locked track that with a pendant bone parented to the neck. If collision was a problem, I might consider flooring the marker to a chest-parented bone that defined a minimum plane for the bone.
Such a structure wouldn't have any need to refer to angles outside of -180, 180 anyways. The head can't rotate 180 degrees about the chest. Unless you're trying to rig a Linda Blair model for an Exorcist remake.
