Javid Butler wrote:

>>For me, the issue of RTnet is irrelevant. I would, instead, just want to 
>>use
>>the Linux driver. If we can get that to generate and receive ethernet 
>>frames
>>in real time, we are in business.
>>
>>Then we could let the PC be a master and any peripherals be slaves. In the
>>case of the UPC board, there might be only one slave. The master would 
>>poll
>>each of the slaves as appropriate.
>>
>>Ken
>>    
>>
>That is the way the ACN protocols work, although they operate with a more 
>peer-to-peer structure. ACN rides on top of Internet Protocol, so the 
>standard Linux driver should work fine. If a device has something to say it 
>just says it, and everyone who wants to listen does. This does not increase 
>bandwidth consumption and may decrease it because there is no need for the 
>controller to ask a responder for information. When looking at things like 
>encoders transported in an uncompressed format over ethernet this is the 
>most bandwidth efficient method. Compressed or interpreted data are 
>similarly efficient.
>
>Let me illustrate with a stepper motor:
>Simple Controller: Move +1 step X
>Simple Drive: Moved +1 step X
>Messages sent until final position reached. This is the direct ethernet 
>equivalent of the parallel port
>
>Medium Controller: Move +1000 steps X
>Medium Drive: Moved +1000 steps X
>One message sent to move 1" (.001 step resolution).
>
>For compound moves either the drive or the controller becomes more 
>complicated in the medium solution, so at this point what I would suggest is 
>to aim for a medium solution for single axis moves that switches down to the 
>simple method for compund moves. This should be relatively easy to code at 
>the EMC end and almost brainless at the drive end. ACN structures already 
>accomodate the different data types.
>  
>
Could you provide an example of a servo motor with feedback?

I believe the main thing keeping EMC2 from using these non-RT 
communication links is that we have kept the motion controller on the 
PC.  This includes PID and feedback, which is what imposes the realtime 
requirements.  In the case of a stepper motor, or a velocity servo drive 
with its own PID, the PC can precompute some number of motions and 
download them as a block.  If you include feed override, especially 
adaptive feed override (which runs in realtime, and is intended to be 
used for things such as EDM and plasma machines), then you make it 
impossible to use a non-realtime communications scheme.  All motors 
*must* slow down not only synchronously, but in response to 
non-PC-generated data (such as a gap voltage sensor for EDM).  A simpler 
and more common example of this is spindle-synchronized motion (though 
the response latency may be more forgiving in that case).

>Advanced controllers are a more involved discussion.
>  
>
Arbitrarily advanced, you could say :)  We could of course stick a 
mini-EMC2 on each controller ...

>I will edit the streaming ACN packet structure and post it to the list.
>  
>
The wiki may be a better place, since we'd probably like the ability to 
revise it, and to keep track of revisions.
Just follow the instructions at 
<http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?BasicSteps> to add a page.

>Thanks,
>Javid
>  
>
Thanks
- 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

Reply via email to