RS232 Device Won't Communicate

[RyanR]

I am trying to control a laser head (M126N-1064-500 from JDSU) with the basic serial write/read vi labview provides in its examples. The device communicates with RS232, which I have plugged into a 4 port RS232 to USB hub from NI (Part #: USB-232/4). The RS232 is connected into port1 of the hub, and shows up as com3 in NI MAX. The manual for the device is attached, and has information on how to enter commands. I am fairly good with labview, but I have no experience or understanding of how to enter proper commands or what parameters must be met to properly control RS232 devices.

The attachments are as follows:

NPRO_M125-6_User_Manual - User manual for laser head and control box

S3010080 - Back of the laser control box

Untitled - screen shot which shows two attempts. The left side shows the command I entered that when run produced no response. The right side

shows the error produced by pressing the query button in an NI MAX test.

Can someone please help me (1) determine if I have made an error in the connection or parameter settings that would prevent communication, (2) show me the proper input of a command (examples are in manual but I can't get them to do anything), and (3) offer other advice I may be neglecting.

NPRO_M125-6_User_Manual.pdf

[ShaunR]

Not sure whether it should have spaces between the characters but CR and LF should be replaced with \n and \r. Try something like "esc040\n\r" (without quotes) if that doesn't work try the same with spaces. Make sure your string control in the left hand example is set to '\' Codes Display (right click menu). In the max example try the same. It's not SCPI compliant so it won't respond to an IDN? command.

Edited October 15, 2010 by ShaunR

[jdunham]

Not sure whether it should have spaces between the characters but CR and LF should be replaced with \n and \r. Try something like "esc040\n\r" (without quotes) if that doesn't work try the same with spaces. Make sure your string control in the left hand example is set to '\' Codes Display (right click menu). In the max example try the same. It's not SCPI compliant so it won't respond to an IDN? command.

Shaun is probably right about getting rid of spaces and of course using the correct end-of-line characters, but also check whether "esc" is supposed to be a single Escape character (\1B in slash code display).

The MAX routine is using SCPI commands, but given the commands you found in the manual, it's very unlikely that your instrument understand SCPI commands.

Also check baud rate, data, stop bits, and parity, and flow control for the serial port settings. You can set them directly in LabVIEW VISA.

Good luck.

[ShaunR]

but also check whether "esc" is supposed to be a single Escape character (\1B in slash code display).

Well spotted.

It says in the manual:

"The general protocol for Lightwave lasers consists of sending an ASCII “command string” with

the following format:

Escape lead-in char, command code, parameter, optional data, End of String."

So this is correct. So try "\1B 0 40 \n\r

[RyanR]

After trying to write "\1B040\n\r" in both the vi and the "test" tab of "communicate with instrument" in MAX I still am not receiving any indication of a response. The writing process seems to be working fine as the indicator lights on the USB-232/4 are flashing the sequence indicative of a write (and I receive no errors in either test). How do I troubleshoot if the write command is actually received by the instrument, and also if I am properly reading what the instrument returns. What should I expect as a response in the "Basic Serial Write and Read.vi"?

On the issue of whether spaces should be included, if I type "\1B 0 4 0 \n\r" in the write buffer, once I click out of it to run the vi, the '\' codes display automatically changes it to "\1B\s0\s4\s0\s\n\r"

I believe all the parameters are entered correctly (baud rate, parity, data bits, stop bits) as I have entered them as directed on page 32 of the manual. However, the manual includes "duplex: Full" which the vi does not, and the vi includes "flow control" ( which I have set to none) which the manual does not mention - do these matter?

[asbo]

Someone else raised the same "full duplex" question on stackoverflow. What I glean is that the duplex mode has no bearing on the flow control, so you should be able to use none.

Looking at their example for "Read Model # & Date", you should write "\1B40\n\r" (notice no spaces) and receive something like "125 dd MMM yy". If you get a garbled response, try changing the flow control around.

[ShaunR]

Actually. Reading a little more than a casual scan. They actually refer to bytes. So maybe we should be inputting "\1B\04\00\n\r"

A NAK is \15 which you wont see unless the string indicator is also set to either \ codes or hex display and an error is "?"

The other thing to check is that you are using a "crossover" rs232 cable (NI part number 182238-02) rather than a "straight through".

[asbo]

Actually. Reading a little more than a casual scan. They actually refer to bytes. So maybe we should be inputting "\1B\04\00\n\r"

Good call - with that in mind, sending "\1B40\n\r" is really sending "\1B\34\30\n\r". Definitely not the same thing.

[jdunham]

Have you called JDSU? They should be able to get you some help. Chances are you're not the first person who has had trouble with the interface. Especially given that whoever designed their protocol should be hung by his or her thumbs. If they have an example program and you have another serial port somewhere, you could run that into your first serial port and read it in LabVIEW and see what characters they are sending.

[EricLarsen]

The other thing to check is that you are using a "crossover" rs232 cable (NI part number 182238-02) rather than a "straight through".

Exactly. The first thing to check when using RS-232 is the cable itself. Was the cable provided by the laser manufacturer? If not, is it one you made yourself? There is no such thing as a "standard" RS-232 cable. Just because a cable worked on one instrument doesn't mean it will work on the next. At a minumum, try swapping pins 2 and 3. Sometimes that will work. The better option is to get a good RS-232 breakout box. If you spend any time at all in the serial world, that will save you hours of headaches.

[RyanR]

For the cable issue: I am using the NI USB-232/4 which is a 4 port hub for RS232 to 1 usb. As stated on the website http://sine.ni.com/nips/cds/view/p/lang/en/nid/14583 there is "DTE and DCE transceiver modes with automatic transceiver detection eliminates null modem cables" This should eliminate that problem, correct?

For the contacting JDSU issue: I have, and it took me over a week to get the following reponse to similar questions I've posted here: " We don’t/won’t provide any additional control program. The section on computer control states that control may be accomplished by sending specific ASCII strings through the RS232 port. This requires that the user write or have available a program that may accomplish this." Needless to say I have sought out different avenues to solve this problem before I take on the burden of getting any help out of them.

Lastly, referring to my earlier post that I believed the write processes were occuring without error: I attempted a loop-back test http://zone.ni.com/devzone/cda/tut/p/id/3450 which was successful. I am than left with the question, how do I trouble shoot if my device interprets the command properly, or if it is even sending commands to be read by the computer - how do I test these?

[jdunham]

For the cable issue: I am using the NI USB-232/4 which is a 4 port hub for RS232 to 1 usb. As stated on the website http://sine.ni.com/n...ng/en/nid/14583 there is "DTE and DCE transceiver modes with automatic transceiver detection eliminates null modem cables" This should eliminate that problem, correct?

For the contacting JDSU issue: I have, and it took me over a week to get the following reponse to similar questions I've posted here: " We don’t/won’t provide any additional control program. The section on computer control states that control may be accomplished by sending specific ASCII strings through the RS232 port. This requires that the user write or have available a program that may accomplish this." Needless to say I have sought out different avenues to solve this problem before I take on the burden of getting any help out of them.

Lastly, referring to my earlier post that I believed the write processes were occuring without error: I attempted a loop-back test http://zone.ni.com/d...a/tut/p/id/3450 which was successful. I am than left with the question, how do I trouble shoot if my device interprets the command properly, or if it is even sending commands to be read by the computer - how do I test these?

*sigh* Well I guess that's one of the many reasons JDSU's stock price went from $1100 down to $12, or I guess the fall from grace gutted their desire to offer decent tech support.

I looked at the manual a bit. Why don't you post the VI you are using? It would be easier to correct the VI than to describe how each byte should go. You definitely don't want any spaces or \s symbols. You need the escape char, and the laser number, command, and parameter bytes need to be plain numerals, that is, '1', not '\01'.

So when the manual says

The sequence

Byte 0 ESC ESC

Byte 1 Laser # 0

Byte 2 Command 9

Byte 3 Parameter D

Byte 4 MSB data D

Byte 5 next MSB data 5

Byte 6 next MSB data 5

Byte 7 LSB data 5

Byte 8 LF LF (a Control J on a terminal)

Byte 9 CR CR ( a Control M on a terminal)

Your string in '\' code display mode should look like: \1B09DD555\n\r.

Also the manual says that if you send it an S (maybe with a LFCR, not sure) then it should start spitting data back at you for display on the terminal screen. If you send S and get nothing, then keep checking your cable and your serial port settings. If you get a stream of data but you can't stop it with a properly-formatted command, then check your command building.

[EricLarsen]

For the cable issue: I am using the NI USB-232/4 which is a 4 port hub for RS232 to 1 usb. As stated on the website http://sine.ni.com/n...ng/en/nid/14583 there is "DTE and DCE transceiver modes with automatic transceiver detection eliminates null modem cables" This should eliminate that problem, correct?

Should elimiate the problem? Maybe. Does it? I wouldn't count on it. It still sounds to me like a cabling issue. If you have a null modem, try it. But null modems don't always solve the problem, especially if they are 25 pin null modems and you are using adapters go to 9 pin connectors. Often times that combination disrupts the ground connection. If you can easily swap pins 2 and 3, that's worth a shot. But I really encourage you to get a break out box.

[Cat]

For the cable issue: I am using the NI USB-232/4 which is a 4 port hub for RS232 to 1 usb.

I've been fighting with a USB hub arbitrarily changing COM ports on me lately. Probably not your problem, but is there any way for you to directly connect the serial ports and not go thru the USB hub (might need a crossover cable)? Eliminate potential hardware issues...

[RyanR]

Thanks for all the help everyone. I got it working today. The device pinouts were totally unconventional, which would not let the straight rs232 or null modem cables to work properly. I ended up going to radio shack and making my own.

For all those helping with the commands, the proper string does look like "\1B040\n\r" as you all figured out.

Thanks again.