LabVIEW Notes



MasTec LabVIEW Notes

March 2017 Summary of all Four Books to date

  LabVIEW Books   
Four Short PDF Books
How to program more effectively
with LCOP LabVIEW

Book 1 "Hidden Data" That is, cleaning up LV Program's by Removing Constants from Diagrams and putting them in Configuration Files for Loading at runtime.

This method does not use ini files but a far more robust LabVIEW centric method, not seen in other literature. It also cleans up Diagrams and Self Documents.

Book 2 "Abstraction" That is, removing complexity in the top layer of a LabVIEW diagram by building Abstracted Message Driven LV Components.

This shows how to build Message driven (Test Verbs) Abstracted named (noun) State Engine Components that are safe & robust. It also leads to better cohension of course and no/low coupling.

Book 3 "Real Time Cluster Constants Editor" That is, Removed Diagram Constants that are loaded at Run Time from a config file, can now be edited, in situ, inside the Program /or its Component while it runs, allowing tuning of programs in Real Time.

Book 4 "Low Frequency Real Time Control", About how to use USB DAQ, DIO and DAC to control a Hydraulic RAM for Testing a UUT.It is a close look at how to use a State Engine for Control.

These books use LCOP methods which simplify and establish design development plus stabilise your programs. It even make installs easier. Updating and expanding programs then follows a standard pattern already in the program design.

Also these Books delineates Public and Private data clearly. This is critical for Component Design and for low coupling and best Cohension.

To get your copy, send this email request to the MasTec LabVIEW Develop Laboratory

 

Feb 2107

Book 4 Feb 28 2017

Book 4 "Low Frequency Real Time Control"

About how to use USB DAQ, DIO and DAC to control a Hydraulic RAM for Testing a UUT.

It is a close look at how to use State Engine for Control.

In Control systems, loop time is critical and this is discussed in the book.

Methods to reduce loop time are shown in the State engine strategy.

Again, this book removes Constants from the program and loads them from file at run time.

Simple but useful for anyone wanting to do closed loop control.

It embodies many of the LCOP methods discussed in the other three books.

It shows how to build a verb controlled VI for DO control using an Enum Type Def. Simple but improves readability and documents.

It whos how to be detailed in State Engine design but not verbose.

 

 

Jan 2107

Book 3 Jan 2017

Book 3 "Real Time Cluster Constants Editor"

That is, Removed Diagram Constants that are loaded at Run Time from a config file, can now be edited, in situ, inside the Program /or its Component while it runs, allowing tuning of programs in Real Time.

Changes to the Constants can also be saved back into their original configuration files at run time.

This addition of the Real Time Editor removes the need to exit a component or program to edit constants.

The Application Editor show in the Book 1 is diferent than this editor.

The App Editor allows access to all Private and Public Constant Data.

This Run Eime Editor is just for Private Constant Data in the Component running.

MasTec LabVIEW Notes

Oct 2016

Two Free LabVIEW Books

"Two Methods to program more effectively in LabVIEW"

A little more info for the Hidden Data Method.

Once you have built a program using this method, if at any point you want to add or delete constants to any of your components cluster constants, maybe just add one more constant or truly expand the calibration to include a whole new sensor set or add more paths etc, just expand the type def for the constant data clusters and make the new entries. These entries can be any data type or grahical data type. Once this new type def cluster is saved, it will automatically appear in the Constant Data Editor TAB Selector . Enter your new data into the new constants and the editor will save this new set of constants for that cluster that has been expanded.

So only one diagram programming step adjusting the Type Def Cluster constant.

Next time you re/start the program, the expanded cluster with the new data will automatically appear in the section of your program. The wire from the file read and unflatten from string section will now contain the new constants.

You do not have to add or change anything in the diagram to make this happen. The program automatically knows the shape and structure of the new cluster loaded via the cluster local variable that will have expanded to include the new constants and this gives the shape to the file read and unflatten from string module.

So with no more programming work in the diagram you have a wire with your new constant cluster.

