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

# 2 years ago
nleclercq	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? Edited 2 years ago

# 2 years ago
AlexK	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.

# 2 years ago
AlexK	Yes, it is from Windows10.

# 2 years ago
nleclercq	AlexK 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. Yes, I expected this kind of side effect. Please upload (or share) your project so that I can have a look to it. Thanks.

# 2 years ago
AlexK	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 https://git.gsi.de/a.kessler/tango-lv-bindings.git Or just copy from here: https://cloud.uni-jena.de/s/CXzwbddBmSLtP4r Edited 2 years ago

# 2 years ago

AlexK

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
https://git.gsi.de/a.kessler/tango-lv-bindings.git

Or just copy from here:
https://cloud.uni-jena.de/s/CXzwbddBmSLtP4r

Edited 2 years ago

# 2 years ago
AlexK	Dear Nicolas, did You have the oportunity to recompile LV bindings? Best ragards, AlexK

# 2 years ago
nleclercq	Hi AlexK, 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.

# 2 years ago

nleclercq

Hi AlexK,

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.

# 2 years ago
nleclercq	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. Edited 2 years ago

# 2 years ago

nleclercq

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.

Edited 2 years ago

# 2 years ago
AlexK	Thank You a lot, i will try it out next week.

# 2 years ago
AlexK	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 https://gitlab.com/tango-controls/labview-binding ?