Showing motion where there are inter-related revolute joints

[R4SMEs]

I am developing a model of an expanding table of the so-called butterfly type,
in which there are two wooden panels joined by a hinge (i.e., a revolute joint) and one of the panels (the upper of the two of the expansion part) has another revolute joint to the structure, i.e., to the framework of the table.

I have successful implemented the components and their revolute joints.
However, I should appreciate advice on how to drag the joints/ animate the overall expanding table such that it behaves/ performs in a reasonably realistic way.

My main objective is to test the motion and check how parts inter-relate to each other.

The overall concept for the table can be seen by looking at the very start of the following YouTube video which shows the expanding leaf being opened and closed in a similar type of table.
https://www.youtube.com/watch?v=rI6Uz4gt_-M

As can be seen from the demonstration of such a table, it is not only the revolute joints but also the weight of a panel that comes into play.

As one part is lifted, the other part tends to either stay where it is (when sitting on the bottom support in the low position) or to move down by itself, as a result of its weight.

Unfortunately, this effect of gravity is something that is not represented in the Fusion model!

ElipticalButterflyExpandingV30_3Dview.png provides a 3D view of the Fusion model.

ElipticalButterflyExpandingV30_EndView.png
This shows the view from one end, including the drawing that was used to extrude the two wooden panels joined by their hinge and the position of the revolute joint between the upper of the two panels and the structure of the table.

I tried to do a generalised drawing.
For this reason, there is a gap at the left between the moving panels to take into account that there may, in general, be a small gap between the panels where they close at the hinge.
[This gap is currently exaggerated for testing purposes, i.e., in the final implementation the gap will hopefully be close to zero.]

Equally, I have the moving panels thicker than the main top of the table (which is seen in cyan).
In practice, the thicknesses of the moving panels will be reduced to be similar to that of the table top itself.

It was an interesting challenge to define where the pivot point between the top of the expansion panels and the table itself should be positioned.
This is seen as the position of the revolute joint in the centre of the image, above the two panels (i.e., the blue and brick red panels).
It is the blue panel that is joined by this revolute joint to the table structure.
[It is seen apparently floating in mid-air but in practice there would be a block of wood attached to the top of that blue panel with an axle going through it, as in the YouTube video.]

To define the position of that upper pivot point, I drew the two construction circles and constrained their centres to be concentric (thereby defining the position of the pivot point).

By constraining the two corners of the upper (blue) panel to be on these circles, it ensures that the top of the blue panel will be flush with the top of the table (cyan) when the blue part is lifted/ rotated into its raised position.

Incidentally, I should mention that there is more than one solution to the geometrical requirements based solely on the two construction circles.
The lower resting position (left to right position/ height/ angle) can vary.

I used "Fix" for two lines in the sketch (note the two green lines at the bottom and left edges of the lower rectangle of the sketch) to fix the location of the sketch corresponding to a particular solution.

In practice, there are other constraints that need to be considered including ensuring that panels in their lowered position fit within the available space.
[They rest at the bottom on a horizontal piece of wood, which is currently drawn in an artificially low position (this is seen at the bottom right of the end view).

At the top, in the stored position, they need to be lower than the bottom of the T-shaped runners which move into this area as the ends of the table are pushed together.]
Also, as the moving parts are lifted up to the raised position, we need to ensure that they clear the apron at the side of the table.

For these and other reasons, it is important to be able to play with/ test the motions ...

Being hinged at its left (to the upper blue panel), the left edge of lower (brick red) panel has to follow the edge of the upper panel.

In practice, its weight would keep it more or less horizontal but, unfortunately, the Fusion model doesn't appreciate this fact!
Consequently, when dragging on either panel, they move in unrealistic ways.

Furthermore, it is difficult to even move things into particular settings (such as "expanding leaves fully up").
I suppose that could be done by playing with joint limits and joint rest positions - but this doesn't solve the issue of how to view the motions/ animate things in a reasonable way.

I can provide the model if anybody is interested and wants to play with it/ hopefully assisting this endeavour.

[R4SMEs]

This seems to be a major step forward!

I didn't know about the possibility of double clicking on the "little flag"!

[R4SMEs]

Following on from last week, I have been busy working on the table design.

I have added the actual hardware associated with the revolute joints, i.e., a pair of Soss model 101 "invisible" hinges between the two rotating panels and
also the revolute joint between one of those rotating panels and the table structure - it is basically a bolt rotating in a hole in the table's cross stretcher.

There was something of a breakthrough last week in understanding how to go about rotating components relative to each other after @TrippyLighting explained that:
> If you double click on the little flag in the joint symbol in the viewport you can rotate just that joint.

However, now that the actual hardware has been added, I am still experiencing difficulty in rotating components relative to each other.

It seems like the several joints are, in some way, fighting with each other (although there are no yellow or red warning issues with the model).

Question 1:
Assuming just 2 simple hinges, if one rotates the little flag associated with one hinge, would the rotation happen, i.e., would the other hinge rotate by itself to follow the specified motion of the hinge being driven?

I think that the answer to this question is probably "Yes" (but are there exceptions to this rule?!).

The Soss hinge is considerably more complicated since it involves multiple interacting components, leading to
Question 2:
If one of the rotating elements of the Soss hinge is driven (by clicking on the little flag, etc.) will the other parts of the hinge rotate in an appropriate way?

