Configuring/reading multiple signal types from one module via serial port

[UMN CEMS]

I have a CB-7018 module (similar to SuperLogics 8018R data acquisition hardware) that is acquiring data directly from type T thermocouples, a flow meter (output: 4-20mA) and a pressure sensor (output: 0-4V), which is then sent to the computer via a single serial port.

Ultimately, I want to "simultaneously" display all three data type values on the front panel with minimal loop delay.  However, when I run my VI (see attached), the temperature and mA outputs randomly "spike" to different (incorrect) values (ie. mA output displays 3.18mA, then spikes to 20.00 and returns to 3.18).

Would anyone happen to know a reason behind this?  I'm not entirely sure that my code is the greatest, either, so if anyone has any suggestions on how to acquire multiple signal types from one module, I would greatly appreciate it! (ie. do I need the VISA Clear's between configuring and writing to the module? Also, are the time delays not long enough?)

Thanks in advance!

Link to CB-7018 user manual:   http://www.measurementcomputing.com/PDFManuals/cb_7011-18.pdf

[Sputnikrent]

Have you tried running the code with acquiring only the mA or temperature data? After isolating the source of the issue we can then work on trying to resolve it. Let us know how that goes!

[UMN CEMS]

I have tried running the code for each individual signal type, and it all works.  It's when everything's running together that the signals get disturbed.

Thanks for replying!

[Sputnikrent]

Hi UMN,

One thing you can do is to put the VISA Configure Serial Port VI, as well as the CLR and VISA Close VIs outside of the loop. This means that the Configure VI runs only once, and the reads and writes run continuously in the loop. When you decide to stop your acquisition, the program will exit the loop and clear the buffers, then close the VISA Session.

[UMN CEMS]

Rasheel,

I put the VISA Configure Serial Port VI, as well as the VISA Close VI outside of the loop (I kept the VISA CLR VI inside the loop), but I still continue to get variations in temperature and mA readings.  However, there is never any "disturbances" in the voltage reading.  Any other ideas?

Thanks for your help!

[MXI Master]

UMN,

I have a couple ideas we could try:

Are you expecting outputs that are pretty much constant or do you expect them to change often? We could treat spikes as bad data and filter them out if every point is not crucial.

Does it always spike up of 20.00 or is that just an example of behavior? Is 20.00 in your expected range, maybe the device is sending us a error code.

As you mentioned it is possible the delays are not proper lengths for your device, you can try lengthening them and then and see if we get the same behavior. If not we can start shortening from there.

Good luck!

[UMN CEMS]

MXI,

MXI Master wrote:

Are you expecting outputs that are pretty much constant or do you expect them to change often?

The temperature outputs are from a distillation column which will eventually reach a steady state over time.  Therefore, there won't be any frequent changes in these values, but a semi-accurate plot is needed (and the temps should never display a reading below zero- which is what I get during "disturbances").

The voltage output, which is a measure of pressure, should not change much at all and the mA output, which is a measure of a feed flow rate, will be at constant values most of the time.

MXI Master wrote:

Does it always spike up of 20.00 or is that just an example of behavior? Is 20.00 in your expected range, maybe the device is sending us a error code.

It is the mA output ("flow rate") that spikes up to ~20.00, which is the maximum output by the flow meter (4-20mA).  I do not believe that 20 should ever be in the range that corresponds with appropriate flow rates.

Also, when I lengthened the delays in the program, I continued to get the same behavior.

Thanks for your help and suggestions!

[Sputnikrent]

Hi UMN,

Is there a reason why you have the VISA CLR VIs in between writes? Try removing that VI and see if that makes a difference. Other than that it looks like you are doing everything right, i can't really think of anything else you could to do change things to make it work.

I imagine that the only difference between reading just one measurement and reading multiple measurements, is that instead of sending the same VISA Write command all the time, you are writing three different commands to the instrument turn by turn. Is this correct? Or are you handling reading a single type of measurement differently?

[UMN CEMS]

If I don't put the VISA CLR in between writes, I read the "status response" of the module before the actual channel values (ie. 04!).  I'm definitely not sure if VISA CLR is what should be placed in between writes, seeing how I randomly chose that VI to follow the first write to see if it fixed an error code.  Any suggestions on what should be in between writes?

And yes, you are correct by saying that I am writing three different commands to the instrument turn by turn.  I first write to tell it to read all channels of module 4, since there are four channels that are connected to thermocouples.  Then I write to tell it to read mA, and then write again to tell it to read the mA value of channel 7 on module 4.  etc....

Also, I did try adding longer delays and that seemed to help minimize the spikes in temperatures and mA signals.  However, if I wanted to plot all the data, is there any possible way that I could have the graph updated more frequently, instead of having to wait for all the delays?

Thanks again!

[RavensFan]

---

UMN CEMS wrote:

If I don't put the VISA CLR in between writes, I read the "status response" of the module before the actual channel values (ie. 04!).  I'm definitely not sure if VISA CLR is what should be placed in between writes, seeing how I randomly chose that VI to follow the first write to see if it fixed an error code.  Any suggestions on what should be in between writes?

---

If you are consistently getting a value in the VISA read that you don't care about, it would be better if you just read it and parsed it out of the incoming data rather than indiscriminately using VISA CLR and running the risk of wiping out data that you do care about.

Also, the default setting for the unwired VISA configure function is to have line feed (/n) as the termination character, but it appears carriage return (/r) is the value that comes in at the end of the responses according to the manual.

Instead of using a wait statement and reading the bytes at port and only reading that many, it would be better to get rid of the wait, read a sufficiently large number of bytes into the VISA Read statement and let the termination character of carriage return be what returns the data from the VISA read function.