search

HALRobotics / Beta

HAL Robotics Framework beta release and associated documentation.
17 stars 3 forks source link

Swapping Composite Child Input Makes Controller Execution Unresponsive #9

Closed bringley closed 6 years ago

bringley commented 7 years ago

The HAL Execute component ceases to respond to input from the HAL Execute Bar after swapping out the Child input of the Composite Mechanism (Assemble) component.

The Execute mesh preview updates properly when the Child input is changed (for example, when a new tool is supplied as the Child input) but does not simulate when the Play button of the Execute Bar is selected.

Furthermore, if the user then proceeds to supply the original Child input once more, neither the mesh preview updates properly nor does the Execute component simulate properly.

This issue can be resolved with a Rhino restart.

This issue occurs in the following Rhino version: Version 5 SR14 64-bit (5.14.522.8390, 05/22/2017)

And the following Grasshopper version: 0.9.0076

On the following operating system: Windows 10 Pro 1703 OS build 15063.608

Please advise and thank you for your time.

bringley commented 7 years ago

This issue can also be resolved by re-executing the Grasshopper graph (re-executing individual components does not seem to work, but re-executing the entire definition seems to work dependably).

I suspect something in HAL downstream is not listening to upstream graph changes properly.

thibaultschwartz commented 7 years ago

Hi Brian, Thanks for reporting this. So it seems that in this case there is an issue when the composition of an identified mechanism changes over time. As a general rule: radically changing hardware settings without creating a new controller for the new hardware might lead to issues such as the one you are experiencing. We will stabilize this.

Also, please note that HAL components are not working like traditional components in GH, as there is no "downstream/upstream" data going through wires, only shared references. We have our own graphs on the back doing the real computations with corresponding objects in the correct order (which does not necessarily correspond to the GH workflow) etc. So it's like having several GH documents talking to each other to solve different simulation aspects. In general nothing in the plugin is standard: component creation, display, parameters, settings, units, everything is custom and running outside rhino/GH, we are just disguising it to make it feel as "grasshoppery" as possible. This is also why sometimes restarting Rhino is the only way to fix an issue: it starts a new, clean session, free of any corrupted elements in the various graphs we run on the background. These cases of corrupted objects should all be fixed before the end of the year.

Best, Thibault

sebandraos commented 6 years ago

This should be fixed in the latest updates. Please feel free to reopen if this is not the case.