Can OpenComConfig() handle 1,000,000 bps for "baudRate" ?

[CviUser2003]

Can OpenComConfig() handle 1,000,000 bps for "baudRate" ?

I am currently using Windows SDK calls CreateFile(), SetCommState(), SetCommTimeouts(), ReadFile(), and WriteFile() functions to perform RS-422 function calls.

I have seen the CVI Calls OpenComConfig(), ComRd(), ComWrt() function calls, but "http://exchange.ni.com/servlet/ProcessRequest?RHIVEID=101&RPAGEID=135&HOID=50650000000800000043870000&UCATEGORY_0=_246_%24_13_&UCATEGORY_S=0&USEARCHCONTEXT_QUESTION_0=Can+OpenComConfig%28%29+handle+1%2C000%2C000+bps+for+%22baudRate%22+%3F&USEARCHCONTEXT_QUESTION_S=0" identifies that we should use VISA calls instead.

I have a FASTCOM/PCI-2 card running at 1MBps baudrate. Should I use OpenComConfig() instead? A
nd can this call handle the speeds that I need? Or should I use VISA calls instead?


I am having timing problems when I am using WriteFile() command. The WriteFile() function returns and indicates no errors, but our embedded hardware indicates the signal has not been received.
- Running at 30Hz rate, with 60-80 bytes per burst of data, the data seem to go to the embedded hardware sometimes at 30Hz rate, but for every 3-4 bursts, the data is bunched up, so the data looks like two batches of 60-80 bytes of data. Our embedded hardware cannot handle that.
- we are guessing that Windows SDK calls is not writing to the COM port when PC app states it is writing to it.
- or could it be that our write thread (running at 30Hz) is being interrupted by Windows O/S? So the 30Hz rate is not deterministic?

Will use of ComWrt() alleviate this timing problem?

[Dan_Mondrik]

If you choose to use VISA calls, VISA will work with whatever baud rates the port supports.

WriteFile() will return as soon as the OS has buffered the data. So you need to wait until all the data is actually written - if you continue to use OS calls, try FlushFileBuffers. Here's the reason, from MSDN:

"The WriteFile and WriteFileEx functions typically write data to an internal buffer that the operating system writes to disk on a regular basis. The FlushFileBuffers function writes all of the buffered information for the specified file to disk."

If you choose to use VISA, viWrite will automatically call FlushFileBuffers for you, by default. If you disable that feature, you can call viFlush to get the same effect.

I am sure someone else from NI ca
n comment on the feasibility and behavior of the CVI API, but I am not an expert in that area.

Dan Mondrik
National Instruments

[CviUser2003]

That is great! I will modify my code to include FlushFileBuffers(handle) and check if this works out. That is the first time I have seen this MSDN comment, so I hope adding it will fix my problems. Thank you!

[bilalD]

The CVI RS 232 libraries would work with 422 ports as well, so you should be able to configure the port with OpenCOMConfig at that speed. Underneath it all, it ends up calling the windows serial driver anyways, but it looks like you're already on the right track with this

Bilal Durrani
NI

[CviUser2003]

I tried using the VISA calls viOpenDefaultRM(), viOpen(), viSetAttribute(), viWrite(), and viRead() functions <~per the example~> to replace the Windows SDK calls CreateFile(), WriteFile(), FlushFileBuffers(), and ReadFile(), just for fun.

All initialization and async serial write functions worked fine. However, my thread that polls the serial port using viRead() does not seem to work. The while loop always returns no data even though 3 batches of 60-80 bytes have been sent through the RS-232 line (in my test configuration).

static DWORD WINAPI rcvThread(LPVOID parm)
{
while (WaitForSingleObject(haltEvent,50)!=WAIT_OBJECT_0)
{
status = viReadAsync (instr, temp, VI_NULL,
&bytes_read);
// sta
tus = viRead( instr, temp, VI_NULL,
// &bytes_read );
if (status == VI_SUCCESS)
{
// process data received
}
else
{
// keep reading
}
}
}

As you can see, I tried using viReadAsync(), and viRead(), with similar results (no data read). I put a breakpoint on VI_SUCCESS, but it never got there.

I am currently sticking with FlushFileBuffers() <~less changes to my code~>, but I'd like to know what I am doing wrong with this viRead() call.

[Dan_Mondrik]

I see 2 problems. First, you have to specify the number of bytes to read. If you know the exact number you'll get, use that. If you know it will be terminated with a specific character, set up the termchar and then ask for more bytes than you know you'll get. But you can't just ask for VI_NULL(0) bytes.

As far as viReadAsync goes, you need to approach it a little differently. The successful return value from viReadAsync just means that the operation *started* successfully. The operation is not complete until you get the I/O completion event, and then you need to query the I/O completion event attributes to see the status and how much data arrived. Asynchronous I/O calls are probably overkill for a C application.

If you want to try fu
rther with the asynchronous I/O calls, consult the NI-VISA User Manual. See the sections Asynchronous Read/Write Services in chapter 5, and example 7.1.

Dan Mondrik
National Instruments

[CviUser2003]

Thanks for the info on viReadAsync().

As far as the viRead(), this thread is persistent, so it is the main thread to read incoming responses to my PC's command to the embedded software. That size is unknown: it ranges from 40 (minimal command) to 1024 (max that the embedded hardware can handle).
- I tried to put a low number, high number, nominal number (80 bytes), but it still didn't work. Or it did not response to the PowerUpInit configuration (known to be 80-bytes long, after the GPIB command has been set, I wait for the 80-byte power-up-init-data).
- I thought I read somewhere that a VI_NULL(0) was valid if the value is unknown - it may be slow, but it should have worked. I can't find the web site that I found it from.

[ebalci]

The CVI functions (OpenComConfig, ComWrt, ComRd, etc) works fine with my FastCOM PCI-422/4.

You can use the serial.exe program to verify that. The program is in the samples folder. Even if you run multiple instances (for my board max 4) of the program (each for a different port) there are no problems reported and you can do a loopback testing on all ports at the same time.