[BUG] Synchronization error when using zero-blend motion settings

[ldemt]

Is there an existing issue for this?

• I have searched the existing issues

Description of the bug

Dear HAL Team,

I have an error when I try to set "zero-blend" motions (motion settings where the blend value is set to 0 mm) in a track and robot cell.

When i set one of the motion settings blend to zero, I get the following error from the "Solve" component and i can't run the simulation :
"1. [ERROR] Ambiguous synchronization order defined. The order of synchronization cannot be defined. This may be due to settings being used in different orders in different procedures."

bug_blend_motion_synchronized.txt

I uploaded an example Grasshopper file as .txt file, to open it please rename it the extension to .gh.

My Rhino version is :
Version 7 SR38
(7.38.24338.17001, 2024-12-03)

Best regards,

Léo

Steps To Reproduce

1. Rename the attached .txt file to .gh
2. verify the procedure is executed and simulated correctly
3. Switch the output motion settings component of "blend motion" to "zeroblendmotion" component (it will replace the motion settings used in some moves of the example file)

Related Issues

No response

Additional Information

No response

[ldemt]

Dear all,

here is a workaround (use the comprehensive "Blend" component with a negligible but non-zero blend value) :

[sebandraos]

Hi @ldemt ,

This is a known limitation that probably isn't sufficiently documented but I will attempt to describe here.

The way synchronisation works in our software is by matching the Synchronisation Settings between one continuous sequence of motions and another continuous sequence of motions. To ensure unambiguous matching of those sequences we only allow each Sync Settings to be used once per Procedure. The issue that you're facing here is that when the Blends are zeroed out, that motion goes from being a single continuous sequence of motions to a series of discrete motions. That triggers our matching algorithm to detect that there are uses of the same Sync Settings in multiple sequences in the same Procedure. This also clashes with the fact that your Track's Motion Settings have a default non-zero Blend so it's multiple discrete motions trying to match to a single sequence. Assigning the same blend to the Track won't fix the problem but will give you a more explicit error:

[ERROR] Synchronization settings reuse found. Synchronization settings have been found in two distinct sequences of the same procedure.

The solution is to generate one Sync Settings per Motion when the Blends are zeroed. You can obviously do that manually but there are potentially a few different ways we can simplify this from a user perspective;

1. We can highlight this as an error during the Motion creation and suggest a solution there.
2. We might be able to add a new version of the Motion component which will, optionally, automatically generate and number the Sync Settings if we know that they won't be a single continuous motion.
3. We can add another component to generate Sync Settings based on a set of Targets or count (List Length of the Targets) and Motion Settings.

Would any of those make more sense to you than the others?

It's worth noting that none of these will fix the fact that the Track and Robot need to both be blended or unblended.