Problem connecting RS232 devices

[Paolo_P]

Just as an additionnal suggestion, have you tried to send {1,000 flowrate set} instead of {1.000 flowrate set}

You can use NI IO Trace to better debug the communication between your instrument and your computer

http://search.ni.com/nisearch/app/main/p/bot/no/ap/tech/lang/fr/pg/1/sn/ssnav:drv/q/NI%20IO%20Trace/

[Hooovahh]

I'd recommend starting with the Simple Serial example found in the example finder by going to Help >> Find Examples and searching for it.  It will send out a command to read the ID of the device (which most devices respond to), wait a bit, then read the data at the bus.  If this doesn't work, you could have a null modem issue, where your device expects the TX and RX lines of your serial communication to be swapped.  This is assuming you are using the correct COM port, and baud settings.

[RavensFan]

---

@Hooovahh wrote:

I'd recommend starting with the Simple Serial example found in the example finder by going to Help >> Find Examples and searching for it.  It will send out a command to read the ID of the device (which most devices respond to), wait a bit, then read the data at the bus.  I

---

I'd be careful about saying that.  Most deviced don't respond to the IDN? command.  Only devices that would be called "instruments" do.  Those high end devices, like oscilloscopes, digital analyzers, power supplies.

So many questions come through the forums where people wonder why things weren't working and it turns out they are just using the simple serial example (which isn't that good of an example in my opinion) and they didn't even bother changing anything, like replacing the default IDN? command, with something that is known to work with their device.  Many times because thay haven't even opened the manual that came with the device to see what the commands should be.

[CWT52]

Hi Daniel,

I have looked over your program and the manual for the pump. I personally don't use NI MAX or the sample serial program for reasons listed by Ravens Fan. I usually find it easier to just start with a blank VI and program a simple command from the manual to test out communications. With that being said, I went ahead and put together a small program for you to test out.

One thing I like to do with serial hardware is include Wait functions to allow the hardware time to accept the commands I'm sending it and to respond back to my program. More than likely, the hardware (especially if it's old) will have some latency that you will want to account for.

Please have a look at the attached program and let me know if you have any questions or if you're still getting errors.

Also, the VI is written with LabVIEW 2015. If you need an earlier version, just let me know.

Hope this helps,

Cory

[arteitle]

---

@Daniel_CB wrote:

Dear aputman,

Thanks for this comment. I think that my problem should be mainly that. The JASCO communication protocol (attached in my first post) gives the following example.

Set the flow rate to 1.000 mL/min

value  command

{1.000 flowrate set}

and then it says "Note: Communucation command is terminated with CR (0x0d). Any LF (0x0a) code included in a seris of the commands are ignored. Data (value and command) is delimited by space (0x20)."

And then it gives the following example:

[1][.][0][0][0][0x20][f][l][o][r][r][a][t][e][0x20][s][e][t][0x0d]

However, I think that the command that I introduce in the NI MAX (1.000 flowrate set), is "translated" by the NI MAX to 1.000\sflowrate\sset.

I wonder if the space (\s) that NI MAX sets into my command is equivalent to [0x20], and I also wonder if I should include the [0x0d] at the end (which I assume is \r), or if by selecting any of the ticks and options of the configuration/ IO settings of the NI MAX is not necesary.

Do you know how can I send a proper command compatible with my particular communication protocol?

Thanks a lot!

---

The byte-by-byte breakdown provided in the manual shows that the curly braces are not meant to be part of the command, so make sure you're not sending those. the \s that appears when you type a space is to be expected when a string is displayed with '\' Codes Display selected; any whitespace character (e.g. space, tab, CR, or LF) will be shown in its backslash form (e.g. \s, \t, \r, \n). So with backslash codes display selected, the sample command would look like 1.000\sflowrate\sset\r .

Aaron T.

[Daniel_CB]

Hello everyone.

Sorry for answering late. I would like to thank you all for your valuable help. I tried all what you suggested and unfortunately it did not work.

Here I will answer more or less your messages and explain what I have tested.

_______________________________________________________________________________

-aputman:

I tried what you mention of “codes display”. Is true that when I write “event load p” it is translated to “event\sload\sp”. I tried to add brackets and \r at the end. I made different combinations and I could not solve it.

-Paolo_P:

I tried using “,” and “.” without any result. In fact I also tried other commands that do not have any “.” and the error was the same. I have no experience in the use of NI IO trace. It seems a good way to figure out what is the problem, however I should take a look at examples and/or tutorials. Any suggestion?

-Hooovahh:

In the NI MAX interface there is a command “*IDN?\n” which I tried the first. It did not work. I tried to change the \n by \r and also did not work. I assume that this is because the reasons explained by RavensFan

-RavensFan:

I read in other threads of this forum and I found what you mentioned (that the IDN?\n command is not “universal” for all the machines). I assume this is the reason why it does not work in my case.

-CWT52

Thanks for your comment, I was not able to download your file, but I included waiting functions as in the vi I attach. I am not sure this is what you suggested, however it did not work as I coded it. Could you please send me the file in an older version of labview? Thanks!

-arteitle

Thanks for your clarification. Nevertheless, it did not work.

_______________________________________________________________________________

I have other hypotheses on the source of error. These are:

-The cable that transforms RS232 to USB is not fully “compatible”:

I am not sure that the cable is working properly. I performed the loopback test (suggested by the NI forum) by shorting pins 2 and 3 of the RS232 plug. I successfully received the test string sent by the vi.

However, I have my doubts about the RS232/USB cable since when I “view attributes” in the NI MAX, the last property “is port connected” says invalid property. I read elsewhere in this forum that one should ignore this “error” but I am not sure about that.

-The pump is not receiving the signal sent by the computer: I really don’t know how to verify this. Is there any “loopback” test that I could perform to verify if the pump connection is working properly?

Once again thanks a lot for your help!

[Hooovahh]

---

@RavensFan wrote:

---

@Hooovahh wrote:

I'd recommend starting with the Simple Serial example found in the example finder by going to Help >> Find Examples and searching for it.  It will send out a command to read the ID of the device (which most devices respond to), wait a bit, then read the data at the bus.  I

---

I'd be careful about saying that.  Most deviced don't respond to the IDN? command.  Only devices that would be called "instruments" do.  Those high end devices, like oscilloscopes, digital analyzers, power supplies.

---

Let me rephrase it.  The IDN? command is the single command that the most devices I've used will react to.  There is no other single command, that I can think of that will detect the present of a serial device.  I didn't mean to say most serial devices will respond (implying more than 50% of the devices in the world will reply which I can't know for certain), but instead that this one command will work on more devices than any other one command.  Reading the data sheet on the hardware is the correct approach in determining what you device will respond to.

[CWT52]

Hi Daniel,

I have reattached the program. It should work in LabVIEW 8.5 and up.

Let me know if you have any questions.

Cory

[billko]

First of all, you shouldn't be using bytes at port and wait at all.  Instead you should be enabling termination, setting to termination character to LF (0x0A) and using Trim Whitespace.vi to delete the CR (0x0D).

Instead of waiting x amount of seconds to allow the equipment to respond, you should be reading the response right away.  I see nothing in the manual to indicate that you actualy have to wait for anything.  This begs for conversion to state machine.

After init, instead of waiting half a second, you should probably be polling to see when your equipment is actually ready, rather than waiting until you are completely sure it is ready.  Besides just wasting time, it may be that one day for some goofy reason, your equipment is not ready on time.

I think this will start working if you do these things.

[billko]

Oh, and with any kind of communications error, you might have to reset or even turn the equipment off and on before you can communicate with it again.