ProcessSystemEvents() in 2-wire communication in RS485

[GaryZ21]

I am using CVI 7.1 in a XP O/S. 


The application that I wrote uses a RS485 (PCI 8433 / 4) card in 2-wire autoconfiguration mode to communicate to the hardware that we built.   This hardware will responds to any correct message within microseconds delay.  However, when I use the RS485 card to communicate to our device, I have to add a "ProcessSystemEvents()" in order for the RS485 to recognize the data responded to it's RX line.  If i the ProcessSystemsEvents() isn't present, the RS485 reports that it didn't receive any data.  However, I am able to verify the data comming out of the PCI 485 card and the response data going to the RS485 card from our device.  Why do I need the ProcessSystemsEvents in my case?  Can I do without it?  If so, how?

[Chris_R.]

Hi GaryZ21,

I don't know much about your program from what you have here, but the ProcessSystemEvents() function is explained in the LabWindows/CVI Help file.  You can find this directly from LabWindows/CVI or from the Windows Start Menu.  Please view this and see if it provides helpful information for your program. If not, please let me know!

[GaryZ21]

The following is a section of my code.    In Step 1, I send the data out on the RS485 card. In Step 2, I read the receive queue for the response I expect from my hardware.  In Step 3, I verify the response data. 

The application works when I put "ProcessSystemEvents()" between step 1 and 2.  When I take "ProcessSystemEvents" out, the receive queue reports no data.  I have an oscilloscope connected to the rs485 line and have been able to verify the correct data going out of the RS485 card to my hardware, and verify the correct data from my hardware going to the RS485 card.  However the application fails without the "ProcessSystemEvent".  Why do I need ProcessSystemEvent?



background:
12 bits communication: 1 start, 8 bits, 1 p, 2 stop.
2-wire autoconfiguration mode.
baud rate: 700,000 bps
response time from hardware is less than 10 microseconds. 

    // STEP 1: Send Dataword
    iWrtCnt = ComWrt(PRI_COM, mesgword, wordcount);            // Step 1: Send data out to RS485 Card
    ProcessSystemEvents();
   
    // STEP 2: Read Response
    iQReadSize = GetInQLen (PRI_COM);
    ComRd(PRI_COM, mesgword, iQReadSize);
    ProcessSystemEvents();
   

   
    // STEP 3: Verify CMD/TLM response
    if ( msgtype == XBits)
        iStatus = VrfyCmdRspnd (mesgword, msgtype);        // Verify CMD response data
    else
        iStatus = VrfyTlmRspnd (mesgword);    // Verify TLM response data
   
    if (iStatus)
    {    sprintf (strmsg, "Error verifying cmd or tlm response data.");
        ErrMesg(strmsg, iStatus);
    }

[Mert_A.]

Hi Gary,

If you have not disabled the output queue (by passing -1 as the output queue size in OpenComConfig), then it may be that your bytes have not yet been transmitted in step 2, where you call GetInQLen.  If you leave the output queue enabled, a call to ComWrt only puts bytes in the output queue.  There must be a context switch in order for a background writer thread to actually send the queued bytes to the port.  This may be the cause of your problem.  It sounds like you are already using OpenComConfig to configure your communication settings, so I would recommend checking if you are passing -1 for the output queue length (not the same as passing 0).

Also, just as a general suggestion, it is usually easier to program if you read within a serial event callback.  Assuming that your overall program structure is event based, and you spend most of your program in RunUserInterface (or a loop with ProcessSystemEvents), you can simply register for a serial event like LWRS_RECIEVE or LWRS_RXCHAR (with InstallComCallback) and be assured that you only read when the data is ready.

I hope this helps.

Mert A.
National Instruments

[jr_2005]

It might be an idea to re-structure your code to take advantage of CVI's event driven design philosophy, rather than treat it as a classical linear program. For example, you could use InstallComCallback() so that your nominated function automatically gets called whenever a specified set of conditions is met on the serial port (eg CR/LF received). This way you would avoid the need for ProcessSystemEvents().

JR

[jr_2005]

Must get quicker at typing... must get quicker at typing... must get quicker at typing...