What this means is the software reads the data from the disk file and unflattens the data into the new cluster wires automatically.

You can then go through your prrogram and pop terminals off these wires for the new cluster constants.

Don't believe it, try it??!! Automatic expansion without programming anything.

It is quite a surprise the first time and very quick changes are possible.

And of course the same is true if you delete from the constant cluster.

 

Oct 2016

a new LabVIEW Book is coming.

Just to give a heads up on the next bit of work under way.

What would be very nice to have is a mini real time editor in each component for its cluster constants that are on file.

This will be released at some point soon.

Then you will not have to bounce out of your programming and testing work when a constant needs adjusting by going to the editor and jump back into the progrm and rerun.

This is very helpful when doing real time tuning of loops espaecially control loops like PIDs etc.

Having it in real time is even more useful.

Nov 2016 >>>The Full Book Set announcement

Three LabVIEW Books
"Three Methods to program
more effectively in LabVIEW"

Book 1 "Hidden Data", that is, cleaning up LV Program's by Removing Constants from Diagrams and putting them in Configuration Files for Loading at runtime.

This method does not use ini files but a far more robust LabVIEW centric method not seen in other literature. It also cleans up Diagrams and Self Documents.

Book 2 "Abstraction", that is, removing complexity in the top layer of a LabVIEW diagram by building Abstracted Message Driven LV Components.

This shows how to build Message driven (Test Verbs) Abstracted named (noun) Components that are safe & robust. It also leads to better cohension of course and no/low coupling.

These two books are expansive, yet simple and this information is not often seen in other LabVIEW information.

Using these methods will simplify design and development plus stabilise your programs and it even make installs easier. Updating and expanding then follows a standard pattern already in the program design.

 

 Also these methods delineates Public and Private data clearly. Private data is not available outside its component. Public data is available to all.

Here is a piece of information about the method that is quite amazing.

Once you have built a program using the LCOP method shown in these two books, if at any point you want to add or delete constants to any of your components cluster constants, maybe just add one more constant or truly expand the calibration to include a whole new sensor set or add more paths etc, just expand the type def for the constant data clusters and make the new entries. These entries can be any data type or grahical data type. Once this new type def cluster is saved, it will automatically appear in the Constant Data Editor TAB Selector . Enter your new data into the new constants and the editor will save this new set of constants for that cluster that has been expanded.

So only one diagram programming step adjusting the Type Def Cluster constant is required for this step.

Here is the amazing part,next time you re/start the program, the expanded cluster with the new data will automatically appear in the load section of your program. The wire from the file read and unflatten from string section will now contain the new constants automatically.

You do not have to add or change anything in the diagram to make this happen. The program automatically knows the shape and structure of the new cluster loaded via the cluster local variable that will have expanded to include the new constants and this gives the shape to the file read and unflatten from string module.

Third Book

Book 3 "Real Time Cluster Constants Editor", that is, Removed Diagram Constants that are loaded at Run Time from a config file, can now be edited, in situ, inside the Program /or its Component while it runs, allowing tuning of programs in Real Time.

Changes to the Constants can also be saved back into their original configuration files at run time.

This addition of the Real Time Editor removes the need to exit a compoent or program to edit constants.

There may yet be more to say.

To get your copy, send this email request to the MasTec LabVIEW Develop Laboratory in Northland NZ.


MasTec LabVIEW Notes

December 2015

This month and for the next 5- 6 months I will be showing a method, when building in LCOP (simple Objects) how to remove and hid constant data.

The final end story will be a simple system to remove and hid constants in files, plus a recall system to allow editing.

I used the methods in the book ." A Software Engineering Approach to LabVIEW" for several years. I always felt it was an akward fit to LabVIEW.

Here is a another way that takes less work and also more LabVIEW focused. ( allows Graphical hybrid Constants rather than just simple text, numbers or booleans)

