Hardware Flow control for RS-232 Ports

[garysdickinson]

Gentlemen,

I have been working  with Mr. R. Tito to interface a FMD series PLC to a GSM MODEM using the RS-232 port.

We have been able to solve most of the interface issues.  We have been able to get a system that handles a reasonable subset of sending/receiving SMS text messages.

I have run into a problem that I can not solve with clever use of TBASIC and ladder logic.  The GSM MODEM can and will send responses that exceed 256 characters.  Unfortunately, the PLC does not appear to support any sort of hardware handshake (RTS or DTR) to prevent the GSM MODEM from sending more characters than the PLC receive buffer can handle.

The typical GSM MODEMs do support hardware handshake on their RS-232 ports to prevent buffer overrun.

Have I missed something in my understanding of the PLC RS-232 behavior?  

Is there some semi-secret system command or jumper that could be set to get the PLC to indicate when it can not accept serial data without corrupting the receive buffer?


Thanks,

Gary D.

[support]

The PLC RS232 does not use any hardware handshaking since for 99.9% of applications the 256 bytes buffer for control purpose is ample.

If you need to buffer more than 256 bytes, then one way is to move them into DM[]. i.e. have a function that runs every scan and monitors the serial port for incoming data and whenever INCOMM returns a data (>=0) you move them into DM and use a variable as index to keep track of it. The program can then process the data stored in the DMs at leisure. This way you can buffer up to 4000 bytes.

[garysdickinson]

Thanks,

I have been using INCOMM rather than INPUT$ because the GSM MODEM sends some data that is not delimited by a CR character.  

I also have been using INCOMM because the GSM MODEM uses the pair of characters, CR and LF, as end of line markers.  INPUT$ leaves the terminating LF in the buffer and it becomes the first character of the next string.

Many of the messages from the GSM MODEM do not fit within the string length limitations of 70 characters, so I have been using DM[] to for a lot of the string manipulations.

I think that the use of DM[] as an extended buffer space is an excellent idea.  I will have to ask Mr. R. Tito to drop the BAUD rate to 9600 to ensure that the receive buffer will not overflow between scans.

Thanks for the suggestion.

Gary D.

[garysdickinson]

I have rewritten my GSM MODEM test code to use DM[] as a FIFO between the PLC's receive buffer for port #1 and the application code.  This is in effect double buffering!

This approach has greatly simplified my application code and provides a much more robust interface for the GSM MODEM.

I've attached an PC6 program that shows how to implement a FIFO structure in DM[] and a replacement for the INPUT$(n) function works with the FIFO structure.

The code shows part of the solution to working with messages that are greater than 70 characters in length.

Please note that this code has been tested on the Nano-10 and the FMD PLCs.  The code makes extensive use the #Define mechanism.

Gary D.