CS104_Slave: ASDU types transmission priority

[PVKonovalov]

In real industrial life, it's assumed that different ASDU types have different priority. For example, single-point data connect with the breakers state, measured values connect with voltage or current etc.
Naturally, that measured values are changing more frequently than single-points. On the other hand, the number of measured values is a lot more than single-points. If both of them have equal priority for spontaneous transmission the powerful flow of measured values jams the seldom transmission of single points.
I met it using the library. As I understand there is a single approach to send spontaneously data using "CS104_Slave_enqueueASDU" function. As a result, single-points and measured values are sent into the single low-priority queue and in case of the queue overflow single-points (and of course, measured values) are removed.
The question is how I can avoid that situation? I am ready to accept that while the transmission I will lose measured values, but not single-points.

[mzillgith]

I think it would be best to solve this situation on applications side. E.g. reducing the frequency of measured values transmission. Usually you should not transmit measured values whenever they change but instead sending sliding averages with a fixed cycle time. When there is a risk that you are loosing values you can increase the buffer size accordingly.
Technically the library could provide different queues for different priorities. But then there is the risk that the sequence of events is violated and more memory is required for the different queues.

[PVKonovalov]

Thanks, Michael! Your proposal is right, of course. But, for example, RTU sends 30 000 data points by general interrogation. It may take some time, maybe more than one minute. In this case, without auxiliary high-priority queue, we risk getting our single-point data very soon.