When programming it is very easy and convenient to drop constants everywhere in a diagram, so as to get the job done. Oh I need to divide by 6 here, pop and there is the 6. However they all eventually need to be removed from the program diagram. This does several things, tidies up the diagram, it will document your constants, and it allows external configuring of the program before and during runtime ( if you have a method to inject into your program at runtime which is quite easy.)

My method for development still uses the traditional old LabVIEW way or dropping constants on the diagram but then a clean up technique for the constants that then translates them into something much more useable.

This method is not new, we have all been doing this from the beginning of LV. (However this is a focused process to convert programs into having hidden constants on file.)

Actually I use it for more than just constants. ( Any data that is semi constant, like Paths, DAQ, GPIB, Serial configuration etc can use this method. )

I do not like rules as such, a book full of method and style rules is extremely boring and cumbersome.

So please don't regard this method as authoritive but experiment and report back if you have more to add or delete, to make it easier or better ??

The Method ( I will add picts a little later)

To get started cleaning up diagrams of constants.

1/ So carry on building programs using constants and when you have finished that VI do this

2/ Drop a constant cluster onto the diagram and ctrl drag all the constants used into the cluster. (This leaves in place the original constant so you know where to wire to later when you remove it.)

3/ Name the constants in the constant cluster meaningfully.

4/ Then drag the constant cluster on to the front panel for translation into a control cluster.

5/ Go back to the diagram and find the control cluster terminal and pop out the named unbundle terminals for each of the constants.

