HDB Archiver New Release - problem in archiving event push by code

# 6 years ago
TCS_GMRT	Hi All, I'm using new version of archiver (v2.2). I'm facing some problems. 1. When I started archiving through event push by code. The data is archived but reflect later into DB (e.g I send one command and get response of it, so response attribute should be logged into hdbpp database but It is not logged into hdbpp database, once I stop DS and again restart DS the attributes shown into hdbpp dtabase). Can anyone know why It is happening ?? 2. When I added attributes into archiving it's working fine. When I stopped DS and again start DS, attributes goes to stop state (stopped attribute). I already set StartArchivingAtStartup property, but that is not work for me. Regards, TCS_GMRT Edited 6 years ago

# 6 years ago

Hi All,

I'm using new version of archiver (v2.2). I'm facing some problems.
1. When I started archiving through event push by code. The data is archived but reflect later into DB (e.g I send one command and get response of it, so response attribute should be logged into hdbpp database but It is not logged into hdbpp database, once I stop DS and again restart DS the attributes shown into hdbpp dtabase). Can anyone know why It is happening ??

2. When I added attributes into archiving it's working fine. When I stopped DS and again start DS, attributes goes to stop state (stopped attribute). I already set StartArchivingAtStartup property, but that is not work for me.

Regards,
TCS_GMRT

Edited 6 years ago

# 6 years ago
TCS_GMRT	Hi, Any update on it. Regards, TCS_GMRT

# 6 years ago
Reynald	Hi, I don't know what you mean with HDB archiver 2.2. Are you talking about the version of the HDB++ Configurator GUI? For me, an archiver is what we call the HDB++ Event Subscriber device server (https://github.com/tango-controls-hdbpp/hdbpp-es) and there is no version 2.2. I don't understand what you mean in case 1. What device server are you talking about when you write "once I stop DS and again restart DS the attributes shown into hdbpp dtabase"? About case 2, it all depends on the version of the HDB++ Event Subscriber you are using. I know that StartArchivingAtStartup property has been removed in recent versions of hdbpp-es, when the notion of archiving contexts/strategies has been introduced. So it might be that you are using a version using Contexts/Strategies. An easy way to verify that is to start an atkpanel or Test Device Panel for instance on one of your HDB++ Event Subscriber devices. If you have an attribute named "Context", then StartArchivingAtStartup property is useless in your case and you should configure your system to use properly the new archiving strategies. If your Event Subscribers (and Configuration Manager device) have the Context attribute, then you should use a version of the HDB++ Configurator GUI able to manage the strategies which is the case if the version 2.2 you were mentioning is the version of your HDB++ Configurator GUI. You can then manage strategies and contexts from Tools menu => "Manage Strategies and Contexts"! You will see the current context from the Diagnostics GUI (View Menu -> "HDB++ Diagnostics") and you can even set it. If you set the context for the E.S. manager, it will set it globally for all your event subscribers too. You can set the context from the Diagnostics GUI by double-clicking on the Context cell of the Event Subscriber or Configuration manager you want to set the context. With the version using contexts/strategies, at Event Subscriber startup, the context being memorized, the saved value of the context attribute will be written, when this will be done, the Event Subscriber will start archiving automatically all the attributes it is responsible for and which are configured to be archived in the current context. One more important thing. If you are using HDB++ Configurator GUI 2.2, you must use HDB++ Event Subscriber and HDB++ Configuration manager DS versions supporting the contexts and strategies too. I hope this helps a bit. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago

Reynald

Hi,

