Delay column in velbuslink logging

English
1

Question, how do we interprete the delay column in velbus link?

i see on certain modules that after a scan i get a realy big delay see the logs below

28/07/2015 20:11:44:128 RECV 0F FB 00 07 FF 05 02 00 00 07 36 AC 04 28/07/2015 20:11:44:166 RECV 0F FB 01 07 FF 22 9B 5E 03 14 29 94 04 28/07/2015 20:11:44:371 RECV 0F FB 02 08 FF 0C 00 FF FF 00 12 47 8A 04 28/07/2015 20:11:44:955 RECV 0F FB 14 07 FF 28 11 CA 01 15 07 BC 04 28/07/2015 20:11:45:156 RECV 0F FB 14 08 B0 28 11 CA 15 16 17 18 CD 04 28/07/2015 20:11:45:357 RECV 0F FB 19 07 FF 17 EB F1 01 13 50 80 04 28/07/2015 20:11:45:580 RECV 0F FB 23 07 FF 17 65 E5 01 13 50 08 04 28/07/2015 20:11:46:514 RECV 0F FB 40 07 FF 17 9D 4C 01 13 50 4C 04 28/07/2015 20:11:46:879 RECV 0F FB 46 07 FF 21 54 46 00 13 25 B7 04 28/07/2015 20:11:47:080 RECV 0F FB 46 08 B0 21 54 46 47 48 49 4A 1B 04 28/07/2015 20:11:47:281 RECV 0F FB 50 07 FF 10 C2 6B 00 13 27 29 04 28/07/2015 20:11:47:289 RECV 0F FB 51 07 FF 10 E1 5D 00 13 27 17 04 28/07/2015 20:11:47:297 RECV 0F FB 52 07 FF 10 56 1A 00 13 27 E4 04 28/07/2015 20:11:47:482 RECV 0F FB 53 07 FF 10 F9 EC 00 13 27 6E 04 28/07/2015 20:11:47:490 RECV 0F FB 54 07 FF 10 E4 3C 00 13 27 32 04 28/07/2015 20:11:47:498 RECV 0F FB 55 07 FF 10 CF 26 00 13 27 5C 04 28/07/2015 20:11:47:506 RECV 0F FB 56 07 FF 11 D0 16 00 13 27 69 04 28/07/2015 20:11:53:733 RECV 0F FB 0A 07 FF 17 4F E4 01 13 50 38 04 28/07/2015 20:11:53:939 RECV 0F FB 0B 07 FF 18 FF 75 01 13 50 F5 04 28/07/2015 20:11:53:947 RECV 0F FB 0C 07 FF 18 1E 6C 01 13 50 DE 04 28/07/2015 20:11:53:955 RECV 0F FB 0D 07 FF 18 A2 19 01 13 50 AC 04 28/07/2015 20:11:54:140 RECV 0F FB 1A 07 FF 18 9C 02 01 13 50 BC 04 28/07/2015 20:11:54:341 RECV 0F FB 1E 07 FF 21 14 7A 00 13 12 FE 04 28/07/2015 20:11:54:542 RECV 0F FB 1E 08 B0 21 14 7A 1F 20 21 22 EF 04 28/07/2015 20:11:55:267 RECV 0F FB 4B 07 FF 17 3B 82 00 11 35 8B 04 28/07/2015 20:11:55:472 RECV 0F FB 01 08 BE 28 00 1A A1 D6 45 AE 83 04 28/07/2015 20:11:55:480 RECV 0F FB 01 08 BE 29 00 04 24 39 FF FF A7 04 28/07/2015 20:11:55:487 RECV 0F FB 01 08 BE 2A 00 1D 84 2D 34 2D D6 04 28/07/2015 20:11:55:495 RECV 0F FB 01 08 BE 2B 00 00 00 01 FF FF 05 04

what could cause this?
is there any way to read out the ‘Bus error counter status’?

2

Since I don’t actually see any scan packets, I suppose you use Home center? Testing with Home center in between is not a good test.

3

no useing velbuslink, and i stripped the scan packets

4

But the title of your topic is “Delay column in velbuslink logging”? I’m confused…

I would want to see the log without modifications, and through VelbusLink, to eliminate all unknown factors

5

there where no modifications, this is a copy/paste from the saved file

anyway here is a screenshot

you see for adress 10, i have a delay of 5000+

6

A lot is wrong with this packet log…

  1. Since no scan packets are visible, the module type responses are far behind which is not normal
  2. The module type responses are out of order; address 10 comes in after address 86 for example
  3. You have large delays between each packet

If you don’t scan, do you get a lot of Sensor temperature packets?

7

i logged in on a pc with abigger screen, hier is a log with the scan packets visible:

the thing why it takes so long before 10 answers that basically the idea of this question, is see a delay of 6000 this time …

all temp sensors are configured to send the temp every 255 seconds, the energy counters (vmb7in) is configured to send every 255 seconds,

i have 4 temp sensors and 4 energy counters

8

any help here?

9

not sure but here are some ideas :

  • some modules aren’t so fast than other (VMB8PB for example are slow compared to VMB4PD)
  • as it’s a BUS, there is a conflict resolution (CSMA/CR) : a big scan make some modules to have priority before other

How do you scan your BUS (programmation or VelbusLink function ? are you using a delay between each scan transmit ?)

10

Scanning in VelbusLink means sending a special packet to each individual possible address. VelbusLink makes sure that there is a delay of at least 50ms between each packet, to prevent overwhelming the USB interface which only has a small buffer.

All other error and collision handling is done by the modules themselves.