Serial communications through USB, problems receiving

[arteitle]

The for loop with the "Bytes at Port" is unnecessary, except possibly as a way to manually stop the while loop with the "Stop" button without having to wait for the VISA Read to time out, was that the intent? Otherwise, as has been said numerous times in this thread, don't use Bytes at Port! It's almost never the right way to do a VISA Read.

There's also no purpose to the 10 ms wait alongside the VISA Read, or the conditional stop terminal based on the iteration number being greater than 9, because it's never going to be greater than 9, since the for loop is hard-wired to run at most 10 times (meaning the iteration number will be at most 9).

You should keep "Bytes to Read" set to a number larger than the longest string you expect to receive; usually an excessively large number is fine. If you set it shorter, your received strings will get broken up. Don't set it to 1 unless you really only expect to receive a whole string that's just one byte (which would just be the termination character). The way you've built it, once you start receiving, your VISA Read will time out if you don't receive either 10 terminated strings in a row, or fewer strings as long as the last one contains "READY". If either of those conditions aren't met, the VISA Read will be left waiting until it times out. Does the transmitter always send either ten strings at a time, or fewer strings ending with "READY"? Looking at your log, maybe the "READY" string does not end with the termination character?

[Hobbs23]

Thanks for your reply.

Yes the only reason I use the Bytes at port is to know if the Sig Gen wants to reply. I removed the delay, and the stop at iteration. The Engineer designing this said if I looked for "Ready" followed by a carriage return, I shouldn't expect more in the buffer.

I set the Byte Count to 50 because nothing will be that big in the buffer.

The loop is set to 10 with the same logic, Could that be my problem?

I looked up the error code in the Help, and it suggested seeing if putting bytes at 1 caused the error to go away, thinking I was waiting for a byte that would never come.

Help also suggested using Bytes at port wired directly into receives "Byte Count" input. I tried this and got the same error.

[RavensFan]

Are you sure you have the right termination character?

You have it set to D in the configuration settings.  I can assume that the constant is set for Hex display (show the radix on that so it is obvious) since there is no other way to have a letter appear in an integer constant.  Hex D is 13 or a carriage return.  If the device is using line feeds as the termination character, then you should set that constant to A hex.

Something is very odd about that read.  the trace shows two reads.  It looks like it gets two characters (unprintable represented by the period), the 2nd one must be a CR in order for it to end the read.  Then it proceeds to read ".READY>" perhaps another unprintable character (maybe a line feed)?  and then READY and a greater than.

Something is not right as you are not getting a carriage return within 2 seconds of that READY> message coming in.

[Hobbs23]

Thanks for responding.

I called out the largest buffer receive that the Sig Gen will send to give another point of view. I also show the receive portion with the things removed and you can see the radix set. This is the whole test receive vi so I can replace/destroy whatever.

Finally, Is there anyway I can sample the raw receive feed? Maybe with another program you may be familiar with that will show if there are or are not additional things going on. I'm willing!

[arteitle]

Pretty sure that timeout is happening because the "READY>" string you're receiving doesn't end with your termination character. Presumably this is meant to be a command prompt. Unfortunately, having to deal with two different termination characters complicates things, because VISA can only be configured for one. If you know when to expect a line with a different termination character, you can change that port setting to the new character just for that line, then change it back. On the other hand, if any received line could end with either character, you pretty much have to switch to reading one byte at a time into a buffer and testing each received byte for a match.

[Hobbs23]

Sounds like it is time to talk with Engineering. Is their another terminal program that would bring what you describe out in the light for the code guy to see when I talk to him tomorrow?

Thanks for the response

[Hobbs23]

Closing the loop!

Both Arteitle, and Ravensfan were correct in their determination that something wasn't right about the "READY"!

I talked to the Engineer today about it, and he confirmed that everywhere in the program they terminate what they send except.... the "READY>".

After I shared our discussion, and the volume of lines to grab the received information one character at a time on NI I/O Trace, he decided to also terminate the "READY>".

The EOL

😉

[RavensFan]

That's good.

It seems like you've been able to teach that programmer a lesson in programming!