Remora - ethernet NVEM / EC300 / EC500 cnc board

Thank you for your efforts.

chrstrvs wrote:

Following my resent failures this is what I've done and where I am at now:

- Flashed the NVEM with the Remora firmware
- Installed Raspberry Pi OS (Legacy), so Buster 32 bit
- Installed xrdp to enable Remote Desktop
- Followed the guide to install LinuxCNC at remora-docs.readthedocs.io/en/latest/sof...nc-installation.html, but since I had issues with the Pi not booting after installing the realtime kernel, I instead installed 5.15.65-rt49 according to forum.linuxcnc.org/9-installing-linuxcnc...n-raspberry-pi-3b-pi.
- Installed the Remora NVEM component
- Followed Scott's videos to configure ethernet
- Flashed the basic config to the NVEM

- I am able to ping the NVEM at 10.10.10.10
- I am able to start LinuxCNC and get out of emergency stop
- I am not able to request movement. If I do, I get "joint [0-2] following error"

I really wan't to move on and reinstall the NVEM in my CNC and continue with configuring LinuxCNC, but I'm stuck with this error.
Scott, help!

Hi, I've just put the STM32 NVEM back on the bench to retest. I could simulate your error when using the remora-eth component. With the latest firmware

github.com/scottalford75/Remora-NVEM/blo...NVEM-STM32-1.0.0.bin

And this config

github.com/scottalford75/Remora-NVEM/tre...es/remora-nvem-basic

Everything is ok.

A full chip erase can be performed in the ST-Link Utility.

Hi, I've just put the STM32 NVEM back on the bench to retest. I could simulate your error when using the remora-eth component. With the latest firmware

github.com/scottalford75/Remora-NVEM/blo...NVEM-STM32-1.0.0.bin

And this config

github.com/scottalford75/Remora-NVEM/tre...es/remora-nvem-basic

Everything is ok.
A full chip erase can be performed in the ST-Link Utility.

I did full chip erase, flashed the NVEM again, uploaded the basic config, but the result was the same.
I did however lower the jog speed from 2979 mm/min to 4 mm/min, and lo and behold it jogs! Albeit very slowly... Anything faster than 4 mm/min and I get the following error again.

So, any ideas why it's like this?

chrstrvs wrote:

Hi, I've just put the STM32 NVEM back on the bench to retest. I could simulate your error when using the remora-eth component. With the latest firmware

github.com/scottalford75/Remora-NVEM/blo...NVEM-STM32-1.0.0.bin

And this config

github.com/scottalford75/Remora-NVEM/tre...es/remora-nvem-basic

Everything is ok.
A full chip erase can be performed in the ST-Link Utility.
I did full chip erase, flashed the NVEM again, uploaded the basic config, but the result was the same.
I did however lower the jog speed from 2979 mm/min to 4 mm/min, and lo and behold it jogs! Albeit very slowly... Anything faster than 4 mm/min and I get the following error again.

So, any ideas why it's like this?

So this will be a LinuxCNC config issue then. Which INI and HAL file are you using?

Hello everyone, I have gotten an encoder with a pin index, but hehehe, it is a PNP output and I cannot find a way to make an inversion through any hardware in the RT1052 since the inputs of the ec500 are for connecting NPN outputs, I have put some PNP collector pulldown resistors to ground but it reverses the input logic... Any ideas

Yeah boby that makes it hard since its an encoder. Perhaps
Invert it in firmware?

scotta wrote:

Hi Cakeslob, 

Thanks for the start on the Ethernet docs, your right we've got more than the NVEM boards, the PicoBOB-DLX uses the same LinuxCNC components. Can you submit a pull request and I'll work in parallel with you. 

Thanks!

Ok cool. I will have to do it when i return home, github mobile is almost useless

cakeslob wrote:

Yeah boby that makes it hard since its an encoder. Perhaps
Invert it in firmware?

scotta wrote:

Hi Cakeslob, 

Thanks for the start on the Ethernet docs, your right we've got more than the NVEM boards, the PicoBOB-DLX uses the same LinuxCNC components. Can you submit a pull request and I'll work in parallel with you. 

Thanks!

Ok cool. I will have to do it when i return home, github mobile is almost useless

Actually if its a input pin you should be able to use the "Invert" string on the pin, unless that wasn't in the QEI module originally.
Probably best to implement pin mode I would think.

scotta I did some testing, I do have 2.54mm movement if I keep moving the same direction it looks like. Still some directional movement problems but also looked it up and it can possibly be from not building up enough current for the movement in the next direction. Not sure how much I believe that though since there is very little friction and no active force pushing on the motor during the indicator calibration routine, but its looking dang good physically, the new DMA Step Gen. I made one last change and did a pull request it should take care of a very rare use case as explained in the github issue and possibly fix any other luming problems.

scotta wrote:

chrstrvs wrote:

Hi, I've just put the STM32 NVEM back on the bench to retest. I could simulate your error when using the remora-eth component. With the latest firmware

github.com/scottalford75/Remora-NVEM/blo...NVEM-STM32-1.0.0.bin

And this config

github.com/scottalford75/Remora-NVEM/tre...es/remora-nvem-basic

Everything is ok.
A full chip erase can be performed in the ST-Link Utility.
I did full chip erase, flashed the NVEM again, uploaded the basic config, but the result was the same.
I did however lower the jog speed from 2979 mm/min to 4 mm/min, and lo and behold it jogs! Albeit very slowly... Anything faster than 4 mm/min and I get the following error again.

So, any ideas why it's like this?

So this will be a LinuxCNC config issue then. Which INI and HAL file are you using?

That's good that it's not a hardware issue or something with LinuxCNC or the realtime kernel. A good opportunity to learn a little about how the configuration works.
I use the once located in github.com/scottalford75/Remora-NVEM/tre...es/remora-nvem-basic. I have attached them here as well.

ok, after a lot of fighting I have agreed to carry out tests with sim_ecnoder(hal) => remora_output_pins => qdc => linuxcnc(hal), I have to say that it looks good, as expected Scott was right we should pass POSH in the index detection, Scott, I have been looking at your PRUEncoder module. In the case of an encoder with an index pin, should we pass index signal in addition to the encoder count?