I need an example of Ascii conversation...

Using a PLC-5 ..

I have a need to send ASCII to a really dumb annunciation device over serial.

There were only 5 strings I ever sent so for years I have simply sent the string out the comm port using AWT and paid no attention to the feedback the device gives in return. Didn't matter and it worked great.

Now I need to be able to send many more commands and most importantly I need to buffer (Queue?) them in the PLC-5 as a few could be needed at the same time and the device will ignore subsequent commands while it processes the current one. This could take several seconds so commands are being lost. Ideally I would sent them one after the other... somehow.

If done properly I send "F" and the device will echo "f" if its happy, then I can send "001", or "002" or whatever address of the canned message I want to call.

If the device is busy it will respond to any command with "e" meaning "error" and it ignores it. I need to send the "F" then read what it responds and act accordingly. If it responds with an "e" I need to wait a second and try the "F" again till I see "f".

I have danced with the ARD and I see the device response in the ST register, but far too late to deal with it. Instead of a single "e" I have 10 of them meaning many other things are being sent before I get to reading the buffer.

If doing this out of a controllogix or some other third party add on module is better suited to this task I'm all ears. It's in a PLC5 now while that would be easiest to leave in place , I can change processors - not really a problem there, but it looks like this is handled with the same commands in every processor so what I am missing is a serial specific technique that wont be any different in another processor.

I see folks here talking to scales and other devices serially so I'm hoping someone would share some example code I can see to show me how this command/response/buffer is best accomplished.

It would appear that ASCII comms is hard fought knowledge that is not readily given up. . As much trouble as I have had, I understand why . I think Ken was the only one doing that with any regularity.

Not sure this helps but I’ve dealt with many panel mount receipt printers that took ASCii from Micrologix 1400 processors. I always just used the AWA command and sent my strings that way. I never set anything up in regards to the printer talking back to the PLC to make sure it was ready to receive data. It sounds like that would really be the right way to do it so that data isn’t lost, but I’ve never had an issue with what I have had to setup in the past in the way I just described.

We have stuff like that at our plant and the ASCII comms are all done with a BASIC module... not sure if that was the only way possible or if they wanted additional logic to run, but that's how it was done back then.

Ahh a BASIC module... Didn't think about that. Overkill... but a solution nonetheless.

It sure looks like bidirectional conversations to/from a device is not done very often, or at the least, is a well guarded secret.

If I had to I feel like I would set it up using the AWA instruction then an ARD(?) or whatever instruction is used to check the buffer on the PLC. Send the AWA then make sure the buffer is cleared before I send the next AWA. But that still doesn’t ensure that the data made it TO the device. Just tells you that it’s not stuck in the buffer on the PLC.

I have used Prosoft serial modules for compactlogix a few times, it allows me to send and receive ascii strings like constantly without solwing down the scantime to much.

Each module comes with dual Serial port, if I remember correct You have some options on filtering the strings in the module before sending the result to the processor.

The last time I had to do two-way communication using ASCII from a PLC-5 I spent about 40 man-hours getting all my ducks in a row to make it reliable. The device I was "talking" to was a vision system from Keyence, and I really didn't have a lot to ask from it, just the width of a web and some status, but it sure was a pain to get all the string handling done right. At the end of it all, there were times when the serial port on the vision system would just quit responding until I power cycled the camera.

If I had it to do over again, I would most definitely use a 3rd party device (probably a Red Lion) to act as the interpreter.

I did a few ASCII things back in the day interfacing with RFID. The thing I remembered is that PLC doesn't do string well and that's an understatement.

Just recently someone asked me to do it again but I pushed back hard on it, since there's other ways to do the same. Future supportablity is always high on my list of priority.

If you HAVE TO DO IT, I 2nd OkiePC's suggestion and look at a RedLion new DA30D or similar as a programming gateway.

Fair enough. Encouraging to know its not just me struggling. I will look into other options.

PLC5 - ASCII writes to RS-232

TheWaterboy said:

Fair enough. Encouraging to know its not just me struggling. I will look into other options.

Click to expand...

TheWaterboy,

It sounds like you have had a long-standing, functioning PLC5 and ASCII write to RS-232 device(s). Great Job!

It also sound like in the year 2019, that the project needs something changed to support the here-and-now.

If you could readily modify the existing ASCII writes to to solve today's needs, then go for it.

But... I would caution that soon neither the PLC5 nor the RS-232 will be a viable player.

Could you use this new requirement to ask for a hardware upgrade justification?

I just hate to see people spend 2019 dollars (hardware, or expensive LABOR), in a negative 1989 direction.


I encourage you to extend the effort toward the long-term future, and do a PLC5 upgrade, to a current PLC/PAC platform (Ethernet/IP).


Also, look for alternative product for RS-232.... but if no ready available RS-232 product available, then add a Real Time Automation Ethernet to RS-232 gateway.


Best Regards,

Plastic

Now that my memory of the project is coming back a bit, yes, you can do that with PLC5 and/or Contrologix. I did on the PLC5 first because the last person, a PC programmer, did it with PC and .NET making troubleshooting impossible.

Basically, you have to strip out the other characters in the response than do a pattern matching. From what you wrote, I think you know that already. I would send you the code if I have it but I don't anymore.

What I do remember is that I had to play with it and experimenting a bit. I used a ProSoft Ethernet/IP to ASCII gateway instead using the serial port on the processor but the logic should be no different since ProSoft only passively pass stuff back and forth.

If I'm doing that today I would use a Red Lion for sure since it supposely got full IEC 61131 codes. Using a Red Lion also let you migrate the PLC over to Contrologix in the future without too much hassle.

I am going to move to Contrologix, an ethernet interface for the device and open socket comms. I can do what I need that way. It also opens up other doors.

I hate being defeated by serial comms like this, but life's too short.

Do you have an HMI that could handle your decision making and response to what the device replies with? I've found that sending and receiving ASCII is trivial with a PLC, but executing logic based on those responses is not.

No HMI available. I need to build a FIFO buffer for these commands as well so lets throw that in there for good measure. Should be a good time. Not using a PLC-5 for this will make me happier anyway.