Instrument Control (GPIB, Serial, VISA, IVI)

cancel
Showing results for 
Search instead for 
Did you mean: 

Serial device driver doesn't support DTR escape code

I am using CVI to program my serial com ports on a PCI 485/4 card.  I am using the ports as a 2-wire mode: DTR Controlled. However,  when I used the ComSetEscape function.  I received the following error message.

 NON-FATAL RUN-TIME ERROR:   "serial.c", line 198, col 14, thread id 0x00000660:   Library function error (return value == -1 [0xffffffff]). The operation completed successfully. 

According to the explanation, this meant the following for my com ports.
ComSetEscape returns Unknown System Error (-1) when the device driver does not support a particular escape code

My question is, does the NI-PCI 485/4 card or the serial driver that I have, NI-Serial 1.8, support the DTR control feature?  If I can, what's the proper way to set it up?  Below is a part of my code.


    RS485Error = OpenComConfig (COMPORT3, DEVICENAME3, baudrate, parity,
                                        databits, stopbits, INPUTQ, OUTPUTQ);
                                       
    EnableBreakOnLibraryErrors ();
    if (RS485Error) DisplayRS485Error ();
    if (RS485Error == 0)
    {
        SetXMode (COMPORT3, XMODE);
        SetCTSMode (COMPORT3, LWRS_HWHANDSHAKE_CTS_RTS_DTR);
        SetComTime (COMPORT3, 1);
    }

    // Configure com ports for 2-wire mode communication.
    RS485Error = ComSetEscape (COMPORT3, WIRE_2_ECHO);
    if (RS485Error) DisplayRS485Error ();


To transmit, I have the following code.
    ierror = ComSetEscape (COMPORT3, SETDTR);
    bytes_sent = ComWrt (COMPORT3, "abcdefg", stringsize);
    ierror = ComSetEscape (COMPORT3, CLRDTR);


The error message I mentioned stops the program at the very first line above.
    ierror = ComSetEscape (COMPORT3, SETDTR);


0 Kudos
Message 1 of 11
(4,951 Views)

Hi Gary,

Have you tried using WIRE_2_AUTO mode to see if this works?  You also might want to try using NI-VISA to see if it's a coding issue.  Here's an example:

http://digital.ni.com/public.nsf/websearch/94899E7A1D9BA56586256ED700641615?OpenDocument

Your code looks correct, and it's not apparent off-hand what might be causing this.  If the VISA example or auto mode doesn't work, then we might be looking at a configuration or driver issue.

0 Kudos
Message 2 of 11
(4,936 Views)
The auto feature does work.  However, I am trying to achieve a 0 (or VERY close to 0) delay time from transmitting to receiving.  Since i wasn't able to get an answer on how long of a delay it takes for the RS485 card to switch the transmitter off to the point when I can start receiving, I was hesistant in using the auto feature in my program.   Therefore I was interested in the 2-wire mode with the echo feature.  I didn't have any luck in getting past the error message I received by using just one of the port. 

i'm going about this issue by setting two ports to auto configuration mode.  I have one as a primary Tx line and the second as a primary Rx line.  However, i think someone should investigate on this issue - why do i get the error message when I try using the DTR enable command in CVI.  I've tried using vi sessions, however due to the amount of code I've built using the serial driver, it's not practical for me to rebuild my code to vi-commands.

Please let me know if there any new findings.


0 Kudos
Message 3 of 11
(4,927 Views)

Hi Gary,

I just noticed that the error you are getting is in "serial.c".  I think this uses the RS-232 library and might not have the correct wire mode needed for RS-485.  Be sure you are including NiSerial.h from C:\Program Files\National Instruments\NI-Serial.

I also discussed the timing question with R&D and found out that auto mode switched the DTR line right before and right after a transmission, and that this transition occurs much faster than the maximun baud rate of you PCI-485.  Auto mode is definitely much faster than executing code to manually switch the DTR.

0 Kudos
Message 4 of 11
(4,906 Views)
I have the PCI RS485/4.  It has a maximum baudrate of 2Mb/s.  So are you saying the transition from turning the tx from on to off after it completes transactions is faster than 500ns? 
0 Kudos
Message 5 of 11
(4,903 Views)

