Development of IMAQdx DS , some questions about best practice, e.g how publish of a cluster array

# 2 years ago
AlexK	Dear community, I want to develop a device server for NI-Vision IMAQdx driver. So every GIGe-Vision compatible camera should be controllable independent from the manufacturer. We use a lot the library HIJ-Vision. It contains the control of the camera via IMAQdx, library of evaluation classes, which are typical for a laser lab, management of ROIs, projection of the results in the image and much more. At the moment the architecture is monolithic, in the sence that the control of the camera, evaluation and display are in the same program. I would like to use Tango to outsource the camera control to a device server, and to use the rest as a Tango client. Thus one camera could be observed by several client instances. I migrated the server examples from Labview bindings to LV2020 examples_lv2020.zip and created an exe for (Single\|Multiple)DeviceDServer -> it works, except for problems with restart. From the examples I conclude that publishing images should not be a problem. What is not clear to me is how to publish an array of clusters in Tango? Specifically, I want the server to send a list of camera attributes in order to build up the camera attribute tree, which You can see in the picture on the left. Fig. 1 IMAQdx offers a generic structure, basically with attribute name, type, and value: DBL, Int, String, Enum, Boolean, see Figure 2. Fig. 2 Of course I can create huge number of arrays for all possibilities and sort the data by index. Or to fold all data into JSON or XML String and publish it via a string attributt. Would there be a more elegant solution? Edited 2 years ago Attachments: 1.85Mb

# 2 years ago

Dear community,

I want to develop a device server for NI-Vision IMAQdx driver. So every GIGe-Vision compatible camera should be controllable independent from the manufacturer.

We use a lot the library HIJ-Vision. It contains the control of the camera via IMAQdx, library of evaluation classes, which are typical for a laser lab, management of ROIs, projection of the results in the image and much more. At the moment the architecture is monolithic, in the sence that the control of the camera, evaluation and display are in the same program. I would like to use Tango to outsource the camera control to a device server, and to use the rest as a Tango client. Thus one camera could be observed by several client instances.

I migrated the server examples from Labview bindings to LV2020
examples_lv2020.zip and created an exe for (Single|Multiple)DeviceDServer -> it works, except for problems with restart. From the examples I conclude that publishing images should not be a problem.

What is not clear to me is how to publish an array of clusters in Tango?
Specifically, I want the server to send a list of camera attributes in order to build up the camera attribute tree, which You can see in the picture on the left.

Fig. 1

IMAQdx offers a generic structure, basically with attribute name, type, and value: DBL, Int, String, Enum, Boolean, see Figure 2.

Fig. 2

Of course I can create huge number of arrays for all possibilities and sort the data by index. Or to fold all data into JSON or XML String and publish it via a string attributt.

Would there be a more elegant solution?

Edited 2 years ago

# 2 years ago
AlexK	Ok, the post above is quite long. Here is the main question: how do you publish a composite datatype (LV - cluster, C - struct)? A statement in the art: it is not possible, or RTFM (with appropriate links ) would help a lot

# 2 years ago
Leonard	Hi Alex, I have never tried this before, so for a quick and easy solution I would probably use a String attribute with some JSON inside. But maybe Pipes could do what you want (I have never used them, maybe an expert can comment). Read this in the general doc: https://tango-controls.readthedocs.io/en/latest/development/device-api/device-server-model.html#the-tango-pipes There are some examples for Cpp and e.g. Python around, unfortunately searching the Labview Gitlab repo for "pipe" yields nothing except for hints its not implemented, if I am not mistaken. Greetings from Munich, Lenny

# 2 years ago

Leonard

Hi Alex,

I have never tried this before, so for a quick and easy solution I would probably use a String attribute with some JSON inside. But maybe Pipes could do what you want (I have never used them, maybe an expert can comment).

Read this in the general doc:
https://tango-controls.readthedocs.io/en/latest/development/device-api/device-server-model.html#the-tango-pipes

