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.
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).
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.
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?
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
If somebody from Tango Community want to yoin us, you are wellcome. I think, login should be possible with GitHub or ORCID.
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.
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.
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.
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?
I think we already such an organisation in gitlab. Let’s me check that later this week.
BTW, thanks for the cintools directory. It comes from LV 2020 for Windows, right?
a comment: if You switch to folder strukture, You have to solve a lot of coflicts. If You want, i can upload my LV2020 project where I have done this allready.
I have arranged the Vis according to the pattern of Actor Framework / LVOOP. I put the _Name.vis in the utility_vi folders. Why are these VIs not part of libraries?
I had to search for some time because after rearrangement LV did not want to load tango_bindings.dll. The DLL calls in Vis are always source of “joy”. But in this case it turned out that LV had to be started with start-labview.bat. I included the folder ..\tango-binding-3.0.0-for-labview-2015-windows-x86 in Path environment variable, but it remains with the behavior.
I have created a GitLab repository. You can clone the project from
Well, I think there’s a misunderstanding. I’m deeply sorry for not reacting before your start to reorganise the VIs.
In fact, a LabVIEW expert already contributed to the VIs reorganisation a few years ago. The result of his contribution is the visrc directory and its client, server and common subdirectories. IMHO, this VIs repo is properly organised so what’s the problem exactly with the current organisation?
The .llb is a legacy stuff. We generate it from the visrc (see build_library.lvproj) in order to ensure backward compatibility with some applications deployed for more than a decade in some institutes (e.g., SOLEIL). The only problem I see is a potential dependency of the VIs stored into the visrc directory vs the .llb - but I don’t think we have such weird/ugly dependency. The provided examples actually rely on the .llb but it doesn’t mean you are obliged to use follow their dependency schema.
BTW, _Name VIs are low-level/private VIs that are properly stored into dedicated “private” directories - see the current VIs organisation.
Let’s clarify this and see what could be done.
BTW, thanks for the reminder regarding the recompilation of the binding for LV2020.
Alex, can you please give this distribution a try?
You certainly need to adapt the launcher/windows/start-labview.bat file to launch LV in the proper env.
BTW, this is a preview of the upcoming release 4.0. It notably offers support for dynamic attributes and commands. You can now start a server with the “minimum Tango interface” (Init, State and Status) and populate its interface programmatically from LabVIEW. You can also (and obviously) add dynamic attributes and commands to an interface defined by using POGO (.xmi). See the PureDynamicInterfaceDServer.vi for an example. This release relies on the new VIs organization (no more .llb). See the vis directory for details.
Hello Nicolas,
I apologize for my silence. I had urgent work in the lab. Unfortunately, I had to realize that I cannot open the linked project with LV2020. Could it be that it was saved with LV2021? Should I use commit 3a385818 state from tango-controls / labview-binding · GitLab ?
) would help a lot 
