I'm not sure what you mean by "set". If you mean the 'Set' buttons in KMotionCNC that wouldn't be correct. Those set GCode offsets. The Kinematics operate on the absolute Machine coordinates of the system. Instead after setting the arms inline go to KMotion.exe Console Screen and issue ZeroN commands for both your axes where N is replaced by your axis numbers. 7 and 6? (Not sure why you aren't using 0 and 1, that would be more logical).After reading your reply I first moved the arms inline and along something close to an x axis. Then I set the postion of the end (47,0)
You should then be able to verify on the KMotion Axis Screen that the Destination on those axes are 0.
KMotion should then show a position or 47,0 if the Kinematics is working correctly.
I do worry that with both arms straight out that it is at a something like a singularity where there is near zero/infinite relation ship between the X position and arm angles. So it might be better to do something like rotate the 2nd arm CCW 90 degrees in KMotion using a Move6=XXX. KMotionCNC should then show 23.63,23.63. Be sure to remove any GCode offset you may have set (clear out everything in the Edit Fixtures Screen) or display Machine Coordinates.
Change the sign of the OutputGain for the Axis.One thing I realized is my shoulder joint is turning the reverse from what I think should be the positive direction, for coordinates as drawn. So for example, a moveRel7=5000 from the console moves in what would be the clockwise direction, looking down on the robot, or towards the x axis. I think I just need to flip the direction in the channel setup? I'm guessing it is straight forward, but I'm missing it.
That's a silly bug we've been struggling to get rid of. Once the values are set negative they can't be changed from the GUI. If you exit KMotionCNC and manually edit the file \KMotion\Data\GCodeConfigCNC.txt CountsPerInch parameters to a positive number then the GUI should allow you to change them.I did try setting the count/deg in the trajectory planner to negative but I don't think that was right. And, oddly, now that I changed x and y ( I mistakenly changed y) I can't seem to set them back? I tried removing the minus, but they seem to persist after choosing "OK" and also after a restart.
Regarding KMotion Vel, Accel, and Jerk you should test in the KMotion | Step Response Screen by performing Moves. The Jerk of 4e6 should be fine which is essentially infinity (pure acceleration limited). The Acceleration seems a bit slow. With a value equal to Velocity means that it will take 1 second to accelerate to full velocity. So you will need to test a move like 3 seconds long to see full velocity. Plot Velocity to observe what velocity you are actually testing.On top of all this, I did not do anything with the "jerk" in the step response screen, I left the default. Not sure important this for what is, if I' sayin git right, effectively an open loop system, form Kmotion's perspective?
Do the test described above (arms at 0 and 90 degrees) to verify the Kinematics are working correctly. as well as some other angles.I was going to clarify that I was mostly blindly using the scara kinematics files included (KMotion5.4.1\GCodeInterpreter\KinematicsScara.cpp) with kmotion, with the one change of making the arm lengths match my machine. I opened it to take a closer look, and now I think I am maybe treating 0,0 wrong. I think this line offsets the machine base to right (x pos) of 0,0 by the length of the arms.
Also Set 'Rapids as Feeds' in the KMotionCNC | Trajectory Planner Screen as with non-linear systems like this rapids need to be treated the same as curved paths from a trajectory planning perspective.
HTH