Remora - ethernet NVEM / EC300 / EC500 cnc board

  

Hello! I am new to the CNC world and am currently building my first machine. Stepper drivers have have not arrived yet, but I already have the ec500-rt1052 and I’m trying to configure it. After countless failed experiments with Windows and Linux virtual machines (I still have to live with the culture shock of seeing the mach3 UI color scheme), I finally came to LinuxCNC on the RPi.

The first problem I tried to solve was changing the IP address to connect to my local network (yes, I know a network switch between ec500 and RPi is a bad idea). I changed the address and added debug code in

Remora-RT1052-cpp/Remora-RT1052-cpp/source/ethernet.h
Remora-NVEM/LinuxCNC/Components/NVMPG/nvmpg.c
Remora-NVEM/LinuxCNC/Components/Remora-nv/remora-nv.c

Did I miss anything?

According to linuxCNC STDOUT it can find the controller and establish TCP and UDP connections. But it is not even possible to toggle the emergency stop in the GUI. At same point it starts to complain in the output "Ethernet ERROR: Resource temporarily unavailable"

As the next attempt I rolled back my changes and returned to 10.10.10.10. It allows to toggle the emergency stop and even to run the sample code. But again at some point it blocks and starts to print "Ethernet ERROR: Resource temporarily unavailable"

I can imagine, that "Resource temporarily unavailable" by missing stepper drivers or by not connected spindle (however I am not sure that is the real reason). But why it does not work at all with the changed IP address? Should it be changed somewhere else? 

oficinerobotica wrote:

Hoping this can help anyone, here is my experience so far. I'm using the DMA branch. I managed to flash the board and upload a configuration to it and install both remora-eth and remora-nv linuxcnc components. I've installed them both because there are various example configurations in various branches. Some use one component, some use the other. 

Long story short, with LCNC out of estop, i kept getting folowing errors as soon as I tried to jog even at 3mm/min. After hours of banging my head I decided to do a full chip erase and a reflash of the board using pyocd.  I supose the full chip erase did something because i reflashed the ec500 before. And wow... no more following errors. Full speed ahead. The same pc and the same configuration.

Now I have created a simulated machine using stepconf just to be able to study the configuration files. Default 3 axis mill. On the simulated machine I get no real-time delay errors.
For the kiks of it I used that configuration loading the remora component in .hal instead of its own and I immediately get the dreaded real-time delay error. Now why is that? The delay is tied in some way to the remora  component? Pinging the board I get ~0.150ms response time. 

Can the delay be safely ignored in my main remora configuration?  I can get rid of it only when I set the servo-thread at 5000000. Anything below will bring it up as soon as I go out of estop. Should I set the servo-thread to 1000000 and just ignore the pop-up?

Great to hear. Yes leave the servo thread at 1000000 and ignore the pop up.

chrstrvs wrote:

Hey, Scott!

Thanks for replying!

The NVEM is a v2 with a STM32F20-something.

1. Flash Remora firmware - done
Yes.
2. Installed remora-nv LinuxCNC component - done, by the sounds as the example config starts
Yes, although since I followed your video, which if I understand correctly might be a bit outdated, I accidentally installed the older component Remora-eth, and then later Remora-nv. I don't know if that could have a negative effect on anything?
3. Checked communication with the board by pinging 10.10.10.10 - done, by the sounds as LinuxCNC has come out of e-stop?
Yes, this works!
4. Uploaded a configuration file to the controller board? python3 upload_config.py yourconfigfile.txt
Well yes and no. I tried it to see that it works, but to be honest I don't know what config to upload.

As I don't have any motors connected it's hard to tell if there is any movement, but looking at the graphic inteface it does not appear to be moving.
Also when I get the "joint [0-2] following error" the machine shuts down.

Ok, so an original NVEM. So the following configs are known to work.

github.com/scottalford75/Remora-NVEM/blo...vem-basic-config.txt

github.com/scottalford75/Remora-NVEM/blo...nvem-full-config.txt

zxfr wrote:

Hello! I am new to the CNC world and am currently building my first machine. Stepper drivers have have not arrived yet, but I already have the ec500-rt1052 and I’m trying to configure it. After countless failed experiments with Windows and Linux virtual machines (I still have to live with the culture shock of seeing the mach3 UI color scheme), I finally came to LinuxCNC on the RPi.

The first problem I tried to solve was changing the IP address to connect to my local network (yes, I know a network switch between ec500 and RPi is a bad idea). I changed the address and added debug code in

Remora-RT1052-cpp/Remora-RT1052-cpp/source/ethernet.h
Remora-NVEM/LinuxCNC/Components/NVMPG/nvmpg.c
Remora-NVEM/LinuxCNC/Components/Remora-nv/remora-nv.c

Did I miss anything?

According to linuxCNC STDOUT it can find the controller and establish TCP and UDP connections. But it is not even possible to toggle the emergency stop in the GUI. At same point it starts to complain in the output "Ethernet ERROR: Resource temporarily unavailable"

As the next attempt I rolled back my changes and returned to 10.10.10.10. It allows to toggle the emergency stop and even to run the sample code. But again at some point it blocks and starts to print "Ethernet ERROR: Resource temporarily unavailable"

I can imagine, that "Resource temporarily unavailable" by missing stepper drivers or by not connected spindle (however I am not sure that is the real reason). But why it does not work at all with the changed IP address? Should it be changed somewhere else? 

This is an Ethernet related error, basically no response back from the controller board in the time expected. 

GeremyL has been doing some great physical testing of the DMA stepgen. Chasing down missing steps, with one theory being the lack of a direction setup time.

The ability to set the direction setup time is now available.

Latest source has been pushed to the repo and a testing bin file as well.