VISA READ Help

[Jessica_2067]

Let's see..... I have a machine set up with a bar code scanner that is triggered by sensors from the machine's PLC's. I am trying to have my vi read the the string and parse the information. It works, mostly. My program doesn't control the scanner, which I was told was something that needed to happen to be able to get a proper "read" of the buffer and get all the bytes that have been sent. I don't agree with that, so I am having been scrolling through all the information I can find on VISA reads, serial devices, etc. Most of what I have found has the config serial device, and VISA write involved.

So the problem is that it doesn't always capture the entire bar code needed. Which happens on the old program that this is replacing, although not nearly as often as this one is. I know it has something to do with timing because when everything is running perfectly (numerous machines in a line) my program doesn't have an issue. When there is a problem (any where in the line) my program fails to capture the bar code correctly.

Right now it is a while loop inside a while loop for the entire program. It needs to run and catch a scan for each part run and the timing between scans may differ.

I have made numerous changes in how it runs to test out different things. The latest rev of what I did is attached. As I said it works mostly, I am trying to see if there is another option from what I am doing to get better results. And again the machine controls triggering the device so I am only trying to read the information when it appears; which I don't always know when that will be.

I did attempt "wait for event" but it never saw an event.

I have also created external vi's to test some other theories so I didn't continue to modify this program. hopefully I added enough pertinent information to get some help and better understanding. Still new to this, but am making progress in my knowledge.

[Ben]

If memory serves me...

I configured the bar code to include a termination character and similarly when I opened the VISA session.

Then proceed to read from the scanner. If I got a timeout error I just went back and tried reading again.

Ben

[Jessica_2067]

The bar code reader has the characters CR LF set for "postamble. I did set up the VISA property node for the termination character and there was no change to how it ran. I think I had it set up similarly to how it is now, but instead of "bytes at port" it was "termination Character Enable."

If it doesn't get a proper read I cannot try again as the part the barcode is on will already be in the machine. This is where having control over the trigger would be better than just hoping to catch the whole barcode through the visa read.

I've attached a picture of how the scanner is connected now (the cable at least). I am using a virtual com port for the USB device now. I don't know if this picture will help with how it is all working and how I have the program set.

[RavensFan]

How frequently does the data come in?  Frequently like once a second or several per second?  In frequently like here or there, once every 20-30 seconds, or one every few minutes?

The default time out for VISA is 10 seconds.  So if the data is coming in more frequently than that, you probably don't have any issues.  If it takes longer, the risk is that you'll hit the VISA read and the 10 second timer starts.  If the next message happens to start right as the timeout is about to expire, you'll get a timeout error with a partial message.

This is just me speculating on what you've said about the operation and how it "mostly works".   If this is all accurate, I would do the following.

1.  Make sure you have the termination character enabled and set for LF.

2.  Do a VISA read for 1 byte in a loop.  If you get 1 byte, i.e. it doesn't time out, then exit the loop and do a VISA read for a large number of bytes, now you'll get a complete message that you can concatenate to the first byte.

3.  Make sure you have proper stops to the loop so that it can exit out and stop waiting for a 1 byte message in case you want to exit the program.  Right now with your stop button outside that while loop, it won't detect a stop button has been pressed until it times out, then times out on the next iteration.  That stop button should have been inside the while loop.

[Jessica_2067]

How frequently does the data come in?  Frequently like once a second or several per second?  In frequently like here or there, once every 20-30 seconds, or one every few minutes?

 For the project that currently runs it- anywhere between 1.5 to 2 minutes between scans, sometimes up to 3 minutes for the test. That would be the highest wait time for all the projects that will eventually be using this.

The default time out for VISA is 10 seconds.  So if the data is coming in more frequently than that, you probably don't have any issues.  If it takes longer, the risk is that you'll hit the VISA read and the 10 second timer starts.  If the next message happens to start right as the timeout is about to expire, you'll get a timeout error with a partial message.

There hasn't been a time out error for this yet.

I had a feeling my stop button wasn't correctly configured, but I wasn't sure that was a big concern yet. I will attempt setting up your suggestion below and run a test.

