From the turntable manufacturer, we were directed to simply set the A, B, C values to zero for the Root Point using the Numeric Input option. His reasoning was that since the table was leveled, which he also directed us to do, that we were simply rectifying the machine data with the actual table.
I just want to state for the record that his advice was fundamentally unsatisfying. I really want to know why the machine made the incorrect calculation to begin with. I get worried that this is the result of crossed wires in the data cable. It should be noted that this same manufacturer sent us a power cable with 4 of the wires in reversed positions; I had to track this problem down myself, open the cable to expose the leads, reverse the positions of the brake power lines and the mains power lines, and reassemble. It all now works. But that isn't to say that the data cable was wired correctly, which I haven't yet checked and don't know how to check.
All that said, our table and the simulation are rotating in the same direction - initially. I have a gh definition that you had made for one my colleagues here and I modified it so that the generic turntable component matches our turntable location as well as to incorporate some changes I had made to our hotwire tool. With another adjustment to the opoint of the Orient Plane component to get the tool to align correctly, I got CORE to solve and generate code that does run in our robot.
However... the robot still thinks it's upside down relative to the table, even though I zeroed A/B/C as seen in the picture: X/Y/Z are all negative. So when I run the program the robot wants to push the TCP to the positive position relative to the table top, which in this case would be underneath the table top. If I then change the C value in the robot back to 180, the program will execute again, but when I gets to about line 14, I think, it links with the table and the TCP and the table start synchronously rotating counter-clockwise, opposite of programmed rotation. Eventually, the robot hits an axis limit and halts movement.
I fully realize that you're not responsible for our hardware problems, but I'm hoping you might have some insight as to what is causing this or maybe direct us to information somewhere, somehow that will reveal what we are fundamentally missing.
As to our calibration method, I've marked the reference point on the table as (395,0,0,0,0,0) [X,Y,Z,A,B,C] per the manufacturers specification, which is also set in the Axis Configurator in the variable $ET1_PINFL. When I calibrate the table, I first unmaster the table, then master in Dial mode with the table top more or less square to the base and in the location that I want to use it for this project. I have created a tool for the reference point using the same input as the Axis Configurator. I used a previously calibrated TCP with a metal point mounted as the measure tool. I followed through with the procedure lined out inside the Root Point measure tool inside Setup.
The way all of this is setup, I would expect that the positive X direction in the Rotary base for the external kinematic should point from the center of the table toward the reference and the positive Y perpendicular to the left of that vector. In fact, after calibration, using the newly calibrated Rotary1 base coordinate system, the positive X lies in the direction of what I thought should be negative Y and positive lies in the direction of what I though should have been negative X. And as you might guess, positive Z is down into the table. No matter what I do, it keeps thinking the table is upside down.
This is why I thinking we've got crossed wires somewhere, or a secret button wasn't set correctly inside some as yet unseen configurator that no one wants to tell me about.
We just can't make any progress at all because of this problem and I just don't know what else to do.
I've attached the rhino and gh files to see our setup. This will run in our robot, just not like what you see in the simulation.
