Remora - ethernet NVEM / EC300 / EC500 cnc board

frayja2002 wrote:

Hi there

I have flashed my EC500 with remora-rt1052-2.1.0-beta.bin & uploaded the config file as listed below ( I have just added the i/o & inverted the inputs as they were back to front compared to my original setup.)
Attached is my setup.

However I am not seeing any speed difference compared to the non cpp branch...
Everything works as expected. The machine moves & homes and I can jog.

When I increase the speed above 4200 mm/min (70 mm/s) I get joint following errors.
I have measured the amount of travel & the axis seems to be moving the correct distance it is just extremely slow.

Is there a way for me to increase the speed of travel without getting errors? Is there some extra parameter I should be using for DMA?
How do I know when I have reached the max speed of the EC500 (or software) ?

Thanks
Alex

I can accomplish about 120m/m or 1800mm/s and thats with a scale of 1280.
I would retry to flash your board, also reupload the config and turn up your pid like i did to about 88, maybe drop a little bit lower as even at 88 i get oscilation and it becomes annoying.

oficinerobotica wrote:

About theese entries in the config.txt . Where can I learn how to tune them? Is there a process to it?

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

My motors are still not attached to the mill but they seemed allot smoother when attached to a mesa card. Now they make a totally different sound when they move. Perhaps I only need to tune those parameters right. Again, it's easier for me to be wrong than right so some advice is welcomed.

its very easy to tell if the motors are skipping steps because what will happen when you command something thats 100% of your speed you will notice as it moves like chopyness, where it will make a smooth motion and then have these crazy pauses that cause a jerky like motion, that happens because your pulses dont have enough pause in them or between them and the driver cant read the signal change in time so it skips the step, its very easy to tell when this happens, you can see it, the other thing you can do is like i did is install a pencil or scribe into the chuck and draw on something with a commanded position and then check that with a micrometer/calipers and see what it moved physically vs what you commanded. Its now like 100% accurate but pretty DANG close. make sure if its on paper to put something on it heavy so it doesnt move.

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

Hi GeramyL

Looking at my ini file the scale is set to -500. If I change that won't it change the length moved per pulse?
Under the [AXIS_X] section MAX_VELOCITY = 170.0
But under the [DISPLAY] section MAX_LINEAR_VELOCITY = 70.0
And I have been changing that to give myself a higher top speed.

The only PID tuning I have is in [JOINT_0] PGAIN = 100

The config file seems to be uploading OK as I can see the changes in the pin outputs.
How do I change PId tuning ( in my ini file or in the config file uploaded to the EC500?)

Thanks


Later...
I don't know if this adds anything further but I tried to use your config file from page 127 but it crashed before starting.
I noticed that it said it could not start rtapi but when I start mine it says its using posix ?!?
Just incase the question arises i'm using linuxcnc-2.8.4-buster with buildbot repositories linuxcnc 2.10 something.
I have uploaded a copy.

 

github.com/scottalford75/Remora-NVEM/blo...-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.

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

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:

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.