Remora - ethernet NVEM / EC300 / EC500 cnc board

cakeslob wrote:

lol Hans, I like your enthusiasm, but the feedback from the motor is not what you may be thinking a. You will still physically get the following error, but it may not alarm for it. The feedback is not from the motor, but from the stepgen.

Code:

error = command - feedback; if linuxcnc commands more steps than it receives feedback , that is ferror and it should be, because you have sent more steps than you actually do. A following error occurs when linuxcnc commands a position that it can not physically achieve in the time required. If your commanded distance/speed cannot be made in the time needed within the FERROR parameter, you get an error. If you didnt get an following error, you would suffer from skipped steps and positional errors. The recommended course of action to address following errors, is probably involving these parameters [code]MAX_VELOCITY = 166.0 --- start low and go higher MAX_ACCELERATION = 400.0 --- start low and go higher STEPGEN_MAXACCEL = 440.0 --- start low and go higher SCALE = 3000.0 --- start low and go higher FERROR = 1.0 --- start high and go lower This is how much distance error you allow MIN_FERROR = 0.5 If your joint scale is still 6000, I would start by making that lower. If linuxcnc is trying to send 6000 pulses per mm, it needs to physically be able to execute that many steps in the time required.

[/code]
 

Hi scotta and cakeslob,
thanks for Your information!
I don't think this parameterizing is necessary with the motors I use.
My Motors can be wired like a "normal" stepper motor (pulse and direction) with the differenc that these motors themself have a closed loop intergrated. This handles a possible following error autonomously.
See attachment and/or www.aliexpress.com/item/1005005276593086.html

That's why I tried to short "feedback = command" in the module remora-eth-3.0.c to "simulate" a motor with no following error, as this would be handled by the motor itself.

For this kind of motors LinuxCNC should be "blind" regarding a possible following error.

Now I found that this short didn't help either.
Sometimes the value of joint.0.pos-fb diverges from joint.0.pos-cmd although the motor doesn't move at all
And this then triggers a following error.

How could this be fixed?

Regards, Hans

Hey Hans.

The type of stepper motor makes no difference in this case, and even closed loop motors will be affected by following error. Following errors would not be detected by your stepper driver, your stepper driver will only detect physically missed steps unrelated to linuxcnc, because it is not in the linuxcnc control loop.

A following error is in the control loop between linuxcnc and remora, your motors are not involved. If the controller ran blind, you would still and the same issue, it would just not be detected. Your stepper motors would not detect the issue because they are not involved in the process.

How could this be fixed? 

You need to understand the issue and fix the root cause.
The issue is Linuxcnc is sending more steps than remora can execute (to put it simply) But it could also have to do with the speed/accel settings, where linuxcnc cannot preform the desired moves without deviating from the ferror parameters. In a blind system with closed loop motors, it would still be a problem, but it would be undetected by the controller. You would have a positional error but linuxcnc would not know, and your stepper motors would not know.



The root cause is found somewhere in your ini file. I would advise you to revert the configuration and component to the supplied default parameters and work from there. By modifying the component and changing critical parameters, you are making it more difficult to troubleshoot. You shouldnt need to modify the component to make it work with your system. I would suggest brushing up on some of the linuxcnc concepts in the manual, keeping in mind not everything will be relevant to remora, but some concepts like motion and speed, will always be relevant.

I made a quick illustration that is a simplification of what a following error is and why it affects closed loop drivers, incase it will aid in the understanding of the issue. I dont have the most comprehensive understanding of it all but I think I understand a general amount.

Perhaps I am wrong, but I would revert your component and configuration and start with the parameters mentions in the earlier post by Scott



 

cakeslob wrote:

Hey Hans.

The type of stepper motor makes no difference in this case, and even closed loop motors will be affected by following error. Following errors would not be detected by your stepper driver, your stepper driver will only detect physically missed steps unrelated to linuxcnc, because it is not in the linuxcnc control loop.

A following error is in the control loop between linuxcnc and remora, your motors are not involved. If the controller ran blind, you would still and the same issue, it would just not be detected. Your stepper motors would not detect the issue because they are not involved in the process.

How could this be fixed? 

You need to understand the issue and fix the root cause.
The issue is Linuxcnc is sending more steps than remora can execute (to put it simply) But it could also have to do with the speed/accel settings, where linuxcnc cannot preform the desired moves without deviating from the ferror parameters. In a blind system with closed loop motors, it would still be a problem, but it would be undetected by the controller. You would have a positional error but linuxcnc would not know, and your stepper motors would not know.



The root cause is found somewhere in your ini file. I would advise you to revert the configuration and component to the supplied default parameters and work from there. By modifying the component and changing critical parameters, you are making it more difficult to troubleshoot. You shouldnt need to modify the component to make it work with your system. I would suggest brushing up on some of the linuxcnc concepts in the manual, keeping in mind not everything will be relevant to remora, but some concepts like motion and speed, will always be relevant.

I made a quick illustration that is a simplification of what a following error is and why it affects closed loop drivers, incase it will aid in the understanding of the issue. I dont have the most comprehensive understanding of it all but I think I understand a general amount.

Perhaps I am wrong, but I would revert your component and configuration and start with the parameters mentions in the earlier post by Scott



 

Hi cakeslob,
Tanks very much for Your detailed information! I appreciate Your time You invested into this!
I reverted the component remora-eth-3.0.c and my ini file.
The only difference in the ini file now is the SCALE only, which I set, according my hardware, to 1000.

I know the theory of following error, but I was not aware that here the following error is caused by remora not beeing able to send all steps.
As a test I increased the SCALE to 2500 and set the setting on the motor accordingly, I got following errors again, especially on fast moves. Back to a SCALE=1000, which would be accurate enough for my use, I can make even very fast moves again.

Thanks again for Your highly appreciated help!

Regards, Hans

Hey Hans, that is good to hear.

My explanation of following error was a narrow one, there can be other causes, relating to things like speed and acceleration. Now that you have a working profile, you may be able to optimize your setting further.

I like using this prusa calculator to find the optimal speed/acceleration settings for my machines

blog.prusa3d.com/calculator_3416/#acceleration

Hi all,
I discovered a new problem.
After startup of LinuxCNC the direction of the stepper is not always the same. Sometimes "+" moves the slider away from the motor and sometime against the motor. The direction remains that way until the next startup or even several startups.
What is wrong with my setup or what could cause this direction swaps?

Because I setup the X-axis only, I attached the config part for that only.

I connected an LED to the direction output. The output of the direction signal is consistent with the moving direction of the motor.
With this LED I discovered that the signal sometimes start to blink after the movement has stopped.

What could cause this changing of the direction of travel?

Regards, Hans

Hmm. I'm guessing this is with the DMA stepgen. I thought my last changes had solved that issue. It's not a LinuxCNC config issue.

If you could monitor the situations which lead up to this bug that would be appreciated so I can try to narrow down the underlying cause.