RT-8p8c - An ethernet based interface for LinuxCNC
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
Please Log in or Create an account to join the conversation.
This is quite interesting. I asked some questions on the RTnet group a while ago aboutHello 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
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
Please Log in or Create an account to join the conversation.
The output data after the receive packet is "posted" so delays there are less critical as theres no CPU wasted waiting for them
Please Log in or Create an account to join the conversation.
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.
Please Log in or Create an account to join the conversation.
No, rtnet can use UDP.
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.
Great, actual measurements are much better than estimates!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.
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
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
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.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.
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:
Assembled boards? No, not yet.any pcb boards available ?
Initial development was done using a Chipkit Max32 with ethernet shield. The other alternative is the PIC32 ethernet starter kit.
Please Log in or Create an account to join the conversation.
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
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.
Please Log in or Create an account to join the conversation.