LabVIEW
Reusable Code in LV.
Not much to add from Ben's response. But if you want good examples of reuse code, look at OpenG and MGI toolkits (free on the LabVIEW Tools Network).
But what I end up doing a lot is making libraries of code that accommodate a very specific thing. For example, I have a library specifically for communicating with devices that use SPCI. I have reused that library many many times for different instruments I have had to interface with just in the last year. Trying to keep things generic is hard sometimes, but the reuse is worth it. Just plan far ahead when you go down this path.
@crossrulz wrote:
Not much to add from Ben's response. But if you want good examples of reuse code, look at OpenG and MGI toolkits (free on the LabVIEW Tools Network).
But what I end up doing a lot is making libraries of code that accommodate a very specific thing. For example, I have a library specifically for communicating with devices that use SPCI. I have reused that library many many times for different instruments I have had to interface with just in the last year. Trying to keep things generic is hard sometimes, but the reuse is worth it. Just plan far ahead when you go down this path.
I design even the little engineering tools I make with scalability and re-usability in mind because I've never known an engineering tool to stay an engineering tool for long. (Or maybe it's just me, because my tools are so easy to use and build on that everyone wants to integrate it into their projects as a full-blown module.)
@LV_COder wrote:
Thanks,
It means that all the LabVIEW design pattern and architecture comes in the definition of Resuable code?
If the code follow basic guidelines like low coupling, maintable, scaleable reabable then it's easy to reuse this type of code?
Hemant
I think you are over complicating this, reusable code means just that, code that can be reused...
Here is a very simplified example. I have a program that monitors a grid tied solar inverter. I graph the amount of power bought and sold, array power, solar irradiation, battery charge voltage and current... etc...
Anyway I need to clear and reset my graphs X-Axis to the next day, every night at midnight.
No problem, setting the X-axis to display time from Midnight to Midnight just takes this.
But wait... I need to do that everyday at midnight, and when the program is started, also I need to reset eight different graphs X-axis the same way... and I might want to do this again someday...
That's where reusable code comes in, I make this a Sub-VI and put it in my User.lib directory.
Now whenever I need to set an X/Y chart axis from Midnight to Midnight I can just drop in this VI.
Over time you will find yourself writing little routines that do the same thing over and over again. Eventually it will dawn on you to make these into a Sub-VI and save it in your User.Lib directory so you can use it again next time without having to reinvent the wheel.
I will offer these two images to try to illustrate what I think is considered highly cohesive.
This image shows the high-level relationship of software to the hardware used in a wind-tunnel application.
This image show the VI-hierarchy of the LV code.
If someone knows the physical system they can understand the software version.
The DAQ Engine shown in that image has been in development for many years now and was recently deployed to support 300 I/O points spread across (4) cDAQ chassis.
Ben
