Modbus control with DAQ Acquisition Setup

[DDuff]

Hi All,

I am currently creating a product test setup that will concurrently control a CN616A temp controller via RTU Modbus, use a USB-6001 digital I/O for controlling some 12V fans, and read in 0.5v-5.5v pressure transducers on the analog side of the USB-6001. 

I am not very familiar with setting up the USB-6001 for proper data acquisition and have been running into memory buffer problems while reading in the pressure data. Additionally the charts are not really displaying the data in a nice continuous way. 

Here is a summary of my setup: 

I need to test a temp controlled pressure regulator. To do this I will place the regulator in a brass oil vat that will have its temp controlled by the CN616A temp controller. I need to measure the pressure differential between the input and output of the pressure regulator at specific temps to make sure it is within tolerance. To measure the pressure I am using a Omega PX-303 0.5v-5.5v output pressure transducer connected to the analog pins of the USB-6001. At times I will need to cool the brass oil vat. to accomplish this I am using the USB-6001 digital I/O pins to control a small solid state relay that will switch on 12V fans as needed. I would like to graph the pressure readings so they show a rolling 5 min window of history. This will allow the technician to easily see when the regulator pressure has reached a steady state. 

Attached is a simplified version of the VI I am currently working with. 

[RTSLVU]

Oh my if that is simplified I don't want to see the real thing. I know the LabVIEW tutorials make it appear that "One Bog Loop" is how LabVIEW programs are written.

But as you are finding out once you get beyond blinking LED's on the front panel One Big Loop no longer works...

Even LabVIEW programs need a proper program architecture, be it a state machine, or Producer/Consumer, or whatever.

1. Why do you continually initialize your Modbus in a loop?
2. Speaking of Modbus, create a set of sub-vi's to control your device using the Modus library. Don't make the end user have to know registers and how to read them.
3. I believe your memory buffer and graph update issues are directly caused by not using a proper program architecture. 

I would probably run the DAQ and Modbus independently in their own loops, with another Event Driven loop to handle the GUI.

Also I would not leave it up to a person to "eyeball" pressure stability. You are measuring it already. Why not just keep track and notify the user when it is stable?

[DDuff]

RTSLVU, 

Thanks for the reply. I agree that the architecture is not what it probably should be, I am just not familiar enough with common practices to know what I should be aiming for. All of the programs I have created to this point have pretty much been one big loop. I think a producer/consumer is the direction I should be heading. Would that be in its own set of loops separate from the modbus control? Also, you mentioned that it might be good to have another event driven loop to handle the GUI. Can you point me to an example of how that might work? 

As for your questions: 

1. The initialize being inside a loop is in case there is a user error and the connection is not established correctly and the initialization fails. When the connection status is ok it drops out of that loop, usually on the first iteration. This just gives me a chance to plug in the USB when I derp out and forget. 

2. I have started making a set of sub-vi's to control all of the modbus elements. The final user will not actually see any registers or anything. I didn't want to have to post all the sub-vi's with this example code so I just put in some of the modbus functions to give a rough idea of what the program is doing. 

3. I think this is probably the problem as well. 

For the final program I will have a bool that lights when the VI determines if the pressure is stable. I like the idea of showing an active graph so the user can easily identify trends in the pressure.

Thanks for the help!

[Frozen]

---

good to have another event driven loop to handle the GUI. Can you point me to an example of how that might work? 

---

File new...

[RTSLVU]

I am going to break my own rules and post a picture as it would be too cumbersome to post all of the code.

At least you will get an idea of what I am talking about looks like.

First picture you have a GUI loop (Event driven State Machine) that handles all the onscreen controls. I use Property Nodes to communicate between loops. Maybe not the best way but it works when all you need to do is to trigger another event loop.

Under that is the Wattmeters loop.(Event driven State Machine) This uses the Modbus library to retrieve measurements from 12 watt meters.

Picture 2 Data Logger Loop (Event driven State Machine), (are you sensing a theme yet?)  I also have an Agilent 34970A DAQ/Switch that take some measurements and controls power.

Finally the Oscilloscope loops (Producer/Consumer) I can also record the scope and all of my indicators.

[DDuff]

RTSLVU, 

Thanks for the guidance. I have created a new VI to start to implement better architecture. I am new to producer/consumer loops and have not found a tutorial that explains it in a way I fully understand yet. Can you take a look at my DAQMx loop and let me know what you think? I would like to set up the chart in the consumer where it will display about 5 min of data. I see that you have an event driven state machine in your producer/consumer. What states do you use there? 

My GUI state machine is very basic at the moment. My thoughts are to use a message queue or property nodes to trigger events in a modbus event driven state machine later. 

Thanks for all of your help!