I don't know what you mean with HDB archiver 2.2. Are you talking about the version of the HDB++ Configurator GUI?
For me, an archiver is what we call the HDB++ Event Subscriber device server (https://github.com/tango-controls-hdbpp/hdbpp-es) and there is no version 2.2.

I don't understand what you mean in case 1. What device server are you talking about when you write "once I stop DS and again restart DS the attributes shown into hdbpp dtabase"?

About case 2, it all depends on the version of the HDB++ Event Subscriber you are using.
I know that StartArchivingAtStartup property has been removed in recent versions of hdbpp-es, when the notion of archiving contexts/strategies has been introduced.
So it might be that you are using a version using Contexts/Strategies.
An easy way to verify that is to start an atkpanel or Test Device Panel for instance on one of your HDB++ Event Subscriber devices.
If you have an attribute named "Context", then StartArchivingAtStartup property is useless in your case and you should configure your system to use properly the new archiving strategies.
If your Event Subscribers (and Configuration Manager device) have the Context attribute, then you should use a version of the HDB++ Configurator GUI able to manage the strategies which is the case if the version 2.2 you were mentioning is the version of your HDB++ Configurator GUI.
You can then manage strategies and contexts from Tools menu => "Manage Strategies and Contexts"!

You will see the current context from the Diagnostics GUI (View Menu -> "HDB++ Diagnostics") and you can even set it.
If you set the context for the E.S. manager, it will set it globally for all your event subscribers too.
You can set the context from the Diagnostics GUI by double-clicking on the Context cell of the Event Subscriber or Configuration manager you want to set the context.

With the version using contexts/strategies, at Event Subscriber startup, the context being memorized, the saved value of the context attribute will be written, when this will be done, the Event Subscriber will start archiving automatically all the attributes it is responsible for and which are configured to be archived in the current context.

One more important thing. If you are using HDB++ Configurator GUI 2.2, you must use HDB++ Event Subscriber and HDB++ Configuration manager DS versions supporting the contexts and strategies too.

I hope this helps a bit.

Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 6 years ago
TCS_GMRT	Hi Reynald, Thanks for you prompt reply. In case 2, It is working now. Thanks for your help. In case 1, I want to try archiving through event push by code without set polling period. Whenever attribute value will change, It should be logged into hdbpp database. Please find tango generated code and snapshot : @Attribute(name="archiverAttr", pushArchiveEvent=true, checkArchivingEvent=false, pushChangeEvent=true, checkChangeEvent=false) @AttributeProperties(changeEventAbsolute="1") I hope you understand what I'm trying to do. Any help would be greatly aprreciated. Regards, TCS_GMRT Edited 6 years ago Attachments:

# 6 years ago

TCS_GMRT

Hi Reynald,

Thanks for you prompt reply.
In case 2, It is working now. Thanks for your help.
In case 1, I want to try archiving through event push by code without set polling period. Whenever attribute value will change, It should be logged into hdbpp database. Please find tango generated code and snapshot :

@Attribute(name="archiverAttr", pushArchiveEvent=true, checkArchivingEvent=false,
pushChangeEvent=true, checkChangeEvent=false)
@AttributeProperties(changeEventAbsolute="1")

I hope you understand what I'm trying to do.
Any help would be greatly aprreciated.

Regards,
TCS_GMRT

Edited 6 years ago

# 6 years ago
Reynald	Hi, The way you configured your attribute with POGO means that you will push some events by code for this attribute and the Tango library will not check the criteria, meaning the events attribute configuration will be ignored. To actually send the events, you still have to add something in your code to explicitly push an event (by code!) whenever you want to send an event. In Java, I don't know the exact name of the method you should use but I guess it is something like push_change_event or push_archive_event, depending on the kind of event you want to send. Since you configured your attribute in POGO so that it won't check for the event configuration thresholds, an event will be forced-pushed every time you call the push_xxx_event methods explicitly from the code. What you observed is normal because when a client tries to subscribe to an attribute, a synchronous call (an explicit read_attribute) is done during the subscription, so when your client subscribes, an event is automatically generated on the client side containing the value read from the synchronous call. When you restart your device server, a reconnection occurs, with a synchronous call again. So an event is again generated on the client side. This is what you were observing. I guess in your case, you forgot to put some explicit calls to push_xxx_event methods in your call so no event was sent, except the synchronous calls events occurring during the client subscription. If you want TANGO to take into account the event attribute configuration thresholds when you're pushing some events, select "Criteria Managed by library" into POGO. In this case, you will still have to add some calls to push_change_event and\|or push_archive_event in your code. I hope this helps a bit to understand better. Kind regards, Reynald Rosenberg's Law: Software is easy to make, except when you want it to do something new. Corollary: The only software that's worth making is software that does something new.

# 6 years ago

Reynald

Hi,

The way you configured your attribute with POGO means that you will push some events by code for this attribute and the Tango library will not check the criteria, meaning the events attribute configuration will be ignored.
To actually send the events, you still have to add something in your code to explicitly push an event (by code!) whenever you want to send an event. In Java, I don't know the exact name of the method you should use but I guess it is something like push_change_event or push_archive_event, depending on the kind of event you want to send.
Since you configured your attribute in POGO so that it won't check for the event configuration thresholds, an event will be forced-pushed every time you call the push_xxx_event methods explicitly from the code.

What you observed is normal because when a client tries to subscribe to an attribute, a synchronous call (an explicit read_attribute) is done during the subscription, so when your client subscribes, an event is automatically generated on the client side containing the value read from the synchronous call. When you restart your device server, a reconnection occurs, with a synchronous call again. So an event is again generated on the client side. This is what you were observing.

I guess in your case, you forgot to put some explicit calls to push_xxx_event methods in your call so no event was sent, except the synchronous calls events occurring during the client subscription.
If you want TANGO to take into account the event attribute configuration thresholds when you're pushing some events, select "Criteria Managed by library" into POGO. In this case, you will still have to add some calls to push_change_event and|or push_archive_event in your code.

I hope this helps a bit to understand better.
Kind regards,
Reynald

Rosenberg's Law: Software is easy to make, except when you want it to do something new.
Corollary: The only software that's worth making is software that does something new.

# 6 years ago
TCS_GMRT	Hi Reynald, Thank you so much for your reply. Yes, It is helpful for me for archiving attributes through event push by code. Regards, TCS_GMRT