6/ Now just wire in the unbundle terminals to the replace the constants. ( Don't delete the constants as you wire up the new method, leave them in lace and you will have a bunch of broken wires. Then just delete the old constants and the wires clear of error as you go along.)

No More Constants.

Next installment I will show how to use this to build a method to take this data out of the program and put it on file.

In the mean time to keep that VI working, make all the old constant data in the Control Cluster the defaults and you can still use the VI OK ( don't forget to save.)

(My feeling is that the Book method ." A Software Engineering Approach to LabVIEW", was more suited to code programs. I think inis are only useful for what they were designed for and that is not storing LV graphical constants.)

To be a true LabVIEW method, the constant removal system must allow any data type and structure in a mix. (The old way didn't and the new way does.)

Also do you notice that suddenly your program is much documented and readable. (Unbundle by mname does this always.)

That is a big step and you don't need to type in a lot of info to make it so, just do the cluster thing and named unbundles properly.

You will have done this many times before so it is not new, however this is deliberately made to remove constants and to hid this data off program.

So now your constants of any type and form can be in a structure all mixed together. This is so much better for boolean, slides, enums, ring, and all those other constants/controls that are hybrids that contain graphical properties and are not just boolean, numeric, string or arrays. ( code program stuff )

As we progress you will see that there is a big win at the end point where the operator wants to change constants for the program.

By allowing the operator to see all the constants ( as controls) in their graphical form is a big step and improvement. ( a nice simple Constant editor can be built to do this )

All the Controls presented in the Editor to allow changes to constants are Named, with each Control cluster being named for the VI they are used in, + a hierarchy of sub VI constants etc.

Next column will explain this further.

 

First just practice removing Constants into Control Clusters.

 

January 2016

Continuing on with the MasTec Constant Removal System (MCRS) developed in a few programs at MasTec back in the late 1990s but not realised as a programming method until recently.

By the way, this information does not in any way indicate that the book " A Software Engineering Approach to LabVIEW" is not worthy of being a reference book for you on LCOP. It is a very important book and will teach you a heap of important design lessons.

However, the only area I found issue with in this book, was the use of ini files for constant removals as it is so limiting and doesn't hold to good LabVIEW practice or design.

So continuing on then after that preamble.

Most of the programs I build are DAQ based, now using USB DAQ boxes. It use to be PCI DAQ boards and before that ISA DAQ boards and in the 1980/90s a lot of GPIB and Serial DAQ. It doesn't matter much what way you are doing DAQ, this method still applies.

Looking over my programs from the past I noted in all of them there are a lot of what I would call Public or Global Constants.

For instance DAQ device Addresses, Port numberss, Channel Numbers, Acquistion rates, etc etc. This information is used repeatedly through out the program as public data and it seemed after some thought to make these constants separate and call them Public Constants, distinct from the more private constants inside Sub VIs and/or Components that the rest of the program doesn't know about. Important for coupling issues.

The reason to make them Public Constants is because almost all high Level Sub VIS use this data to run. Making them Public lets the constant data bounce through the program, usually stored on a shift register on the edge of a loop acting as an Event engine or as a State engine. Loading the public constants at run time and they stay on the SR for the duration of the operation of the program.

This observation is put in here so you can see sometimes it is a good idea to divide up the Constants into famillies, Public and Private

Another good example: I use devices like VSDs, Servos, Pumps etc and these devices need a variety of constants to connect ot the program correctly. These constants are also public not private.

VSDs, Servos Pumps etc are often controlled with 0-10VDC DAC signals.

A Technical Help Idea here: I always and forever, put an analog isolator module between the DAC and the VSD, Servo, Pump etc to safe guard the integrity of the DAC modules output. Ground loops, RF and electostatic noise can blow a DAC very easy.

These controllable devices always require calibration coefficients to convert the 0-10VDC into 0-120HZ, 0-90 degrees or 0 to max flow etc.

These calibration coeficients are also public data and again can be loaded at runtime and put on a SR on the same while loop event or state engine to be called on by all Sub VIs, Components that need that detail.

So consider your programs, make famillies of constants public and private. I always separate DAQ constant from Devices constants but there are no rules, just make up your own as you go. Often you can cluster all the devices together in a cluster called Device,s another called DAQ.

Do the same cluster familly idea for File Paths and also for Calibration data for Gauges Sensors and Transducers.

You will know what is best for you, and if you get it wrong, it doesn't matter you can evolve as you go along.

It is often shown in LabVIEW discussion notes, a while loop with a dozen SRs carrying specific public data of some sort. You can probably take that dozen and reduce it to 3 or 4 SRs just by bundling. It tidies the diagrams up considerably.

Again have a look at your programs and see there are several types of constants. Global or Public, Private, Fluid, Hard Code and variable fixed are some of the names I have come up with. You can name yours also as each programmer is making magic their way.

I have also come to the conclusion that some constants, I call them hard coded, do not need to be removed from the diagrams but left in and compiled into the program. These are usually mathematical formulas that are locked down, or similiar. You will know not to mess with them and to leave them in the program as hard code.

This may not be the puriest ideal but who really decides, you do, as the expert in your program.

However be prepared to evolve your practice, it is good for you and your programs will slowly take on a new and fresh look.

So how did you get on with practicing removing constants from last month?

Did you run into some of the ideas above, I am sure you did and it is a bit of head scratch how to manage these issues inside programs. There are very few LabVIEW books addressing it.

So here is the nub of the idea behind MCRS that came up in the late 90s.

You are actually making a secondary front panel of controls that represent the constants by using this MCRS and then unbundling with names that cluster's control terminal and putting the constants back into the diagrams documented and named. A neater and better design results.

Another old LabVIEW trick to hold all the Cluster Controls data as defaults is to click on the Operate Menu and choose Make current values defaults and then save that VI. The control cluster values that were the constants are now locked as defaults on load time of that VI.

I am sure you know this but I put it in for the newer programmers to know about also.

So that is it for this month. Just a little prelim info on what will come over the next few months. It may actually tke a year to do all the parts so far developed.

I look forward to hearing from anyone, either in discussion or for help. Send your mail to Rob Maskell. Go to contacts and send me a mail.

 

February 2016

As you will read in the upcoming March Newsletter, a decision has been made to conv er the whole thing into a rough book and release in March as a PDF.

Approx 70 pages of notes and screen shots plus a few other little additions.

March 2016


email request

If you have been following the MasTec LabVIEW Notes recently, you will have been reading about the new method developed at MasTec for "Removing Constants" from Programs.

We were going to release the notes over a 6 month period as stated in the Februray notes, but due to significant interest we have decided to release all in one PDF.

This is a 70+ page document/book with a load of Panel and Diagram screen shots and and tutorial text that outlines "Removing Constants" from programs and around the method develops a complete "Program Design Method"

There book also includes a little on the Author's 60 year technology background and how these new LabVIEW ideas were evolved etc.

It is simple but comprehsive, maybe even interesting!

To get your copy, send an email request to our LabVIEW Develop Laboratory in Northland.

This is for all users from beginners to Advanced.

It sorts a few points that haven't been addressed overly.

June 2016

Cohension, Coupling, Abstraction and Data Hiding.

Important words for any programmer.

Build High Cohension VIs only - In other words focus on what the VI is attempting to do and just make the VI do that, nothing else.

Build Low Coupling VIs - In other words do not have the same configuration data in different VIs so they cross couple. Make Public Data constant across all VIs and keep Private Data inside each VI with no leakage out of that VI.

Abstraction - In other words move away from details as you build VI wrappers for each level of VI. That is take IO level VIs and wrap them with another VI that moves them to function verbs like Power On, Power Off, Servo 30 degrees Servo 0 degrees.

Data Hiding - Almost never discussed. Take all your constants out of your programs and make them into control clusters that load and run time. You can then unbundle these control clusters make into the constants using named Unbundling. This tidies up a diagram very well.

Complete with a Hidden Data - Hidden Constants Editor to allow all your data to be controlled out side your programs in files.

Done - a better design and better diagram and an easy way to update a program with out recoding.

Sept 2016

Two Free LabVIEW Books

"Two Methods to program more effectively in LabVIEW"

Book 1 "Hidden Data", that is, cleaning up LV Program's by Removing Constants from Diagrams and putting them in Configuration Files for Loading at runtime.

This method does not use ini files but a far more robust LabVIEW centric method not seen in other literature.

It cleans up Diagrams and also self documents.

Book 2 "Abstraction", that is, removing complexity in the top layer of a LabVIEW diagram by building Abstracted Message Driven LV Components.

This shows how to build Message driven (Test Verbs) Abstracted Components that are safe and robust.

It also leads to better cohension of course and no/low coupling.

Both books are expansive, yet simple and this information is not often seen in other LabVIEW information.

Using these methods will simplify design and development plus stabilise your programs and it even make installs easier.

Updating and expanding then follows a standard pattern already in the program design.

These methods delineate Public and Private data clearly.

To get your copy, send this email request to the MasTec LabVIEW Develop Laboratory in Northland NZ.

Our instructor will also cone to your site and do training with your LabVIEW team using these new methods.

Thismethod is a big step up for development work.

It makes ini files look like dynasaurs. Don't use inis.

This method is usable even if you are a non LCOP program of course and applies to any method.

However it takes you one step closer to OOPs woithout all the OOPs grude + Straight Jacket) and high memory and low performance.


MasTec LabVIEW Notes

February 2013

This month we look at MCC's LabVIEW .net based DAQ library called ULx for LabVIEW.

It is quite a smart piece of work. You will know this as soon as you start playing or watch the video.

It runs in LabVIEW 8.5 to 2012, best on Windows XP (32 and 64 bits) SP2, Vista, 7 and 8 machines.

To start to play and learn, just go straight to the Examples that are embedded in LabVIEW directly.

These Examples will form the framework for almost anything you want to do with any MCC device. Just cut and paste the examples and modify.

If you are a fan of the Blume LabVIEW Styles book, you will instantly feel at home with this software.

It builds consistent polymorphic error propogated VIs running in Tasks. The Errors have a good database hung off them also, not just errors, but ways to solve the errors.

If you use LabVIEW waveform data types you will aslo feel at home as the polymorphic ULx VIs also allow making of LV Waveform data types.

Instead of multiple single controls to manage DAQ, everything is included in one Control Cluster. Very clean and efficient. Enumerated Type Defs rule the day throughout the library.

Video Using ULx Demo
PDF Getting Started with ULx
PDF Specs for ULx

Free Download of the ULx Library and a heap more

Now a little on the Older MCC LV UL library.

I imagine there are many LabVIEW programmers out there that get Legacy code thrown at them regularly for upgrades and expansion etc.

SWS has also been doing quite a bit of work using legacy code upgrades recently. In many cases the work to lift from say LabVIEW 5/6/7 to 2012 is not warranted.

SWS lifts to LabVIEW 7.1 and occassionally LV 8.2 for legacy systems but the changes after this are often so great that it is better almost to rewrite the software in the new version, cutting and pasting as you go.

For thoise still working in the old MCC LV UL library SWS has made wrappers for several of the DAQ VIs that make them a little more modern in appearance and use.

The wrappers construct a true LabVIEW error cluster and all the controls are in one Control Cluster .

Anyone interested to see how this is done please email

SWS will gladly share this with any user. It transforms the old library into something much friendlier.

March 2013

LabVIEW 2012

MasTec's Programmer has been using LabVIEW for over 26 years now. Our.collection of LabVIEW versions extend from LabVIEW 0.9Beta of 1986 right through to the LV 2012.

We stayed with 6.1 and 7.1 for many years waiting for a definitive New Open LabVIEW to appear.

LabVIEW 2012 may be that version that is really worth while upgrading to and or starting to use.

LabVIEW 2012 New Features at a Glance link.

Self-Paced Online Training if you buy LV with SSP
Enhanced Stability
Mobile Apps - very important
FPGA Enhancements - very expensive
New Analysis Tools - Super
System Simulation - Great
Productivity Enhancements - Very useful
Ecosystem Improvements - more to come
Data Management Enhancements

If you are a fan of the Blume Book on LabVIEW Style, you will find that 2012 has style templates and sample projects that will get you building better styled and documented applications.

So have a look, it may be a good time to start using LV 2012, as it is a professional tool for building almost any type of application or library, from simple to extremely complex.

The work between LV 8 2006 until 2012, has been largely on Professional Development, Rapid Starts with Templates and Project samples, and to bring OOP to LabVIEW development. This maybe a good or bad thing depending on viewpoint but one thing is certain OOP ability is still expanding.

There was also a large push to get Real Time LV running well on FPGAs. This is now maturing. With LV 2012 Embedding tools these may become less important as it is going to be very nice to put LabVIEW on a great variety of small mobile ATOM platforms with Windows 8.

Most programmers only use 5-10% of LabVIEW, much like Excel and Word. It is a vast piece of software and it takes years to get fully conversant.

LabVIEW 2012 was beta for some time and released in Aug 7, 2012. We received our copy in late Sept 2012 and have been playing and developing. Any updates are automatic and seemless. It seems very stable.

Our first job was lifting legacy code and it was a challenge considering most of it was LV 5. The way through was to go to 7.1 then 8.2 then jump to LV 2012. Not everything is clean as you would expect but in most cases was 99% and easily patched into operation.

How can MasTec Help

MasTec would like to talk to any company thinking of starting to use LabVIEW as their main software tool to help in training or at least consulting on the first few projects undertaken.

More for March 2013

OOPs versus LCOP or Ols Style Straight Dataflow

For those not too interested in OOPs LabVIEW , MasTec has just released a series of LCOP examples to introduce this concept to programmers.

LCOP requires a little more planning and design work, like choosing nouns and verbs to make components and messages but it gets directly to the heart of coding correctly.

LCOP - LabVIEW Component Orientated Programming or LCOD - LV Object Design

If you have an interest in

  • Increasing Cohension in VIs
  • Reducing Coupling between VIs
  • Data Hiding in VIs
  • Greater Abstraction

in your programming send us an email.

We will respond with a few examples of LCOP and also some wrapper methods to show how to clean up old legacy code.

For LabVIEW hardware, we have everything from National Instruments range through our vast array of technology. MCC and others are a very good alternative to NI DAQ systems. Almost all our instruments link to LV with Drivers, eithe rUSB, Serial or GPIB, even some LXI or VXI, or even PXI.

Ask our engineers to help you find the lowest cost system to meet your needs. Contact

 

April 2013

LCOP example set

I have moved all this original LCOP demo work into one simple DAQ example.

There are several levels of components made to access any MCC Digital Port either as an Input or anOutput Port.

++ included for comparison same work showing

Old Style LabVIEW
Error Wrapper LV
LCOP examples
Translator Component
True Component

LabVIEW Development Course or Consulting

We are thinking of developing an informal Course

LCOP - LV Component Orientated Programming
LCOD - LV Component Orientated Design

This brings to your programs.

  • Increasing Cohension in VIs
  • Reducing Coupling between VIs
  • Data Hiding in VIs
  • Greater Abstraction
  • Better design
  • Useability
  • Easier documentation
  • Easier trouble shootin
  • Easier upgrade or expansion later

The reason for the course. and or consulting

We have a feeling that many sites using LabVIEW and there are hundreds in NZ and Australia, maybe thousands, are not getting the best from the product.

After years of development work in LabVIEW, we thought we had a good method and in comparing our work with the LCOP method, we found we were quite close but needed to smarten up a little. We are working on LCOP right now to clean up legacy code on several of our sites.

Common Problems: - Just like in Novopay, many software projects when they get close to the end of development suddenly become very hard and stubborn to complete properly. Even when using excellent tools like LabVIEW, Code OOPs or others.

We get to look at quite a bit of code from other programmers. We sometimes get called in to clean up code or complete a difficult project. We see these common causes often.

  • Loose Cohension in VIs
  • Cross Coupling between VIs
  • Most Data in public view
  • Low abstraction
  • Flat designs
  • Poor designs
  • Over use of Globals
  • Little understanding of Type Devs
  • Haphazrd inilisation.
  • No internal documentation

Some companies feel adding OOP will fix this poor outcome. Unless it is done well it can make it worse.

Adding OOPs to LabVIEW is over kill for most small and medium size projects .

To start the ball rolling on this design work, it may require just a short talk about this LCOP development technique, and some simple development demonsrations. This may be enough to introduce the culture change required to improve outcomes.

We are interested to discuss this with any manager, programmers or development teams. Interest

More for Jan 2014

LabVIEW Tip for the month- Using Type Defs

We will leave LCOP for a while.

From the beginning, when developing in LV use Type Defs

1/  Complex Cluster data structures you build.
2/  Enumerated Types for Case control
3/  Clusters for file pathways for init work
4/  DAQ, IEEE, Serial control clusters
5/  Error and any Data Structures
6/ When build Components use Type Defs for each Component state. This then acts as the message or verbs for the states or nouns.

Any Data structure that has a habit of changing with development or as a consequence of design roll over during projects, are best as Tyoe Defs.

It will save a load of re-development work with you start building Type Defs early.

 

Feb 2014

LabVIEW Tip for the month-

Using Type Defs
More on Abstraction

When building Type Defs for case control, LCOD Component's States, Data Structures etc almost always use Enumerated Data Controls and Indicators.

Enumerated Controls allow several nice operations on then to recover enumerated text from the control specifically or build lists in reverse or check to see if that particular text does exist in the enumerator for error checking etc. Also use them to build specific file names etc.

The only time enumerators are not used is when you want ot build a verb translator from one Enumeration verb list to a renamed verb list to obtain greater Abstraction.

For Example :

You have built a very nice DIO LCOD abstracted VI and the Enumerator Control for the DIO contains verbs such as Config Port, Set 0, Set 1 etc, Reste 0 Reset 1 etc and you want to drive this same DIO Component with another verb list such as Configure Motor Controller, Start Motor 0, Start Motor 1 etc Stop Motor 0, Stop Motor 1 etc.

In other words a verb translation to a higher level of Abstraction.

Build a Sub Vi, Clone the original Compont DIO LCOP enumerator Type def to the Front panel of the Translator SubVi, Open this Type def and replace the Enumerator with a Ring Control, and then relist it with the new verbs, Configure Motor Controller, Start Motor 0, Start Motor 1 etc Stop Motor 0, Stop Motor 1 etc.

The Sub VI output indicator can have the original DIO LCOP verbs on a Ring Indicator.

Now wire the control directly to the indicator with nothing in between,

You can now embed the Verb translator in a wrapper with the Component DIO VI and drive the new abstracted DIO VI directly with the new verbs.

That is one very quick way to Abstract.

Note:- if you use Enumerators in the Translator you will get errors as the strings for the enumerators do not match.

More next month on Abstraction.

More for March 2014

LabVIEW Tip for the month-

More on Abstraction

Note the example in Feb 2014 was actually not making a true Component with new messages or verbs but a forced translator.

To build a true component, it is necessary to build a new State enegine that acts as the Component Wrapper.

The enumerator that will act as the message or verb set will now not only have the actions required like motor on, motor off etc, but a complete Initialise, error and exit section so the component is managed as a private encapsulated VI set.

In the translator you will still have the other actions the DIO ports can perform, such as Set 3 set 4 etc and reset 3 reset 4 etc.

This makes that type of component dangerous as it really has undefined actions.

A true component can only do what is required of it and the enumerator messages only allow that. In fact if any other message is attemped either above or below the enumerator numerical values, errors will be thrown up.

This dose mean that then component can now be complex in nature and allows each state to perfom more than one thing.

eg You want to turn on Motor 1. However to do this first requires the state to test to see if the power relay is closed, the voltage level is correct and then the motor can be turned on.

This can all be placed in the Motor 1 On State, with the logic, error trapping and maybe timing required.

This means that if the message is selected Motor 1 On, the component does this and looks after all of the process in a private matter.

This is true abstraction to higher levels, with nouns and verbs leading the way.

If any constants are embedded in this component they all come off the disk ini file from Section and Key, which allows easy changes to program functionality in the ini file.

December 2014 MCC Bluetooth DAQ BTH-1209LS

This is a great bargain for anyone needing a low cost General Purpose DAQ unit.

It can be prgrommed directly in LabVIEW using ULx for LV.

However for this discussion we are looking at Android App use.

It has a built in Battery Caddy for two niMH AA Cells. It also has a USB port that can have a USB Power Supply connected or it can be directly connected to a PC USB port.

When run on Batteries or a USB Power Supply, it is a remote DAQ unit and can be connected to via a Bluetooth Link. Range is 10 meters.

When directly connected to a USB port in a PC, it is a teethered standard DAQ Unit, similar to the USB-1208LS.

MCC have made a series of downloadable Android Apps ( In Google Play ) that connect the BTH-1208LS via Bluetooth to a Tablet or a Smart Phone. Downloading the Apps is very quick and simple.

One App is a Multi Channel Logger which stores data in a CSV file on the Android device and also allows emailing the CSV data file after collection.

Another App allows Analog input scanning at rates up to 1KHZ and graphing the data as it is collected in the Android App.

All of the above only takes a few minutes to get running and can be put to use for tasks readily, without programming.

MCC also has excellent development tools for building Apps in Andorid, using the MCC UL for Android library with Java.

It even comes wit two Ni-MH batteries for the remote Bluetooth setup.

A great product in every way.

Nov 2015 A Better Method for Removing Constants.

Just to complete the 2015 year, I would like to discuss more details about LCOP. I went to sleep on this notes page about LCOP it seems about Dec 2014.

I ran into an issue with the LCOP method advocated in the book " A Software Engineering Approach to LabVIEW". I like what the book says about design, I have always been a fan of this type of programming going right back to 1997 with LV .9 Beta when I first got it.

However, I came to a realisation about one of the sections in the book, Hidden Data, or removing constants from programs. I am going to dedicate a full page to this over the next few months.


  © MasTec Ltd