Unexpected DC frame on the Configurator

[HypancistrusZebra]

Hello

When there is one device which is Node Address = 0xE8, we launched the Communication manager V4.1.1.

Next, we launched the Configurator  V4.1.1.

The Configurator sometime uses two selector (ex F3 and F8) at the same time and transmits to the device.

Though the Configurator requests the device by selector F8, it doesn't sometime wait for responding from the device and quickly transmits DC to the device.

The device seems that it is too short interval to respond.

Why can't the Configurator wait for responding from the device ?

I show the following when catching the bus monitor.

#185 - ABS_TIME - 00:00:06.902273 [ADDRESS - 0x10] LENGTH - 14

 0x1021 -> 0xE8F3 DT1

 DTC_REQ

 (55) CONF_REQ  READ 1016

======================================================

#186 - ABS_TIME - 00:00:06.911491 [ADDRESS - 0x10] LENGTH - 14

 0x1020 -> 0xE8F8 DT1

 DTC_REQ

 (61) CONF_REQ  READ 257

======================================================

#187 - ABS_TIME - 00:00:06.932991 [ADDRESS - 0xE8] LENGTH - 12

 0xE8F3 -> 0x1021 DT1

 DTC_RES

 (55) CONF_RES  READ ( U8 = 1 )

======================================================

#188 - ABS_TIME - 00:00:06.941436 [ADDRESS - 0xE8] LENGTH - 56

 0xE8F8 -> 0x1020 DT1

 DTC_RES

 (61) CONF_RES  READ ( VCR_RECORD = 0 4278190336  SIZE = 44 )

======================================================

#189 - ABS_TIME - 00:00:06.997249 [ADDRESS - 0x10] LENGTH - 14

 0x1021 -> 0xE8F3 DT1

 DTC_REQ

 (10) CONF_REQ  READ 2014

======================================================

#190 - ABS_TIME - 00:00:07.006466 [ADDRESS - 0x10] LENGTH - 14

 0x1020 -> 0xE8F8 DT1

 DTC_REQ

 (71) CONF_REQ  READ 269

======================================================

#191 - ABS_TIME - 00:00:07.240167 [ADDRESS - 0x10] LENGTH - 10

 0x1020 -> 0xE8F8 DC1

 ABT_REQ

======================================================

#192 - ABS_TIME - 00:00:07.472027 [ADDRESS - 0x10] LENGTH - 63

 0x1020 -> 0xE807 EC1

 ASC_REQ ( SEND_AREP = 59640 )

 (42) INITIATE  REQUEST

[LewisL]

Hi HypancistrusZebra, So the problem here is sometimes Configurator/CM doesn't wait for a response from the device when selector 0xF8 is used and transmits DC to the device? You mentioned that the interval is too short for the device to respond. Any chance if you know how long the device would expect this interval to be, and if this happens only on a particular device or generally every device? Thanks.

[HypancistrusZebra]

Hi LewisL

Yes, that's right.

I observe this phenomena when the Configurator uses only F8 selector.

Conversely, it seems that the Configurator doesn't quickly transfer DC in case of other selector.

The Configurator except F8 selector seems to retry 4 times to a device if not responding over 2.5sec.

Why does this case transfer DC quickly on only F8 selector without not retrying ?

F8 Selector is defined as FF assignment.

Are there any reason for SM/NM in FF Spec ?

I think FMS-Read/Write is handled as lower priority so that it is difficult to respond quickly.

So the device might spend from a few hundred msec to 1 or 2 sec.

Especially, it means much time to adjust the input/output of the sensing function.

When the device receives DC, it should break the request message.

But the device has already received the request message and started to process it before DC processing.

So the device might transfer the responded message to the bus despite non-existent VCR.

I think this message doesn't influence other devices. But communication band is so wasteful.

[LewisL]

Hi HypancistrusZebra,

Thanks for the information so far. 

What do you mean by "I think this message doesn't influence other devices. But communication band is so wasteful." Does the error happen to other devices or not?

In order to debug I need to reproduce the phenomenon first.

[HypancistrusZebra]

Hi LewisL

I made you confuse.

I suppose that there is a possibility that every device occurs for the error.

The device of which the Configurator requested DC is handled and stops responding despite creating the response requested from the Configurator.

If the Configurator is waiting for publishing DC, we can make an effective use of communication band of this loop.

[LewisL]

I'll update here as soon as there is a conclusion. 

[LewisL]

empty.

[LewisL]

Hi HypancistrusZebra,

Sorry it took so long.

I ran a test on a random device (one of SMAR's positioner) hoping to replicate the error you have encountered. There seems no such error. I tried to follow your steps in your original post.

I set the node address of the device to E8, and capturing packet while I open Configurator till the device panel has finished reading.

I searched for E8F8 DC in the capture, and at the occurrence I could observe that they all had a response from E8F8 to 1020 (DT).

I attached the capture, in case I misunderstood anything.

Thanks.