Dave Engvall wrote: > Jon, Rafael, et al > > IIRC CAN is 1 Mbit/sec. Well, that is at least possible, but we can work out what the performance would be. With 8 byte packets, you can't even send all the encoder positions for 4 axes in one packet, as that is 12 bytes. Anyway, for a 4-axis system, we need to read 12 bytes of position, and then send 8 bytes of velocity command to a PPMC or UPC, and 12 bytes to a UPC. They all have 3 bytes of sense input, and 1 or 2 bytes of digital output. So, a minimum of 15 bytes to read, and a minimum of 9 bytes to write. So, 15 + 9 bytes is 24, and at 1 MBit/sec, that is 192 us. Given all the required overhead to read and write multiple packets, it is already pretty close to chewing up a whole millisecond, and there's no way it could handle even 5 KHz servo update rate. So, I really don't think CAN is a good candidate. It severely limits the possible complexity and/or speed of the system. A worst-case system might be 2 encoder counters, 2 DACs, and 4 DIO cards. That would be 404 bytes total, for 3.2 ms, not counting ANY overhead. So, such a system would probably be limited to a 200 Hz servo update rate.
The same data transfer, again ignoring all protocol overhead, on 100 MBit/sec Ethernet, would only be 32 us, which is much more reasonable. And, you get galvanic isolation of the ethernet, too! Jon ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
