Distribuited Clocks : Speedup Time Analysis with the new latest Plugin
Since the wireshark version 1.12.3 I have decided to improve more the plugin.
The reasons are many and all related to zone registers that are placed from 0x900 to 0x9FF.
This is the most delicate part linked to the setup of DC clocks. In the past there were only some sporadic quotes dedicate to some limited area , as 0x910, and submitted also to some heavy restrictions as the number of bytes (>16 bytes)
I worked to dissect completely the whole area (as the previous regs) and also I set the registers values in a more readable content (decimal format) with calculations and comments
We can start now with many examples that help to clarify and to become confident with the tool.
First example : we work with a trace and we are interesting to check if the reg 0x990 is present and what is the value.
In the filter area (1) we write as filter the following text : ecat.reg990_8b.
It means ecat.regxxx_yb: xxx = reg number as 990, y=4/8 it is the number of bytes.
Naturally if the register is 4/8 bytes long.
There are many registers that can be used as 8/4 bytes , also it depends on the command that the EtherCAT Master sends to read/write it. When the register is 8 bytes long , we can check also if it is used as 4 bytes : ecat.reg990_4b.
The last option as single byte , this is not so usual , but I added also this option because there could be present a command that cover an area where only some bytes are involved. In this way in all situations there is the register commented.
In the central area , there is the commented value with the numerical format in decimal style. I am convinced that it is easier to work with 32/64 bits in hexdecimal format.
Numerical calculus with hex format becomes complex with 64 bits number, less.
Everyone that loves hex can enjoy with the third area in any case.
It works for all tastes.
Second Example: Single byte register
This time we can filter with the same technique, but the notation can vary from one registers to another.
The reason is the following: each register has some bits used or not used, grouped or single.
The filter follows the documentation provided with EtherCAT 's specification.
Each register shows different splitted values and each comment is always linked with the corresponding value.
The last example is related to Receive Time Ports
a) There are reported the values in decimal format
b) At the end there is a report that takes a care about the REAL situation. Here there are four regs involved from 0x990 to 0x90C. The reg 0x908 reports a null value and the reg 0x90c a value too much different from a realistic situation.
Normally the calculus follows the schema :
c) For the Receive Ports , the plugin applies the differences if the command is a Read one ("APRD" or "FPRD") otherwise there is only the commented value
It can happen that one port is closed with a "dirty value". The plugin takes into consideration this possibility and also the rollover. These are 32 bits regs and after about 4 sec they restart from zero. If the time difference is higher than 20000000 (ns) than the relative port is ignored. The value equals to 20000000 it is arbitrary.
Example : if we consider a delay of 1 µs between the slaves => 20.000.000 =>20 000 slaves => a big trace !!
That 's all! I hope you enjoy it .
For any comment feel free to contact me via email