labwindows 7.1 ComRdTerm problem

[Homa]

Hi

I am working in project which uses 4 com ports. I am using InstallComcallBack(com1,LWRS_RXFLAG,LF,MyFunction1) Funation

for each com port.Instrument transmits plain text and termination char is LF. My callBack function

Void CVICALLBACK MyFunction1(int com eventMask, void *callbackdata)

{

     memset(buff,0,150);

    if(eventMask &LWRS_RXFLAG)

   {

       count=ComRdTerm(com,buff,150,LF);

       if(count>0)

       {

            buff[count]='\0';

            dosomting with buff...........

        }

   }

  return;

}

I expect t see buff contain : <1020> 99.00, 99.00, 99.00

after sevark min i get error and my buff cotains: <1020> 99.00, 9991>1

is this a known problem ? or I am missing somthing

Thanks in advance

Homa

[MJF]

No, it isn't a known problem. The callback mechanism works quite well.

Are you certain that the device you are communicating with is not producing erroneous data?

You say it produces an error, what is the error code you get?

Use ReturnRS232Err() to get the code and if it is -1, it is a Windows system error. In that case, you will need to use GetRS232ErrorString() to get a description of the problem.

If you are using memset() to zero your buffer each time the callback is triggered, the assignment of buff[count] = '\0'; is not needed. It won't hurt anything (unless the buffer overflows and then it will give a GPF), but there is no need for it.

[Homa]

Thank you for comment on memset function.

The error I am getting is related to the function which  I am trying to parse the reply. The reply from the unit I am getting is alway the same.

when the reply is not what I expected  let say I am searching for 3 commas and  I get only one,  I look at the buffer and  my buffer shows

<1020> 99.00, 9991>1

instaed of

 <1020> 99.00, 99.00, 99.00, 99.00

[msaxon]

It looks to me like some characters have gone missing. Have you set up hardware or software flow control? What baud rate is the interface running at? What RS-232 hardware devices are you using on the PC, and do they have their FIFO buffers (if any) enabled?

[MJF]

Yes, I understood that the buffer has the wrong data in it, but that does not mean that your instrument is delivering the data you think it is. It could be working fine, then again, it could be the cause of the problem. One way to verify that the instrument is not a problem is to use a terminal program like ProComm or something similar to monitor the output. Depending on how your instrument functions, it may be as simple as just monitoring the output for a while or it could involve a short script to query the instrument periodically. If the instrument has to be queried to get the output, you may be trying to query it too fast.

Martin's suggestions about checking the serial port configuration are good ones. I would suggest that if you are trying to run at a very high baud rate that you try to use a slower one to see if that helps. Also, when running at high baud rates, you should use hardware flow control if the instrument supports it. Synchronization and buffer management are much more important at higher baud rates.

[Homa]

Hi

My system uses USB Serial Adapter ( 230 kbps )  baud rates for 2 port set for 34800 and one port sets for 19200

The receive  FIFO buffer is enabled (size=16).

port setup:

OpenComPort(port,"",baud,0,1,4096)

SetCTSMode(port,LWRS_HWHANDSHAKE_OFF)

SetXMode(port,0)

SetComTime(port,2.0)

Looking at the bad data in my buffer tells not only  missing characters, but wrong data ( >) and (1) in a wrong place.

is hard to say what went wrong.

Homa

[MJF]

OK, those baud rates for the devices are pretty sane so that should not be a problem even with hardware flow control shut off.

I would suggest as a next step that you try connecting one of the devices directly to a serial port on the PC (if one is available) to try to eliminate the USB adapter as a problem. If you have not tried accessing the device with a terminal program, I would also suggest doing that as I mentioned above. You may also want to try the probram on a different computer to make sure the computer hardware is not causing the problem.

Right now, you have too many variables, you need to isolate the problem to determine where it is coming from.

[menchar]

We've had problems with USB - rs232 converter thingies (dongles).  In particular, on a multi-core (hyper threaded and/or multi-processor) system, we've had to turn off hyperthreading to get them to work at all.  And the first one we got wouldn't work reliably no matter what we did with it.

We gave up on the USB / rs232 converters and used NI 843x multiport serial boards, which NI asserts to specifically be hyper-thread compatable.

A great freeware program to use with figuring out all things serial is terminal.exe  from http://bray.velenje.cx/avr/terminal

Menchar

[MJF]

Well, I don't know what to say to that. One of the products I am developing test code for uses a virtual COM port over USB type of driver to implement a command interface via USB to the hardware. This USB to RS-232 converter is actually built into our product (it was easier and cheaper to implement the USB interface that way than to try to do it another way). We run that interface at a baud rate of 460800.

I've never had a problem communicating with it, it does not drop data and it is very robust. So I can only say that at least one implementation of such an interface works great.

[menchar]

Well, it's all true.

I've seen some dialogue somewhere that claimed that most of the USB-rs232 converter designs are flakey, only three or four are "industrial strength" designs, NI's being one of them.  The ones we had were cheapos bought at CompUSA or the equaivalent.

All I'm saying is that there are plenty of poor implementations of USB / rs-232 converters out there.

Menchar