Knee mill table height; external offset or something else?

Thanks for suggestion, pos3 is there because without it there is no change in neither joint.2.pos-cmd nor joint.3.pos-cmd when table is moved. Z value in dro changes though. I would like to understand why it does that.

When pos3 is added to kinematics, joint.2.pos-cmd follows the position of the table encoder, but pid goes crazy. Screenshot attached. 

 

 

tightmopedman9, I just connected some cheap chinese linear encoder to Mesa board encoder input. 

 

Thanks for suggestion, pos3 is there because without it there is no change in neither joint.2.pos-cmd nor joint.3.pos-cmd when table is moved. Z value in dro changes though. I would like to understand why it does that.

I would only expect the z dro position to change as you move the table up. Are you expecting the quill to automatically retract? 

I'm just somewhat doubtful that the 'pos' variable actually works across both the forward and inverse functions the way you think. But since I'm no good at C I may be wrong and your code may be right.

It would not be necessary for quill to retract automatically but I can't figure out how it could work otherwise.

If custom kinematics is made without additional variable, for example zeroing Z axis in dro does not work. It kind of zeroes only joint2 part so joint3 reading will stay in the dro.

I think it's because there is following error in joint3 (joint3.pos-cmd will stay at zero) but I'm not sure. Also joint3 position wont reflect to MDI commanded position, so basically only dro reading changes but nothing else works.

Ok it seems to be working now. I ended up using additional variable (pos3) in kinematics module and smoothing out the joint3 encoder input signal in HAL wit LIMIT3. Still need to verify that joint limits are completely functional but i guess they should be.
Thanks

No luck, trajectory planner seems to care only about axis limits. So back to square one.

I found some old posts from 2016, github.com/LinuxCNC/linuxcnc/issues/97

Apparently this remains to be unsolved issue with trajectory planner.

Joint limits are respected when the program is executed but violations will not be detected when a program is loaded. This can lead to a program aborting during runtime.
In your particular case there may be a workaround as it is possible to change the limit settings in the ini file from inside a running Linuxcnc session. So you could adjust the knee during job setup, adjust the limit values and then load/reload your gcode and it will behave just like a regular machine.

It might respect joint limits but the trajectory planner does not seem to calculate deceleration approaching soft limits. I tried only by jogging onto soft limit -> following error.

Interesting, I have to study this inihal thing. Thanks again!

m0602232 wrote:

It might respect joint limits but the trajectory planner does not seem to calculate deceleration approaching soft limits. I tried only by jogging onto soft limit -> following error.

It does, i have several machines that can do 24-36M/M and can jog them freely up to limits at full speed, it never hits the hardware limits since soft limits are set 5mm before hard limits.

Yes when using axis limits it works but I can only rely on joint limits in this case. Are you sure it should work with only joint limits in world mode?