Announcement

Collapse
No announcement yet.

Using com_TXemptyEvent

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Using com_TXemptyEvent

    I've been trying to communicate to a smart relay using RS485 running half duplex. I haven't been able to get a reliably timed signal out of an IO pin for the send/receive enable on the RS485 driver chip. Timing is critical as the smart relay sends a response code back with necessary information shortly after receiving a command.
    I am trying to use the com_TXemptyEvent to do the change of state on the IO pin but find that the pin changes state before the message has finished sending (confirmed by looking at signals using a CRO). Have I not set things up properly? Dose changing the values in the com array post the to (COM0);print (" "); command have an effect on how com_TXemptyEvent works. I've pasted the code in below.
    Thanks
    christopherjc

    *************************************
    func WRITEVARIABLE()
    com_Init(recCombuf, 17, STX);
    com_TXbuffer(combuf, 32);
    com_TXbufferHold(ON);

    to (COM0);print (" ");
    combuf[0] := (NODE2 << 8) + (STX &amp; 0b0000000011111111);
    combuf[1] := (SUB2 << 8) + (NODE1 &amp; 0b0000000011111111);
    combuf[2] := (SID << 8) + (SUB1 &amp; 0b0000000011111111);
    combuf[3] := (MRC1 << 8) + (MRC2 &amp; 0b0000000011111111);
    combuf[4] := (SRC1 << 8) + (SRC2 &amp; 0b0000000011111111);
    combuf[5] := (VARTYPE1 << 8) + (VARTYPE2 &amp; 0b0000000011111111);
    combuf[6] := (RSA3 << 8) + (RSA4 &amp; 0b0000000011111111);
    combuf[7] := (RSA1 << 8) + (RSA2 &amp; 0b0000000011111111);
    combuf[8] := (BITPOS1 << 8) + (BITPOS2 &amp; 0b0000000011111111);
    combuf[9] := (NOE3 << 8) + (NOE4 &amp; 0b0000000011111111);
    combuf[10] := (NOE1 << 8) + (NOE2 &amp; 0b0000000011111111);
    combuf[11] := (b6 << 8) + (b7 &amp; 0b0000000011111111);
    combuf[12] := (b4 << 8) + (b5 &amp; 0b0000000011111111);
    combuf[13] := (b2 << 8) + (b3 &amp; 0b0000000011111111);
    combuf[14] := (b0 << 8) + (b1 &amp; 0b0000000011111111);
    combuf[15] := (BCC << 8) + (ETX &amp; 0b0000000011111111);

    pin_HI(IO1_PIN);
    TX_EmptyEventFlag := 1;
    com_TXemptyEvent(drivercontrol());
    com_TXbufferHold(OFF);

    while(TX_EmptyEventFlag == 1)
    print("in loop waiting for com_TXemptyEvent\n");
    pause(1);
    wend
    com_TXemptyEvent(0);

    return;
    endfunc
    ************************************

    ************************************
    func drivercontrol()
    pin_LO(IO1_PIN);
    print("in func drivercontrol()\n");
    TX_EmptyEventFlag := 0;
    return;
    endfunc
    ************************************


    CHRIS

  • #2


    Do you have more info on exactly when the buffer empty event is firing, in relation to the message going out?
    I suspect the the buffer empty event may be firing when the last byte is pulled from the buffer (in preparation for transmittal), NOT when the last bit of the last byte has finished transmitting.....
    _______________
    Best Regards,
    Howard

    Comment


    • #3


      It is firing 10uS before the data is leaving the com port so your previous statement of the last byte being pulled from the buffer is correct. This means that this function is not much use for an RS485 bus in controling the Rx Tx enable as the internal functions PDF states on page 167.Is there any other way to know when the last bit of the data steam is actualy sent?
      I have used the pause() function to wait for the data to be sent but this is unreliable.
      CHRIS

      Comment


      • #4


        We will look at ways to improve this function for the next release,
        in the meantime, a workaround would be a simple loop delay that
        will need a bit of experimental fine tuning, eg:-

        dly := DLY_FACTOR;
        while(dly--);
        Regards,
        Dave

        Comment


        • #5


          a loop also proves unreliable.
          I will probable make a hardware buffer with a PIC to recieve the data string from the touch screen (at a higher baud rate) and then resend it from the pic as i can use interrupts to control the RX TX line to the RS485 transiver.
          Thanks for the help.
          CHRIS

          Comment


          • #6


            That may be a bit of overkill, although I'm not not sure what you are requiring to do.

            Have a look at the simple 555 circuit here, this would also mean you get a pin back.

            http://www.lvr.com/rs-485_circuits.htm
            Regards,
            Dave

            Comment


            • #7


              I just noticed something in your code that may be breaking it.

              com_TXemptyEvent(drivercontrol());


              should be com_TXemptyEvent(drivercontrol);


              The way you have it would call the event as soon as you set the event up ,
              and not actually set the event at all....
              Regards,
              Dave

              Comment


              • #8


                Thanks for the idea about the 555.
                I also changed the syntax as shown in your last message, this works alot better but still fires when the last byte leaves the buffer rather then when the last bit is sent. i'll try a small delay to resolve this and disable the touch screen and other events to try and improve reliability. May be worth changing the example in the Internal functions data sheet (page 167) as it shows the called function with the brackets.
                CHRIS

                Comment


                • #9


                  I have to do this exact same thing. Has anyone come up with a good solution without having to add another micro? It would be nice to see this as a secondary function of one of the I/O pins.

                  Comment


                  • #10


                    That's a rather old post, as I understand it the problem has been fixed
                    Mark

                    Comment


                    • #11


                      It's an old post but there is no definitive solution to the problem. I would not call this
                      i'll try a small delay to resolve this and disable the touch screen and other events to try and improve reliability
                      a robust solution.

                      Comment


                      • #12


                        As I understand it a new PmmC was issued with a fix, at least release notes say

                        PmmC Revision R3.2 29th October 2012
                        ***************************************

                        1] Buffered TX service was still turning pin around too early when buffer empties.,
                        added code to wait for buffer to completely empty on last byte before turning pin around.
                        Mark

                        Comment


                        • #13


                          Great news! Thanks for the quick response, I will give it a try tomorrow.

                          Comment

                          Working...
                          X