problem with serial communication

[staunton]

Im having a problem with serial communication in labVIEW, Im trying to access registers in a chip on a modem,
I can do this sucessfully in hyperterminal using the commands "rd" and "wr"(I have included a example hyperterminal session below), to start off i tried the loopback test for serial communication and this works as expected.
Then i tried a simple serial interface using the "serial communication VI" got in the find examples menu in labVIEW(i modified this vi slightly to use a delay after writing).
Here proved the problem when i used this VI (initalising correctly with baud rate) i sent the command "rd 8f02"(with a carrige return character) where 8f02 is a known register in the chip, the returned string was
r f2
8F02 : 01
M>
which is as expected, except the first line "r f2" this is the given command with every second character displayed,
i dont know why these characters are looping back i tried increasing the delay after write but it did not change it.
does anyone have any ideas?
My goal is a program to send a txt file of such writing to and reading from commands to the modem.
regards,

Staunton
PS: im using labVIEW ver 6.1

[mikeporter]

Don't have any specific ideas except that for it to be doing something this strange (ever other character being echoed)the thing must be doing it on purpose. If it does this reliably, I'd say just trim off everything up to and including the address (in this case the "8F02 : ", convert the next two characters into a byte, save it and call it done.

Mike...

[Ben]

Wild guess,

The modem is set to "echo"
and
you are lossing every other character (maybe due to u16 vs u8).

Just a guess!

Post your code, we do better with pictures.

Ben

[staunton]

thanks for your responses,
I have attached a example vi, which for me is just the serial communication vi (shipped with labVIEW) slightly modded.
the suggestion that the modem is set to echo is plausible, what do you mean by "....maybe due to u16 vs u8"
thanks again for taking the time,
Kevin Staunton

[staunton]

Any ideas welcome

[Ben]

Hi Staunton,

I generally only allow myself to answer Q's first thing in the AM (Gotta feed the family).

Not knowing what you were doing in the code I was forced to guess. The U8 vs U16 thing was just a guess based on the apparent loss of every other charcter. Now that I have seen your code, forget that!

Re: your code.

LV uses "Data dependencies" to determine execution order. Your "wait" that you inserted between the transmit and recieve does NOT recieve data from the transmit and does NOT send data to the recieve case.
So,
there are no data dependencies to determine when the "wait" executes. If you watch it in "execution highlighting" mode it may apear that way, but when the code is running, Lv will do the "wait" anytime it fe
els like it! It could be before, after or durring any of the other operations.

To force it to happen after the send and before the recieve you have to wire it up to the other "blocks" in the place you want it to happen.

Did you try shutting down local echo?

Shut off local echo, re-wire your diagram, and let us know if anything is different.

Ben

[Dennis_Knutson]

A couple of things that you might want to change. One, your write is not terminated with anything. Most serial communications require a LF or CR/LF. Secondly, your 500 msec delay has no dataflow connecting it to the write operation so there is no guarantee that the delay will occur after the write. Those things in LabVIEW with no dataflow, LabVIEW will attempt to execute in parallel. Wire your VISA ref and error cluster to the case structure and through it for both cases in order to force a delay after the write. Thirdly, add a VISA Flush I/O Buffer after you initialize the serial port. Fourthly, what I always do is use the VISA Bytes at Serial Port to determine how many bytes to read instead of a fixed byte count. Put that and the VISA Rea
d inside a while loop and read until there are no more bytes available, the termination character is read, or a timeout condition happens. Imho, the shipping examples of serial communication are not very robust. Look for other examples posted to this forum.

[LarzQuest]

I happened across this thread by searching for the symptoms matching a problem I am having with a "black box"

parallel to serial conversion cable. I don't know if the problem here could be related but, I too am only receiving every-

other character at the serial port. However, the SERIAL portion of the device is NOT the problem. It is the handshaking

from the parallel port of the machine I am interested in capturing the printer output from. The reason I say that is because,

it works well with parallel ports from other computers. I don't believe that the machine (LPT) is defective (because it

prints great) but, it is obviously configured differently that the others I have tested (SPP, ECP, EPP?). I am still trying

to narrow it down. Anyway, it makes me wonder if you might not have a handshaking problem (of a sort) also? Good luck.

Lp