LabWindows/CVI

cancel
Showing results for 
Search instead for 
Did you mean: 

OpenComConfig returns -5

Hi All,

 

Anyone have any ideas why OpenComConfig would intermittently return a -5 on some but not all serial ports after being looped several times in a test execution?  The application is  multithreaded, uses  a PCI based serial port, and runs on Windows 7.

 

According to a look up of the rs232 library, the error is:

 

-5 kRS_InternalError Unexpected internal error.
0 Kudos
Message 1 of 7
(3,182 Views)

Hi rp00

Do you have any timeout expression in your code?

Are you closing correctly the references and flushing the queue?

0 Kudos
Message 2 of 7
(3,145 Views)

Hi Andr3s_Br3n3s,

 

For a timeout and closing the references could you please provide examples.

 

I have recently made a shortened test so "mostly" all it does is opens/closes the ports from different sockets and threads in TestStand.  I can now repeat the return of -5 in about 10 minutes.  For this case there are no UUTs connected, no serial data sent or received.  I've noticed on one Test PC OpenComConfig so far always passes it has (CVIRTE 9) and the other Test PC it fails with (CVIRTE 2015) amongst other likely differences.  The CVI dlls were built with CVI 8.5.  Both Test PCs started with different PCI serial port driver versions but now they are the same.

0 Kudos
Message 3 of 7
(3,128 Views)

Hi rp00, 

 

At this moment I don't have any example or code that I can share with you. Did you check in the example finder of CVI?

Did you tried to use NI  MAX and test the Com port (Hyperterminal) ?

I would definitely try this to see if I have the same error, use the VISA test panel.

 

0 Kudos
Message 4 of 7
(3,111 Views)

Did you check commcallback.cws and serial.cws  shipping examples of CVI ?

 

0 Kudos
Message 5 of 7
(3,102 Views)

On the PC receiving the error the COM ports were not in the NI MAX.  I updated NI S/W which allowed the serial ports to show up in NI MAX.  However that did not fix the problem.  Rolling back to CVIRTE 2009 fixed the problem.  As soon as I moved up to the next CVIRTE 2010 the problem started occurring again.  Experimenting some more and I found enabling a TestStand "use lock to only enable one thread at a time" on the higher level COM open port step also seems to fix the problem.

0 Kudos
Message 6 of 7
(3,033 Views)

rp00

Thanks for sharing the steps.

Is there any way we could try to reproduce this? it would be good to know if that is a bug in 2010 version and if that also happens on never versions.

0 Kudos
Message 7 of 7
(3,009 Views)