Visa Events, Serial-Character vs Serial-TermChar

[Siniz]

I have a question about the following block diagrams:

http://hernstig.com/misc/labview/wagner-serial-char.gif

http://hernstig.com/misc/labview/wagner-serial-termchar.gif

Notice that the only difference is how the VISA Enable Event triggers on a Serial-Character or Serial-TermChar (termination character, in this case a line break).

The reason why I am using the approach with Events is to prevent LabVIEW from continously polling the com-port with the VISA Read function. This can be read about here: http://digital.ni.com/public.nsf/allkb/179E61F87CF8B340862571EA0037CFA3

My question is now as follows:

- When I use the serial char to trigger the event, everything works smoothly. If I put up a counter to the iterator of the while loop the counter increases fairly slowly (compared to having nothing happen in the while loop).

- Now if change it to trigger the event on a term char, the indicator called Force [N] will still display the value (somewhat). I say somewhat because the value flickers, like it resets the window (nothing written in it) to writing something. The graph will also display the value, but at a very high speed and uneven. The graph jumps up and down from the value, down to 'nothing' (it is the same problem as the indicator displays, but graphically). If I now put up a counter to the iterator of the while loop the loop will run tremendously fast compared to the other scenario.

Why does this happen?

It might be good to know that data is sent continously to the com-port. I THINK the following is happening:

The first bit of data, let's call it a package (with about 9 bytes), is sent to the com-port. The VISA Event triggers on the first termchar and starts reading the 9 bits.When it is in the while loop, extracting the characters from the comport, the serial device manages to send a new package (9 new bits) and thus a new termchar. Since the while loop is still running the VISA Read till it finds the termchar in the first package of data, it discards the new trigger event from the termchar in the second package. It thus SKIPS one package, and then just triggers on the third package (or maybe even later packages if the serial device sends much faster than the while loop). I don't see how the while loop becomes so much faster though!?

All advice welcome here, as I think it is fundamental to know what is going on behind the scenes of the program to truely get a grasp of LabVIEW.

[Siniz]

When I think about it I would want to say that my 'imagined' scenario does not make sense. Even though it misses the Serial-TermChar trigger event, it should read the following package the next time around. Is there a certain buffer size for the incoming data to the com port that I need to take into consideration here? (was thinking maybe it was a buffer overrun, but it seems farfetched?).

[RavensFan]

We can't access the first two hyperlinks you posted.  If there is something important in those, please attach those files to your next message.

Why don't you post the VI has you have it now so we can see what you are doing? Also, tell us what a typical packet of data looks like.  Sometimes you mention 9 bits, do you actually mean 9 bytes?

[Davidek]

Hi all

I was able to access the pictures, was a bit tricky. You had to go to just http://hernstig.com/misc/labview/ and then open the links from there. Anyway I downloaded the pictures and even recreated the VI, but I don't have the time or the equipment to do some real testing at the moment (sorry Siniz). So I thought I'd tap inte the vast potential of the forum and have someone else help out

Thanks guys

Best Regards

David

NISW

[Siniz]

I am sorry about the links not working. Go here:

http://hernstig.com/misc/labview/

You should be able to access them directly from there.

[Siniz]

I just recently realized I can not edit posts here, so I will try to not be so trigger happy my next time. Sorry about that.

Ravens Fans, I meant 9 bytes.

Davidek, thank you so much. Can't believe you went through all the trouble to do that! Very noble sir.

You can find the proper way to find the links in the above post from both me and Davidek. (I don't allow random websites to link to images on the server, for various reason. I guess I could stop being lazy and get this website access to the images though.)

[Dennis_Knutson]

The best thing to do is to attach the VIs to your posts here with the Add Attachments option. Attaching images to the posts is okay but it's impossible to debug an image (unless its' a VI Snippet) and your gif files are obviously not.

Also, a lot of us work at places where web access is limited to trusted sites and only sites of a certain type. You are just cutting off a large audience if you continue the way you have.

[RavensFan]

If you are getting sporadic zeroes messing up your data, then you are perhaps getting other characters in there with no data in between.  Is it possible the device is sending double termination characters?

Take a closer look at the device manual to see what they say the format of the data is being sent.  Look at the data stream coming in using hyperterminal.  Or use Portmon, to see what the actual data stream is.

I've never felt the need to use the VISA event functions.  If I'm getting a stream of data and I know each block of interest ends in a termination character, then I just enable the termination character and configure the port to that.  In the loop I read the data based on a number of bytes that is more than what I expect to see in the package.  In your  case, if you are expecting 9 bytes,  I'd set it to 10 maybe 15.  The VISA read will wait until one of three things happens:

1.  The number of bytes have been read in from the port.

2.  The termination character was read from the port.

3.  The timeout has expired.

In all cases, the VISA read will return what it has gotten:

1.  The X # of bytes requested

2.  however many bytes up to the termination character.

3.  however many bytes it had received so far at the point the timeout expired.

How fast frequently is your device sending data?  Do you have any other code in the loop besides what you show here that could be slowing everything down?

[Siniz]

Dennis Knutson: Thank you for the advice and I will make sure to follow them. Hopefully I'll get into LabVIEW fast enough to help other people here so I can give something back to this community. Do you have any suggestions as to what sites I should use to upload VIs that are trusted sites?

For now though, here is the VI: http://hernstig.com/misc/labview/

Ravens Fan: I will go ahead and test hyperterminal. I am fairly sure it only sends one termination character. I have read the manual and it does not state anything about how many termination chars it sends, but by just disabling termination char I found it it only sends one. There should be no other data inbetween but yet again I am going to confirm this. I understand the scenarios you describe. I do not have any other code used in this loop. The reason why I am using the polling function is that I am going to place this as a subVI in another VI later on and lots will be going on. So the more processor power I can save in every area, the better. This is just one of thoose efficiency parts. It sends about 100 samples per second. Each sample containing 9 bytes, each byte containing bits depending on what I set the rs232 settings to. The baud rate is 38400.

(I want to reiterate that it is working by just waiting on a serial character, I moreso want to know the reason as to why it is not working when using termination character).

p.s. This VI is slighthly different from the gif I posted in that the graph has been removed and I made it a subvi with some inputs/output. The basic problem still persists though.

[Dennis_Knutson]

This is a trusted site. Just use the 'Add Attachments' below the message body.