Structuring code for reuse

[andrewDJ]

Answering both...

Perhaps I'm using the word "framework" in too loose a fashion: what I am really working on is a Hardware Abstraction Layer as a means of getting to grips with LabVIEW.  I know this already exists within LabView but I don't learn by taking someone else's version so I very specifically want to create my own: it's a reasonably complex problem domain and will cover many aspects of LabVIEW features.  I've had a good success with LabView NXG but...well, let's not go there.

I'm experienced with developing application architectures in other languages and this certainly isn't anything like that.  It is more akin to a plug-in if anything.  So when I want to create a new test project, I would just sit it on top of the HAL, extending out of it.

There is only me and everything I do, I do for myself, although obviously I'm more than happy to share what I do with anyone who is interested and I often blog about what I do.  I have plenty time to research and try out (for example, I've spent around 3.5 days so far just on this - actually between this and deciding if I want to take a by-value or by-reference approach!) That basically means there's no corporate involvement, no "rollout", no ongoing maintenance unless I'm interested and do it myself and so on.  I'm using LabVIEW Community Edition to support some of the electronics work I do (totally non-commercial).

Having said this, I don't want to take a particularly lax approach to anything I do - I want to take advantage of what the tool offers me.  The Template approach is a good example: seems to fit well with the idea of reuse and I can set it up to be visible across both my computers (I develop on a 2-screen iMac setup, but mostly would use via a MacBook)  The approach I originally did with creating a Library file seems to fit as well.  The only weird thing was the error message that popped up when I was trying to do a "replace with" operation as described above.  

When I have an idea of what I want to achieve, I try and research it and work it out.  Sometimes though, if I don't what the art-of-the-possible is it can be difficult to articulate a search to uncover it.  You don't know what you don't know as they say, and being pointed at the use of templates dragged me in a completely different direction than I was originally thinking.

Anyway, this has been very useful for me so many thanks.

[andrewDJ]

---

wiebe@CARYA wrote:
Why not use source code control for that?

Put a repo on \LabVIEW Data\ and make a local branch (on any PC).

Almost the same effort (slight learning curve) but you'll gain a huge amount option (tracing builds, bugs features, comparing with old versions, etc.).

---

I may do that at some point as it makes sense for managing the code in that location.  And also because there may well be "funnies" that arise from sharing a "LabVIEW Data" directory across two different installs!  That's already a suspicion and I'm looking into it - keeping "LabViEW Data" as default and "LabVIEW Data\Project Templates\[my template projects]" as a repo.

I mean, it's not like I have enough to figure out already 😁

[wiebe@CARYA]

---

@andrewDJ wrote:

---

wiebe@CARYA wrote:
Why not use source code control for that?

Put a repo on \LabVIEW Data\ and make a local branch (on any PC).

Almost the same effort (slight learning curve) but you'll gain a huge amount option (tracing builds, bugs features, comparing with old versions, etc.).

---

I may do that at some point as it makes sense for managing the code in that location.  And also because there may well be "funnies" that arise from sharing a "LabVIEW Data" directory across two different installs!  That's already a suspicion and I'm looking into it - keeping "LabViEW Data" as default and "LabVIEW Data\Project Templates\[my template projects]" as a repo.

I mean, it's not like I have enough to figure out already 😁

---

SCC is one thing I regret not starting 10 years sooner. (OO is another.)

Git works non-distributed (you don't need a server, like SVN). So if you just install it, you can create a repo. Optionally, clone it. You don't need to know all the hard stuff, esp. if you're a one man band. Start doing 'trunk development', simply push and pull, no fancy stuff like feature branches. You don't need LV merge nor LV compare, you can set it up as you go if you want to (I don't bother, but LabVIEW and git). There are a few threads (e.g. Re: LabVIEW and git (same name different thread) on how to setup git so it doesn't automatically merge .lvproj, .lvclass, and a few others  ).

I'd be surprised if it would take more then a day to get up and running. If you have a \git mentor\, you'd understand everything you need in 2 hours.

[andrewDJ]

I'm familiar with Git and spent some time yesterday afternoon looking at this.  Can't believe LabView doesn't integrate natively in 2023!  I saw those posts for .gitignore and .gitattributes thanks - and yes, I don't think merging/comparing will be a thing for me.

[wiebe@CARYA]

---

@andrewDJ wrote:

I'm familiar with Git and spent some time yesterday afternoon looking at this.  Can't believe LabView doesn't integrate natively in 2023!  I saw those posts for .gitignore and .gitattributes thanks - and yes, I don't think merging/comparing will be a thing for me.

---

But...

"LabVIEW integrates with various source control providers via the Microsoft Source Control Interface...

I'm not sure how that works out for git. You must have LV FDS.

I'm not even sure what this gives you if it would work...

Perhaps it's better that SCC isn't up to NI. I'd actually prefer the community to keep up with the latest trends. Provided NI enables us of course.

There are 3rd party add-ons, but I never bothered.

You'll soon run into limits and want to use tortoise, fork, sourcetree, etc...

[andrewDJ]

That doesn't extend to Git unfortunately and is relevant to SCCs such as SVN.  I don't mind that it isn't integrated, I'm just surprised that's all.  

[JÞB]

---

@andrewDJ wrote:

That doesn't extend to Git unfortunately and is relevant to SCCs such as SVN.  I don't mind that it isn't integrated, I'm just surprised that's all.  

---

I usually recommend Tortoise SVN ( and the repo can be on a shared drive between your machines.  Think One Drive)  and VIEWPOINT Systems TSVN TK brings all of the necessary tools directly into LabVIEW Project Explorer and integrates the LabVIEW Compare tool as well.   Both are free!  I use them myself for my own reuse code and have seen them used for large scale multi developer groups ( 20- 50 dev team members)

VIPM/NIPM really doesn't come into play, for my money, until you have a good size team working on multiple projects.  Then you simply place the project reuse packages in separate JIRA workflows and install each project package onto the various project VMs on each Developer workstation (letting 1 Developer work on proj A in LabVIEW 20xx for Win and proj B in LabVIEW 20yy for RT etc....) and you still need SCC for the source and packages.

[andrewDJ]

I used to use SVN at work (TortoiseSVN) but I'm happy with Git and GitHub now.

The Project Managers and others who purported to be non-technical used to drive me mad with SVN!!  Every change to a document or file had the date appended to the filename so they knew when something had changed 😣  Couldn't tell them otherwise!  Project repositories were MASSIVE.

[wiebe@CARYA]

Old school LabVIEW style did that too: Main V1.vi, etc. Imagine the hell when all type defs where kept, and of course some where not replaced. 

[Yamaeda]

---

@andrewDJ wrote:

Every change to a document or file had the date appended to the filename so they knew when something had changed 😣  Couldn't tell them otherwise!  

---

LOL! That's not a problem with SVN though, you'll get the same issue in Git, Clearcase or version database of choice.