Steve Weidman

QUOTE(Steve Weidman @ Mar 8 2007, 10:29 AM)

Thanks so much for the VI. That makes pretty good sense. I can see how that will be able to latch the outputs from the min/max test.

Now, what I also need to do is capture the output from a push button. I need the push button to do a user dialog for entering a serial number and to also start a test. Right now, I can capture the serial number fine by using a momentary push button that triggers a case structure with the dialog in the true portion of it. But what I also need to do is capture the fact that the push button has started my test running. This is going to be really simple to put into what I already have if I can "capture" or latch the fact that the push button has been pressed. I want to latch that so that additonal clicks to the push button don't do anything until the test has been completed. Did that make sense at all?

Thanks,

-Steve

Also, how do I make this into a sub-VI? Every time I nest While Loops, the outer loop seems to stop running.

Thanks,

-Steve

QUOTE(Michael_Aivaliotis @ Mar 8 2007, 01:42 AM)

I've attached a VI that does what you ask. I suggest you study shift registers.

(LV8.0)

http://forums.lavag.org/index.php?act=attach&type=post&id=5149

http://forums.lavag.org/index.php?act=attach&type=post&id=5150

Thanks so much for the VI. That makes pretty good sense. I can see how that will be able to latch the outputs from the min/max test.

Now, what I also need to do is capture the output from a push button. I need the push button to do a user dialog for entering a serial number and to also start a test. Right now, I can capture the serial number fine by using a momentary push button that triggers a case structure with the dialog in the true portion of it. But what I also need to do is capture the fact that the push button has started my test running. This is going to be really simple to put into what I already have if I can "capture" or latch the fact that the push button has been pressed. I want to latch that so that additonal clicks to the push button don't do anything until the test has been completed. Did that make sense at all?

Thanks,

-Steve

QUOTE(dsaunders @ Mar 7 2007, 12:42 PM)

Judging by this statement it seems that you are using the "Latch When Pressed" or "Latch When Released" action. These actions cause the boolean to revert back to false after LabVIEW reads the boolean in the program. If you use the "Switch" actions, then the boolean stays true even after LabVIEW reads the switch.

David

I thought about using the switches instead of the push buttons, but I really need it to do both. I have a case structure that needs to operate once, and I also have a routine that needs to run for an extended time (ie my need for the latch).

Also, I need the latch to show a condition. I have an In Range and Coerce function that if a signal ever drops too low or goes too high, the In Range function's output needs to be latched for the entire time of my test. It will not be reset until the beginning of the next test (which is started by a push button).

I'm open to any ideas...

Thanks,

-Steve

QUOTE(dsaunders @ Mar 6 2007, 03:46 PM)

This latching behavior is found in the "Mechanical Action" submenu that is available upon right-clicking on the boolean. The correct behavior depends on how you want to reset it. If you want to reset it programmatically, then you would choose either "Switch When Pressed" or "Switch When Released". This would change the boolean state and leave it in the new state. Then you would change it back in your code.

If you want to have the boolean change as soon as you press it, and then 'reset' when you let go, then choose "Switch Until Released". I hope that helps. If you are talking purely holding or latching a value in your code, then look into shift registers.

David

Thanks for the input. I knew about the button's actual latching function. Unfortunately, this is not going to accptable since it goes away once LabView reads the switch. Now in regards to a shift register, do any of you have examples of a scheme that will allow me to "capture" the fact that a button was pushed and use it in the rest of the VI until I'm ready to discard it?

Thanks,

-Steve

I'm still very new to LabView and need some help.

I would like to capture the output of a button and latch it until I reset it. Is there any kind of a latch function that can capture and hold boolean values until I reset it?

Thanks,

-Steve

If you are speaking of the read buffer size ...

( "Number of Bytes to Read" input to the VISA Read function or "Max Allowed Byte Count" input on the VI I posted )

... then there should be no problem with a 1000-byte buffer. Heck, it's a U32 number so it should be able to take a really BIG value if you wanted.

