Trajectory Planner using Ruckig Lib

The concept of a following error is strange when talking about stepper motors. Since they are an open loop system, there is no position feedback to let you know if you actually are out of range. LinuxCNC calculates if it can keep up with the motion called for, and if not, then it gives a following error. Following errors usually are the result of one of the following on stepper systems.

• FERROR too small
• MIN_FERROR too small
• MAX_VELOCITY too fast
• MAX_ACCELERATION too fast
• BASE_PERIOD set too long
• Backlash added to an axis

Any of the above can cause the real-time pulsing to not be able to keep up the requested step rate.

smc.collins wrote:

You can use encoders for position feedback with Linuxcnc, there's a bunch of threads about it.
 

    /* calculate following error */
    if ( IS_EXTRA_JOINT(joint_num) && get_homed(joint_num) ) {
        joint->ferror = 0; // not relevant for homed extrajoints
    } else {
        joint->ferror = joint->pos_cmd - joint->pos_fb;
    }
    abs_ferror = fabs(joint->ferror);
    /* update maximum ferror if needed */
    if (abs_ferror > joint->ferror_high_mark) {
        joint->ferror_high_mark = abs_ferror;
    }

    /* calculate following error limit */
    if (joint->vel_limit > 0.0) {
        joint->ferror_limit =
        joint->max_ferror * fabs(joint->vel_cmd) / joint->vel_limit;
    } else {
        joint->ferror_limit = 0;
    }
    if (joint->ferror_limit < joint->min_ferror) {
        joint->ferror_limit = joint->min_ferror;
    }
    /* update following error flag */
    if (abs_ferror > joint->ferror_limit) {
        SET_JOINT_FERROR_FLAG(joint, 1);
    } else {
        SET_JOINT_FERROR_FLAG(joint, 0);
    }

Joco wrote:

smc.collins wrote:

You can use encoders for position feedback with Linuxcnc, there's a bunch of threads about it.
 
Yes I understand that. I have that on my mill.  However that is not the issue.  The problem is that for some reason the addition of the ruckig runner instances has somehow/somewhere generated a following error condition within in open stepper system.  So we need to unpick where/why/how that is happening.  As where things stand the code is great in the sim and dead in the water on physical kit, well specifically my phyiscal kit.  Unless someone has tested this latest code line on physical kit and has it working.  If so I REALLY want to see what their config setup is.


 

• MIN_FERROR = 0.010 - This is the value in machine units by which the joint is permitted to deviate from commanded position at very low speeds. If MIN_FERROR is smaller than FERROR, the two produce a ramp of error trip points. You could think of this as a graph where one dimension is speed and the other is permitted following error. As speed increases the amount of following error also increases toward the FERROR value.
• FERROR = 1.0 - FERROR is the maximum allowable following error, in machine units. If the difference between commanded and sensed position exceeds this amount, the controller disables servo calculations, sets all the outputs to 0.0, and disables the amplifiers. If MIN_FERROR is present in the .ini file, velocity-proportional following errors are used. Here, the maximum allowable following error is proportional to the speed, with FERROR applying to the rapid rate set by [TRAJ]MAX_VELOCITY, and proportionally smaller following errors for slower speeds. The maximum allowable following error will always be greater than MIN_FERROR. This prevents small following errors for stationary axes from inadvertently aborting motion. Small following errors will always be present due to vibration, etc.

Grotius wrote:

•  
  • 
    @Rmu,
    The planner Joco is tested, is the original planner written by Rob Ellenberg. Integrated are 3 ruckig runners.
    The trajectory planner updates next position by a trapezium vel profile. The velocity profile of the ruckig runners is of type
    scurve. So there is a difference. But the difference is tiny because of the 1ms cycle. This approach works in simulation and there is even published a video proof of it.
    
    This approach simply can't work even in principle.
    I don't agree with your statement. It's proved working.
    
    in RTAI, realtime stuff is running as kernel module, and C++ is not possible in kernel modules. Nor can you link shared libraries. Hiding the C++ stuff behind extern "C" is not enough.
    I also disagree with this statement you made here.
    Using c++ in kernel modules is almost my daily task.