die Lösung für Lost-Telegramme-Problem mit FT12 Firmware?

[StefanT]

Hello vannachen!

Sorry for the late answer.

I realized that I need more information about what happens between ETS and the FT. I have written a sniffer that outputs the serial communication for me. Now I can continue to investigate what is going on.

What I have changed is that previously, when the FT got a telegram to send from ETS, it immediatly reported this telegram as being sent. Now it sends the send report only when sending really happened. It is possible that this change alone improves the situation. However, I have not made a release firmware containing this change. If you want, I can send you a current firmware for testing.

[vannachen]

Hello, stefanT,

thanks for your reply and effort!

i'm glad to test it if you can share the improvement.

could u please attach the firmware here? I will test it and report it as soon as i can.

[StefanT]

Here you go: FT1.2 firmware snapshot

[vannachen]

Here you go: FT1.2 firmware snapshot

Hallo stefanT,

thanks for your sharing! My test report is:
Today i have checked this new-firmware, but the result is also not so good. The problem is also there when i send the telegramms in queue with each the status-telegramms back.

mfg

[StefanT]

There is still only one buffer for sending and receiving, in the FT1.2 software.

When a telegram comes in, and there is a FT1.2 frame in the buffer that contains a telegram to be sent, the FT1.2 frame is dropped in favor to the bus telegram.

I am still working on the issue. Unfortunately the LPC does not have much RAM. It's not so easy to just add a second buffer.

[vannachen]

There is still only one buffer for sending and receiving, in the FT1.2 software.

When a telegram comes in, and there is a FT1.2 frame in the buffer that contains a telegram to be sent, the FT1.2 frame is dropped in favor to the bus telegram.

I am still working on the issue. Unfortunately the LPC does not have much RAM. It's not so easy to just add a second buffer.

hallo

why don't we change the send_telegramm_temp just as the parameter or the buffer in the function-block? That means we can store the buffer into the array in the send_function(maybe in function ft_process_var_frame()) before sending. The receive-send-buffer can be changed but the send_temp buffer is not changed!

I want to change the code but i find it is difficult to understand something such as the file"fb_lpc922.txt" wrote:

Senden eines Telegrammes aus der app:
-------------------------------------

Man ermittelt die Objektnummer dessen Wert gesendet werden soll. Es ist sicherzustellen, daß
man den Wert des Objektes vorher so gespeichert hat, daß read_obj_value() ihn ausgeben kann. Dann wird einfach die Funktion send_obj_value(objno) aufgerufen. Das Senden erfolgt komplett im
Hintergrund. Man kann also ruhig mehrere Telegramme direkt hintereinander senden. Der
Ringspeicher reicht für 8 Telegramme, was im Normalfall völlig ausreicht. Sollten doch
einmal mehr als 8 Telegramme gesendet werden, kan man über tx_nextwrite und tx_nextsend das
Sendeverhalten überwachen.

why we must send the telegramm "ruhig im hintergrund"?

[StefanT]

It means "it is no problem that it is done in the background".

Telegram sending in the lib is implemented mainly for sending communication objects. There exists a queue of com object numbers that are to be send. With send_obj(n) the com object #n is added to the queue. When the lib wants to send a telegram it calls it's build_tel function which fetches the value of the com object with read_obj_value(n) from the application.

But FT1.2 uses the mini version of the ft library. This is a stripped down version where build_tel() is implemented in the application.

The lib uses the global variable telegram[] for sending and receiving telegrams. When a telegram arrives from the bus, telegram[] is filled with it's contents.

[vannachen]

It means "it is no problem that it is done in the background".

Telegram sending in the lib is implemented mainly for sending communication objects. There exists a queue of com object numbers that are to be send. With send_obj(n) the com object #n is added to the queue. When the lib wants to send a telegram it calls it's build_tel function which fetches the value of the com object with read_obj_value(n) from the application.

But FT1.2 uses the mini version of the ft library. This is a stripped down version where build_tel() is implemented in the application.

The lib uses the global variable telegram[] for sending and receiving telegrams. When a telegram arrives from the bus, telegram[] is filled with it's contents.

Hello,

yes! the telegram[]-filled is the main-problem of the "loss"!
But is the Ringbuf "bedeutungsvoll" for the sending? the RAM of LPC is not enough, so we may reduce the Ringbuf of the sending, in order to add a new telegram_tx[] just for sending.

I will try this when i have the time.

[StefanT]

Unfortunately I had only little time for Selfbus in the last couple of days. Great that you found time to further investigate in the problem

I think that changing the library should be the last resort as other applications might be affected.

Lets do some calculations...

The buffer size for reporting a received telegram is:

• 23 byte telegram (up to 15 bytes data payload)
• 4 bytes EMI frame (a L_Busmon.ind frame)
• 7 bytes FT frame

Total: 34 bytes (!)

Yes the current buffer is too small, it only works because ETS does only send 13 bytes payload and not 15 bytes payload as it could.

The maximum size for sending a telegram is:

• 23 byte telegram (up to 15 bytes data payload)
• 1 byte EMI frame (a L_Data.req frame)
• 7 bytes FT frame

Total: 31 bytes

But for sending the telegram could be stored in an extra "send-telegram" buffer, so the sending buffer would be only 23 bytes.

PS: "bedeutungsvoll" means important

[vannachen]

Unfortunately I had only little time for Selfbus in the last couple of days. Great that you found time to further investigate in the problem

I think that changing the library should be the last resort as other applications might be affected.

Lets do some calculations...

The buffer size for reporting a received telegram is:

• 23 byte telegram (up to 15 bytes data payload)
• 4 bytes EMI frame (a L_Busmon.ind frame)
• 7 bytes FT frame

Total: 34 bytes (!)

Yes the current buffer is too small, it only works because ETS does only send 13 bytes payload and not 15 bytes payload as it could.

The maximum size for sending a telegram is:

• 23 byte telegram (up to 15 bytes data payload)
• 1 byte EMI frame (a L_Data.req frame)
• 7 bytes FT frame

Total: 31 bytes

But for sending the telegram could be stored in an extra "send-telegram" buffer, so the sending buffer would be only 23 bytes.

PS: "bedeutungsvoll" means important

thanks stefan!

the calculations are so interesting!
According to the EIB-Telegramm-structure the telegramm is the 23 bytes, do you mean exactly it need only 15 bytes? If that we can use more RAM for the library.

I guess we have no idea if we don't want to add the new telegramm_tx[] to avoid the collision. Because we can not decide the BUS-action when the telegramm arrived. (Even among the sending-bytes, etc.)

in other word, i think the problem occurs in all of the modules such as 8out when we open all outputs and meanwhile get the status-telegramms, and the problem is:

the out8 try to send the status-telegramms at the time when it received the OPEN-COntacts commands. And the array of the telegramm is ??? So the status-telegramms lost some...