It seems like @Ebbe is referring to this workaround from 2019 : API generated Waypoints lack in Range of TCP Offset - #8 by jbm
Apparently, there is a quite long-lived bug in the way API generated waypoints have their inverse kinematics solution calculated. It only seems to happen when the relevant tcp-offset has some specified rotation. And the effect is that the joint angles of the generated waypoint does not match the configuration of the qNear parameter. Here is a way to recreate the bug: PositionParameters / Wrong Pose using WaypointNodeFactory with specific TCP Rotation - #7 by m.birkholz
@jbm’s solution above involves adding a MoveNode configured to use a defined TCP rather than “Active TCP” or “Ignore TCP”. Here is an example of some code to fetch one of the defined TCP’s from the installation API:
This bug was super annoying for us to work with and it set us back a couple of weeks of development. In my opinion, it should have been fixed a long time ago, or an official workaround should have been released so that it was easier to find.
Hope this helps!