LabVIEW - Make it easy to change the DLL path

[ryannazaretian]

| Camera Model | D435 |
| Firmware Version | 05.09.11.00 |
| Operating System & Version | Windows 10 / Ubuntu 16.04 |
| Kernel Version (Linux Only) | Unsure at the moment (don't have PC available) |
| Platform | PC |
| SDK Version | 2.13 |
| Language | LabVIEW 2017 32-bit |
| Segment | Robotics |

Issue Description

Feature Request

First off, thanks for providing us with LabVIEW wrappers. That saved 90% of the time needed to get started just by seeing the examples and having all the library calls prototyped out.

However, when I downloaded the latest wrappers, the DLL calls seem to be set to an absolute path: C:\Users\agrunnet\Documents\libRealSense6\realsense2.dll

Going forward though, I'm going to be moving these wrappers to Ubuntu 16.04 to run on an UP Board, our on-board vision processing computer. Using the current implementation, this would require us to update all 80ish VIs to use the new realsense2.so path for Linux.

Rather than going through an updating every function's Call Library Function to point to a new absolute path, I selected "Specify path on diagram" and created a VI that gets the path to the file for me, and even detects if it's running in LabVIEW 32-bit or 64-bit. On Ubuntu/Linux, I'll just need to update this one VI's file path to point to the realsense2.so file rather than updating all 80ish VIs.

I can create a Pull Request for this issue since I have updated all of the VIs to use this new "rs3 get dll path" call.

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment]
@ryannazaretian
Welcome to contribute what you've done to LibRealSense, please create the PR and we will have someone review for you.

[dorodnic]

Hi @ryannazaretian
Thank you for the pull-request. It is not a good practice to maintain binary files in Git.
@agrunnet please consider integrating this into next release of the LabView package.

[ryannazaretian]

Agreed. It's rough to work with LabVIEW in version control.

[agrunnet]

@ryannazaretian
Thanks for the contribution. I am still of two minds regarding whether I should add this path as I prepare a new version for release. I absolutely understand your position, and it is annoying to redo the paths. However, not having the path explicitly called out is what I have seen done a lot by others, presumably because it reduces wiring. What is the preferred convention in general? You think it will be much better to add this path to all VIs?

[ryannazaretian]

I'm not sure what the preferred convention is. It does add an additional VI and wire to each low-level RealSense library call, but it's an easy way to set the library path for all VIs. I don't think it adds much noise to the block diagram as the intention is pretty simple.

I'm obviously biased towards the way I implemented it, but I'm also jumping between two platforms, which makes checking in code from a Windows system and checking it out on an Linux system much harder to manage.

Thanks,
Ryan Nazaretian

[RealSense-Customer-Engineering]

[Realsense Customer Engineering Team Comment]
Please refernce PR #1964 that allows users to make this change.

[churujia]

| Camera Model | D435 |
| Firmware Version | 05.09.11.00 |
| Operating System & Version | Windows 10 / Ubuntu 16.04 |
| Kernel Version (Linux Only) | Unsure at the moment (don't have PC available) |
| Platform | PC |
| SDK Version | 2.13 |
| Language | LabVIEW 2017 32-bit |
| Segment | Robotics |

Issue Description

Feature Request

First off, thanks for providing us with LabVIEW wrappers. That saved 90% of the time needed to get started just by seeing the examples and having all the library calls prototyped out.

However, when I downloaded the latest wrappers, the DLL calls seem to be set to an absolute path: C:\Users\agrunnet\Documents\libRealSense6\realsense2.dll

Going forward though, I'm going to be moving these wrappers to Ubuntu 16.04 to run on an UP Board, our on-board vision processing computer. Using the current implementation, this would require us to update all 80ish VIs to use the new realsense2.so path for Linux.

Rather than going through an updating every function's Call Library Function to point to a new absolute path, I selected "Specify path on diagram" and created a VI that gets the path to the file for me, and even detects if it's running in LabVIEW 32-bit or 64-bit. On Ubuntu/Linux, I'll just need to update this one VI's file path to point to the realsense2.so file rather than updating all 80ish VIs.

I can create a Pull Request for this issue since I have updated all of the VIs to use this new "rs3 get dll path" call.

can L515 run it??