LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Reading Continuous Data on Multiple Ports

The attached VI works. That said, I can't help but look at it and think that someone more knowledgable would do it differently.

 

The data that comes in is a constant stream, something like "= 0023.2= 0023.2= 0023.2= 0023.2= 0023.2= 0023.2= 0023.2= 0023.2"

With the data like this, I can't use the Instrument I/O assistant. (Right?)

 

I read four or five scales like this, so I have several of these loops running simultaneously, as shown by the two in my attached vi.

I'm converting from lbs in the data to kg on the display. I also have an LED to show that it is working, because sometimes it doesn't.

I ignore all the errors. 1073676294 is a common one. I know that's wrong - what SHOULD I be doing with those errors?

Then everywhere in my program that I need that data (an additional loop among my dozens of concurrent while loops), I call it up with a local variable.

 

So it gets the job done, but it's terrible. Where would you go from here?

0 Kudos
Message 1 of 17
(3,441 Views)

Hi there

 

First of all it's not THAT bad...

 

1. If all the while loops do the same thing, then create a sub vi of the inner parts of the loop. You may pass some constant parameters to this sub vi to make it more generic. Make this sub vi reentrant (VI properties->execution). Then there's less code to handle.  

 

2. If all while loops have the same timing and the data arrives at the same (constant) rate on any port you may try to run the sub vis in ONE single while loop in parallel (make sure that the sub vi is reentrant!!) instead each vi in its own loop.

 

3. To pass the data to other parts of your app use a FGV (functional global variable) or named queues (with buffering of data). Then you can get the data EVERYwhere in your app, even in nested sub vis.

  

4. Find the source of your error codes and get rid of them!

 

 

Best regards
chris

CL(A)Dly bending G-Force with LabVIEW

famous last words: "oh my god, it is full of stars!"
0 Kudos
Message 2 of 17
(3,433 Views)

Hi IMSargon,

 

The code is not bad. My recommendations would be similar to chrisger. Use reentrant SubVIs to cut down on the amount of code and combine the loops if possible. You may also want to implement some better error flow by connecting the error lines from the VISA Configure Serial Port VIs to the VISA Read VIs and adding a Simple Error Handler VI after the VISA Close VIs. You may also want to use a Merge Errors VI to tie things up.

 

As far as the errors are concerned, check out this KnowledgeBase article: http://digital.ni.com/public.nsf/allkb/C96C84C922DC3F978625632500482F78?OpenDocument

 

Thank you for choosing National Instruments.

 

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support

0 Kudos
Message 3 of 17
(3,409 Views)

I'll work on those subVIs. I've been working on this program for half a year now, and have never used a subVI. It's about time I got around to doing that. 

 

I've been pondering this idea of moving the Simple Error Handler outside of the loop after the close. I'm executing the Simple Error Handler so frequenty it's causing me a performance hit. But the error doesn't get outside the loop unless the loop ends, right? How do I end the loop in the event of an error without using the Simple Error Handler? Or am I looking at this the wrong way? How does the error handling change if this is a SubVI instead of a loop within the main VI?

0 Kudos
Message 4 of 17
(3,404 Views)
oops.PNG
IMSargon wrote:

I'll work on those subVIs. I've been working on this program for half a year now, and have never used a subVI. It's about time I got around to doing that.

 

AND "I can't help but look at it and think that someone more knowledgable would do it differently."

 

How does the error handling change if this is a SubVI instead of a loop within the main VI?


 

 

Yep, 6 months is a long time to ponder that code.

 

Use sub.vi s they are the basis of reuse

Reuse common code (you will need sub.vi's)

error handeling is a common stumbling block to the new LV programmer that has not had any training. I've attached a common (but not ALWAYS ideal) example of where a sub.vi starts.

 

Message Edited by Jeff Bohrer on 06-12-2009 06:26 PM

"Should be" isn't "Is" -Jay
0 Kudos
Message 5 of 17
(3,400 Views)

Yep, 6 months is a long time to ponder that code.


😛 There's more to the program than just that loop. My software runs the whole chemical processing plant ... poorly.

0 Kudos
Message 6 of 17
(3,396 Views)

Just to let you know 1073676294 , is a warning and not an error.  (Positive numbers are warnings, negative error codes are errors.)  It means you got back exactly the number of bytes you asked for, so there may be more bytes yet remaining in the serial buffer.

(Honestly, I don't know what is the point of this warning.  If I ask for 8 bytes and get 8 bytes, then I know what I got.  If I ask for 8 bytes and get 6 bytes because the VISA Read timed out, I can figure out there are only 6 bytes, and I'll have a timeout error.  The warning is more of a nuisance than useful information.  A programmer should always be able to assume there are potentially more bytes left in the buffer, or check for the number of bytes and know for sure.)

0 Kudos
Message 7 of 17
(3,384 Views)

@Ravens Fan

 

Yeah, that's what I read the error meant, but I can't figure out why the computer wants to tell me this. As I mentioned in the origianl post, the units I'm reading data from just send a constant stream of data. There will always be more bytes in the buffer. Can LabVIEW be prevented from giving this warning? (Besides telling simple error handler to ignore it)

0 Kudos
Message 8 of 17
(3,381 Views)

Not that I know of.

 

Just set up your code so that it ignores that particular number.

0 Kudos
Message 9 of 17
(3,377 Views)

IMSargon wrote:

I'll work on those subVIs. I've been working on this program for half a year now, and have never used a subVI. It's about time I got around to doing that. 

 

I've been pondering this idea of moving the Simple Error Handler outside of the loop after the close. I'm executing the Simple Error Handler so frequenty it's causing me a performance hit. But the error doesn't get outside the loop unless the loop ends, right? How do I end the loop in the event of an error without using the Simple Error Handler? Or am I looking at this the wrong way? How does the error handling change if this is a SubVI instead of a loop within the main VI?


 

Hi IMSargon,

 

Yes, the error doesn't get outside the loop until the loops ends, but there is a pretty simple way of exiting the loop in the case of an error. Here is an example:

 

errorcluster_unbundle.PNG

 

 

Thank you for choosing National Instruments.

 

Aaron Pena

National Instruments

Applications Engineer

http://www.ni.com/support 

0 Kudos
Message 10 of 17
(3,351 Views)