EibPC missing telegrams

[martenss]

My EibPC became selective on the telegrams captured from the bus since I downloaded a new application program yesterday.

I've taken two screen-shots (one from EibStudio and another one from ETS3 logs), clearly showing that the response GA 4/2/100 coming from source address 1.1.7 after launching request GA 4/2/0 (from EibPC) is not captured by the hardware. The internal EibState for 4/2/100 still shows ON, which is corrected after manually reading the value from the bus. Note that the first read response is also not captured, a second attempt recovers the situation.

The problems is there for multiple GAs and physical devices, so problem clearly resides in the EibPC which is connected via FT1.2 to the bus since 6 months now. The occurrence seems higher for GAs at the upper part of the hauptgruppen list, however this be a coincidence as I've more dynamic elements in there (temperature updates, heating control, ...).

The problem started when adding some code that seems to blow up the usage% across the (magic?) 10% barrier, I reached 11.1% now. I remember that some months ago a problem had been solved when reaching 12% -> could this one be related?

I'd also like to mention that I've noticed telegrams being lost during start up - particularly when a lot of ToggleButton makros are sending their read request. I assumed this was due to internal queue overflows and didn't raise a ticket for that before.

Usage EibPC 11.1 %.

EibParser ended without errors.

(c) 2008-2010 Enertex Bayern GmbH
www.enertex.de
% C:/bin/Eib/nconf -i 192.168.1.6
IP-Address of EibPC: 192.168.1.6
Firmware Version of EibPC: v1.308
Serial of EibPC: 00000209
Netzwerkeinstellungen: DHCP
Netzmaske: 255.255.255.0
Gateway: 192.168.1.1
Nameserver 1: 192.168.1.1
Nameserver 2: ?
Nameserver 3: ?
Patches:
1.000.ptc
1.001.ptc
1.002.ptc
1.003.ptc
1.004.ptc
1.005.ptc
1.006.ptc
1.007.ptc
1.300.ptc
1.301.ptc
1.302.ptc
1.303.ptc

EIB-Interface: FT1.2

[enertegus]

EIB-Interface: FT1.2

Which FT1.2 config do you use? If the traffic increases, the FT1.2 looses messages in Busmonitormode. So this is my first guess:Choose the groupmonitormode in EibStudio for Communication

[martenss]

I am indeed using busMonitorMode. In the mean time I reloaded the application, which seemed to solve the reported problem - not sure what caused the problem as I didn't touch any configuration. I am afraid that this might come back...

Now changed to groupMonitorMode as you suggested to validate if the loss of telegrams at start-up is also solved, but here the result is negative.
Some responses are still not captured. I also noticed that some read commands (during Init load) are not being sent out on the bus (not logged in event buffer either). Any clue here?

Thanks again, martenss

[enertegus]

Now changed to groupMonitorMode as you suggested to validate if the loss of telegrams at start-up is also solved, but here the result is negative.
Some responses are still not captured. I also noticed that some read commands (during Init load) are not being sent out on the bus (not logged in event buffer either). Any clue here?

