Serial communications through USB, problems receiving

[Hobbs23]

Hello Labview gurus

I have a device under development that I have the first run of. It is a Sig Gen. I can tell it what to do and it does it. I can not get anymore from it than an echo of what I send it.

I am using LV2009 f3 Basic, and have tried NiMax while watching trace. Everything seems great until I just do a "CONF", and it is supposed to spit out a few lines of register information. All I get back, is CONF

I use Realterm and it works no problem, or Hyperterminal. I do get some errors from IO Trace about configuration inconsistencies, but not sure where to go. I have fiddled with all kinds of settings through visa to no avail. I can comm other test equip ok.

Can someone give me a boost up?

[Blokk]

You should share more info about this "Sig Gen". Do you have a documentation for it? Does it use RS232 protocol? Does it use a termination character to mark ends of the requests/responses?

Did you test the unit from MAX? If so, what settings did you use for the serial comm (baud rate, term char, etc)? Did you use the proper settings required for this particular unit?

[Hobbs23]

Thanks for the response

It uses RS-232 protocol over usb. No docs yet. most settings are typical. in realterm or hyperterminal, I set the following: baud=115200, n, 8, 1, no flow control, EOL is +CR. How the terms I mentioned relate to others in NI-Max that seem the same is confusing.

I did use MAX and it did not find and errors with my settings, but when I wrote the CONF, it complained of timouts.

Now I totally believe the problem is either my ignorance with the protocol, (used to BBS back in the day) but have forgotten alot, or with LabView. LabView is so flexible Whereas the terminal programs just work after a few settings. 

[crossrulz · Accepted solution]

---

Hobbs23 wrote:

I am using LV2009 f3 Basic, and have tried NiMax while watching trace. Everything seems great until I just do a "CONF", and it is supposed to spit out a few lines of register information. All I get back, is CONF

---

Assuming you have the termination character turned on (which you should based on what you have already posted), then the VISA Read will only read 1 of the returned lines.  Just perform more reads when you expect more lines.

[Hobbs23]

Yes I think so. The bottom pic is the init section as you can see. To the left is that vi that you see in the bottom pic. I have heard that this is not the best way to do the receive from what I have been able to pick out. That may be why as you indicated. but what are your thoughts on what you see to the left?

[Hobbs23]

YYYEEEAAAYYYYY!!! I added 4 of those sub vi's I showed you a pick of, and I got 3 out of 5 or 6 lines that he sends. Fine tunning suggestions for Monday?

[Blokk]

Do not use the "bytes at port" method to read the response. You have a device which uses a termination character. Just after you send a request with a VISA Write, you can use a single VISA Read in a FOR loop, and set the iteration number to the expected number of lines. But I am just repeating crossrulz 🙂

[crossrulz]

---

@Blokk wrote:

Do not use the "bytes at port" method to read the response. You have a device which uses a termination character. Just after you send a request with a VISA Write, you can use a single VISA Read in a FOR loop, and set the iteration number to the expected number of lines. But I am just repeating crossrulz 🙂

---

Just to clarify some...

DO NOT USE THE BYTES AT PORT!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! (still not enough emphasis)

When you have the termination character turn on (which you do), the VISA Read will stop reading on the first of the following conditions:

1. It reads the number of bytes specified

2. The termination character is read

3. The read times out.

So to do a proper read, all you need to do is use VISA Read and tell it to read more bytes than you ever expect in a line.  I tend to use 50.  This way, the read will end with condition 2.

So again, all your subVI needs to be is a FOR loop to read N lines.  Inside the loop is just a VISA Read with a large value for the number of bytes to read.

[Hobbs23]

Now those are the kind of responses that start my Monday off great. Since you only used all caps and did not increase the font size, I can conclude the "bytes at port" is ok for some times.... maybe next time.... but not this time. 😉

Thanks guys!!

[crossrulz]

---

@Hobbs23 wrote:

Since you only used all caps and did not increase the font size, I can conclude the "bytes at port" is ok for some times

---

I have 1 valid situation for the Bytes At Port and it is used to determine if a message has started, not to tell the VISA Read how many bytes to read.  I really need to get my nuggets finalized...