Remora - ethernet NVEM / EC300 / EC500 cnc board

Hello everyone, I have continued investigating how to increase the counting speed for the qdc module, after looking at the firmware many times I have decided to look at the hardware of the board (the type of board does not matter EC500, EC300), multimeter in hand and measure continuity, after a few minutes I found that the +/-WHA and +/-WHB signals go directly to two optocouplers "B119V EL3H7" not to a differential driver as I had thought, along the way I also traced the other inputs that we could use with the qdc module and although I was already clear about these last inputs that they were connected to the "L247 M27" optocouplers, that said, I have not been able to find the data sheets for these optocouplers, although they are from other manufacturers (if anyone has information about these integrated ones, please report), I have the slight impression that these optocouplers will be a problem for reading the encoders although I must say that I have not tested the 24V inputs connected to the "L247 M27" optocouplers as I have to adjust the voltage levels.
A solution would be to unsolder these optocouplers, replace them with ones with faster times and try.
Please look at the previous post also where I documented the problem a little, regards.

yeah 0jw, looking at it now, in your hal change remora-eth to remora-eth-3.0 i think.

Yes, I noticed that as well and noticed that for the remora-rt1052-basic/remora-ec500 it was just missing the remora-nv.so
Afterwards it worked for loading linuxcnc. So I'm trying to find the e-stop io to test further.
I also noticed a lot of spi functions in the remora-eth. Buy not really sure if that matters.

Unfortunately I'm still getting errors. When launching Linuxcnc I get "unexpected real time delay on task 0 with period 1000000"
When I try to click estop in Linuxcnc I can see the led next to the ethernet port flash. I found a asus d340mc-c desktop pc and tuned off aliasing and power save setting, then installed updates. From what info I could find this might have somthing to do with Intel ethernet. But I really have no idea.

hello everyone, I've been racking my brain to get a significant speed increase with a closed loop configuration, I've looked at the sample closed loop configuration from Scott's repository and I've noticed that the *.ini file has it configured a 100 scale encoder and I remembered that I had a 500ppr encoder, this already assuming the poor quality of the optocouplers (guys we have to deal with this, there is no other option...), well screwdriver in hand and I I got to work to change the disc marked 500ppr for the 1000ppr one to achieve a lower resolution and lower frequency in the encoder pulses, well pure mathematics I have achieved double the stable speed for closed circuit, I have no idea How much speed would be ideal for a milling machine, for example? but I have achieved about 2400mm/min for one axis, obviously if we continue lowering the resolution we could achieve greater speed, the project I would like to achieve would be to carry out a conversion of an HBM BF35 milling machine, I have no idea of the speed at which this machine could reach In order to find a relationship between speed and physical operation of the machine, if anyone has an idea about speeds for similar machines I am all ears, well guys, greetings

Whats your latency?
Try to run in terminal: latency-histogram —nobase —show
Let it run for a while

Also you can try to list exact hardware specs (incl ethernet adapter)

0jw post your hal/ini file

scotta wrote:

I was able to confirm the direction output issues. My approach to getting the step and direction outputs into a "known" state during restarts was not consistent. So, with this bugfix I'm reading the actual output port DR register and then performing a direction change if needed. Happy testing and thanks again for the feedback. We'll get this stable.

I'll merge the bugfix branch once we have some feedback.

github.com/scottalford75/Remora-RT1052-c...t1052-3.1.1-beta.bin
 

Hi scotta,
I'm sorry for not seeing Your bugfix immediately! I was away for a short vacation.
I tried the version 3.1.1-beta. After every start the direction was always correct. I did about 15 starts.
The only problem I found instead is, I'm not able to upload a configuration. The remora stops its timers and that's it. The config upload repeats its requests, but doesn't get a response from the remora.
As a test I retried to upload the configuration again with version 3.1 and there it did work.

Regards, Hans

hanskuster wrote:

scotta wrote:

I was able to confirm the direction output issues. My approach to getting the step and direction outputs into a "known" state during restarts was not consistent. So, with this bugfix I'm reading the actual output port DR register and then performing a direction change if needed. Happy testing and thanks again for the feedback. We'll get this stable.

I'll merge the bugfix branch once we have some feedback.

github.com/scottalford75/Remora-RT1052-c...t1052-3.1.1-beta.bin
 
Hi scotta,
I'm sorry for not seeing Your bugfix immediately! I was away for a short vacation.
I tried the version 3.1.1-beta. After every start the direction was always correct. I did about 15 starts.
The only problem I found instead is, I'm not able to upload a configuration. The remora stops its timers and that's it. The config upload repeats its requests, but doesn't get a response from the remora.
As a test I retried to upload the configuration again with version 3.1 and there it did work.

Regards, Hans

Thanks for testing! And discovering another problem. I'll check it out.

the latency actually looks pretty bad on this desktop. I have youtube running in the background and some files open.