Remora - ethernet NVEM / EC300 / EC500 cnc board

rbobey1989 wrote:

Hello everyone here, first of all thanks to Scott for keeping my work in mind and including it in the remora project, this is a great project without a doubt.
Well, to the point, I've been looking at some cheap drivers from AliExpress and Ebay, but I'm a little confused with all this about the new DMA stepgen, I would like to be able to get the most out of it, the DM860H stepper drivers that I've seen have a pulse frequency and direction between 100khz-200khz, I imagine that this frequency has to coincide with the 500khz of the DMA stepgen module. If you can clarify this for me, I would appreciate it and if you can point out a particular stepper driver.
I intend to buy an HBM BF35 milling machine and use some nema 34 12Nm motors with closed loop and yes Scott, the idea has always been to convert this machine to CNC in closed loop control, that's why I decided to take on the task of implementing the module QDC, thanks Scott for your ideas, I really appreciate them.
The HBS86 closed loop drivers, I am not sure if they can work in open circuit, I have used cloosed loop drivers before and they do not allow them to be used without the encoder connection, if someone can clarify this it would be good.

Thanks to you for your great contribution!!

The DMA stepgen uses a form of Direct Digital Synthesis. The underlying 1mhz clock drives the DMA. The required frequency is synthesised as close as possible over this clock frequency. There has to be a bit of inaccuracy between steps but the average will be very very close to the requested frequency.

rbobey, I've had a look at the stepper driver manual and this has prompted me to add a dirHold parameter to the DMA stepgen.

Now available in v3.1.0

For the DM860H stepper drivers the following step parameters are needed. Unfortunately we only have 1 micro second resolution to play with.

Hello everyone! I managed to install and configure everything! Thank you very much, Scott! But maybe someone has encountered the same problem as me, when I want to make changes to the HAL file, it gives an error at startup that an unknown loadrt command. Any ideas how to solve it?

Hello Scott, thank you for your very illustrative answer, I think I have understood, in the stepper driver datasheet there is a graph showing the time requirements for the step/dir signals and as you say, having a resolution of 1us, the times that you explain before are very Logically, I am about to order some DM860H drivers and some nema 34 motors but I am waiting for a response from the seller because I want to make sure that the encoder outputs are the ones I need, as soon as I have everything I will start testing a closed loop configuration, greetings

scotta wrote:

hanskuster wrote:

scotta wrote:

hanskuster wrote:

cakeslob wrote:

Hey Hans,
Since we are using  external hardware, I dont think that we use a basethread. That is mostly for parallel port setups. 
Its good that it shows up in the preview
 
Hi cakeslob,
I updated to the newest firmware and modified according to the info from scotta ( forum.linuxcnc.org/18-computer/44828-rem...rd?start=1360#285461 )
After many tries and tests I found that the stepper motor moves though, but only under certain conditions which I have no explanation for:
- I had to change the [JOINT_0].SCALE from 3000 to 6000
- when running the sample program axis.ngc the stepper move only sometimes, maybe bigger rapid moves?
Whenever the stepper moves, then I get many "Spike filter active..." in the console.
In Jog I can move the stepper only in bigger moves like 5mm and up. On smaller steps the motor doesn't move at all. Only its position on the display changes.

Any Ideas?

Regards, Hans

Wow, I've never seen the spike filter active in the Ethernet version. I think this is due to miss match between the LinuxCNC servo period and the controller board servo period.

The following line must to match the controller board servo frequency.

Code:

SERVO_PERIOD = 3000000 should be [code]SERVO_PERIOD = 1000000 ie 1khz   hi scotta, I had to modify the SERVO_PERIOD to avoid the latency error message. With the latency test I got a value of 40153 which should be good, I think. I changed the SERVO_PERIOD back to 1'000'000 and still get "Spike filter active..." but now with smaller values than with 3'000'000. Regards, Hans Don't worry about the latency warning. As we're only using the LinuxCNC servo thread a bit of jitter is of no concern. The hard real-time stuff is running on the controller board. I've got so use to closing the error pop up on every restart.   Hi scotta, thanks for Your help! The version 3.1 and the new parameters I could make my system running. I had to set the following parameters:  

[/code]
 

Hi scotta, rbobey1989 and cakeslob,
with Your help and infos I could make my system running!
I checked my motors and found that they are capable of 200kHz only, but Remora delivered 500kHz.
So I flashed version 3.1 and modified the parameters to
Now the motor did move but I still had the "following error".

I had to modify the module remora-eth-3.0.c as follows: The commented-out code is not needed because I don't have any feedback from my motors.

Now, let's start to conquer the next problems

Regards, Hans

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. 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

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.