Remora - ethernet NVEM / EC300 / EC500 cnc board

Unfortunately following error is the joy of LinuxCNC as Cakeslob said it's a necessary part of the motion control loop and what separates LinuxCNC from other "blind" CNC controllers.

SCALE should equal your physical steps/mm

Your joint max velocity should be higher than your [TRAJ] max velocity so that the control loop can try can reduce the following error.

Hi Scott,
CMSIS-DAP ST-Link to program EC300 (MIMXRT 1052)

After all of the questions that you received with the DAP-link issues, I feel awkward to ask for help with the CMSIS-DAP ST-Link method.
I have the two ST-link clones wired as in the 'Remora RT1052 DAPLink Programming' YouTube video but discovered that I had missed the chance to download the two .bin files for the DAP-link method.

I have the CMSIS-DAP-STLINK21.hex file.
How do I get this firmware onto the ST-Link clone?  Using MCUXpresso?
Is there a link describing this initial step, without having previously made a DAP-link with the old .bin?

TimGow wrote:

Hi Scott,
CMSIS-DAP ST-Link to program EC300 (MIMXRT 1052)

After all of the questions that you received with the DAP-link issues, I feel awkward to ask for help with the CMSIS-DAP ST-Link method.
I have the two ST-link clones wired as in the 'Remora RT1052 DAPLink Programming' YouTube video but discovered that I had missed the chance to download the two .bin files for the DAP-link method.

I have the CMSIS-DAP-STLINK21.hex file.
How do I get this firmware onto the ST-Link clone?  Using MCUXpresso?
Is there a link describing this initial step, without having previously made a DAP-link with the old .bin?

Hi, it's the same process as using a ST-Link to convert another ST-Link into the DAPlink like in the video. You just use the CMSIS-DAP firmware.


 

Hi! I want to connect nvmpg to my machine, but not to the axis GUI, but to gmoccapy. The board I use has an RT1052 chip. Do you have any ideas how this can be implemented? And is it possible to do this?

I dont know the details for what or how the pendant is supported but there doesnt seem to be anything axis UI specific in the sample config. It all appears to be connected to halui and motion. So it should just be a matter of changing your ini file to say gmocappy

github.com/scottalford75/Remora-NVEM/blo.../remora-nvem-mpg.hal

Thank you for your reply! I will dig in this direction.

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.

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