Remora - ethernet NVEM / EC300 / EC500 cnc board

According to the component, the range is between 40,000 and 120,000.  500,000 exceeds the range and the component doesnt load. 

Change your PRU_base_freq to 100000 and see if it loads. 

The PRU_base_freq needs to match what is in your config.txt

frayja2002 wrote:

I have tried to add this but then LinuxCNC crashes with the following error...

LINUXCNC - 2.10.0-pre0-2069-g9de3c86d4
Machine configuration directory is '/home/alex/linuxcnc/configs/biessie'
Machine configuration file is 'remora-nvem.ini'
Starting LinuxCNC...
linuxcnc TPMOD=tpmod HOMEMOD=homemod EMCMOT=motmod num_dio=11
Note: Using POSIX realtime
Found file(REL): ./10_remora-nvem.hal
ERROR: PRU base frequency incorrect
remora-nv: rtapi_app_main: Operation not permitted (-1)
./10_remora-nvem.hal:8: waitpid failed /usr/bin/rtapi_app remora-nv
./10_remora-nvem.hal:8: /usr/bin/rtapi_app exited without becoming ready
./10_remora-nvem.hal:8: insmod for remora-nv failed, returned -1
Shutting down and cleaning up LinuxCNC...
USRMOT: ERROR: command 30 timeout
emcMotionInit: emcTrajInit failed
Note: Using POSIX realtime
LinuxCNC terminated with an error. You can find more information in the log:

Please not the lines....
ERROR: PRU base frequency incorrect
remora-nv: rtapi_app_main: Operation not permitted (-1)

Not sure how to diagnose this.

Thanks

If you are using the DMA branch, Scotta has said some posts before that we don't need to pass the frequency option in hal because the frequency is hard coded in the firmware. Just remove the pru frequency from hal. This if you are using the DMA branch. I hope I'm not wrong

cakeslob wrote:

Code:

PRU base frequency incorrect [code]loadrt remora-nv PRU_base_freq=500000 https://github.com/scottalford75/Remora-NVEM/blob/main/LinuxCNC/Components/Remora-nv/remora-nv.c#L201 The value exceeds the values in the remora-nv component. Im not sure whats going on in this thread development wise, so maybe they changed it for the rt1052 at the component.

[/code]

Since the dmastepgen branch is not exactly a release version things are a bit up in the air as far as whats what and there isnt clear messaging about it but, i do have my frequency set to 500,000 i have adjusted the remora-nv to allow this see attached. 

For the DMA testing branch you will need two things.

In your HAL

loadrt remora-nv PRU_base_freq=500000

And in the remora-nv component change the following line also to have a max of 500000.

github.com/scottalford75/Remora-NVEM/blo...-nv/remora-nv.c#L204

No need to add anything to the board configuration file. Without these changes the LinuxCNC component will limit the max frequency to 40khz.

When the DMA stepgen is ready for release this will also correspond to some other updates and some name changes for the Ethernet component so it's generic.

The DMA stepgen has highlighted an underlying issue in the software stepgen implementation. I'm currently doing testing in the SPI version with good success and hugely improved following error. Some boundary condition errors just need to be figured out. This should flow across all the software stepgen versions all going well.

cakeslob wrote:

Code:

Found file(REL): ./10_remora-nvem.hal ERROR: PRU base frequency incorrect remora-nv: rtapi_app_main: Operation not permitted (-1) ./10_remora-nvem.hal:8: waitpid failed /usr/bin/rtapi_app remora-nv ./10_remora-nvem.hal:8: /usr/bin/rtapi_app exited without becoming ready ./10_remora-nvem.hal:8: insmod for remora-nv failed, returned -1 Shutting down and cleaning up LinuxCNC... Please not the lines.... ERROR: PRU base frequency incorrect remora-nv: rtapi_app_main: Operation not permitted (-1) According to the component, the range is between 40,000 and 120,000.  500,000 exceeds the range and the component doesnt load.  Change your PRU_base_freq to 100000 and see if it loads.  The PRU_base_freq needs to match what is in your config.txt

Let me be extra clear, the configuration file for the ec500 as far as thread frequency DOES NOT APPLY.
But the remora-nv and the frequency inside the .HAL FILE DOES APPLY.
Use my remora-nv to allow you to unlock the 500,000 frequency. This frequency tells remora-nv and LinuxCNC that it is allowed to make steps that go up to 500,000hz otherwise you wont be able to take advantage of the full 500,000hz dma step generations. But again I can only do 200,000 because of my drivers being limited, so technically in my hal I could put 200,000. LinuxCNC/Remora-NV will limit itself to that frequency as far as maximum steps per minute. The configuration file for the ec500 should not contain any frequency adjustments if you are using DMAStepGen. I hope that clears things up.

frayja2002 wrote:

Everything looked like it worked properly.

I erased the board first with
pyocd erase --chip --target mimxrt1050_quadspi
flashed the firmware... No errors
PO/PO
Had some red output light on (expected)
Modified & uploaded the config file... No errors.
PO/PO
Rel light now go out after 2 secs (expected)
Start linuxcnc & home & jog. Look in halshow... Everything seems OK.

in "remora-nvem.ini" I have PGAIN = 100. Could that make a difference. What is a good value for higher speeds?

Thanks for the quick response.
Alex

as far as I know I am the only one here so far above 1000 steps per unit here. I have my PGAIN at 88, but its still a little high and causes oscilation and of course this depends on your ping time to the card to, I believe. Not a whole lot but it is a small factor, I would recommend nothing above 80 if you are running 1000 steps per unit and unit being mm. Or step scale sorry. I would also recommend that all your step scales are positive or negative to make things simpler. So if you have your drivers wired backwards being A and B on your driver i would flip it or vice versa to get all your drivers to go in the positive direction when the stepscale is positive. At least for me this made things a lot more stable. I would recommend you use the HAL scope in run mode and jog the machine back and forth to find your perfect pgain/ff1gain, you can run the halcmd in a terminal which I believe I explained above in order to change the remora ff1gain and pgain on command as you are testing with the hal scope, you should move the pgain as much as possible to get the ferrors as low as possible and ff1gain is what will help you get rid of the curve to a point. PGAIN is the correction speed or how fast it corrects in the algorithm but if you set it too high you will get oscillation. Someone else if I have this wrong please correct me.