Project Portability #3 Modbus Library Case Study

[swatts]

Morning Projecteers

I modified the Modbus toolkit (some version I got off NI.com a while back) and in my normal fashion wanted to control my dependencies. All I wanted to do was to move the modbus directory from vi.lib and embed it into my project hierarchy. I also need to be able to then move my entire project hierarchy about on the drive too.

Here's how it went......

The Modification

I had to modify Create Slave Instance (TCP).vi so that I could point it at a specific ethernet port. In this case I added an extra input so it was very obvious if I had the wrong library version on my machine (this is not a given and the implications are discussed in detail here)

All I wanted to do was move the \modbus directory from vi.lib and into my project directory so I can push it up to my repository.

Step 1 Move Directory from vi.lib

And we get warnings and errors, which is actually not a bad thing.

First it’s locked because it’s part of a RT deployment (multiple instances). I removed the called vi from the RT Project.

Step 2 Loading Project With Embedded Library

I closed LabVIEW and started again getting the following message.

As I was writing up this process I persisted pressing [Ignore] for longer than I usually would, after 15 minutes I got bored.

So I Killed LabVIEW.

Step 3 Tackle Slave Class On Its Own

And after a bit of whirring it all loaded nicely

When I opened up Initialize.vi none of the called classes where found, but after a bit of saving and loading all was good.

Step 4 Saving SubVIs.lvlib

Loaded up SubVIs.lvlib, this is called by both the Master and the Slave Classes.

And a Save All saved 216 files, which was very encouraging. I loaded and saved both the Master and Slave Classes and all appeared to be good.

Step 5 Back In The Project

I reloaded my project

and dealt with all the conflicts (not too many) and then went into the dependencies to clear those up.

Step 6 Cleaning House

As I've said before a tidy project is a happy project.

These were essentially old test-stubs and examples so I had the bonus of deleting old unused code from the code-base (the best type of programming!)

This was now all working OK.

Step 7 Making It Portable

Although it was all working the project wasn't actually portable, if I moved it on disk it lost the SubVIs Directory and here I ran into a common faulting finding problem. I had a gut feeling for what was wrong, but had convinced myself that it shouldn't be a problem. I also wanted to bounce some ideas off someone else so started to skype-hassle Fabiola. She kindly started looking through the issue with me offering me use of the Delacor Library Duplicator and also showed me that I could open the lvlib file with notepad and check the files were relative and not absolute.

The directory structure on disk was still niggling me tho'

Here's how it was originally.

I moved the subvis subdir into the slave subdir and deleted the master directory as it was not required. And now I can export it from my repo to anywhere and it will work. I've said this before but never actually done the hard graft to prove it.

LabVIEW likes subVIs to be below the caller in the hierarchy.

And that's what I'm talking about when I'm talking about project portability.

Lots of Love

Steve

[FabiolaDelaCueva]

Steve,

I was so glad you could figure it out and I am glad I could be of assistance. Still not happy that you had to go through all that trouble.

We both agreed that this was not LabVIEW making it hard to port code, this was a series of ill advised decisions with a file hierarchy structure that does not work well with LabVIEW.

Once again you proved that if we stick to some basic code organization principles, we can avoid a log of headaches:

---

@swatts wrote:

LabVIEW likes subVIs to be below the caller in the hierarchy.

---

My advice to anyone reading your post:

• Build code you distribute to others on a computer other than the one you used to develop. (I don't care if it is a source distribution, VIPM package, exe, dll, etc).
• On that build server, put the code in a different directory. For example if it was in C:\dev code\ in your development computer, put it in C:\build code\ in your build server.

If you do this often and starting early on in the process, you will find any portability issues early on. This is a way of being nice to future you and others.

Best regards,

Fab

[swatts]

100% Agree!

Portability is an essential part of our code review, and that means from repository to vanilla machine to new directory.