[RavensFan]

---

@Jessica_2067 wrote:

There hasn't been a time out error for this yet.

---

Are you sure there wasn't a timeout error?  I can almost guarantee there was if there are several minutes between scans.  But you won't see that because your inner while loop will only exit once it has successfully read at least 67 bytes.  In that case the the VISA Read would not return an error and there would be no error once it gets passed out of the loop to the rest of your code.  The error out indicator is outside of all your loops.  Try putting a probe or indicator on the error wire inside the inner while loop after the VISA Read and monitor that.

Exactly what happens in those instances when the code isn't working?

I see this scenario.

1.  Right before your VISA Read times out, it starts getting a message.  Let's say 30 of the 67 bytes (or 68 or 69 if the string comes with a CR/LF termination characters)?

2.  Because you didn't get a full 100 bytes (or a termination character assuming that is enabled), you get a timeout error.

3.  You didn't get 67bytes, so your loop iterates again.  Timeout error goes nowhere since its value ends at the exit tunnel.

4.  You try to read 100 bytes.  You'll get the remaining 37.  But points #2 and 3 apply again.

5.  Eventually, when the 67 or more bytes all fall within the 10 second timeout period, the loop will stop and the data passed out for processing.

You shouldn't need a VISA Clear after the loop.  If things are behaving correctly, clearing the buffers is unnecessary, or worse, could be clearing out the next message that has already started to come in.

[Jessica_2067]

You are correct, I do not really know if there is a timeout occurring or not.

When it isn't working: Barcode gets scanned and most times the last 4 or 5 digits show up on what looks like another iteration of the loop. But since the machine got a "good scan" indication the part goes into the machine and tries to test.

I can remove the VISA clear, see if there are any changes there too. I am about to test out your first set of suggestions now. I will follow up later when I have some results.

Thanks for your help.

[crossrulz · Accepted solution]

---

@Jessica_2067 wrote:

 For the project that currently runs it- anywhere between 1.5 to 2 minutes between scans, sometimes up to 3 minutes for the test. That would be the highest wait time for all the projects that will eventually be using this.

---

I put that in the realm of "Sporadic Updates" (updates at a non-deterministic or "very long" time).  So what I do in that situation is use the Bytes At Port to determine of a message has start to come in.  DO NOT USE THE BYTES AT PORT TO TELL THE VISA READ HOW MANY BYTES TO READ.  So when a message has at least started, read the entire data and process it.  If there is no data in the port yet, wait for 50 or 100ms.  This avoids using a massive amount of CPU to do nothing.  It also uses the VISA API to greatly simplify your code.

NOTE: The FALSE case has the Error and VISA Resource wires wired straight through and there is also 100ms wait.

[RavensFan]

Yes.  Crossrulz's method of using Bytes at Port in this situation (part of the 1% of cases where Bytes at Port should be used) is a bit better than my attempts to read just 1 byte.  Only because when you attempt to read 1 byte and nothing has arrived, you need to deal with the error as an indicator that there is no message which in this situation is a common, expected situation.  It almost removes the need to concatenate the 1 byte with the remaining bytes.  The method he shows gets all the bytes at once in as single VISA Read.

[crossrulz]

---

@RavensFan wrote:

Yes.  Crossrulz's method of using Bytes at Port in this situation (part of the 1% of cases where Bytes at Port should be used) is a bit better than my attempts to read just 1 byte.  Only because when you attempt to read 1 byte and nothing has arrived, you need to deal with the error as an indicator that there is no message which in this situation is a common, expected situation.  It almost removes the need to concatenate the 1 byte with the remaining bytes.  The method he shows gets all the bytes at once in as single VISA Read.

---

I have been down that road and it is fraught with memory and performance issues (mostly due to concatenating strings).  I developed the Bytes At Port method when I had an instrument that only spit out data when the measurement changed (it measured the angle of a nut, in case anybody cares) and my life got a lot simpler since.  I really need to find time to work on those nuggets I have in my head...