 LabVIEW Notes  |
|
November 2019 :-- Multi Distributed Modbus IO MasTec has developed a Method to connect or disconnect multiple Modbus Distributed IO Modules running on POE TCP Modbus. This does mean you can take out of service a failed Distributed IO Unit and Start in a replacement Distributed IO Unit with the flick of a switch on a Dash Board. This Dash Board can be live or called up from Disk. The Dash Boards allowing this are Alive and/or stored on Disk and called when required. Each Dash Board resides in a TAB in a Master TAB. |
November 2019 :-- Virtual IO System MasTec has developed a method for their Modbus TCP Distributed IO System to make any Application run with Real IO or Virtual IO. This is very useful when Programming and the only thing being worked on is look and feel. Also good for demos when IO won't run properly in Demos for you. Does happen yes or No >> Yes always. |
November 2019 :-- Adding Raw data into " Check or Test " sections of an Application. MasTec has developed a rule, yes a rule haha, on What to call Data IO VIs. Raw Data are called RU = Raw Units -- can be counts from ADC or DAC or Bit States On Off etc Calibrated Real Data are called EU = Engineering Units can be mm, Pascals, Kgs, Power On, Power Off or some meaningful data. In Check or Test Applettes, place the RU units on the one of the FP TABs also, so you can see what the IO is actually doing. The Operators won't look at those TABs but you can if you have to visit or Teamveiwer In. |
|
September 2019 :-- LCOD Cluster Constant Editor MasTec has developed a new method that allows the LCOD Cluster Constant Editor to resides as a SubVI in an App. This does mean it can be dropped into any application easily and modified (It is Type Defs) In the developed of the new method for the Editor a new Framework was also developed for building LCOD Apps. The Editor SubVI is feed all Public Cluster Data via several wires that reside on SRs. |
September 2019 :-- Commissioning Tools MasTec has developed a new Commissioning Tool set that resides as a SubVI in an App. Consists of a Several Tools 12 to 48 channel
DVM This allows Commissioning Engineers to cheack each channel as installation takes place. |
September 2019 :-- New Framework MasTec has developed a new LCOD Framework that only has SubVIs in any App, so very clean. The Framework is a State Engine fthat Configures Front Panels, Pre Sets IO and Loads up the Application Public Data at run time. In the "Last State" an Eventing Frame maps the Apps Function Selection Buttons to the SubVI that can pop a Front Panel for a specific function. This simple Framework has Public Data on SRs that feed all the Sub VIs requiring this Data. Public Data are all clusters loaded at Runtime and are typically ADC, DAC, DIO, Paths, Control, Master App data and also Public Cal Data. |
|
August 2019 :-- Windows 10 Info MasTec has been trialling various products in Windows 10. Some very good news for some LabVIEW people like me that use LV 7.1.1, yes it will run in Windows 10 well with no issues that we have seen. The only issues. National Instruments LV 7.1.1 DAQ and GPIB drivers will not run in Windows 10 LabVIEW 7.1.1 by it self works flawlessly |
MCC DAQ drivers in Windows 10 We know that MCC instacal works fine, it is desiged to, so no issues. The ULx DAQ drivers will run in Windows 10 but not with LabVIEW 7.1.1 However, the original ULLV drivers and VI libraries run faultlessly in Windows 10. wow So this is amazing news for LabVIEW 7.1.1 users. LabVIEW 7.1.1 is still the best LabVIEW it seems. |
Some Info on what we are able to do in Windows 10 One of our applications uses MCC USB DAQ, also several LabJack TCP Modbus and an RS-485 comms link off a USB to RS-485 converter from Adlink. So quite a brew of stuff. It was lifted out of Windows 7 as an application and dump in a Win 10 computer and it ran just like the Win 7 system application. So try this out. MCC's ULLV drivers and VIs are great for real time systems where you need single pt reads with out a lot of fuss. |
|
Oct 2018 :-- LCOP Additional MasTec has recently started naming the Cluster Constants in TABs as Settings This Is to make it clear what these values are, truly App settings. This is a better choice of wording. Naming is everything. |
Oct 2018 :-- LCOP Additional MasTec has recently started using State MAchines driven by Button Events to make sequential Calibration LCOP Objects The reason for this addition to all its new Apps and some older Legacy work is due to a review of On Line Help given over the last 3 years to sites. 50% of all calls are to correct calibration values. |
What we have had for 30 years: If you offer an open ended Calibration App that has the ability to do both offset and gain on one page, assuming users will know it is aways offset first and then gain, you will have many un needed calls as we have. So force Calibration methods using a State Machine Sequencer that does Offset first and then Gain. This will make for quiet phones and emails. |
|
July 2018 :-- LCOP Site Review MasTec has recently reviewed a site with an LCOP Cluster Constant File System. This work was undetaken by a mid level programmer. After the review it was decided to take the program a step or two back in LCOP design. The revert that was decided on, was back to one level lower than the file cluster constant method and use Front Panel TABS to store the Cluster Constants in and make these values in the Cluster Constants as the Defaulted Variables for the program. They are hidden in the TABs. |
This simpler design still acheived the LCOP four major design criteria Hidden Data Abstraction Cohension Coupling. |
July 2018 :-- LCOP New Design Method The Review exposed two short comings. The first was the editor design used for the hidden data constants was not complete and was stilll evolving as the program expanded. This produced instability and a lot of time was being used to move the editor design along successfully. The new design only took a little time to implement and development proceeded much quickly. MasTec now recommends after this site review to develop all LCOP application in this simpler method and then when complete build the editor in one pass to make configuration file if required. |
|
Jan-May 2018 MasTec has just released and commissioned its first Modbus TCP Test application for Window walls facades and doors using the new LabJack T7 DAQ unit. This T7 Unit was selected as it has all the Hardware and Expansion features required for the Tests and comes with a large LabVIEW library and EXAMPLE SET. This sytem has 56 ADC channels, 16 DAC channels plus several Relays for controlling the Seismic Test sections. |
The software released is newer version of the last USB release with many new features. Of note, this Test Set of Hardware and Software is built around distributed I/O. The ADCs for Deflection measurement are right on the Test Chamber face with short cables reducing noise in the system. The system can easily resolvedeflections to .01 mm and with more signal averaging could do .005 mm. Sample rates are impressives. Single point read from the Modbus TCP comms is > 1000 readings/sec Multi Point scanning runs up to KHZ but in this system it was set to 1500Hz scans. |
Calibrations are very stable also due to low noise. ONe important point for designers is that the system now only has one Cat 6 TCP cable going back to the Control Room's Computer. We can recommend this T7 Unit for this type of work. Expect to see more and more DAQ come with Modbus TCP over the next few years as it seems to becoming a standard. Last Point, The T7 has a LUA engine built in and we plan to use this to do filtering, Signal Averging and EU work in the future off loading this work from the Test Computer. |
|
Nov/Dec 2017 MasTec has just released its 5th LV LCOP Book on the building on an "Off Line Cluster Editor". This editor allows each and every Cluster Constant held on disk file to be edited and saved. Why do you need this?? If you are servicing sites remotely or even on site it is important to be able to edit the master configuration files to change look, settings and performance of the application. This can be done off line and down loaded to the remote system and without a reboot change the system. Sort of like a DLL configuration system. The key method to do this sort of real time reconfiguring is to design software that always re configures each time a object runs. In this way it is transoparent changing or reconfiguring. Just a file load at each object run time. It also shows how to build a hierarchy of folders and files for configuration of systems. It also shows how to build and modify calibration data for use in measurement and control systems. Lastly it adds a duplicator function that will take a master configutation folder set and duplicate it wit a new master path and then make a new cluster path constant set that points at each and every file. This is for replicating configuration data across many sites but making each site's configuration folder set distinct with a master name ( usually the company name where it resides). You will be surprised how simple this all is but it is transformative to running many test sites using similar software. July 2017 Summary of using this technique of LCOP Over the last 2 years MasTec has developed several very large software Test Systems using their LCOP method and is now in a position to release a report on the experiences. This info will only really make sense if you have read the first three LCOP books from MasTec. The first project undertaken to extensively test the MasTec LCOP method was a rewrite of a large Test System. This Test System had evolved from a simple system in 1992 to becoming more and more complex. The first undertaking was to pull the old code into a newer State Engine using Events Buttons to drive the operators selections. Once this was acheived, the LCOP methods of building Abstraction into each Component was applied using State Engines with Enum Tyoe Defs as the State Engine Verbs. The Components in these Test Suites build into several Applications accessed by the Test Operator. A Check It section allows each Hardware Control system to be checked before running any Tests. This Check It section can also be used for trouble shooting Interfaces, Cabling and other Software issues. A Calibration Section allows each parameter measured ( linear displacment, pressure, flow, temperature, RPM to be calibrated and the data stored in the Cal Folder. |
Additional Calibration is for the Control sections for VSD Hz, Servos angle, Actuators action, Pumps Flow etc and this data is also stored in the Cal Folder. A Tests Section. This is the heart of the System with several applications doing very involved IANZ accredited Tests to AUD and NZ standards. All these Test Applications were rewritten to use the LCOP components also. Once this rewrite was completed the next step was to remove all Constants from all Components and Sub Components and place them in files as Diagram Clusters . Each Applications Diagram Constant Cluster was loaded at runtimeand the constants were reembedded into the diagram using Unbundle by Name. This documents these Constant also. Next the Public Data and the Private Data for each Component was sorted. Public Data is in the form of Initialisation data and the Private Data as Diagram Cluster constants. The Private data is not avaiable to any other section of the program other than that particular Component. The Terminals on all the Test Applications are by nature the same and receive the Public Data Clusters as Configuration or Initialisation data. These Public Data Clusters are loaded from files at runtime as the first initialisation, These Data Clusters are next addressed. To Facilitate this design change to LCOP, the Front Panel for each Test Application became a consistent TAB Control with a Tab for each Public Data source. These Public data sources in this Tesy Suite are Path Clusters Several Clusters for every file type in the system Calibration files ADC Cluster Configuration setup for Scanning Channels and Single Samples, rates, counts, gains, etc. DAC Cluster Configuration setup for all 16 Channels with Range and Assignment of each channel to a particular function eg VSD drive, Servo #x Drive, Test Voltages etc. DIO Cluster Configuration setup for all DIO Channels used Control Cluster Configuration setup for all Controlled Items VSD, Servos, Actuators, Pumps etc Calibration Clusters All the Cal data for each sensor usually as y=mx+b as Offset and Gain. Master Cluster Allows turning on editing functions for the user and also turns on the the Cluster Constant Editor |
Error Cluster All errors end up here Additional Applications in each Test Suite. These Applications can be accessed by a full virtual tool set also built in for commissioning, DVM for all channels, 2 channel Scope, a Spectrum Analyser and a noise calculation set for each ADC channel Plus several EU calculators like cubic feet per minute to liters/sec, pascals to PSI and more. All these Data Clusters are Type Def as the clusters are sprinkled through out the program. Inside these Clusters are LabVIEW controls and this means also can be graphical controls and not limited like silly ini file with only boolean, texts or numbers. As an example : Changing the gain of an ADC in the ADC Data Cluster displayed as an Enum with ranges from +/- 10 VDC to +/-1VDC and are not not selected by a number which is quite meaningless unless you have some other ADC information to look at This almost completed the work. and a very large installation was undertaken and the experience of commissioning in comparison with the older method of hard coded programming was noted. The Application was now extremely adjustable. In most cases it was adjusting configuration cluster data in files rather than adjusted the program to make everything work correctly. The most important gains it appeared was with the Path Cluster as this allowed easy adjustment of all file paths. There were about 30 paths for this Test Suite. As this work of installation was being undertaken it became very obvious that an off line stand alone Cluster and Constant Editor would be a big asset. This Editor tool was built and is used to bring up a program that had no configuration data in place such as paths setups, calibration data and test data files. etc It also allowed building Dummy data files that were used in the paths cluster for first start or to start commissioning.. When the system runs for the first time or as it is commissioned, it will have no real cal data but it needs the cal path to save the cal data when Calibration is done. The editor allowed a dummy files, path and folder to be made to facilitate the program actually running correctly even if the data in the files was not correct. Calibrating and Test commissioning was a simple process of adjusting paths and making correct cal data files. Lastly this off line editor, now allows off site maintenace also via the net sign in. Final Conclusion. A vastly superior program in all respects. Commissioning is speed up significantly and is also more accurate with usual only one pass for each Test Application to get success. However these are further things to add yet. Often when you transfer the program onto a new site machine, fonts blow out and there is a sudden need to do a lot of editing. The next edition will have all of this under Properties to adjust in the Constant Editor. A series of Master Enums for Font, Size and Colour. |
|
March 2017 Summary of all Four Books to date 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 |
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.
|
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. |
|
"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. |
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 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. 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. |
|
December 2015 LCOP Hidden Data Methods 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 is more LabVIEW focused. ( It allows Graphical hybrid Constants rather than just simple text, numbers or booleans as in ini files) 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 Constant Removal System Continuing on with the MasTec Constant Removal System 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 conver the whole thing into a rough book to be released in March as a PDF. Approx 70 pages of notes and screen shots plus a few other little additions. March 2016 Get your Copy  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.
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
2016Book 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. |
|
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 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 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 More for March 2013 OOPs versus LCOP
or Ols Style Straight Dataflow 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
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 LabVIEW Development Course or Consulting We are thinking of developing an informal Course LCOP - LV Component
Orientated Programming This brings to your programs.
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.
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. 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 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- 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 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 the Hidden Data section in the book, or removing constants from programs is not very sound and useful. I am going to dedicate some time to fixing this over the next few months. |
 © MasTec Ltd 1997- 2024 |