Subscribe events from device with many attributes

Development C++
1

I’m trying to get events from device with really many attributes.
(About 600 attributes). Below code is what I tried with wild chars.

	try 
	{ 
		// create a connection to a TANGO device 
		device = new DeviceProxy(device_name); 
  
		// Ping the device 
		device->ping(); 


		double_callback = new DoubleEventCallBack;

		const string attr_name("*");  // this causes exception

		event_id = device->subscribe_event(attr_name, Tango::CHANGE_EVENT, double_callback);
		std::cerr << "event_client() id = " << event_id << endl;
		// The callback methods are executed by the Tango event reception thread.
		// The main thread is not concerned of event reception. 

		return 1;
	} 
	catch (DevFailed &e) 
	{ 
		Except::print_exception(e);
		return -1;
	}

And exception show that I cannot do this. (See attached picture.
)

It says that * attribute not found.
I was expecting that receiving events from all attributes available under the device.

Is it impossible?

2

Hello,

As far as I know, wildcards are not supported by the subscribe_event method.
When you look at the API documentation ( http://www.esrf.eu/computing/cs/tango/tango_doc/kernel_doc/cpp_doc/classTango_1_1DeviceProxy.html#a5fef157c74708fa54acde839749b9449 ), you can see that it says:

Parameters
[in] att_name The attribute name

There is no mention of wildcards support here.
If you want to subscribe to events for all the attributes of a specific device, you will need to:

Hoping this helps,

Reynald

3

There’s another function with less argument like this

//-------------------------------------------------------------------------------------------------------------------
//
// method :
// 		DeviceProxy::subscribe_event
//
// description :
//		Subscribe to a device event- Add the statless flag for stateless event subscription.
//
//-------------------------------------------------------------------------------------------------------------------

int DeviceProxy::subscribe_event (EventType event,CallBack *callback,bool stateless)
{
	if (version < MIN_IDL_DEV_INTR)
	{
		stringstream ss;
		ss << "Device " << dev_name() << " does not support device interface change event\n";
		ss << "Available since Tango release 9 AND for device inheriting from IDL release 5 (Device_5Impl)";

		Tango::Except::throw_exception(API_NotSupportedFeature,ss.str(),"DeviceProxy::subscribe_event()");
	}

    ApiUtil *api_ptr = ApiUtil::instance();
  	if (api_ptr->get_zmq_event_consumer() == NULL)
	{
		api_ptr->create_zmq_event_consumer();
	}

    int ret;
	ret = api_ptr->get_zmq_event_consumer()->subscribe_event(this,event,callback,stateless);

	return ret;
}

May I ask what is this function used for, then?

I could change my test code without any error, but it won’t get any eventsè_é

	try 
	{ 
		// create a connection to a TANGO device 
		device = new DeviceProxy(device_name); 
  
		// Ping the device 
		device->ping(); 


		double_callback = new DoubleEventCallBack;

		if (attribute_name.length() == 1 && attribute_name[0] == '*')
		{
			event_id = device->subscribe_event(Tango::INTERFACE_CHANGE_EVENT, double_callback);
		}
		else
		{
			const string attr_name(attribute_name);
			event_id = device->subscribe_event(attr_name, Tango::CHANGE_EVENT, double_callback);
		}

		std::cerr << "event_client() id = " << event_id << endl;
		// The callback methods are executed by the Tango event reception thread.
		// The main thread is not concerned of event reception. 

		return 1;
	} 
	catch (DevFailed &e) 
	{ 
		Except::print_exception(e);
		return -1;
	}
4

Hi,

As explained in the documentation (http://www.esrf.eu/computing/cs/tango/tango_doc/kernel_doc/cpp_doc/classTango_1_1DeviceProxy.html#ac33ae96ec8f69bdd5a16020fd799293c), DeviceProxy::subscribe_event (EventType event,CallBack *callback,bool stateless) method is available only for the device interface change events, which will send events … only if your device interface changes(!), when new dynamic commands or dynamic attributes are created.
You are probably not interested in that in your case.

There are several types of events in TANGO. You need to understand the differences between these different types of events and subscribe to the ones you are interested in.

I advise you to try to receive events from one attribute first, to get familiar with Tango events and because you seemed to be interested in attribute related events.
Please be aware that some configuration might be needed.
If you are not pushing events manually from your device server code, you will have to activate the polling on the attributes you want to receive events from and depending on the event type you are interested in, you might need to configure the events parameters for these attributes from jive because the events will be sent only if some conditions are met, which is the main interest of this feature actually.
Please have a look at the section 4.6 from the TANGO Controls System Handbook.

Hoping this helps,

Reynald

5

Hi,

what events are you expecting from the 600? Is your device server pushing CHANGE events or have you configured the polling and events to have the TANGO library send them? 600 attributes sounds like a lot (too much?). Even if it works and interface with 600 different attributes will be difficult to handle in the gui tools and for the operators. Are you sure some attributes cannot be grouped together to reduce the overall number. I would try to get them under 100 unless you have a special use case and you really need 600 and your operators know how to manage this. If you could tell us more about your use case we could maybe give you some tips.

Your need to subscribe to events from many attributes using wildcards like “*” is not possible today. In order to do this in code today you have to introspect the interface to get the list of attributes for your device and then subscribe to each one in a loop. It might be a good idea to add a feature request for subscribing to a group of attributes.

Cheers

Andy

6

Thanks Reynald and Andy for your feedback.

Tango system needs to get data from 3500 devices.
And each device has from 350 to 1500 attributes. (So I assume that average 600 attributes)
The total number of the attributes is over 2,100,000.

Regarding the GUI, this size can be handled without much trouble, I assume.
Of course operators cannot manage this just using jive tools:-)

Even though making them under 100 per each device (as Andy’s suggestion), it comes to 350,000 attributes.
As the manual says polling is inefficient under this circumstances.

I’m thinking push subscribe instead of pull, because the events are not triggered so often.
So I configured the polling and event and let the TANGO library handle them.

As Reynald suggested, I could loop each attributes for one device and found it works.
But repeating them over 3500 times really takes too much timeè_é
Also I’m afraid TANGO could handle the full capacity, finally.

Below is what I tested with only one device;

// global variables
DeviceProxy *device = NULL;
DoubleEventCallBack *double_callback = NULL;
deque<int> event_ids;


// forward declarations
int handleExit();
bool subscribeEvent(const string &attr_name);


int main(int argc, char* argv[])
{
	string device_name;
	string attribute_name;

	if (argc == 3)
	{
		device_name = argv[1];
		attribute_name = argv[2];
	}
	else
	{
		cerr << "Usage : TestEvents.exe [device_name] [attribute_name]" << endl;
		cerr << "Example :" << endl;
		cerr << "   Get one attribute" << endl;
		cerr << "        TestEvents.exe sys/database/2 one_attr" << endl;
		cerr << "   Get all attributes" << endl;
		cerr << "        TestEvents.exe sys/database/2 *" << endl;

		// use default names
		device_name = "sys/database/2";
		attribute_name = "*";
		cerr << "Connect to device " << device_name << " ..." << endl;
	}

	try 
	{ 
		// create a connection to a TANGO device 
		device = new DeviceProxy(device_name); 
  
		// Ping the device 
		device->ping(); 


		double_callback = new DoubleEventCallBack;

		if (attribute_name.length() == 1 && attribute_name[0] == '*')
		{
			vector<string> *attribute_name_list = device->get_attribute_list();

#if DO_NOT_USING_THIS_IT_IS_TOO_SLOW
			/* get the attribute configuration */
			Tango::AttributeInfoList *attr_config_list;
			attr_config_list = device->get_attribute_config(*attribute_name_list);
			
			/* loop over all attributes */
			for (int i=0; i<attribute_name_list->size(); i++)
			{
				Tango::AttributeInfo ai = attr_config_list->at(i);

				// skip write attribute
				if (ai.writable != READ)
					continue;

				subscribeEvent(ai.name);
			}
#else
			/* loop over all attributes */
			for (int i=0; i<attribute_name_list->size(); i++)
			{
				Tango::AttributeInfo ai = device->get_attribute_config(attribute_name_list->at(i));

				// skip write attribute
				if (ai.writable != READ)
					continue;

				subscribeEvent(ai.name);
			}
#endif
		}
		else
		{
			subscribeEvent(attribute_name);
		}

		// The callback methods are executed by the Tango event reception thread.
		// The main thread is not concerned of event reception. 

		// Sleep some time to check events
		sleep(10000);

		return handleExit();
	} 
	catch (DevFailed &e) 
	{ 
		Except::print_exception(e);
		return -1;
	}

	return 0;
}

bool subscribeEvent(const string &attr_name)
{
	assert(device != NULL);

	try 
	{
		int event_id = device->subscribe_event(attr_name, Tango::CHANGE_EVENT, double_callback);
		//std::cerr << "event_client() id = " << event_id << endl;
		event_ids.push_back(event_id);
		return true;
	}
	catch (DevFailed &e) 
	{ 
		Except::print_exception(e);
		return false;
	}

	return false;
}

int handleExit()
{
	if (device != NULL)
		return 0;
	
	try 
	{
		while (!event_ids.empty())
		{
			int event_id = event_ids.back();
			device->unsubscribe_event(event_id);
			event_ids.pop_back();
		}

		delete double_callback;
		delete device;

		return 1;
	}
	catch (DevFailed &e) 
	{ 
		Except::print_exception(e);
		return -1;
	}

	return 0;
}
7

While testing events, I found that the device name and attribute name is coming with small chars only.è_é
Any option to get the names as they are. (case sensitive)

8

Hi,

now that I understand your use case a but better. Tango should be able to scale to the number of attributes you mention because it is based on a point to point protocol between servers and clients. If you need more attributes and the server cannot handle the load then simply distribute the attributes to more servers and more hosts. You are right the polling thread is probably not optimised for 600 attributes but would need to be tested to be sure. It depends on how the attribute data is read. If the values are already in memory then 600 is not an issue. Version 9 of Tango has optimised the polling a bit more by reading all attributes polled with the same period in one call using read_attributes().

If you want to avoid the large number of device attributes to import by clients you could group multiple attributes into one and return the data in an array. This will enable you to reduce the number of attributes. This is a common design pattern if you have attributes which are related.

You are right the name returned is normalised to small characters. This is because Tango does not distinguish between small and big letters in device names. Therefore all device and attribute names are converted to small letters in the code to optimise comparisons.

Hope that helps.

Andy

9

Andy

When you say “goup”, you mean Spectrum attribute?

Not the “Tango::Group” that something like


g1 = new Tango::Group("many_devices_all_together");
g1->add("my/device/01");
g1->add("my/device/03");
g1->add("my/device/02");
10

By group I mean simply putting data into an array (Spectrum or Image data type) and not the Groups supported by the api you mentioned.

The Groups are convenient for accessing many devices with one call either reading/writing their attributes or sending the same command to many devices. For example we have 224 beam position monitors which we access using the Groups in the api.

But as you have noticed these Groups do not support subscribing to events from hundreds of attributes in one call. Reducing the number of attributes would help solve this problem. Note it is only necessary to solve if you have a client(s) which will subscribe to all the attributes. If each client subscribes to only a few attributes then it is not an issue.

Andy

11

Andy
Thanks for your kind explanation;

When I tested with add_dynamic_attribute routine I have two questions;

  1. How to set the set_event_abs_change for DEV_BOOLEAN
    It gives error that

[quote]The property abs_change is not settable for the attribute data type
Setting a valid value (also ‘NaN’, ‘Not specified’ and ‘’ - empty string) for any property for this attribute will automatically bring the above-mentioned property to its library defaults
Hint : Check also class level attribute properties
Origin = Device_3Impl::read_attributes_no_except()[/quote]

  1. When I tried to delete the dynamic attribute pointere, it gives abnormal quit.
    Is it not recommended?

[quote] // below caused abnormal quit!!
//if (a)
// delete a;
[/quote]
Below is the code that I tested

void TOmronServer::add_dynamic_attribute (const DynamicFINSAttribute::Config& cfg)
{
	//DEBUG_STREAM << "TOmronServer::add_dynamic_attributes () for " << cfg.m_name << std::endl;

	DynamicFINSAttribute * a = NULL;
	try
	{
		a = new DynamicFINSAttribute(cfg);

		a->set_disp_level(Tango::OPERATOR);

		if (cfg.m_rw != Tango::WRITE)
		{
			// write only does not need polling && event
			Tango::UserDefaultAttrProp	event_prop;
			event_prop.set_event_abs_change("1");
			//event_prop.set_event_rel_change("1");

			// TANGO::DEV_BOOLEAN - error
			/*
				The property abs_change is not settable for the attribute data type
				Setting a valid value (also 'NaN', 'Not specified' and '' - empty string) for any property for this attribute will automatically bring the above-mentioned property to its library defaults
				Hint : Check also class level attribute properties
				Origin = Device_3Impl::read_attributes_no_except()
			*/

			//- set other attribute properties : label, display format,...
			a->set_default_properties(event_prop);

			a->set_polling_period(1000);
			//a->set_change_event(true, true);
		}

		this->m_dyn_attrs.add(a); 
		return;
	}
	catch (std::bad_alloc)
	{
		ERROR_STREAM << "TOmronServer::add_dynamic_attribute caught bad_alloc" << std::endl;
	}
	catch (Tango::DevFailed &e)
	{
		ERROR_STREAM << "TOmronServer::add_dynamic_attribute caught DevFailed " << e << std::endl;
	}
	catch (...)
	{
		ERROR_STREAM << "TOmronServer::add_dynamic_attribute caught (...)" << std::endl;
	}

	// below caused abnormal quit!!
	//if (a)
	//	delete a;
}
12

Hi,

About your first question, you don’t need to use set_event_abs_change for DEV_BOOLEAN attributes.
If a client subscribes on CHANGE event on a DEV_BOOLEAN attribute, it will receive an event every time the value changes from true to false or from false to true.

About your second question, it seems we don’t have enough information to be able to help you.

Where does DynamicFINSAttribute class come from?
Is it a class you created?

Kind regards

Reynald

13

Reynald,

Thanks for your response.
Regarding the second question;

The DynamicFINSAttribute class was actually copied and renamed from “ModbusDataViewer” under Communication.

After digging into existing code, I found critical bug in there.

The original code in [quote]DynamicAttributesHelper.cpp[/quote] is

void DynamicAttributesHelper::add (DynamicModbusAttribute * _attr)
	throw (Tango::DevFailed)
{

  // clipped

  //- add it to the device
  try
  {
    this->host_device_->add_attribute( _attr );
  }
  catch(Tango::DevFailed& ex)
  {
	  RETHROW_DEVFAILED(ex,
                      "INTERNAL_ERROR",
	                    "attribute could not be added to the device",
                      "DynamicAttributesHelper::add");
  }
  catch(...)
  {
	  THROW_DEVFAILED("UNKNOWN_ERROR",
	                  "unknown caught while trying to add attribute to the device",
                    "DynamicAttributesHelper::add");
  }
  
  //- ok, everything went fine :
  //- insert the attribute into the list
  std::pair<DynAttrIt, bool> insertion_result;
  insertion_result = this->rep_.insert( DynAttrEntry(_attr->get_name(), _attr) );

The problem is when there’s chances to add duplicate attribute.
Then the add_attribute routine releases the attr without raise exception.

So the program abnormally quitted at the code of[quote] _attr->get_name()[/quote].

I’m not sure whether quick fix for this problem as below is the proper one;

	//---------- _FIX_BUG --> added from here
	//	below copied from DeviceImpl::add_attribute(Tango::Attr *new_attr) at device.cpp
	string &attr_name = _attr->get_name();
	bool need_free = false;
	long i;

	vector<Tango::Attr *> &attr_list = this->host_device_->get_device_class()->get_class_attr()->get_attr_list();
	long old_attr_nb = attr_list.size();
	for (i = 0;i < old_attr_nb;i++)
	{
		if ((attr_list[i]->get_name() == attr_name) && (attr_list[i]->get_cl_name() == _attr->get_cl_name()))
		{
			need_free = true;
			break;
		}
	}
	//---------- _FIX_BUG --> added to here

	//- add it to the device
	try
	{
	this->host_device_->add_attribute( _attr );
	}
	catch(Tango::DevFailed& ex)
	{
		RETHROW_DEVFAILED(ex,
						"INTERNAL_ERROR",
						"attribute could not be added to the device",
						"DynamicAttributesHelper::add");
	}
	catch(...)
	{
		THROW_DEVFAILED("UNKNOWN_ERROR",
						"unknown caught while trying to add attribute to the device",
					"DynamicAttributesHelper::add");
	}
	
	//---------- _FIX_BUG --> added from here
	if (need_free)
	{
		//_attr is already freed - no longer available
		return;
	}
	//---------- _FIX_BUG --> added to here

	//- ok, everything went fine :
	//- insert the attribute into the list
	std::pair<DynAttrIt, bool> insertion_result;
	insertion_result = this->rep_.insert( DynAttrEntry(_attr->get_name(), _attr) );  // no more abnormal quit here!!!

I wish the add_attribute function returns result value, not just deleting the passed parameter silently.

14

There are some important lines missing in the code you pasted from DynamicAttributesHelper.cpp file.
(https://sourceforge.net/p/tango-ds/code/HEAD/tree/DeviceClasses/Communication/ModbusDataViewer/trunk/src/DynamicAttributesHelper.cpp)

There are some lines at the beginning of the method which are checking whether the attribute was already added, and if it was already added, the method throws an exception:


  //- check attribute does not already exist
  DynAttrIt it = this->rep_.find(_attr->get_name());
  if (it != this->rep_.end())
  {
	  THROW_DEVFAILED("OPERATION_NOT_ALLOWED",
	                  "attribute already exists",
                    "DynamicAttributesHelper::add");
  }

So it seems there is no chance to add a duplicate attribute with this code.

15

Reynald,

The code that you mentioned is already there.
It was clipped for clarification.

See the captured picture which shows this case;

16

Hi,

Indeed you are right.
It seems the developer should not try to access to the attribute variable passed to add_attribute() after having invoked this method since, as you noticed, add_attribute() might release it if the attribute was previously already added (even by another device).
This is not well documented.
I think the documentation should be improved by giving examples on dynamic attributes management.
I guess this is what you were looking for when you ended up re-using ModbusDataViewer code.
I’ve never used this ModbusDataViewer device server, but it might be that in practice, it has never been used (or was not supposed to be used) with several devices per device server instance.

Cheers,

Reynald

17

I actually would not recommend the approach from ModbusDataViewer device server in recent Tango code.

The recent versions of Tango have introduced the add_dynamic_attributes() method for a better and more standard way to handle dynamic attributes.
Let’s suppose your class is named Example.
If you generate C++ code from POGO for a class named Example, you will notice that POGO generates a method named Example::add_dynamic_attributes() for you in Example.cpp

Pogo will also generate some code to invoke this method during the device creation (after init_device() is executed).
You can see this code in ExampleClass.cpp generated file in ExampleClass::device_factory() method.

In ExampleClass.cpp, you will also notice that there is a method called ExampleClass::erase_dynamic_attributes() which will take care of erasing the dynamic attributes which were created during the previous call to add_dynamic_attributes().

So what you need to do is simply add the code to create the attributes in Example::add_dynamic_attributes() method. Tango will take care of cleaning the created attributes for you the next time the device is created again (typically when you invoke restart device). You don’t need to maintain yourself a map containing the list of attributes you dynamically created and you don’t need to remove them in Example::delete_device().

Please be aware that if you are using what I suggested above, if you invoke the Example::init command, Example::add_dynamic_attributes() will not be invoked.
It is invoked when you click on restart device from jive though (equivalent to DevRestart command from admin device).

I would recommend this approach since the recent tango code and recently added features like the Interface Change Events have been designed with this approach in mind I think.

Hoping this helps,
Reynald