> Karl Reichert wrote: > >> Karl Reichert wrote: > >>>> Jan Kiszka wrote: > >>>>> Karl Reichert wrote: > >>>>>> Jan Kiszka wrote: > >>>>>>> Karl Reichert wrote: > >>>>>>>> Hello, > >>>>>>>> > >>>>>>>> I have a question concerning RTcfg-frames. I couldn't completely > >>>>>> understand from RTcfg.spec how these frames are looking like. I > made > >>>> two models > >>>>>> and I think one of these is correct (see attachment). Which one? > >>>>>>> The first one. RTmac frames have their own Ethertype (0x9021), and > >>>> they > >>>>>>> only contain discipline frames (like TDMA) or encapsulated non-RT > >>>> frames > >>>>>>> (see the vnic tunnels). RTcfg frames are just plain RT payload, > like > >>>>>>> frames issued by RT-applications. > >>>>>> BTW, Ethereal, err..., Wireshark perfectly understands RTnet. =8) > >>>>>> > >>>>>> Jan > >>>>>> > >>>>> Thanks. Another question: Are those Frame Identifier Bits (B4..0) > the > >>>> same like the ID? It's little bit mistakable because they are 1 Byte > >> (all > >>>> taken from RTcfg.spec). > >>>>> If not, what if the Frame Identifier for / filled with? > >>>> I see the confusion: "Frame Identifier" may rather be called "Frame > >>>> Type" so that "Frame Version" + "Frame Type" form the "Frame ID" (or > >>>> just ID) as this byte is called later on. May may grab this > information > >>>> >from the textual description, but the naming can indeed be > misleading. > >>>> > >>>> HTH, > >>>> Jan > >>>> > >>>> > >>>> PS: _Always_ reply to all... > >>>> > >>> Another question, maybe very simple but can't find it in the spec: How > >> is data send? Just as a plain/raw packet or is there also sth added > like > >> version or type in the TDMA-Frame? > >> > >> But that should be clear from the spec: plain Ethernet frames, no > >> additional headers. > >> > >> Jan > >> > > Thanks Jan. I also have a question to the normal starup, Calibration > Phase: > > The Slaves are waiting until Slot Timeout before they send their > Calibration Request. Is this timeout a random value? Because there aren't any > sync > clocks yet, I think this value cannot be a value to help them to send > their answer in their timeslot, right?! > > There are sync frames at that point, the master is already fully > functional. The slaves just have to know the parameters of at least one > slot that they can then use for the calibration. And that data is > published via RTcfg. > > The only systematic shortcoming is that the master-slave round-trip > cannot be included into the slave's clock adjustment at that point (as > it's yet unknown), so the actual slot transmission time will be slightly > later than during regular operation. But given the small calibration > frame sizes and a typically larger slot to stuff them in, this > practically doesn't matter. > > Jan > How do the slaves synchronize to the global clock? To use their slot, they also need a sync slot. When is this synchronization done? Is there any other document giving more information about these themes? In the spec I can only find those pictures with nearly none further information, I would like to read sth more about that if existing.
Thanks Karl -- von Karl Reichert "Feel free" - 10 GB Mailbox, 100 FreeSMS/Monat ... Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ RTnet-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/rtnet-users
