Serial communications with Windows 7

[Integrator_Dave]

Hi,

I have serial I/O application which was wriiten written in CVI v7.0  and has been running happily for sometime on an Windows XP machine. The user has just updated the PC to Windows 7 and although the application is able to recieve data it does not transmit commands relaibly via the inbuilt COM port.

Are there any know issues with CVI/7.0 applications running under Windows 7?

Many thanks

[rsw]

Hi,

CVI 7.0 applications dont have official Windows 7 support which could explain the issues you're seeing, although the fact it works (just not reliably) it's probably also worth checking the code for timing as the Windows 7 OS may be working faster than XP (especially if its a different or upgraded PC) which is showing these reliability issues up.

Failing that if you're able to load it on an updated version of CVI (or Evaluation copy of it) to see if this helps it will help narrow down the issue.

Kind Regards,

[Integrator_Dave]

Hi Rob,

Thanks for your reply,

I did re-compile the application with CVI 2009 but still had the same issue. I then, through trial and error found that I had to insert a 10ms delay after the ComWrt command even though the ComWrt return status said all the characters had been sent and then GetOutQLen returned zero... See code snippet below...

int n;

unsigned char cmd[512]={0};

cmd[0]=0x0;

cmd[1]=0x6;

cmd[2]=0x0;

cmd[4]=0x2;

cmd[5]=0x0;

cmd[6]=0x8;

n = ComWrt( 1, cmd, 6);             // n = 6

n = GetOurLen ( 1 );                   // n = 0

Delay(0.01);                                // Need small delay here otherwise message not send!

FlushOutQ(1);

I also had to vary the delay time according to the length of the message i.e. <50 charactes 0.01 secs, >150 characters - .03 secs.

Hope this make sense. I have a working solution but still not sure why this wait is required. It worked fine on an XP machine and you are right, the new PC has a faster processor.

Regards

Dave

[RobertoBozzolo]

Hi Dave,

How is your port opened? OpenComConfig accepts -1 in output queue size parameter, which means Windows output queue is not used and message is written directly to the port. This option has solved some problems I had in the past and may have beneficial effects for you too.

Additionally, it may be a typo in your message, but you are not filling byte cmd[3] but are filling cmd[6] instead, which is not sent since you are sending 6 characters, that is from cmd[0] to cmd[5].

[labc]

Hi, Glassglimmer,

Wait time is always required for serial communication, especially to retrieve something after sending out a command.

My experiece of controlling a serial power meter in LabVIEW,  is to check it on a slower PC, record the safe waitting time, and then apply it on all clients. This helps in CVI as well. 

Waitting time varies with command size, returned characters size, PC processing capacities, oh, just like you were trying. If project is not time-sensitive, you might set it to 1~3 seconds.

[Integrator_Dave]

Hi,

I had a serial port sniffer running to watch the ougoing and incoming data packets and without the wait the characters were not being sent, it was not that I needed the delay for the receiving instrument to reply.

I have done a lot of serial comms applications and this is the first where I had to add a wait post the write command to ensure the characters were sent. As mentioned, without this wait characters were being transmitted intermittantly.

[Integrator_Dave]

Hi,

The post is bening opened using OpenComConfig with Tx and Rx queue sizes of 512. I will try 1 as you suggest for the out queue.

The cmd[3], cmd[6] is a typing error by me.

Thanks

Dave

[RobertoBozzolo]

Dave,

have you tried commenting out the FlushOutQ immediately after ComWrt? If your PC is significantly faster that the older one and you are using Windows buffers it could happen that the queue is flushed before it is sent out the port! In this respect, adding a wait is a good cure for a bad habit

Why you have used that FlushOutQ after writing? It seems better to me to call it before writing, to be sure that no unwanted characters are present in the buffer that the target device may not recognize.

Warning: use -1 in output buffer size; look at the help for that parameter

[jr_2005]

I'm with Roberto on this one - you should not call FlushOutQ() just after writing data, as this will discard the output queue. (This is perhaps counter-intuitive, since the similar fflush() for file operations forces a write to file to take place.)

JR

[Integrator_Dave]

Thanks Guys,

You have given me a couple of things to look at - the output queue size and buffer flushing.

As mentioned originally, this application had been running for a couple of years on an XP machine without any issues. There is a lot of serial communications with the instrument  - an automotive ECU and I was looking for a quick answer. It is running at the moment and next time I'm on-site I'll experiment with what you suggest.

Regards

Dave