--- Jon Elson <[EMAIL PROTECTED]> wrote: <snip> > comes back. But, that isn't how the regularly-scheduled RT > processes work on EMC. If you give up control, you can't get it > back until the next servo cycle. I need to send a command > packet, wait for the encoder position to be returned in a > response packet, and then send another packet with the velocity > commands, all in one servo cycle. Anyone have any ideas about > this?
If I ever get anywhere with my fpga-to-ethernet project, here's what I have planned: -force the user to connect the board directly to the computer - no hub, switch, etc - ensures that there is no extra traffic -ignore the RTMAC TDMA packets - with only two devices on the net, both at full duplex, there can be no collisions. -fpga transmits a status packet every 1ms. (period is re-programmable and should match servo-thread period(right?)) -watchdog functionality: if fpga transmits 3 packets without receiving a valid packet, it automatically enters e-stop mode. I don't think you need a "command packet" - just one type of packet transmitted from the computer, and one type transmitted by the USC/UPC/whatever. (At powerup, other packets would be necessary, at least for the computer and fpga to discover each other's MAC and/or IP addresses.) HTH Mark ------------------------------------------------------------------------- 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 Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
