Karl Reichert wrote: >> 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.
Hmm, didn't we already discuss clock synchronisation? Each sync frame triggers this synchronisation, and it also marks the beginning of a cycle in which a slave finds its slots (according to slot offset, period, and phase). Jan
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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 RTnet-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rtnet-users
