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
