Mark Pictor wrote: >--- 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. > > Good point.
>-fpga transmits a status packet every 1ms. (period is >re-programmable and should match servo-thread period(right?)) > > Wellll - not quite. Unless they use the same clock source, there will be skew. Every once in a while, you'll get two packets in a single servo period, or you'll get none. That doesn't even take into consideration the jitter you get on the PC end, which will cause the same problem even if you do have a common clock source. You either need a request/response system, or you need the remote unit to update frequently enough that the data isn't too stale no matter when you read it. For example, if you have a 1ms period, and 25 us old data is "close enough", then send packets at 4 or 5 KHz, and the data can never be more than 25 or 20 us old. Of course, you then need some way of marking a set of data as complete (so HAL can read from it) and as "in use" (so the net driver doesn't write to it) - all of that non-blocking ... Restricting the network to two nodes also relieves the 64-byte packet size, but I'm not sure you can convince a network card to send out smaller ones. With an FPGA at the other end, it may be possible to have the MAC address match trigger a send, so all you'd need for the request is to send anything with the right MAC address, and the return transmission comes back as soon as the etherner frame header is done, not the whole packet. >-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.) > > Yeah - discovery is an "interesting" issue. Especially if you want to be able to use a semi-generic driver for multiple devices (which I think would be cool, but may not be in the cards) - Steve ------------------------------------------------------------------------- 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
