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.
> -fpga transmits a status packet every 1ms. (period is
> re-programmable and should match servo-thread period(right?))
"Matching" the period and being "in synch" are not the same 
thing.  No, you can't trust the two to truly "match".  You 
either need the CPU to command the device to report, or you need 
to make the device cause an interrupt to start the driver process.
> -watchdog functionality: if fpga transmits 3 packets without
> receiving a valid packet, it automatically enters e-stop mode.
That's easy, I have a watchdog on mine.

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
Emc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/emc-users

Reply via email to