PLC5/20 serial comm port to communicate on ASCII format,,, How?

Hello Ron,

I am working with that program with slight change but I am facing a problem with reception of data. The data is coming continuously from the COM port of the embedded PC in ASCII format as I can see it connecting my laptop through HyperTerminal. But when I connect the communication cable to PLC from embedded PC, I am getting ASCII string in PLC memory ST19:0 but not regularly. Most of the times it work fine but I don't receive any data string in PLC memory ST19:0 few times even embedded PC is sending data continously. The only link between the PC and PLC is communication cable.

All connections in the cable are ok as per your previous mail and we receive data also most of the times but few time it doesn't appear. The only change I made in the program you sent is instead of using ABL instruction on the first rung I used ACB instruction because the string is not having any end of line character. Although I am enclosing my program for your kind perusal. I could not find the problem of working this program intermittently. It would be very helpful if you could put some light.

Even though I'm not sure where this thread started I'm still going to throw in my 2 cents worth.

I've done a number of projects interfacing PLC-5s and SLC-500s with ASCII devices that continuously transmit data. I've given up on expecting the data to arive perfectly.

Since the xmitting device is constantly sending out data it (usually) doesn't matter if I miss a reading or two. Therefore, I read what's in the buffer and search the string for the known starting point (ie. STX or whatever). Once found I process the string from that point on.

I know that I'm loosing data but in the projects that I've done this hasn't been an issue.

Hope this helps,

Good Luck,

(8{)} ( .)

Greetings, Umesh,

I’m sorry that I don’t have enough time right now to go through your problem in detail. Here are some general tips which might (or might not) be helpful:

how long is the communication cable between the PC and the PLC? ... RS-232 should be limited to no more than 50 feet ... in electrically noisy environments, the length might need to be kept even shorter ... (note to one and all: yes, I know that RS-232 can be used successfully at much longer lengths – but here we’re looking for things that might be causing a problem ... too long a cable COULD be causing a communication error) ...

in your post (on the other forum) you said that you have the XON/XOFF option “checked” ... but when I looked at the program you have posted, I see that the XON/XOFF option is NOT checked ... this is just a guess at this point but I believe that the XON/XOFF option should NOT be checked for your application ...

I have never personally used the ACB (ASCII Characters in Buffer) instruction ... from what I can understand without running some experiments (I tend NOT to believe everything I read in the books), it appears that the ACB will report “how many” characters have been received at the PLC’s serial port ... since all of your strings always seem to be the exact same length, you might try adding an “error handler” routine to your program ... this would be some extra rungs which would examine the value stored in the ACB’s “.POS” field and take some type of action to “clear” the serial port buffer and reset the program when the length of the string is incorrect ...

as our friend (?) above has correctly pointed out:

I've given up on expecting the data to arive perfectly.

Click to expand...

ASCII communications seldom work flawlessly ... if this is a critical application that you are working on, then you should definitely add some type of “error handling” routine to gracefully recover from the inevitable glitches which will occur from time to time ...

while examining your program I also see that your baud rate is set to only “2400” ... that (by itself) should not cause a problem ... but it does bring up a thought ... this is a long shot but it MIGHT be helpful ... is there the possibility that your PC is sending out the data string so OFTEN (but so slowly) that one string occasionally “overlaps” another? ... in other words, could the PC begin sending out the NEXT string before the LAST string has been completely received and processed by the PLC? ... usually a slower baud rate is selected to help reduce transmission errors ... BUT ... if the PC is actually doing (as you say) a “continuous” transmission of data, then it’s just possible that increasing the baud rate might be a good idea ... in other words, maybe a faster transmission would give the PLC more of a “break” between strings ... specifically, more time in which to scan and process one string’s information before the next string arrives ...

it might help if you could post a shot of the HyperTerminal screen while it is monitoring the data stream ... this might show us something interesting at the PC’s end of the communications path ... if you have trouble posting a graphic on this forum, here is a link which should help ...

help with posting graphics

finally, it will be at least a week or two before I’ll have time to tackle this with some experiments of my own ... in the meantime, there are many knowledgeable people on this forum who can offer you some help ... for those who are interested, this thread started on another forum ...

link to original thread

I hope that this helps ...

PS ... welcome to Phil's PLCs.net forum ...