serial modem communication

[Jerry In Maine]

...so my boss found out that I USED to do some hobby programming in Borlands C++ BUILDER years ago and he thinks that makes me the resident programming "expert".  He bought LabVIEW  and despite the fact that I've never seen it before he tossed it to me and said "'you da man!"...

He's ordered  device that connects multiple monitoring instruments to a serial port.  He want me to produce a app that'll eventually grab the data it logs and save it to a file. Sounds pretty easy ---

To begin  I connected a modem as a device to test with and made sure I could talk  to it via AT commands  with HyperTerminal. I've spent considerable time since trying to cook something up to communicate with no luck - and then tried lvterm.vi (found it here). I'm hoping it'll give me some insight and I can mod it as needed.

LVTerm seems to allow me to set the port parameters get an echo of what I type but I can't get the typical responses to the AT commands (followed with /r/n).  I can see my modems Rx & Tx light blink - but that's all.

I've never played with apps that work with ports (even in C++)....anyone have any tips or references that might help? LabVIEW seems pretty robust with regard to this sort of thing so it can't be too tough.

thanks -

[RavensFan]

It is good to start with hyperterminal.  If you can't get it working in hyperterminal, then you will certainly have problems with LabVIEW.

Make sure you have the right kind of cable.  Whether it needs to be null modem or straight through.  Many devices might use a null modem cable.  Cables for modems tend to be straight through, or of DB9 to DB25 variety.

The other thing to check is baud rate, data bits, stop bits, and parity.

There are several things that are good to have in a toolkit for working with serial ports.

1.  A couple of straight through cables.

2.  A couple of null modem cables.

3.  DB9 to DB25 adapters, and the opposite direction as well.

4.  Several M/M and F/F gender benders.

5.  A null modem apapter (similar to a null modem cable, but it is in a simple box like a gender bender to make it easier to change between the two types of cables without adding another cable.)

6.  Loop back tester (Feeds TX back to RX so serial port can talk back to itself, also the handshaking lines loop back)

7.  An inline tester where the lights light up on each line to show you the activity.

8.  A breakout box.  Let's you use test out different wirings in the event you are using a device that doesn't use a standard DCE or DTE configuration.

9.  A Y-adapter.  It has a second tap into the line.  Gives you a chance to monitor the communication stream between two different devices.

10  RS-485 to RS-232 adapters.  In case you are working with any devices that use RS-485 serial ports.

11.  DB9 terminal strips.  DB9 on one side, terminal strip on the other, so you can adapt loose pigtail wiring to your PC.

These are the things I have in my toolkit.  You don't need to acquire all of them at once.  Acquire them as you find you need them.  But definitely get the first 6 or 7.

Also, make sure you look through all the serial examples in the Example Finder in LabVIEW for the software side.

Message Edited by Ravens Fan on 09-06-2009 11:42 AM

[Jerry In Maine]

Thanks!

I have a straight-through cable on the modem now.  Using one of the example apps I got  framing errors when I sent the modem a AT&VI - which causes it to give an extended response showing the parameters of its various registers.  A framing error tells me that there's data coming back and that something like baud, parity, etc is not set the same on DTE and DCE.  I went through all possible variations with no luck.

With lvterm.vi I can't even get the usual "OK" response to commands.

So - I think I might be 96.5% "there" but it's that last little bit that can be such a PITA.

Anyone please chime in if you think you might have something that would help.  The dent in my desk where I bang my head is getting pretty deep.

[Jerry In Maine]

Seems odd that I can see the modem echo the characters I send but not respond to AT commands. I must be initializing the port and connecting to the modem OK.

Changing baud/parity/bits doesn't help....

[Jerry In Maine]

I give up. Head scratching, searching these forums, Google yield very little on this.

Not even anything from the field reps.  From what I read about VISA prior I figured this would be pretty straight forward.

Live and learn I s'pose...

[Dennis_Knutson]

Can you explain what this LVTerm is and how you are using it? If there is a string you are sending, enter it into the control/constant and go to the edit menu and select 'Make current values default'. Post the VI.

What about the serial examples that come with LabVIEW? Have you tried either of those?

[smercurio_fc]

LVTerm was an old example to make a VI that operated sort of like HyperTerminal. 

OK, let's back up a second here. Did you say you have it working with HyperTerminal? What are your settings in HyperTerminal (including the terminal and ASCII setup) ?

Message Edited by smercurio_fc on 09-08-2009 04:16 PM

[Jerry In Maine]

I can send successfully send AT commands to the modem via Hyperterminal. For example, sending ATH0 or ATH1 will take the modem on / off hook. AT&VI will display the data stored in the various registers.

Attached is a .vi that I found on the forums here that I think would serve as a base for what I want to do with LV.  It's similar to what I came up with on my own so I don't feel too bad about using it - especially since the author said it worked well for him. With it I can send (for example) ATH1/R/N or ATH0/R/N and  take the modem on/off hook. I got success with this late last night after whining about having the trouble I've had.

-BUT-

I don't get the verbose responses  - or even the typical "OK" after sending a valid command like I do with Hyperterminal. Should I? Maybe the issue is my not understanding what to expect.  I do get the original command I sent w/o the "/r/n" suffix . I also do sometimes get framing errors to queries which tells me that baud/bits/parity might be incorrect, but since I can control the hook relay I assume that the modem and I are seeing eye to eye on parameters. Framing issues also indicate to me that there's some sort of data on the line from the modem. Summary is that I don't know if there data is there and I'm not accommodating it or if there's nothing there at all.

I get similar results with the various serial examples that ship with LV.

I figure that if I can see the verbose text responses from the modem I'll be able to do the same with other equipment that connect via a serial port and send data in response to particular commands. 

Thanks

Jerry

(in Maine - where the leaves are just fixin' to change into their autum colors) 

[Dennis_Knutson]

That image is next to worthless because it's impossible to know what you are sending and even if you showed the front panel, It's impossible to say whether the control is set to '\' Codes Display. And, if you are sending /r/n, that is wrong. It has to be \r\n.

Attach the actual code or if you are using LabVIEW 2009, attach a snippet.

[Jerry In Maine]

Sorry Dennis....I've had LabVIEW for all of about a week now so I'm tryin' to muddle through as best I can. I've seen other attach images of their block diagrams and I figured it was the thing to do.

Attached is the .vi, and I mistyped when I posted...I am indeed using the proper "\r\n"