I thought this should be a new topic for discussion. I hope I have not messed things up.
Previously posted: John Figie: Interesting video and an impressive amount of work done. I have some comments: I think it would be nice if all of the LinuxCNC I/O could be connected using standard ethernet and IEEE1588 for time synchronization. This means that a servo drive needs to be developed that has an ethernet connection to LinuxCNC. Ideally - but not necessary - each I/O device would include an embedded switch so that 2 ports are available and allow daisy chaining of the I/O devices. LinuxCNC could then be run on any computer that supports IEEE-1588 on its ethernet including the rpi4 ? It seems like there are a lot of pieces that could be taken and then improved on to reach this goal. There is the STMBL servo drive, Mesa already has a simple LBP16 protocol that could be used as a starting point. Maybe the protocol could be similar to ODVA Ethernet/IP with CIP motion but simplified and without all of the legacy baggage. To me it would be an interesting project to work on but maybe too much for someone like me to do alone. Ralph Stirling [email protected] via <https://support.google.com/mail/answer/1311182?hl=en> lists.sourceforge.net Tue, Feb 22, 5:35 PM (17 hours ago) to Enhanced I think you have just described Ethercat. There are open source Ethercat master and slave implementations (soem and soes). The slave requires a Microchip interface device (LAN9252). I would like ethercat interface to steppers of various sizes, and may work on that this summer. -- Ralph John Figie <[email protected]> Tue, Feb 22, 6:40 PM (16 hours ago) to Enhanced Actually What I described is not exactly Ethercat but more similar to Ethernet/IP with CIP Motion. Ethercat is not standard Ethernet and that is why the slave requres the mictochip interface device. But if open source master and slave implementations are available maybe that would be a good possibility. Since an Ethercat slave does not use standard ethernet I believe that the master tunnels other protocols through the eterncat networks, although I think in theory both protocols might be able to exist since Ethercat is its own ethertype so that packets can be separated form ethernet protocols. Anyway, for a dedicated network of just I/O Ethercat works very well. On the othehand the problem with using CIP Motion is that you need to belong to ODVA and pay a fee to get the specification so although they claim it is open it really doesn't seem so and I am not sure if it could be used in an open system because then the specifications would also be public. It would be nice if there were a simple and free open protocol and if it were based on standard ethernet then it could be long lasting and would be extensible to faster ethernet speeds and IP-6 if needed. John Figie Ralph Stirling [email protected] via <https://support.google.com/mail/answer/1311182?hl=en> lists.sourceforge.net Tue, Feb 22, 10:46 PM (12 hours ago) to Enhanced I do wish that Ethercat was truly open source from the ground up. Beckhoff holds all the copyrights, and has an annoying association that holds all the docs. Membership is free, but a hassle. I am jumping through the hoops to join, but haven't finished yet. A real open source vhdl module for FPGA's would be really nice, to avoid single source chip risks. There are a couple of projects on Github, but both are empty of actual source code. What I like about Ethercat is it is truly real-time, whereas Ethernet/IP does not guarantee timing. The two-port daisy chain approach of Ethercat is also very handy. Actually, you made another suggestion that has me thinking again. The Mesa LBP16 protocol over ethernet is typically just used to connect a host pc to a single fpga card, which has i/o and possibly sserial links to additional i/o. The sserial i/o has some limitations on speed and is best suited to pendants and coolant or tool changer type use. I'm wondering if a reasonably fast pc with GigE and a GigE switch could have a number of LBP16 devices running full speed, one device per port on the switch. Hostmot2 already supports multiple devices, although I've never tried using more than one per pc. -- Ralph Yes the proponents of Ethercat and other protocols will point out that Ethernet/IP does not guarantee timing, but for Ethercat to work you need special MACs and a dedicated network. If Ethernet/IP is also run on a dedicated network that excludes large packets from random devices then it too can guarantee timing as well. This is the case with Ethernet/IP and CIP motion. So I know it is possible for even hundreds of axes to operate on the Ethernet/IP network and all be synchronized, that is what Rockwell Automation does using CIP motion. Now I am just wondering if there is a way for some kind of truly open protocol to be useful and gain some kind of acceptance. I know there is RTnet, but it requires a special MAC software layer, and I don't think it has gained much traction. On the other hand devices using CIP motion will usually bypass the normal ethernet protocol stack for the high speed UDP messages used for motion. Another aspect of real-time I/O is time or clock synchronization. For the simple Mesa I/O devices I think a PLL is used to keep timing uniform in the I/O devices. For CIP motion (and I think Ethercat can use this as well) IEEE-1588 PTP protocol is used to synchronize clocks. PTP runs in the background and there is a Linux version called ptpd https://packages.debian.org/sid/net/ptpd I have this installed on my Debian 10 computer using an intel NIC card that is supported and as far as I can tell it works because I can see PTP protocol packets using wireshark if another PTP device is on the network. But I am not actually using or trying to use PTP for anything at the moment. One of the issues with Ethernet/IP - CIP motion is that the protocol seems pretty complex. Packets are of varying size to I/O devices and contain Cyclic data, Event data, and Service data. Most CIP motion devices include an ethernet switch and at 100Mbit speeds the switch needs to be a cut thru switch to avoid latency increasing with each device. Note that Ethercat is similar but also modifies the packets on the fly with its special MAC. Most Rockwell drives can operate at 1mSec update rates and the drives interpolate fine positions (if position mode) between updates on the wire. At Gigabit speeds Maybe store and forward switches can be tolerated as you suggested especially if one large switch is used with a dedicated port for each I/O device connected. In fact a single store and forward switch may also be tolerable at 100MBit speeds. Another consideration are the emerging standards for TSN (time sensitive networking) which allow time critical traffic over standard ethernet. But in my opinion TSN is overkill for controlling machines using a dedicated network for the I/O. TSN adds a lot more complexity. Anyway I find this whole topic interesting and I welcome other comments or insights. Regards John Figie _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
