I was lucky that one of the guys on the team had a LabJack U3-HV that I could test out with LabVIEW. The following describes the install of the software and a simple compatibility test. The goal is to determine if this DAQ works with LabVIEW therefore when we scale for the larger device we should have confidence in the purchase. 

In order to use LabVIEW both the LabJack Driver and the Library needs to be downloaded. Follow these instruction here to get setup, its pretty straight forward. After install I opened the example program "U3 Multiple IO Example.vi." I then simply plugged in the U3-HV into my PC and ran the program. The DAQ connected with program and displayed open input floating data on the front panel. To validate it was actually working I stopped the program, unplugged the USB and ran the program again. The "Error Out" displayed a connection error, this gave me the confidence that LabVIEW is actually communicating with the Device. 

Definition: "A state machine reads a set of inputs and changes to a different states based on those inputs." 

There are usually two schools of when it comes to programing: The Linear Execution or The state machine. 

The Linear Execution: An example is the small code snippets that I discussed about coils. They serially operate code once in order then stop.

The State Machine: Is a continuous loop that runs linear executions based on the input and reacts based on the results. 

Probably one of the most enjoyable things that I enjoy about LabVIEW is how easy it is to build state machines.

The point of this project is to safely execute a series of commands to hot fire lots of expensive hardware. Here is a list of states that I would like to incorporate so far: 

Typically I like to build my state machines with the first state or default state as the Main or Wait state. This means all Inputs originate or wait at the Main and then cascade out to the other sates. Note: State 1 does not have a human input. This state in actuality is the first state that runs (typically once), this state re-initializes and nulls inputs. This state can be run again however only in special circumstances. 

In LabVIEW tools, a state machine is simply a while loop with a shift register and a case structure. I personally like to add the use of a Event Structure coupled with the "Select" comparison tool to make the execution of the (Human controls) more stream lined. 

I also like to use "Enumerated Constants" this give a selectable string value to a numeric constant. This is helpful for code debugging and visuals, cuts down on the amount of labels. However, if more states needed to be added they all should be replaced to have the most current list. 

The code snippet above shows the Abort sequence execution after the human control input is selected. When a change in Input value occurs state 5 is executed.

Shown below: The linear execution code then runs turns off all coils, read the coils, and then gray & disable the test stand fire control inputs. This abort sequence will eventually get more tailored based on actual hardware, but for now helps me debug the states. After all code is executed in state 5 the "enum constant" returns the code to 0 to wait for the next input. 

Future posts will discus the states in more detail when hardware is finalized. 

There is a few basics that have to be understood first before starting a connection with the Productivity 2000 PLC. From Automation Direct's website I found a good resource that explains how the Modbus addresses work. The address Identifier has a prefix that designates what the address type is. The remaining digits are the unique address channel. In order for LabVIEW to understand the address identifier it needs to be mapped to the PLC tag related to the Input or Output (IO). Below shows what identifier is used with the LabVIEW Modbus API VI. 

As stated each IO Modbus Address needs to be mapped to its corresponding tag.  For this to happen the Productivity Suite software needs to be installed. During setup of the software configure your PLC chassis and connect to it over your local area network. On the left hand side of the software find "Write Program > Tag Database" then double click. Scroll down and find your tags for your IO cards. For this demo I am using the default tag names. Double click on the "Mod Start" and two numbers will show up. The left most number is the address type and the right is the address number. The address number can be any value, however it will auto assign and increment when clicking through the rest of the tags. After assigning tags close the Tag Database and "transfer project to CPU."
​Below is how I setup my tags:  

 Now we should be ready to program LabVIEW!

Use LabVIEW VIMP to download the Modbus Library. The library can be found under "Data Communication" > Modbus Library > Master API.   

We will start off with a simple coil write program. A coil is PLC language for a relay contact. Its also important to realize that LabVIEW is based on "0" index. This means the address that the desired address needs to be is subtracted by 1. Example: Modbus Address 000001-1 = LabVIEW Address 0. Also the Address identifier does not implicitly need to be stated, the Modbus VI adds this info at a lower level based on the type needed.  

Simple Coil Toggle

1. The VI starts off with Opening the TCP/IP Channel. The IP address is assigned and can be found during setup of the Productivity Suite Software. 
2. Next the the coil is set to TRUE, closes the relay contact @ address 000001
3. Finally the Modbus connection is closed
4. Note: The Program will run once when started, run program.

Now toggle the constant from TRUE to FALSE to turn off the coil, then run the program

In the next post we will get into advanced programing techniques and test stand related programs. 

After reading about modern PLC remote control, the best solution available today is using OPC protocol. This allows the programmer to directly interact with the PLC tags and have seamless access to modern data types. LabVIEW also has made a stream lined method of pulling OPC tags into code; they act like global variables so low level VI tool kits are not needed to poll the PLC directly. I was very excited to use this protocol until I saw the price. National Instruments (NI), the developer of LabVIEW makes the user purchase the "LabVIEW Datalogging and Supervisory Control Module." This data module is coming in at $1,382, yikes! As a hobbyist this price is insane, so unfortunately this killed my dreams of using OPC.  

Modbus TCP/IP is a well established protocol that communicates over local area network. Yet again LabVIEW offers a very sleek version of Modbus in the "LabVIEW Datalogging and Supervisory Control Module." However this still leaves us stuck with the hefty price tag. The good thing is NI offers a "free to download" library through of Modbus TCP/IP in VI Package Manager. 

I hope to use this blog to document the development my teams rocket engine controller. I am teaming up with my friend Dylan Romig & Rocket Lads to develop a rocket stand that we eventually hope to hot fire in the Mojave Desert. I want to bring to the table my expertise in LabVIEW control and PLC/Electrical design to build a pro-level fire control & monitoring system. 

I have 16 years of experience using LabVIEW in various platforms and techniques. I think the blend of computation power and rapid User Interface (UI) development will be perfect for this project. 

Project Goals: 

• Develop a travel friendly PLC driven fire control box
• The box must have safety systems. (EStops, Reset controller, Contact relays) 
• Develop a tactile control plane and laptop UI 
• Create self-powered system for remote work 
•  Devices must communicate on off net local network
  
• Share codebase in revision control system.
  
• Teach team mates how to program LabVIEW