Remora - ethernet NVEM / EC300 / EC500 cnc board

cakeslob wrote:

Frame size you might have some searching to do, they have 60mm frame size but Im not sure the nema equivalent.
Im fairly sure AC servos will be better, as the motors will probably be 200v. I dont remember if the ac servos get converted back to DC anyway.

When it came to sourcing the motors between AC and DC, my main deciding factor became supply voltage. I found it hard to source the servo drive with my voltage requirements for AC servos, as most I came across were 220v, where DC servo drives I could use 48v DC. My machine is a 110v machine, so it was the deciding factor. If you do not have these limitations, probably go with AC

Yeah my spindle is 220v, so I would rather use AC servos, I seen some on omc-stepperonline but their kind of expensive for the Nm output they have. Also for some reason they seem to be pretty low or out of stock.

If voltage is not an issue, I suggest use AC probably. something like 200W-400W is what your size group will be.

chrstrvs wrote:

Which one is the correct one to use for NVEM with STM32F207?

Yeah good question. Everything is rather confusing at the moment. A newly structured Remora repo is in the works with all firmware, configs and components in one central location, to make everything much easier.

According to the docs , NVEM is the branch you are looking for, as stated before

remora-docs.readthedocs.io/en/latest/har...hernet/ethernet.html

Hi there

To recap, I am trying to setup LinuxCNC with the testing branch of DMA (IE the cpp firmware)

I have formatted a new computer with Debain 12 (Bookworm) as the old computer I was using had had a lot of different softwares during the course of testing various things.

I am running "LINUXCNC - 2.9.0~pre1+git20230208.f1270d6ed7"
And I have put loadrt remora-nv PRU_base_freq=450000 in my HAL file (also changed the remora-nv.c to 500000 )

I have changed the PRU from 80000 to 450000 in stages, but the problem remains.

The problem is this, sometimes when I start LinuxCNC everything runs smoothly & other time when I jog the axis they stutter & stall. I haven't changed anything. When I exit & restart it sometimes fixes itself. There doesn't seem to be any rime or reason.

I know this is all experimental but I thought I'd see if anyone else had come across this.
I have a video of whats happening so see what you think.
Just to repeat the PRU value doesn't change between videos.

youtube.com/shorts/XIrLCH1m3ZI?feature=share

Alex

Perhaps try setting something like this:

"Step Length": 4,
"Step Space": 4,
"Dir Setup": 15

For every joint in the ec500.txt config file that gets loaded on the board via ethernet. Seems like the board is too fast for what your drivers can handle. Just a guess ... Worth triyng

Load it on the board then power cycle it to be on the safe side

frayja2002 wrote:

Hi there

To recap, I am trying to setup LinuxCNC with the testing branch of DMA (IE the cpp firmware)

I have formatted a new computer with Debain 12 (Bookworm) as the old computer I was using had had a lot of different softwares during the course of testing various things.

I am running "LINUXCNC - 2.9.0~pre1+git20230208.f1270d6ed7"
And I have put loadrt remora-nv PRU_base_freq=450000 in my HAL file (also changed the remora-nv.c to 500000 )

I have changed the PRU from 80000 to 450000 in stages, but the problem remains.

The problem is this, sometimes when I start LinuxCNC everything runs smoothly & other time when I jog the axis they stutter & stall. I haven't changed anything. When I exit & restart it sometimes fixes itself. There doesn't seem to be any rime or reason.

I know this is all experimental but I thought I'd see if anyone else had come across this.
I have a video of whats happening so see what you think.
Just to repeat the PRU value doesn't change between videos.

youtube.com/shorts/XIrLCH1m3ZI?feature=share

Alex

With the DMA stepgen implementation you do not have the flexibility to change the PRU_base_freq on the controller board. It is hard coded for 500khz. In LinuxCNC the command line setting only sets the upper frequency limit (velocity command) allowed to be sent to the controller board.

What pgain have you set? I've found that to higher pgain will cause oscillations.

Here is the machine with the exact same setting ( just a restart) running smoothly.
You can hear the sound difference.

Seems to be random.

youtube.com/shorts/0rLC4tKUu0I?feature=share

Edit-01

I have tried this on my Biessie machine which used Yaskawa driver servo motors & yes the speed is much increased & working better, but at random the direction of the axis changes. I think I saw mention of this earlier in the thread. I'm assuming it's related?!?
 

cakeslob wrote:

If voltage is not an issue, I suggest use AC probably. something like 200W-400W is what your size group will be.

chrstrvs wrote:

Which one is the correct one to use for NVEM with STM32F207?


Yeah good question. Everything is rather confusing at the moment. A newly structured Remora repo is in the works with all firmware, configs and components in one central location, to make everything much easier.

According to the docs , NVEM is the branch you are looking for, as stated before

remora-docs.readthedocs.io/en/latest/har...hernet/ethernet.html

Yeah, some organization wouldn't hurt. I'm very greatful for the hard work by people like Scott, but for a beginner like me, it can be quite difficult when the documentation and organization isn't complete.

I was clever enough to figure out that the NVEM branch is the correct one to use, but in that branch there are two different firmwares in two different locations without any documentation stating which one to use. Now I know though =)

Hello everyone! There is an NVEM board with a MIMXRT1052CVL5B chip, tell me, will it be stitched under LinuxCNC or not?

Is remora able to do encoders yet on the EC500? Looking to get the turret working. It has one signal for tool position and one for  full revolution. 5v

Spindle encoder is a single phase feedback with index. (Cheese wheel notched) 5v

Hi Murphy, the hw encoder module is under development again as of this moment hehe, I say as of this moment because one of the possible modes of operation of the encoder would be just as you explain but I didn't think about it when I implemented it, although not It would be difficult to add that behavior currently, Scott is aware of my progress with the QDC encoder module, a QDCencoder branch has even been created for the hw encoder module although it is not updated with the final version of the firmware, I leave you my repository for Take a look, I could look at this topic on the weekend if I have some time, greetings