How much memory do you have in your machine?

The number of bytes to read on the VISA read function.

I didn't figure it would hurt anything, but wanted to make sure.

Thanks,

-Steve W.

Take advantage of the fact that the VISA system can buffer the data for you until a complete message is received and then return that message to you. Don't use "Bytes at Port" except for possibly checking to see when it is non-zero which would tell you when it was OK to start attempting to get or to wait on a message. Enable the VISA "read termination character" feature to look for the carriage return that each message contains. It will be used as a signal to VISA when it has a complete message available to return to your code for processing. If you specify a large enough read buffer to the VISA read function then it can buffer multiple messages from the instrument and return the oldest one each time you do a call to it.

You should only get out of sync if your message processing routine cannot keep up with the rate of incoming messages. (in that case I would suggest, as a last resort, you read two or more VISA messages for every one you pass off to your processing routine, dumping the extras).

I may have to set my "read" constant fairly high (like 1000 or more). Is there a problem with doing that?

Thanks!!

-Steve W.

Take advantage of the fact that the VISA system can buffer the data for you until a complete message is received and then return that message to you. Don't use "Bytes at Port" except for possibly checking to see when it is non-zero which would tell you when it was OK to start attempting to get or to wait on a message. Enable the VISA "read termination character" feature to look for the carriage return that each message contains. It will be used as a signal to VISA when it has a complete message available to return to your code for processing. If you specify a large enough read buffer to the VISA read function then it can buffer multiple messages from the instrument and return the oldest one each time you do a call to it.

You should only get out of sync if your message processing routine cannot keep up with the rate of incoming messages. (in that case I would suggest, as a last resort, you read two or more VISA messages for every one you pass off to your processing routine, dumping the extras).

That seems to be working well too. I put a while loop around it and it seems to be kicking my data stream out perfect every time.

Thanks so much for the help!!

-Steve W.

Here's an example. It may need some refinement, but it explains the idea behind "producer/consumer" loops. The consumer loop is where the work gets done.

Notice that even if the consumer loop takes a long time to process, the producer loop continues to gather data and store it in the queue.

Download File:post-3266-1140219841.vi

Hope this helps. I think there are some examples in the help under the keywords of "queues" and "serial" if you need more explanation.

Joe (orko)

Sorry for the delay in getting back to you. Lots of things to do here.

Thank you so much for the VI. That appears to be exactly what I'm after. I should be able to test it later today.

Again, thanks so much for the help!!

-Steve W.

Can you provide an example VI? It would help if you save it for LV 7.1 so more people could look at it (I'm hoping to upgrade to 8.0 next month).

What are your settings for the serial connection set at? You probably already verified that your port settings are set exactly to what your instrument specifies, although sometimes it is a matter of tweaking the timeout value, if it is set too low (I think it defaults to 10 seconds though). Are there any errors set when the incomplete reads happen?

Another thing to look at is if your data reads are being slowed down by other logic in your VI. It may help to stream incoming data into a queue in one while loop, and perform operations out of the queue in another. Since you have no flow control lines, you may be running into a condition where you miss data when your logic takes more than 500 msec to run.

Joe (orko)

That's an interesting idea concerning the missed data. That may be what's happening.

While I pull together the other information you asked for, could you explain how I can make a queue to store the intermediate data?

Thanks!

-Steve

Good Morning.

I'm new to LabView, having just gotten the version 8 full development suite.

Overall, everything has worked out great, but I'm having trouble reading a processing a serial string.

Here is my situation:

I have a three wire serial port (no flow control) running at 38400.

Twice per second, my instrument sends out a comma delimited data stream with a CR on the end. I need to capture the whole data string and take it apart at the commas. I know how to take it apart, so no problems there.

By using the "bytes at port" connected to the standard serial read, I can see my data. At times though, it gets "out of sync" for lack of a better term and doesn't capture the whole string.

I thought that maybe using events, might capture it, but no luck there at all.

Any ideas or futher clarifications for me?

Thanks!!

-Steve Weidman