robotsNplcs (Customer) asked a question.

Edited May 1, 2024 at 12:20 AM
RS 232 Serial Communication stuck in Receiving..

New to the PLC world. I am charged with connecting a gauge my company made to a PLC that is the standard used by our CM for an in-line inspection at the manufacturer.

 

I have a custom sensor that has an RS 232 output that is output a standard length bit-stream sequence at a known baud rate. The bit stream features a set standard length, and has known header byte (0xAA) followed by a bunch of data packaged into 35 additional bytes. I have confirmed that this gauge is outputting the correct information using standard serial monitors. This serial output streams automatically whenever the gauge is turned on.

 

I need to hook this gauge to a Click Plus PLC C2-03CPU-2. I have wired the output to come into the Port RS-232 phone jack. I have confirmed the wiring is matched to the Rx and appropriate power lines of port 2.

 

When I run a program on the Click Plus, the receiving status is stuck on, but it never transitions to 'Success'. I have tried the following options:

  • Configuring the receive block to be Modbus or ASCII
  • Note, there is no standard addresses being published, so I don't expect Modbus to work as it doesn't adhere to that protocol, it was just a grasp at straws. I believe it's most practical to use ASCII with standard length, but so far no luck. I am aware that not all bytes transmitted map directly to ascii characters, but I cannot even read the data as a bunch of "0"s
  • Configured the receive block for standard length or for stop bit
  • Used standard lengths for the length of bits and the length of bytes being transferred

 

If I can get the byte or bit stream in, I know that I can decode it. I just need the Receive block to take the info and store the bits into memory some how.

 

Any ideas on how I can configure the receive block to successfully read this byte stream?

  • 8 answers
  • 494 views

  • ADC Community_04 (AutomationDirect)

    "I have confirmed that this gauge is outputting the correct information using standard serial monitors."

     

    How are these serial monitors configured? Baud rate, parity, stop bits?

    Have you configured Port 2 on the Click to match the monitors' settings?

    Are you able to post a screenshot of the data received in these monitors, as an example?

    Expand Post

    • robotsNplcs (Customer)

      I have matched the configuration. Serial monitor confirmed output shows below image.

       

      image

      • robotsNplcs (Customer)

        Again, very naive user here. But based on my limited understanding, I think I might have to change the serial output stream. Can you help confirm/refute/refine these thoughts:

         

        • To use ASCII I have to add a ':' to the start of the stream and a carriage return to the end of the stream. At that point the PLC would recognize this as an ascii string and would convert these to ASCII characters that I can back out to more useful hex information
        • It's possible that carriage return might not be needed because of fixed length
        • Because not all of the data packet bits map to ascii characters, some data may get lost?
        • Alternatively, I can use existing stream with modbus and treat the 0xAA bit as an address (it's a constant header)
        • In order to make modbus work, the second bit needs to be changed to a standard modbus function code. So the 0x41 needs to be re-mapped to 0x01 - 0x04. at which point the following 34 bytes would be interpreted as data.

         

        Any insights would be helpful. Thanks in advance for the guidance.

        Expand Post

  • ADC Community_04 (AutomationDirect)

    I set up a device to send the byte string exactly as you posted and was able to receive into the Click without issue, using ASCII. I set the instruction for fixed length 36 TXT addresses. The TXT registers were then copied to DH registers to get the raw byte data that was originally sent. The DH registers are 16-bit registers though.

    Are you seeing the RX LED blink when the string is sent?

    2024-05-01_13-54-46

    Expand Post

    • robotsNplcs (Customer)

      I am seeing RX on constantly, not blinking. And it never transitions to the C2 Success. Just stuck on C1 Receiving as a constant.

       

      I don't have the C1 NO leading into the Receive block though. Can you explain or send me to documentation on why that block is needed?

  • ADC Community_04 (AutomationDirect)

    The NO contact in the screencap is actually C10, it is cut off in the image. The instruction needs to go false and then true again to retrigger the instruction after it completes (Success or error).

     

    If Port 2 RX LED is constantly on, I think you have a wiring issue because that shouldn't be the case.

    Having said that, the LED may appear as constantly on if the device is constantly streaming out without a pause between packets.

    Expand Post

    • robotsNplcs (Customer)

      So I have confirmed that the wiring is correct, and that the gauge FW is designed to constantly output data at the 115200 baud rate. It is pulsing at the baud rate, but not stopping to wait for any signal from the PLC before continuing to send. Is there a set up in the Receive block to indicate that this is happening?

       

  • ADC Community_04 (AutomationDirect)

    If your device is constantly streaming without pause, it may not be a good fit for the Click Receive, using just a fixed character count. We cant determine that until you can get the Click to bring in at least something.

    Are you able to connect your device to a PC using RS232? Just to see if you can get it communicating with a PC, using PuTTy or other.

    Can you verify the signal voltage?

    Also, reply with your Click project, though I don't think there will be much in there that will help, just in case.

    Expand Post

 

Did this information resolve your issue?