Could you please send your complete project to eibpc@enertex.de, so that we can see it here (to make sure, there is no problem with the EibPC?
Did you limit the telegram rate to 7? One problem is, that the EibPC sometimes is too fast - which could occur with IP Interfaces, too, see https://knx-user-forum.de/knx-eib-fo...nterfaces.html.
Especially during start up, if a lot of reads are initiated, these telegramms could have a collision. (For startup reads we have built in a new feature in the next release coming soon).
You watch the telegrams with an IP Interface and ETS? Perhaps you can change the interface of the EibPC?

[martenss]

I didn't enable the (expert) telegram limiting option - should I do this?
Limit to 7 or 10?

Why do you suggest using an IP interface? In the other thread you describe that the problem only occurs with IP interfaces, so this won't be an improvement for me, right?

Do you prefer to receive the full program or would a start-up log be sufficient for now?

Kind regards, martenss

[enertegus]

I didn't enable the (expert) telegram limiting option - should I do this?
Limit to 7 or 10?

No, Standard is limited to 7.

Why do you suggest using an IP interface? In the other thread you describe that the problem only occurs with IP interfaces, so this won't be an improvement for me, right?

My experience is: The FT1.2 sends faster than the Siemens Router/Interface, but the latter has a bigger buffer.

[martenss]

Thanks, so default limitation should be active.
I meanwhile did send all info to eibpc@enertex.de.

[enertegus]

Thanks, so default limitation should be active.
I meanwhile did send all info to eibpc@enertex.de.

A last question: If you fetch all telegrams to a csv-file, do you see the reads then? It could be, that the online telegrams are just missing in the online monitor during startup. Does it principly work now in the group monitor?

[martenss]

I based my analysis on the csv file already.

Look eg for "Raam dressing open-6/1/112" which should be queried from a ToggleButton macro during start-up, but this read request is not present.

Similarly, some responses are not logged although they are seen on the ETS3 log (eg "Raam sanitair open-6/1/116").

[enertegus]

Look eg for "Raam dressing open-6/1/112" which should be queried from a ToggleButton macro during start-up, but this read request is not present.

The read requests are randomized during the first minute of the systemstart. Unfortunately you didn't send the csv - file.

Similarly, some responses are not logged although they are seen on the ETS3 log (eg "Raam sanitair open-6/1/116").

Do you see an event? Which FT1.2 do you use?

[martenss]

The csv file was attached to the mail seperately (not within the zip).

I use the EIBMarkt N000250 (RS232 itf).

I didn't save the ETS3 log but did observe what I was describing. If this is not reproducible at your side then I will re-do the test and keep both logs.

[enertegus]

I made some experiements with the Siemens FT12 and my traffic:

The ETS3 logged (also with an Siemens FT12) in Busmonitor showed sometimes errors on the BUS, same as the EibPC using the Busmonitormode (see event logs with "invalid Telgram"). Both ETS3 and EibPC missed some telegramms, which can be seen, as they are not missing always the same telegramms.

I switched to both Groupmonitormode. Things become better then, but still there are some misses during startup. This occurs if 10 or more Telegramms per second are on the Bus. I limited the EibPC to 7 Telgramms per second, but especially during startup this means, there are up to 7 responses per second, too. Additionally there are some "normal" telegramms, so I've seen up to 18 telegramms/s. It seems, that the EibPC looses more telegramms, but not always. I changed the performance settings with the EibPC, so that the FT12 communication has more cpu time, I increased extra loads (mails etc) - but it makes no difference - meaning regardless of the cpu load the EibPC-FT12 looses more telegramms sometimes with low load. So I have the feeling the whole thing is not a performance issue of the EibPC but the FT12 Interface. Anyway the firmware team will have a look on this, to see if there could be any problem. I don't know, if the difference of ETS and EibPC using the same FT12 is because the EibPC both sends and reads with the FT12, whereas the ETS only reads with the FT12. I reduced the EibPC send rate to 3 telegramms/second and now I don't see a difference between the ETS log and the EibPC log.

In one out of 15 startups with many reads the ETS (@FT12) missed 50% Telegrams and I had to reinit the FT12 Interface. As far as I know, the newer FT12 Interfaces have a thermal protection, as many telgramms can heat the chipset.

Next I connected the EibPC to a Siemens IP Interface. Now, there are some repeats obviously initiated by the IP Interface. After recording 5.000 Telgrams both ETS3 (with FT12 Groupmonitor) had same telegrams. The repeats can only be seen, if there is the ETS3 FT12 is in busmonitor. Then (ETS & Busmonitor), the ETS looses telegramms and show errors.
From what I can see now, my IP Interface can obviously better handle high peaks, whereas I've seen (at another customer), that Ft12 can handle higher telegram outputs per second, as long as there are not more than 10 to 15 on the bus.

So a recommendation can be:
1. Limit the number of telegrams sent by the EibPC
2. Limit the bus traffic (if somehow possible)
3. Use your IP interface with the EibPC and the Ft12 with the ETS3

Additionally the new firmware has the InitGA possiblity (reads before the EibPC starts processing). This will surely remove the startup problem. As we will adapt the macros, you would only have to reload.

[martenss]

Did some tests following your suggestions, with following outcome:

1. Limit the number of telegrams sent by the EibPC
2. Limit the bus traffic (if somehow possible)

Reduced load of frequently used ToggleButton macro by only reading StatusGA. No real improvement, always the same EibPC reads are missing both in EibPC event log as well as ETS log.

3. Use your IP interface with the EibPC and the Ft12 with the ETS3

Using an IP interface doesn't make any difference. I notice that eg always the same read of status GA 4/0/100 is not put on the bus by the EibPC - this GA is read in a macro at the bottom part of a block executing the same macros. Moving the Macro to the top of this block executes the GA read but leaves the new last one un-executed -> I believe this should be an internal issue not related to the communication channel used. Hopefully this gives a hint on where to look (parser issue?).

Additionally the new firmware has the InitGA possiblity (reads before the EibPC starts processing). This will surely remove the startup problem. As we will adapt the macros, you would only have to reload.

Not really as solution for me as I didn't sent the EibPC back to load the new kernel. As I currently use it to control the heating it will take a while before I'll be able to miss it for a few days...

Kind regards, martenss

[enertegus]

Moving the Macro to the top of this block executes the GA read but leaves the new last one un-executed -> I believe this should be an internal issue not related to the communication channel used. Hopefully this gives a hint on where to look (parser issue?).

Oh yes, that is an complete other issue - already fixed in actual firmware. Sorry I didnot think of that, as I have here the pre-release. I only tested, what could happen if the bus at maximum load condition - complete wrong direction.
In the past, there has been an maximum of to be processed objects, which have been increased (made be configurable, respectivel. This error occurs, if about 10% of possible objects are used.
We will soon release new software. In the meantime you could reduce your objects a bit or contact me directly.
EDIT: You would have to make an new kernel upgrade. Let me see tomorrow what we can do without that.

[martenss]

In fact I referred to this restriction in my very first question:

I remember that some months ago a problem had been solved when reaching 12% -> could this one be related?

.

Thanks for pointing that out!
I'll await your suggestion to overcome this issue without the kernel update.