In an attempt to answer my own question ...
"Yes, but the process seems to be extremely problematic and inconsistent from one usage to another!"
Using only the model for the hinge, I drove the joint entitled "B1 to Top axle".
Sometimes it behaves nicely.
From the starting point of 0 deg, dragging on the icon which allows rotation of the joint enabled the overall hinge to be rotated through 180%.
This shows that "B1 to Top axle" joint as changing to -115 deg.

Repeating the process, but entering another intermediately value, say -80 deg, results in an apparently unpredictable/ inconsistent outcome.

Repeating the process yet again, but entering, e.g., 0 or -115 deg (or any number?!) generally seems to result in an unpredictable outcome!

Other usages of this rotation process seem to show that angles of other than -115 may result in the hinge rotating through the 180 degrees from its home position.

Question 2a:
When a joint is driven, is the angle an absolute rotation or is the angle relative to that of a previously driven rotation?
[Obviously, after doing a rotation, the fact that the position of the model has changed is indicated in the menu bar at the top of the screen (offering the alternatives of Capturing the position or Reverting).]

Following these experiments, I went back to the more complex model which involves a pair of the Soss hinges joined to a panel which itself rotates on the pivot to the table structure.

One of the moving panels (the beige coloured one) can be easily dragged to its raised position simply by clicking on the panel itself and dragging it.

However, it is not then simply possible to rotate the blue panel relative to the beige panel by dragging on it.
Dragging on the edge of the blue panel can result in some (a small/ limited amount) movement but this involves the beige panel also moving.

[I mention this for the purpose of completeness - as we learnt last week, this is not an unreasonably behaviour if by using the flags we can rotate a specific joint independently of other unrelated joints.]

I then selected the "B1 to Top axle" joint of the (first of the two) Soss hinges in the browser and attempted to rotate it.
From the starting position seen as -0.1 deg, it can be easily dragged up but only by a little, i.e., to the angle of -5.1 deg.
During the dragging around process, a large number may be seen/ attempted to be entered, but it isn't actually realised and, by closing and subsequently opening the dialogue, the -5.1 deg is seen remaining.
Refer: DraggingBluePanel_V67.png

Question 3:
Why does this "B1 to Top axle" joint behave differently between the model of the hinge alone and when that same hinge is input to the table model?

I then selected the "B1 to Top axle" joint of the second of the two Soss hinges (which had been generated as a Copy and Paste of the first) in the browser and attempted to rotate it.

It shows the starting point of -5.1 deg (i.e., the same as the ending point previously seen for the first Soss hinge).
It can only be rotated towards the panel to the 0 deg angle.

-----------
[This is a related important observation but somewhat off-topic:]

Dragging other joints of the hinge also result in surprising behaviour.

In particular, I should mention having observed jumping of the indicated rotation angles;
as I drag other revolute joints around, I see things like 0 deg, -25 deg, -30 deg, 330 deg
Probably the fact that (in this example) 30 + 330 = 360 is not a coincidence?!

In an attempted animation by @davebYYPCU, severe jumpiness and hysteresis effects were observed, but not explained.
Refer messages 4, 5 and 6 of this thread.
I had written:
> I don't understand why the brick red (lower) panel jumps suddenly from being together with the blue panel to going to its final raised position at the other side of the table.

> There is a big hysteresis in the behaviour - after that sudden jump, going back in single steps doesn't reverse the motion before a lot of steps.
> Such an effect seems inconsistent with the linear slopes of the MS graphs.

> The associated revolute joint between the panels jumps through the full approx. 180 degrees for just one step of the Motion Study, despite the graph having a linear slope.
> The (linear changing) blue curve of the MS doesn't seem to be followed.

Question/ issue/ bug 4:
Although -30 and +330 deg may be considered the same mathematical, it is a bug to jump from one to another, at least in relation to severely impacting on a motion study!

-----------
It should be noted that a part of the hinge was grounded in the hinge's model, for the purpose of visualising the rotations in that model.

When the hinge is input as a component into the table model, it seems necessary to unground the component of the hinge that was grounded.

Question 5:
Does the exact point in the timeline matter where the unground is located?
I have it after all the stuff relating to the imported hinge.
Or, should it better be located immediately after the ground within the hinge's own part of the timeline?

Question 5a:
The same single unground also seems to unground the second hinge (which is a Copy/ paste of the first).
This is believed to be the case since I don't see any red pin in that component.
Is this the case that the single unground operation indeed applies also to the Copy/ pasted component?

The Soss hinge is a complex component involving three rotational axes and two slider joints.
Based on questions 1 and 2, it could be considered beneficial to, in some way, emulate the functionality of the hinge by a simpler "virtual" hinge with a single rotational axis.
However, doing so is probably not as simple as it seems.
When considered closely, the Soss is not behaving as if it has a single rotational axis.

The technical drawing of the Sass shows that there is a small gap of 1/32 inch between the faces of the hinge when the panels are in-line.
I take this into consideration in the table model in relation to the extension panels aligning flush with the edge of the main table top.
The hinge model seems to properly/ closely model the hinge parameters in the technical drawing.

I obtained it from the CAD section of Hafele's web site. Their catalogue states that it is a branding of the Soss 101.

I mention these details simply to highlight the fact that it is not possible to replace with a simpler "virtual" hinge.

In any event, I believe that the issues I have brought up are widely applicable to other applications and deserve to be properly considered, with hopefully solutions found and/ or bugs logged.