LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading from CO2 sensor connected to the PC

Solved!
Go to solution

Hi Raven

 

That is correct. I do not have any error that are the result of problems with the data coming in and the format string used to scan the data from the string.

 

Yes, the problem now is that it I get an error message telling me that an error occured during transfer and that a chacter was not read from the hardware before the next character arrived. I assume that it is because the buffer is filled up.

Well now I removed the boolean but before when the VI was running I would toggle the boolean and get the error. Now I just get the error when running the VI, when I then restart it the error disappear. So I guess the serial port is left open because it still is transfering data to the buffer as far as I can see on the usb LED. How can close the serial port? 

 

Greetings 

DP

0 Kudos
Message 51 of 63
(712 Views)

@DP123 wrote:

Hi Raven

 

That is correct. I do not have any error that are the result of problems with the data coming in and the format string used to scan the data from the string.

 

Yes, the problem now is that it I get an error message telling me that an error occured during transfer and that a chacter was not read from the hardware before the next character arrived. I assume that it is because the buffer is filled up.

Well now I removed the boolean but before when the VI was running I would toggle the boolean and get the error. Now I just get the error when running the VI, when I then restart it the error disappear. So I guess the serial port is left open because it still is transfering data to the buffer as far as I can see on the usb LED. How can close the serial port? 

 

Greetings 

DP


So you are saying you run the VI, you get the error.  But you stop and restart the VI and the error goes away?  That doesn't make any sense.

 

You can close the serial port the same way you are doing it after the loop.  Use the VISA Close function!

 

If you are still having problems, you may want to do a little more debugging.  Use the Bytes at Port property node and wire an indicator and waveform chart to it.  See if while your VI runs if it seems to generally be increasing (bad), or stays fairly consistent at level near 0 or perhaps about the size of a typical message string.

0 Kudos
Message 52 of 63
(715 Views)

Yes, because when I stop the VI the device is still sending data and filling up the buffer when I then run the VI I get an error if the buffer is filled up. If I then stop and run the VI after the error the error does not occur again because it keeps emptying the buffer. Does that make sense? I might not be that good at explaining it but I hope that makes sense.

 

Could you maybe show me where to place the VISA close before the loop? 

 

Greetings 

DP

0 Kudos
Message 53 of 63
(710 Views)

Attached is a modified version of your VI.

 

How are you stopping our VI?  It does not make sense because if you hit the stop button in your VI, the VISA Close would have executed and closed the port.

 

You really have 4 situations going on here.

0.  Port was closed and still is closed.  Do nothing.

1.  Port was closed, now you are opening.  Configure the port, clear and flush the buffer.  (I added buffer flush)

2.  Port was open, now you are closing.  Close the port.

3.  Port was open and remains open.  Read the data.

 

So I used a boolean array to number to look at the previous setting of the switch vs. the current setting and act accordingly.

0 Kudos
Message 54 of 63
(705 Views)

Hi Raven

I found out what the problem is. If I use the abort execution in labview without using the stop button it does not close the serial port and therefore it keeps filling up the buffer. If I use the stop button before restarting the VI it does not give me an error.

 

Greetings 

DP

0 Kudos
Message 55 of 63
(689 Views)

Well that would do it!.  You said you stopped your VI, you never said you were aborting it.  The abort button should never be used other than for debugging purposes.  It should be removed from the VI whenever you get to releasing the code.

 

There is a phrase often repeated in the forums. "Using the Abort button to stop your VI is like using a tree to stop your car. It works, but there may be consequences."

Message 56 of 63
(687 Views)

Hi Raven

 

Haha 😄 That is a really good phrase. I will remember that for sure! 

 

Well I guess that my problem has been solved. 

I have one more question. After pressing the stop button is there a way to make it read again without having to restart the whole VI?

 

Greetings 

DP

 

 

0 Kudos
Message 57 of 63
(667 Views)

No.  The purpose of the stop button is to stop the VI.  If you don't want the VI to stop, don't hit the stop button.

 

That is the reason for the open com port button.  It allows you to stop reading without stopping the VI.  And to restart reading when you are ready.

 

In your VI, you have 2 different stop buttons, one stopping each of the parallel loops.  The problem is that for the user to stopo the VI, they need to remember to hit both of them.  That is an awkward user experience.  You are better off having one stop button for both loops.  There are a few ways of doing it.  Some methods are quick and dirty, others are better structured.

 

The quick and dirty method is to create a local variable of the lone stop button and read that in the other loop.  You'll need to make the mechanical action of the button Switch When Released first.  Because it is no longer latch action, you'll want to write a False value to another local variable of that button set so that it only executes onces both loops have ended.

 

Better methods would have a loop handling user events and send notifications to other loops to teel them when to stop.

 

Some people suggest that there should never be a stop buttons at all and you should only use the X button on the upper right of th window.   (After all, you don't need to tell Microsoft Excel to stop before you close it out.)  But I think you only really need to do that if you are making an application for truly inexperienced PC users.  Anyone running an app for recording data from a lab experiment is probably capable enough to understand a few basic concepts in how the LV environment works.  But even with that, you may want to have some specially handling of the press of the red X.  (an application close event).  There have been a number of times in the past where I might want to X out some windows when my screen gets clutterd only to accidentally close out a windows I didn't intend to.

Message 58 of 63
(665 Views)

Hi Raven

 

Yes. I can see that it might be too confusing with two stop buttons. I tried following this guide: http://digital.ni.com/public.nsf/allkb/267704CDE91156D186256F6D00711AAE and make it the quick and dirty way as you described but it is giving me some troubles.

I tried doing it by making a property node of the stop button in the first while loop and putting it inside the second loop and wired it to the loop condition.

 

Greetings

DP

Download All
0 Kudos
Message 59 of 63
(650 Views)

Use a local variable.  Not a property node.

 

That error has nothing to with the property node for the stop button.  Some other problem with the DAQ device has cropped up.

0 Kudos
Message 60 of 63
(647 Views)