There are some examples for Cpp and e.g. Python around, unfortunately searching the Labview Gitlab repo for "pipe" yields nothing except for hints its not implemented, if I am not mistaken.

Greetings from Munich, Lenny

# 2 years ago
nleclercq	Hi Alex, So far, the Labview binding doesn't support Tango pipes - neither in client, nor in server mode. You know the story, as a developper, you often say, "ok, this feature is useless, nobody use it" and finally, 10 years after, a guy shows up and ask for the missing feature. You're that guy I could certainly add pipes support but it would require time I don't have those days. That's why I would follow Leonard's advice and use some JSON structs into a single DevString. There's a JSON parser for LabVIEW that could help (I simply googlized "JSON parsing Labview" so don't ask me anything regarding that parser . Hope this help. N. BTW, can you comment on "I created an exe for (Single\|Multiple)DeviceDServer -> it works, except for problems with restart" please? What's this restart problem you mention exactly? Edited 2 years ago

# 2 years ago

nleclercq

Hi Alex,

So far, the Labview binding doesn't support Tango pipes - neither in client, nor in server mode.
You know the story, as a developper, you often say, "ok, this feature is useless, nobody use it" and finally, 10 years after, a guy shows up and ask for the missing feature. You're that guy smile

I could certainly add pipes support but it would require time I don't have those days. That's why I would follow Leonard's advice and use some JSON structs into a single DevString. There's a JSON parser for LabVIEW that could help (I simply googlized "JSON parsing Labview" so don't ask me anything regarding that parser smile

.

Hope this help.
N.

BTW, can you comment on "I created an exe for (Single|Multiple)DeviceDServer -> it works, except for problems with restart" please? What's this restart problem you mention exactly?

Edited 2 years ago

# 2 years ago
AlexK	Dear Lenny and Nicolas, Thank You very much for your clarification and apologies to Lenny for late feedback. I had a few weeks vacation and then no time to work on the IMAQdx DS. After the long silence in the blog after my question, I assumed that the possibility of structs is not provided in Tango. In that respect, Lenny's hint is an insight for me, because I haven't read in deeth about pipes so far. I have decided for myself to make workaround either via FolderToJson, XML or String VIs. I used JSON with LV before. Debugging nested clusters can be very annoying, especially if you use e.g. RubyOnRails to create JSON and LV to read out the data. I hope with LV in LV out it will be better. P.S. We have some discusion about a meta data standard for High Intensity Laser experiments at this mattermost channel https://mattermost.hzdr.de/hmc-public/channels/metadata-in-the-laser-community If somebody from Tango Community want to yoin us, you are wellcome. I think, login should be possible with GitHub or ORCID.

# 2 years ago

AlexK

Dear Lenny and Nicolas,
Thank You very much for your clarification and apologies to Lenny for late feedback. I had a few weeks vacation and then no time to work on the IMAQdx DS. After the long silence in the blog after my question, I assumed that the possibility of structs is not provided in Tango. In that respect, Lenny's hint is an insight for me, because I haven't read in deeth about pipes so far. I have decided for myself to make workaround either via FolderToJson, XML or String VIs.

I used JSON with LV before. Debugging nested clusters can be very annoying, especially if you use e.g. RubyOnRails to create JSON and LV to read out the data. I hope with LV in LV out it will be better.

P.S.
We have some discusion about a meta data standard for High Intensity Laser experiments at this mattermost channel
https://mattermost.hzdr.de/hmc-public/channels/metadata-in-the-laser-community
If somebody from Tango Community want to yoin us, you are wellcome. I think, login should be possible with GitHub or ORCID.

# 2 years ago
AlexK	Dear Nicolas, i start SingleDeviceDServer from LV -> Builds -> Run. LV was started via start-labview.bat. If I start Exe direct from folder, it is not exutable, because it can't find a lot VIs from LV-Bindings.dll. I am wondering about this. Even if tango path is not in Windows ENV Path, it should find VIs, because dll is in standard data subfolder. Also I start from LV, stop the server by click on stop button. Start it again with cklick on LV run button and the result looks like this: Update: After stop I need to click twice on the white run button. After fist time, it jumps out. Edited 2 years ago Attachments:

# 2 years ago

AlexK

Dear Nicolas,
i start SingleDeviceDServer from LV -> Builds -> Run. LV was started via start-labview.bat. If I start Exe direct from folder, it is not exutable, because it can't find a lot VIs from LV-Bindings.dll. I am wondering about this. Even if tango path is not in Windows ENV Path, it should find VIs, because dll is in standard data subfolder.

Also I start from LV, stop the server by click on stop button. Start it again with cklick on LV run button and the result looks like this:

Update: After stop I need to click twice on the white run button. After fist time, it jumps out.

Edited 2 years ago

# 2 years ago
nleclercq	Hi Alex, The VIs are stored into a dedicated library: tango_vi.llb. The dll (i.e., tango_binding.dll) contains the C++ part. The Tango VIs are supposed to be packed together with your own VIs when LabVIEW generates the standalone app. That's weird. I'm going to generate a standalone app from one of the examples and let you know (later next week). Regarding the "start error", the messages I see in the ATK panel are the signature of an initialisation failure followed by an immediate execution of the cleanup sequence (normally executed when the device exits). The cleanup sequence fails cause nothing has been properly initialised. This is not the expected behaviour cause the cleanup sequence is supposed to cleanup only what has been actually initialised. I've never observed that before. That said, the root cause of the initialisation failure you observe remains unknown. We have to work on that first. Which Tango binding distribution are you using? I could try to recompile the binding for your LV version. In that case, I would need you to send me the cintools directory of your Labview version.

# 2 years ago

nleclercq

Hi Alex,

The VIs are stored into a dedicated library: tango_vi.llb. The dll (i.e., tango_binding.dll) contains the C++ part. The Tango VIs are supposed to be packed together with your own VIs when LabVIEW generates the standalone app. That's weird. I'm going to generate a standalone app from one of the examples and let you know (later next week).

Regarding the "start error", the messages I see in the ATK panel are the signature of an initialisation failure followed by an immediate execution of the cleanup sequence (normally executed when the device exits). The cleanup sequence fails cause nothing has been properly initialised. This is not the expected behaviour cause the cleanup sequence is supposed to cleanup only what has been actually initialised. I've never observed that before.

That said, the root cause of the initialisation failure you observe remains unknown. We have to work on that first.

Which Tango binding distribution are you using? I could try to recompile the binding for your LV version. In that case, I would need you to send me the cintools directory of your Labview version.

# 2 years ago
AlexK	Hello Nicolas, well, I have converted llb into a folder. I assume lld are deprecated. I can't imagine they work smoothly with git. But, if llb is necessary, I can live with it. Especially if you would compile Labview bindings for LV2020. That is certainly a good idea. The cintool folder is in the attachment. The version of bindings is 3.0.0. for LV2015-windows-x86. I downloaded it from SourceFourge. I am using LV 2020.0.1. Thanks a lot! Attachments: 465Kb

# 2 years ago

AlexK

Hello Nicolas,

well, I have converted llb into a folder.

I assume lld are deprecated.
I can't imagine they work smoothly with git.

But, if llb is necessary, I can live with it. Especially if you would compile Labview bindings for LV2020. That is certainly a good idea. The cintool folder is in the attachment. The version of bindings is 3.0.0. for LV2015-windows-x86. I downloaded it from SourceFourge. I am using LV 2020.0.1.

Thanks a lot!

# 2 years ago
nleclercq	Hi Alex, I'm definitively not a LabVIEW expert. If .llb files are deprecated, let's move to a more modern approach. We were still using them for "legacy" reason. Si far, every single Tango VI rely on this llb - i.e. it's supposed to search for its dependencies (i.e., sub-vis) into the tango llb. What would be your proposal to switch to another organisation of the VIs?

# 2 years ago
AlexK	I sugges: Folder with a .lvlib file and a subfolder with the VIs that belong to library.