RT-8p8c - An ethernet based interface for LinuxCNC

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 :blink:

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.

So you are not enabling RTnet's TDMA discipline?
Seems not to be needed as the board does not talk unless asked, you may just daisy-chain several of these without collisions...

I wonder how would you manage the 100uSec ask-reply delay if you were to implement a closed-loop. You would ask on one iteration of the rt-thread and use the reply on the following itaration?

Regards,
Fernando

fmederos wrote:

So you are not enabling RTnet's TDMA discipline?

I'm not using TDMA. There's just a single "user" in this case.

Seems not to be needed as the board does not talk unless asked, you may just daisy-chain several of these without collisions...

Or have the board serve as a gateway to other devices so that there will be no network contention.

I wonder how would you manage the 100uSec ask-reply delay if you were to implement a closed-loop. You would ask on one iteration of the rt-thread and use the reply on the following itaration?

Start the sequence with a TX then RX with the initial read value discarded. Then adjust the reply delay such that by the time the READ thread starts a reply is already waiting.

[WRITE THREAD] TX -> reply delay -> RX [READ THREAD] --> Process --> [WRITE THREAD] TX -> delay -> RX [READ THREAD] --> ...

Regards,

GP