How to solve this kinematic loop?

Hi,
I have this model:

When I play it runs perfectly, here is a screenshot of the animation:

As expected, the model behaves like a pendulum connected by bars.
However, I would like to model with a fourth bar, something lke this:

The animation would something like this:

This results in a kinematic loop ( I guess it is the right term…). When I try
to simulate it, I get this error:

The following equations are redundant:
body2.frame_a.r_01 = body1.frame_a.r_01 + 10.0 * revolute1.R_rel.T[2,1]
body2.frame_a.r_02 = body1.frame_a.r_02 + 10.0 * revolute1.R_rel.T[2,2]
body2.frame_a.r_03 = body1.frame_a.r_03 + 10.0 * revolute1.R_rel.T[2,3] Corresponding variables with arbitrary value:
fixedTranslation6.frame_b.f1, fixedTranslation5.frame_b.t2,
fixedTranslation5.frame_a.t1 Message for
fixedTranslation6.frame_b.f1:
All Forces cannot be uniquely calculated. The reason could be that the mechanism contains a planar loop or that joints constrain
the same motion. For planar loops, use for one revolute joint per
loop the joint Joints.RevolutePlanarLoopConstraint instead of
Joints.Revolute.

I tried variations of this model, but I noticed that as far as I have the fourth bar (the one that closes the loop) I will have a problem to simulate. I think I understood the problem, I may sound dumb now, but what I have to do to model with the fourth bar? Is there a way to solve it?

The model follow attached to the post.

My SM short information:

Product version: 13.1.0.3 Client: Model Center Client version:
13.1.0.4 Client creation date: 2022-05-20T15:21:04.469569 Client build revisions: J:a111bde51, L:cc04976b1, S:dd80ee46c Client build
type: 64 bit Kernel version: 13.1.0.4 Kernel creation date:
2022-05-18T09:41:31.112079 Kernel build revisions: J:a111bde51,
L:cc04976b1, S:1d9b31919 Kernel root directory:
/usr/local/Wolfram/SystemModeler/13.1 Installation directory:
/usr/local/Wolfram/SystemModeler/13.1 Platform: Linux Mint 20.2

kinematic_test.mo (3.54 KB)

Hi, the general problem you are encountering is that it is not allowed to construct over-constrained equation systems. Connecting a fixed translation between two points that already have a fixed translational relation is an example of creating an over-constrained equation system. You can easily avoid the problem by breaking one of the connections where it is already known that the connected frames will coincide:

I hope that you are aware that adding this FixedTranslation component will not have any impact on simulation dynamics, even though it is visible in the animation. To actually have an impact on dynamics, one has to use a component with inertia, for example BodyCylinder that combines a FixedTranslation with a Body.

Sorry for the late response, but thanks Henrik, I could solve the problem with your answer.