Remora - ethernet NVEM / EC300 / EC500 cnc board

I added more printfs and recorded this:
joint 2 frequency command: 16777215
frequency command pointer: 16777215
frequency command pointer: 536872064

rxData frequency command: 16777215
rxData frequency command pointer: 536872064
rxBuffer frequency command: -1
rxBuffer frequency command pointer: 536871996

This suggests that the copy from rxBuffer to rxData is being interrupted by a read event.

Some really interesting and useful observations and fault finding!!! 

The udp_data_callback() is running in the main loop, with the threads running in interrupt context. If a thread ISR is triggered during the call to the callback then it would be possible for the data move to be interrupted by a memory read.

Implementing a mutex for the data buffer would be the solution if your theory is correct. And probably a good feature anyway.

The may also explain why the SPI version of Remora has not seen this issue as DMA is used to move data with the memory management ensuring that only DMA or the CPU accesses memory at a time.

IT'S FIXED!! .... well it looks like it.

A huge thanks to spdbmp927 for working out that it was a corrupted rxBuffer. I have pushed a bug fix to the develop branch. I've run Roy's gcode file, which before would cause lots of following error spikes, successfully with a very small follower error setting. And this is at +400% normal speed.

The fix was as simple as disabling interrupts when moving the rxData into the rxBuffer.

Would be great to get feedback from others if this issue is now resolved.

Thanks again spdmbp927!!

Yes I can confirm that it's fixed. I'm really glad you both found and solved the problem!

Hi Scotta,
Were the master branch implement C Axis? I tried XYZABC configuration and saw C Axis pulse/dir were not there.
BR
Win

Win_D wrote:

Hi Scotta,
Were the master branch implement C Axis? I tried XYZABC configuration and saw C Axis pulse/dir were not there.
BR
Win

Opps, yes there is an error in the master branch, line 259 in main.cpp. Looks like a hang over from testing. Not to worry. I'm going to merge the develop branch into main hopefully today. This will make using the configuration file the standard way to set-up the NVEM.

For those monitoring the dev branch, I've pushed a new update that includes a default configuration. This implementation presents 3 joint stepgens and no IO so that people can know the board is up and running when first set-up. Alternatively this could be a full config if people would think this is more appropriate. The intention is to merge dev into main and create a release now that bugs have been resolved.

Remora-NVEM 1.0.0 has been released. Thanks to everyone for testing and helping with the beta bug fixes.

github.com/scottalford75/Remora-NVEM/releases/tag/1.0.0

For those not wanting to worry about the source, the bin file is github.com/scottalford75/Remora-NVEM/tree/1.0.0/Firmware

I have received another NVEM board (I killed the PWM output on the test board) and will use this to make some short YouTube videos on how to flash the firmware and get LinuxCNC up and running with the board.

I'd like to step through the LinuxCNC configuration setup (ini and hal) for the different features such as setting up and e-stop, end stops, spindle etc. If you have a running config for some of these, please share them here so we can consolidate into a working example to help people get up and running.

For those want to run B and C Axis.
Not sure if all NVEM V2 are the same in pul/dir pins, for my PCB,  B and C Axis as following:
 B step: PE_7 
 B dir: PE_6
C step PE_5
C dir  PE_4
I downloaded this config and all XYZABC were running fine.
 

Scott,

Spi vs Ethernet.
I have a Ethernet module that I could connect to my 3d printer main boards. Any advantage vs using spi?

The main one I can think of is the com is less sensitive to interference. And not limited to devices with spi support.
Any other reasons?