07-05-2006 01:48 PM
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
07-05-2006 05:54 PM
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.
07-05-2006 07:09 PM
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
07-06-2006 07:56 AM
07-06-2006 10:09 AM
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.
07-06-2006 11:43 AM
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
07-06-2006 11:54 AM
07-10-2006 12:11 PM
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
07-10-2006 12:45 PM
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.
07-10-2006 01:14 PM
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