RT-8p8c - An ethernet based interface for LinuxCNC

Hello All,

I have been working on PIC32 based ethernet interface board for LinuxCNC.

This board uses a simple UDP protocol for communication. The HAL driver is based on RTnet.

Currently, only the software step generator for 4 axis is implemented. Code for spindle pwm and 16 bidirectional I/O is not yet finished.

Tests are done using halrun, no connections to a real machine yet.

Everything is still in alpha stage but results shows that realtime control over ethernet is feasible.

More details can be found at code.google.com/p/rt-8p8c.

Regards,

GPO

kinsa wrote:

Hello All,

I have been working on PIC32 based ethernet interface board for LinuxCNC.

This board uses a simple UDP protocol for communication. The HAL driver is based on RTnet.

Currently, only the software step generator for 4 axis is implemented. Code for spindle pwm and 16 bidirectional I/O is not yet finished.

Tests are done using halrun, no connections to a real machine yet.

Everything is still in alpha stage but results shows that realtime control over ethernet is feasible.

More details can be found at code.google.com/p/rt-8p8c.

Regards,

GPO

This is quite interesting. I asked some questions on the RTnet group a while ago about
the LinuxCNC model of servo operation, where every ms you would send a command to
the motion interface, it would build a packet and send status and encoder counts back,
the PC would compute new velocity and send a velocity command packet to the
motion interface. They were pretty negative about getting 3 packets transferred
all in one ms.

I am guessing your setup is all one-way, perhaps just step rate commands?

Jon

Pretty sure this should be OK with a dedicated link, That is, even with an old PCI interfaced 100BT card you have roughly 80-100 MBytes/sec DMA bus bandwidth to/from the card so with no switches (and their added store/forward delays) you get a little more than 2 wire times at ~12 MB/sec plus parsing times for time between request packet send start and receive data available in system memory. For small I/O systems a minimum 64 byte data request packet and a 128 byte returned data packet ought to be just fine. The remote receive request parsing time must be added but for example on our 7I80 I get a turnaround time of less than 100 uSec for these packet sizes (including about 20 uSec parsing time for parsing our register access protocol)

The output data after the receive packet is "posted" so delays there are less critical as theres no CPU wasted waiting for them

jmelson wrote:

This is quite interesting. I asked some questions on the RTnet group a while ago about
the LinuxCNC model of servo operation, where every ms you would send a command to
the motion interface, it would build a packet and send status and encoder counts back,
the PC would compute new velocity and send a velocity command packet to the
motion interface. They were pretty negative about getting 3 packets transferred
all in one ms.

I am guessing your setup is all one-way, perhaps just step rate commands?

Jon

I think they were referring to using TDMA. I'm using UDP on a master and slave configuration. The PIC32 board doesn't send anything unless a command is received from the hal driver.

A round trip transfer of 64 bytes, with no processing, takes around 90 us. This includes the UDP overhead on a 100M interface. With the stepgen code running, it takes around 150 us.

Currently, only position feedback is received. This is actually a port of the stepgen module running on the PIC32 board, but only taking the velocity command instead of the position command as input.

kinsa wrote:

I think they were referring to using TDMA. I'm using UDP on a master and slave configuration. The PIC32 board doesn't send anything unless a command is received from the hal driver.

No, rtnet can use UDP.

A round trip transfer of 64 bytes, with no processing, takes around 90 us. This includes the UDP overhead on a 100M interface. With the stepgen code running, it takes around 150 us.

Great, actual measurements are much better than estimates!
One thing that could help is to have the motion interface set
the timing of the sample, and the LinuxCNC thread could
be started on receipt of the message. That way, there'd
only be one message each way per servo cycle, and the
timing jitter could be very small.

Thanks for working on this!

Jon

any pcb boards available ?

jmelson wrote:

One thing that could help is to have the motion interface set
the timing of the sample, and the LinuxCNC thread could
be started on receipt of the message. That way, there'd
only be one message each way per servo cycle, and the
timing jitter could be very small.

There is a variable reply delay that can be configured to precisely match the hal thread's period so that a message is already in RTnet's buffer before the read thread starts.

The hal driver is currently using two threads, read and write. I'll try to merge the two next.

There are still some issues regarding unloading the module, RTnet doesn't close properly.

cncbasher wrote:

any pcb boards available ?

Assembled boards? No, not yet.

Initial development was done using a Chipkit Max32 with ethernet shield. The other alternative is the PIC32 ethernet starter kit.

Hello gents.

To have CNC hardware modules connected via Ethernet card should be very interesting.
Also because of the future availability of the PCI Slots on the mother board card.
One option could be to implement a driver for one of the commercial deterministic protocol like Ethercat, Ethernet Powerlink ... .
Another option could be to have external hardware module like this www.ajaxcnc.com/mach3-cnc-control-systems/ .


bigalex

no i was just looking for the pcb on it's own , iv'e not looked at the chipkit Max32 as yet

Email me your address and I'll send you one.