Command polling behaviour - TANGO Controls

# 8 years ago
drea	I have a device with a number of commands. I want to start polling on a particular command (no input parameters). This is achieved with the poll_command(self, cmd_name, period) method. However, for some reason, the command is not being polled. If instead, I start polling on the Status of the device, and then consequently start polling on my command, I can see from the stdout that both commands are being polled. So this works: proxy.poll_command('Status', 5000) proxy.poll_command('my_command', 5000) Weirdly though, if I go in Jive to look at which commands are being polled, I can see that Status is marked as polled (ticked), whilst 'my_command' is not. If I try to check this programmatically from ITANGO, I am given the same information (TRUE for 'Status', and FALSE for 'my_command'). If I stop polling on Status, then the run on 'my_command' stops as well! Restarting polling on 'Status' does not cause 'my_command' to run again. I have then deleted the device from the database, added it again, started the device server, and tried to poll my command from Jive. The command runs a single time, and doesn't run again. If I try to stop polling (again from Jive), I get an error saying: Desc -> Device test/tile/1 is not polled Reason -> API_DeviceNotPolled Origin -> DServer::rem_obj_polling Desc -> Cannot execute command RemObjPolling on dserver/Tile_DS/test Reason -> TangoApi_CANNOT_EXECUTE_COMMAND Origin -> Connection.command_inout() After this error dialog, Jive still shows the command as "unticked". I try to tick it again (to poll), and I get a new error: Desc -> The polling threads pool is full. Device test/tile/1 should be polled by the thread already polling but this device is not defined in the polled device map!! Reason -> API_PolledDeviceNotInPoolMap Origin -> Util::create_poll_thread Desc -> Cannot execute command AddOjbPolling on dserver/Tile_DS/test Reason -> TangoApi_CANNOT_EXECUTE_COMMAND Origin -> Connection.command_inout() Desc -> Cannot poll object my_command Reason -> TangoApi_CANNOT_POLL_OBJECT Origin -> DeviceProxy(test/tile/1).poll_object() I'd really need some help with this. I am using PyTango 8.1.8. Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA) Lecturer \| Researcher Department of Physics Institute of Space Sciences and Astronomy Room 220, Maths and Physics Building University of Malta, Msida MSD2080, MALTA

# 8 years ago

I have a device with a number of commands. I want to start polling on a particular command (no input parameters). This is achieved with the poll_command(self, cmd_name, period) method. However, for some reason, the command is not being polled.

If instead, I start polling on the Status of the device, and then consequently start polling on my command, I can see from the stdout that both commands are being polled. So this works:

proxy.poll_command('Status', 5000)
proxy.poll_command('my_command', 5000)

Weirdly though, if I go in Jive to look at which commands are being polled, I can see that Status is marked as polled (ticked), whilst 'my_command' is not. If I try to check this programmatically from ITANGO, I am given the same information (TRUE for 'Status', and FALSE for 'my_command').

If I stop polling on Status, then the run on 'my_command' stops as well! Restarting polling on 'Status' does not cause 'my_command' to run again.

I have then deleted the device from the database, added it again, started the device server, and tried to poll my command from Jive. The command runs a single time, and doesn't run again. If I try to stop polling (again from Jive), I get an error saying:

Desc -> Device test/tile/1 is not polled
Reason -> API_DeviceNotPolled
Origin -> DServer::rem_obj_polling
Desc -> Cannot execute command RemObjPolling on dserver/Tile_DS/test
Reason -> TangoApi_CANNOT_EXECUTE_COMMAND
Origin -> Connection.command_inout()

After this error dialog, Jive still shows the command as "unticked". I try to tick it again (to poll), and I get a new error:

Desc -> The polling threads pool is full.
Device test/tile/1 should be polled by the thread already polling but this device is not defined in the polled device map!!
Reason -> API_PolledDeviceNotInPoolMap
Origin -> Util::create_poll_thread
Desc -> Cannot execute command AddOjbPolling on dserver/Tile_DS/test
Reason -> TangoApi_CANNOT_EXECUTE_COMMAND
Origin -> Connection.command_inout()
Desc -> Cannot poll object my_command
Reason -> TangoApi_CANNOT_POLL_OBJECT
Origin -> DeviceProxy(test/tile/1).poll_object()

I'd really need some help with this. I am using PyTango 8.1.8.

Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA)
Lecturer | Researcher
Department of Physics
Institute of Space Sciences and Astronomy

Room 220, Maths and Physics Building
University of Malta, Msida MSD2080, MALTA

# 8 years ago
Vincent M	It might have something to do with the device server. I just tried with TangoTest (sys/tg_test/1/DevVoid) and it works fine. Could you try this as well? Edited 8 years ago

# 8 years ago
drea	Hi, Thanks for the reply. Indeed it works. And I have solved my problem. Basically the logic of "my_command" was to stop polling on all other currently polled commands prior to starting to poll the new command. Inherently, "my_command" is registered as "polled" before the command is actually executed even once, and therefore I was starting and stopping the polling on it almost instantly. In scenarios like this, there seems to be a mismatch between which commands are actually being polled and which commands seem to be "registered" as polled. It all makes sense now - I just didn't know this :) Thanks, Andrea Dr Andrea DeMarco, BSc (Hons) (Melita), MSc (Melita), DPhil (UEA) Lecturer \| Researcher Department of Physics Institute of Space Sciences and Astronomy Room 220, Maths and Physics Building University of Malta, Msida MSD2080, MALTA

# 8 years ago

drea

Hi,

Thanks for the reply. Indeed it works. And I have solved my problem.

Basically the logic of "my_command" was to stop polling on all other currently polled commands prior to starting to poll the new command. Inherently, "my_command" is registered as "polled" before the command is actually executed even once, and therefore I was starting and stopping the polling on it almost instantly. In scenarios like this, there seems to be a mismatch between which commands are actually being polled and which commands seem to be "registered" as polled. It all makes sense now - I just didn't know this :)

Thanks,
Andrea

# 8 years ago
Vincent M	Glad you got it to work!