Cool! It's been a while since I looked into RTNet. IIRC, things are simpler if you can guarantee that there are only two devices on the network and that the network is full duplex (use a crossover cable with no hub or switch). In that case you should be able to do away with the sync frame. I envisioned a timing algorithm to time creation and transmission the feedback data packet such that it arrives at the host immediately before the servo cycle. The RTNet driver would read the data, pid calculations are done, and then a command packet is created and transmitted.
The system will perform better if the feedback data is fresh, and consistently so. A timing algorithm could help with this. It would be necessary for the command packet to include information on the delay between recieving the feedback packet and the beginning of the servo cycle in which it is processed, so that the device can adjust transmission time. Otherwise there will be drift since each end of the cable has its own clock source. Keep us posted Mark On Fri, Dec 18, 2009 at 5:40 PM, Frank Tkalcevic < [email protected]> wrote: > I've been playing around with RTNet (realtime ethernet). I've been looking > at it as an alternative to parallel ports, and internal cards. > > I've built an embedded slave using the Atmel NGW100 board. I have a test > application that runs on RTAI linux (the master), which reads the encoder > and IO statuses, does PID calculations, then sends PWM and IO ouputs. The > unoptimised code can run at 200Hz. I'm hoping to get this up to 1kHz. > This > is driving my dinky robot arm (6v 30mA motors, encoder, 485:1 gearbox). > > On top of RTNet runs the TDMA protocl, time division multiple access. The > master sends out a sync frame at the start of every period (current every > 5ms - 200Hz). The 5ms period is divided up into time slots, and the > master, > and each slave are allocated one or more slots to send. > > Now I'm trying to integrate it into EMC and I have a couple of issues. > > 1) RTNET wants to run the rtai timer in one-shot mode. So, I can either > set > the EMC base thread to run at a high rate so RTNET can get close to when it > wants the timer to be fired, or I can modify EMC to use the one-shot timer > instead of the periodic timer. (RTNET has the option of not starting the > rtai timer and use whatever is active). How will the one-shot timer effect > EMC threads? I'm guessing this will introduce jitter. Is this a problem > for a servo system? > > 2) As described above, the time on the ethernet wire will be divided up > into > 5ms periods, with slots defined as... > > 0ms | 0.1ms | .3ms > Sync | Slot 0 | Slot 1 > | Slave sends encoders | Master sends PWM info > > In order for this to work, I need to be able to synchronise the Sync frame > of RTNet (the start of the period), with the servo thread in EMC (with > offset). > > Ideally, when the EMC servo thread starts processing, RTNet has already > received the data from wire, and it is ready to be processed. So I need to > set the Rtnet Sync frame to begin at "servo thread time - (0.1ms + > transmission delay)". Rtnet currently doesn't have a way to do this. Does > EMC? If not, I need to change either EMC or RTNET to support this. Does > EMC need a facility like this? On the Rtnet mailing lists, I was asked if > EMC supports realtime events like Fieldbus, but I have no idea what it is? > > 3) And finally, when I create my realtime hal component to do this, should > I > be using the function interface of EMC, or just use RTAI events? > > If I use hal functions, then I rely on getting question 2) solved. I need > a > read() function to be called at the start of the cycle, and a write() at > the > end. Then I need to ensure they are called at the correct times. > > The other way I was thinking of handling it would be to use RTAI directly, > setting up a read task and a write tasks that fired independently, and just > kept the hal pins and paramaters up to date. This would have the problem > of > possibly being 0.5 - 1.0 cycles out of sync, but then there wouldn't be > timing issues of missing read/write time slots. > > Any thoughts? > > Thanks, > Frank > > > > > ------------------------------------------------------------------------------ > This SF.Net email is sponsored by the Verizon Developer Community > Take advantage of Verizon's best-in-class app development support > A streamlined, 14 day to market process makes app distribution fast and > easy > Join now and get one step closer to millions of Verizon customers > http://p.sf.net/sfu/verizon-dev2dev > _______________________________________________ > Emc-developers mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/emc-developers >
------------------------------------------------------------------------------ This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________ Emc-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