I was assuming you were using the older PCI-485/4 board which has a maximum baud rate of 460.8 kb/s.  The PCI-8431/4 does have a maximum baud rate of 3 Mb/s with NI-Serial 1.8, and it can control the DTR line in 2-wire auto mode up to 2 Mb/s.  In order to have a transitions period between transmitted frames, the transition rate of the DTR must be faster than 500 ns.  I don't have the exact timing information, but you can always test this transition timing.  Using auto mode, this timing should be consistent.

Were you able to check to make sure you are including NiSerial.h?

0 Kudos
Message 6 of 11
(4,888 Views)
Question 1:
I am still getting the same results even after I changed the the header file to NiSerial.h.  I am still not able to use that escape function to get CVI to accept the code without giving me the following message below. 

 NON-FATAL RUN-TIME ERROR:   "Temp.c", line 37, col 15, thread id 0x00000944:   Library function error (return value == -1 [0xffffffff]). The operation completed successfully. 



Question 2:
When I'm on a 4-wire mode configuration using this card, the 485 line is in idle state(pulled-high) when the Tx is not transmitting.  However, when I'm in 2-wire auto configuration mode, the line is pulled low.  Is there a reason for this?  Is there a way to pull the line to high?


Gary Z.

0 Kudos
Message 7 of 11
(4,848 Views)

Q1)  I see that the error is now in Temp.c.  Is Temp.c a file that you created? Is the error generated at the same SetComEscape function?  Could you post this c file.

Q2)  Which 485 line are you refering to?  The TX +- and RX +- lines use bias/pullup resistors to pull the lines to a known state when the tranceiver is tri-stated.  The board itself should include these bias resistors, but you chan change them to pull the line to what ever state you wish.

http://digital.ni.com/public.nsf/websearch/12BB6CD900B2D0EF862564980050F5A7?OpenDocument

0 Kudos
Message 8 of 11
(4,826 Views)
Q1:
I used the same exact code as the first posted message. The only difference was the change in header file.  However, I'm still getting the same error message. 

#include <rs232.h>
#include <utility.h>
#include <NiSerial.h>


int main (void)
{
    int iStatus;

     iStatus = OpenComConfig (3, "com3", 9600, 1, 8, 2, 512, 512);
                                      
    EnableBreakOnLibraryErrors ();

    if (iStatus == 0)
    {
        SetXMode (3, 0);
        SetCTSMode (3, LWRS_HWHANDSHAKE_CTS_RTS_DTR);
        SetComTime (3, 1);
    }

    // Configure com ports for 2-wire mode communication.
    iStatus = ComSetEscape (3, WIRE_2_ECHO);
   


    iStatus = ComSetEscape (3, SETDTR);
    iStatus = ComWrt (3, "abcdefg", 7);
    iStatus = ComSetEscape (3, CLRDTR);

    return 0;
   

}










Q2:
I am reading the differential across the Tx+ and Tx-.  I have one scope probe channel 1 connected to the Tx+ and another scope probe, channel 2,  connected to the Tx-.   The grounds for both probes are connected to pin 1, gnd, from the DB9 connector.  On the scope, I have Ch1 - Ch2 to get the differential signal.  I can monitor the differential signal when Tx is transmitting, however I'm not sure if the differential is supposed to pull to low when Tx is not transmitting.  I'm guessing that could be the right value since that value could correspond to the voltage across the terminiation resistor.  I want to verify this with you before I pass the information to the responsible engineer. 
0 Kudos
Message 9 of 11
(4,818 Views)
Gary,

I get the same error message when I try to run your code on my PCI-8431.  I am in contact with R&D about why we are getting the error and how to fix it.  I will let you know as soon as I receive a response.

However, I am hesitant to believe that you will see any improvement over using the auto mode.  In fact, my guess would be that controlling the DTR line in software could potentially slow your application down.  Each of the driver calls to change the DTR line would be controlled and timed by Windows instead of at the hardware level.  You would be at the mercy of Windowsnot an enviable position.

You are correct that the differential transfer line is supposed to be pulled low when not transmitting.
Robert Mortensen
Software Engineer
National Instruments
0 Kudos
Message 10 of 11
(4,798 Views)