Hello Buestad

let's start by makingsure that we all agree that UDP is a "best effort" protocol.
It contains no acknowledgement nor attempts to retransmit if a package is lost.
In other words, it is unreliable by its very nature.

FB68 "TURCV" also containsthefollowing warning in its inbuilt help:
When transferring data with UDP according to RFC768, the data is transferred to the remote partner without acknowledgment and is therefore unreliable. This means that data can be lost without this being indicated by the block.

As such, I am not aware of any way that you can "trap this discarding of UDP packages in the PLC code so we can generate an alarm".

I presume that your application can generally live with the "unreliable" nature of UDP and that you are merely interested in getting the latest up to date values from Kongsberg Seatex MRUas often as possible, correct?

If so, here are a few ideas that may help:
1.) FB68 operates asynchronously, which meansits job processing can/may extend over several FB calls.
In light of this, consider calling it from an dedicated cyclic interrupt OB that you for example call every5 ms (or even faster, play with the interrupt times to see what you can achive. Notethat code in the interrupt OB must execute fasterthan the interrupt frequency, otherwise OB80 will come knocking and your CPU will stop).

2.) If you have a newer spare CP343-1 lying around you can try it instead of the CPU's PN port.
The advantage of a CP is that you candisable UDP frame buffering (this option is yet not avialable for the CPU's PN port).
This means that only the last received frame is buffered in the CP that you'll pick up as fast as your program allows you too and do not have to worry about the receive buffer filling up (the CP will take care ofdiscarding receive data frames that your program didnt't pick up for you).
Note that you can NOT use FB68 "TURCV" if a CP is used and need to use AG_RCV instead.
Have a look at How do you configure a UDP connection for data exchange between S7-300 and/or S7-400 by way of Industrial Ethernet CPs? for more on this.

3.) Do you really need new values from the Kongsberg Seatex MRU as fast as every 10 or 20 ms or so?
if not, why not simple slow theKongsberg sending down toonly send very 50 or 100ms or so?

All from my side, I hope this helps and perhapsothers have more ideas on this matter.