Solving some lingering F_error problems

I've been working on my 8 axis drink pouring robot for a while, and for the most part it's going smoothly. There are a few nagging errors that I am trying to track down so the thing is as robust and reliable as possible. One of the errors I experience is an f_error that happens with some motions.

To refresh, 4 of my axes are going through the motion controller and are working well in harmony. The other 4 axes are being controlled by M-codes and utilizing limit3 as essentially a one dimensional motion controller . The M-codes change the setpoint of the limit3 as well as it's Max Velocity so we have some control over the speed.

For the most part this works perfectly as expected. However, some motions seem to trigger an f_error fault. The f_error happens so quickly that it can be tough to see exactly when it happens. My first thought was that we're actually calculating the Max Velocity poorly. We were taking a bad assumption and dividing the change in position by the desired time to get the velocity. This doesn't take into account the acceleration, so it's off and always a little late. I did some math to determine the real values of Max Velocity to get from point A to point B in time t. I checked my math with some values and it seems to check out. This seems to have improved my situation a bit, but I'm still seeing an f-error consistently in some simple motions.

Perhaps there is a subtlety in how limit3 handles a changing Max Velocity. Maybe the timing of the g-codes isn't happening like I thought I understood (we're using G93 and being explicit about the feedrate between every "node"). Anyway, I've got some testing ahead of me, and I'm trying to figure out exactly what to look for. Maybe there's something I'm not thinking of?

They're steppers, and the errors are coming from a limit3 controlled axis.

I'm sure something is wrong, but I'm trying to figure out what it might be, and I don't think it's in the .ini file. I can smoothly control the axis via M-codes manually. However, if I run a full program that has m-codes interspersed within it I am more likely to suffer an f-error. I have a feeling its due to a more subtle timing issue and perhaps an artifact of how limit3 handles a changing Max_Velocity that might cause a motion spike.

Here's what I think might be happening.
I send the axis from A to B at a high Vmax. But, before it arrives at B I send another m-code that changes the destination to C but with a lower Vmax. If the velocity doesn't decelerate to the new lower Vmax, then I can imagine a feedback error that builds beyond my already large f-error limit. I'm going to have to read the source code of limit3 to see how it handles such a case.

Overall I'm also thinking generally about how to control my robot with accurate timing. I'm less interested in feedrates (I'm not machining), but I would rather have the robot arrive at the nodes at the right times and smoothly transition between them. I can make some pretty large compromises in positional accuracy to achieve faster response and smoother motion.

I would simply widen you following error limits
(say make them 10 times bigger than their current values)

This has two advantages:

1. It may solve your problem with no further work needed

2. If you still have issues, widening the following error limits may allow you to plot the error with halscope and perhaps determine the cause

I'm going to play around with increasing the following error limits even higher and see if I can snag a major deviation as it happens. I also need to figure out halscope a little bit so I can make sure it's doing what I want it to do.

I am using M-codes, but I'm not sure how they would prevent f_error messages. My m-codes only change the setpoint of the limit3 input. You can see my example code here.

I never implemented the branch that dgarret programmed. Maybe I take the time to get that implemented too.

The way I have it implemented is this:

limit3.out + axis.motor.cmd = > pid.in
pid.out goes to the 7i76.velocity-cmd

then the 7i76.position-fb gets the limit3.out subtracted off of it before it goes to the axis.motor-pos-fb

the 7i76.position-fb also gets sent to the pid.feedback

This way the axis can take control and conduct a homing cycle. Then afterwards I can control everything with limit3. (I use m-codes to change the setpoint and velocity of that limit3). This works a charm most of the time.

Is my problem because I'm driving with a velocity command through the pid loop? You had suggested I get rid of that earlier but I didn't get around to it because I got it to work and I didn't understand why the change was necessary. I figured there's a reason the pid loop is part of every axis...

By the way, how else do you envision this being structured? Which pins should limit3 be connected to?