Yes for all attributes, spectrum is of length 6.
Four of these strings are of average 10 characters except two. Remaining two strings are of varying length from 40 to 140 characters.
Yes for all attributes, spectrum is of length 6.
Four of these strings are of average 10 characters except two. Remaining two strings are of varying length from 40 to 140 characters.
[quote=“Reynald”]t depends on your use case. You can use the same callback or a different callback. Both are correct.
In some cases, it is more convenient to have a separate callback and in some cases, a generic callback is better.
It all depends on what you need to do.[/quote]
Okay. Actually I thought as same callback might be being called simultaneously, so we are missing issue??
I will try to separate the callback and let you know the results.
[quote=“TCS_GMRT”]Okay. Actually I thought as same callback might be being called simultaneously, so we are missing issue??
I will try to separate the callback and let you know the results. [/quote]
I mean events in above post
so we are missing *events??
[quote=“TCS_GMRT”][quote=“Reynald”]t depends on your use case. You can use the same callback or a different callback. Both are correct.
In some cases, it is more convenient to have a separate callback and in some cases, a generic callback is better.
It all depends on what you need to do.[/quote]
Okay. Actually I thought as same callback might be being called simultaneously, so we are missing issue??
I will try to separate the callback and let you know the results.[/quote]
Well, this sohould not be the case. The event subsystem is supposed to implement an ingress queue, thus keeping all the received events, but there is a threshold (high watermark) upon which the 0MQ starts dropping the events (default value is 100). This can be changed to a suitable value.
Normally, when ZeroMQ is starting to drop events, Api_MissedEvents error events should be seen on the client side.
Is your callback written in such a way that it displays/reports the error messages when an error event is received?
We are getting some event errors in between, but I am not sure about the exact errors.
I will check and let you know.
Could you elaborate on how to catch these? I’m not finding anything in the C++ documentatino for Api_MissedEvents.
Hi Thomas,
The following piece of code in a C++ callback would display these errors:
void MyCallBack::push_event(Tango::EventData *ev)
{
if (ev->err == true)
{
Tango::Except::print_error_stack(ev->errors);
}
}
Error events with Api_MissedEvents error are generated on the client side when the client receives an event having a counter which is bigger than the “previous received event counter + 1”.
Kind regards,
Reynald
Thanks Reynald, very useful!
Some artifacts encountered during debugging / testing.
Additionally, int the image “Listeners for an attribute”, the attribute “UTC” is actually subscribed by only one client, however, the stats show that there are 9. Any thoughts will help.
Hi,
This window in the ATK Diagnostic showing the listeners is showing only the listeners in your ATK application (ATKPanel in your case), so the number of listeners here does not corresponds to the number of Tango clients having subscribed to UTC attribute.
The listeners listed here are internal Java objects in ATKPanel listening for some events occurring on this attribute.
By the way, what are the other screenshots you attached?
Cheers,
Reynald
I would also encourage you to put less attributes per device if you can…
For instance, in your case, we can clearly see you have many attributes starting with " Sub Array 1_" prefix…
It would probably be better to create a device dedicated for this Sub Array 1.
It is not a good practice to put everything into a single device.
What surprises me the most is the name of some of the attributes… Maybe it’s an optical illusion or a display artifact but it looks like some attributes are containing spaces in their names…
For instance “MNC/CMC/AGN0/Sub Array 1_RA”.
Is the name “MNC/CMC/AGN0/Sub Array 1_RA” or “MNC/CMC/AGN0/SubArray1_RA”?
Cheers,
Reynald
[quote]TCS_GMRT
We are getting some event errors in between, but I am not sure about the exact errors.
I will check and let you know. [/quote]
Please find attached, the event errors that the Java DS received.
We are using JTango version 9.3.4, which is known to have few issues and we are suggested to use 9.5.0
I am listing here the major software components on my Ubuntu 16.04.3 PC, with their versions below, just to confirm their copatibility/ ensure that they are not root cause of the issue.
Software Name—> Version
Java—> 1.8.0_151
Taurus—> 4.1.1
PyTango—> 8.1.8
Tango—> 9.2.2
OmniORB—> 4.2.1
Zeromq—> .0.7
Log4py—> 1.3
MySQL—> 14.14 Distrib 5.7.21
Panic—> 6.0.6
fandango—> 12.3.0
Python—> 2.7.12
Jtango—> Version 9.3.4
PyQT—> ver 4