Remora - ethernet NVEM cnc board

Aaroncnc wrote:

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?

The main advantage is being able to use any PC (inc SBC) as we only need an Ethernet port. I'm still working on the W5500 implementation to give ethernet capability for 3D printer boards but it will come with an increased servo period due to the speed of the SPI communication with the board. As you said, the less sensitive interface will help and we will have the ability to move the RPi (or other LinuxCNC capable PC) away from  the 3D printer. 

The original Remora SPI concept is still great and works well where appropriate. Rafal in the other thread has done work to reject corrupted packets on the SPI bus, which also raises the question as the applicability of SPI in some environments. With Remora is was really repurposing off the shelf hardware.

Remora-NVEM is a pleasing outcome to give another option for the LinuxCNC community to use readily available hardware.

I'm just adding trifles. M64P03 and M65P03 still need to be placed in the probe screen V2 file in Macros / manual_change.ngc

    net probe-input motion.probe-input => remora.input.5
    net probe.toolchange-input => remora.input.7

    net flood remora.output.3 iocontrol.0.coolant-flood
    net mist remora.output.4 iocontrol.0.coolant-mist

#   M64P03 ON air blow for toolsensor.M65P03-OFF
    net probe.toolchange.blast motion.digital-out-03 => remora.output.2
 
I have the tool sensor connected in series with the E-stop so that the tool does not break if it accidentally exceeds a given height.

Could you give me a basic idea, what would be the logic you used to make the dds control along with the interrupts to be able to generate the pulses? I'm trying to understand to study something with esp32.

Hi eng, 

No problem, I did see your posts in the ESP32 thread. Below is the data flow. The two threads are essentially timer ISR routines that iterate over a vector of pointers to the base class method of the modules.

 

The Remora stepgen module evolved from the standard LinuxCNC stepgen.c, with the two halves split between the LinuxCNC component and the controller board. A PID loop was adapted into the stepgen to cope with the time difference between a read and write to the controller board.

 

The DDS (position) accumulator is at the heart of the make_pulses(). It does two things, the first storing the position (counts) and the other determining when a step should occur by monitoring a step bit (pickoff)

Hi Scotta,
The firmware can generate 40khz is maximum? Did we reach the limit or we could increase it higher later on?
As per original Mach 3 can reach up to 200khz, was it because of nature of Mach 3 structure?

No we haven't tested the highest step rate as yet. Both the firmware and LinuxCNC component are capable of having configurable thread frequencies just like the SPI version of Remora.

50 or 60khz may be achievable but with the current software step generator 200khz is not likely.

I've just published the first of hopefully a few videos on setting up Remora-NVEM. 


 

looks awesome.

I wonder what step generator they are running with mach 3 that they are able to get to 200khz

I seem to remember in an older post there was speculation to double the speed of the unit i thought that would have brought it to 80khz.

Thanks, and I'd love to know the original step generation scheme as well. I had another look at the decompiled original firmware but it's very challenging to understand.

The Remora-NVEM step generator now runs at the base thread frequency. It use to take two base threads to raise and then lower the step pin. I need to migrate this into the standard Remora code as well.

Another short video stepping through using the JSON configuration capabilities of Remora.