LabVIEW
VISA READ Help
Solved!
@crossrulz wrote:
@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...
I've been told I have nuggets in my head, too - but they're usually referred to as "rocks".
@crossrulz wrote:
@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.
I see that you have the VISA serial configuration set up outside the loop. Do I need that in the program? I set it up close to how you have it and it didn't do anything. I took the config VI out and was told I need to wait until tomorrow to do any follow up testing as the machine was taken back for production use. I'm going to try and steal the machine back for a bit though. 🙂 I'll post again when I get a result.
@Ben wrote:
It is nice to read that the "Bytes at port" are still in the tool box of Bill and Tim.
Thought it was only myself that used that property.
Ben
The Bytes At Port has a very small window of use. The times I use it the most is just when I do not know when data is coming and I just want to check if a message has at least started, as I have already described in this thread. Where Bill and I find it to be evil is when it is used to tell the VISA Read how many bytes to read. In 99.99% of the instruments out there, there is a good protocol for the message the instrument sends out so that we know we have a proper message (termination character for ASCII protocols; start byte(s), message ID and/or message length, possibly a CRC for binary/hex/raw byte protocols). Use the protocol and the VISA buffer instead of the Bytes At Port and your life will get A LOT simpler.
@Jessica_2067 wrote:I see that you have the VISA serial configuration set up outside the loop. Do I need that in the program? I set it up close to how you have it and it didn't do anything.
Most likely due to the configuration not being right, most common issue being the Baud Rate.
As far as necessity of the VISA Configure Serial Port, I find it best to have it in there so that your application makes sure the settings are correct. With the code you originally posted, you are relying on the configuration in MAX being correct. But I have seen plenty of technicians mess around in MAX and break something. So try to lock things down as much as possible.
I did this below. I had the config vi in there initially too. Tried it this way and the other way and it didn't acknowledge the scan, when I got it to finally scan. I am thinking that the way I set it up is now incorrect.
@Jessica_2067 wrote:
I did this below. I had the config vi in there initially too. Tried it this way and the other way and it didn't acknowledge the scan, when I got it to finally scan. I am thinking that the way I set it up is now incorrect.
The VISA Configure should be outside the bigger loop. So should the VISA close.
The Default Values.Reinit belongs outside the loop as well, and that's only if you need it. I really doubt you would. Right now you'd have an issue that if you press the stop button, the Reinit would reset it back to false before the terminal has a chance to be read unless you happen to press the Stop button at just the right time.
@RavensFan wrote:
@Jessica_2067 wrote:
I did this below. I had the config vi in there initially too. Tried it this way and the other way and it didn't acknowledge the scan, when I got it to finally scan. I am thinking that the way I set it up is now incorrect.
The VISA Configure should be outside the bigger loop. So should the VISA close.
The Default Values.Reinit belongs outside the loop as well, and that's only if you need it. I really doubt you would. Right now you'd have an issue that if you press the stop button, the Reinit would reset it back to false before the terminal has a chance to be read unless you happen to press the Stop button at just the right time.
I was trying to set it up so that the "captured" indicator and "Panel Barcode" string would stay populated longer and then reinitialize it to default/empty before the next read. It didn't work and I never took it out; It is now.
