Sending ascii string from Omron Serial Port to Channel 0 of PLC 5/40

Holmzy

Member
Join Date
Jan 2006
Location
Cambridge Ontario
Posts
26
I am having trouble sending a ascii string of information from
an Omron PLC to a PLC 5\40.

I am connected to channel 0 and the PLC is configured User Ascii
and I made up a cable based on the info from Omron and AB.




I connected with Hyperterminal and confirmed that data is being
sent from the Omron PLC but when I connect the cable to the PLC5
I do not get the same info.

Can anyone comment or has anyone done this before.
 
The Omron side of the cable may need a jumper between 4 and 5, depending on CTS. It appears that the Omron is sending information based on Hyperterminal.

I do seem to remember that we used to short 6, 8 and 20 together on the old 25 pin ports. That might be worth a try.

Any luck sending a string to the PLC5 with Hyperterminal as suggested above?
 
Greetings Holmzy,



you said:



I connected with HyperTerminal and confirmed that data is being
sent from the Omron PLC



when you did this step what cable were you using? ... basic idea: MOST computers with a DB-9 serial port use pins 2, 3, and 5 for basic (non-handshaking) communications ... let’s look at the cable pinout that you posted ...



omronpinout.JPG




according to this, the Omron uses pins 2, 3 and 9 (NINE-not-FIVE) for its basic communications ... if you say that it works, then I don’t have any reason to doubt that “Omron” end of the cable ... but I’m wondering what pinout was being used on the computer/HyperTerminal end of the cable when you confirmed that the Omron was sending the data ... let’s assume (gosh I hate that word) for a moment that the computer/HyperTerminal end of the “Omron’s cable” used pins 2, 3, and 5 ... (personally, I don’t think that the computer/HyperTerminal end could work any other way) ...



now ... if my assumption is correct, then a cable with the “Omron end” pinout that you’ve shown above was talking correctly to HyperTerminal on a computer ... (NOTE: ignore the Allen-Bradley end for now ... we need to concentrate on the “Omron-to-HyperTerminal” connection first) ...



now if a cable with a “9-pin Omron end” was indeed talking to HyperTerminal through a “9-pin computer end” cable, then here’s what I’d try next ... several years ago the serial ports on personal computers were switched over from the old-style 25-pin connectors to new-style 9-pin connectors ... there was a big market for 9-pin-to-25-pin adapters ... if you have one of those available, try using that to connect your “working’” cable to the front of the PLC-5 ... I’ll bet (pocket change only) that the adapter will have the proper internal “cross-over” connections to make things work right ...



if you don’t have a 9-pin-to-25-pin adapter handy, you can make up a cable to do the same thing ... normally I have an adapter available to ring out ... I don’t have one handy today or I’d post the pinouts for you ... I’ll bring one in tomorrow if you still need the information ... (someone else will probably beat me to it) ... once you get things working with the adapter, you can always duplicate its internal connections in the wiring of your own “made-to-fit” cable ...



now ... the next big question has already been asked by others ... but I’ll repeat it because it’s VERY important ... have you already connected to the PLC-5 with HyperTerminal and confirmed that the Allen-Bradley end of things will indeed accept the incoming communications? ... please answer either:



(1) yes, I have connected to the PLC-5 with HyperTerminal and confirmed that the Allen-Bradley will accept the incoming communications ... or ...



(2) no, I have been trying to use the Omron to send the information into the PLC-5 ...



if your answer is ANYTHING other than number (1) above, then you’re probably going about this the wrong way ... you need to use HyperTerminal FIRST to do “one end” of the cable ... and then you need to use HyperTerminal SECOND to do the “other end of the cable” ... and then (FINALLY) you need to tie the two devices (Omron and Allen-Bradley) together and see if you can get them to talk to each other ... any other approach is probably just making things harder than they need to be ... (SINGLE exception: you just walk in “fat-dumb-and-happy” and plug things up and they just instantly starting talking away ... now how often do you think that happens in the real world?) ...



next question ... does the Omron need to do “handshaking” to make this work? ... please answer:



(1) yes, the Omron needs to do “handshaking” for this application to work ... or

(2) no, the Omron does not need to do “handshaking” ... or ...

(3) I’m not really 100% sure what you mean by “handshaking” ...



hint: when you confirmed that the Omron would talk to HyperTerminal, did the HyperTerminal setup have “handshaking” turned off or on? ...



next question ... does the Allen-Bradley need to do “handshaking” to make this work? ... please answer:



(1) yes, the Allen-Bradley needs to do “handshaking” for this application to work ... or ...

(2) no, the Allen-Bradley does not need to do “handshaking” ... or ...

(3) I’m not really 100% sure what you mean by “handshaking” ...



basic idea behind “handshaking” ... suppose that the Omron is sending a LOT of data very fast ... suppose that the Allen-Bradley can’t properly receive and process all of that data as fast as it’s coming in ... ooops! ... some of the data gets “dumped/lost/missed” along the way ... we can use “handshaking” to help solve this problem ... the basic idea is that the Allen-Bradley can turn its “CTS” (Clear-To-Send) signal wire ON or OFF to let the Omron know that it’s



(A) “ok-to-send-more-data-now” ... or else

(B) “hold-on-for-a-second-I’m-already-full-right-now” ...



here’s just a wild guess ... if your messages are short and simple, then you probably don’t need handshaking at all ... in that case the Allen-Bradley end of the cable will need only three connections ... pins 2, 3, and 7 ... now for the Omron end ... I’m not so sure about that one ... I have ZERO experience working with Omron ... (not that there’s anything wrong with Omron - it’s just that NOBODY has ever asked me for any Omron training) ... but ... if you’ll carefully nail down EXACTLY what cable pinout you were using when the Omron successfully communicated with HyperTerminal, then I’m pretty sure that we can start seeing the light at the end of the tunnel on this project ...



you said:

Both are set to 9600,8,1 par even error check BCC no Handshake



well, IF (big IF) the “no handshake” setting is correct, then you don’t need all of those extra wires in your cable ... specifically, if you aren’t going to use handshaking, then the Allen-Bradley will need only three wires ... specifically, pins 2, 3, and 7 ... all of those other jumpers are only required if you’re using “handshaking” to control the flow of data between the two devices ...



again, I can’t tell about the Omron end of the cable ... some devices will NOT transmit data unless they have the “handshaking” feature turned ON ... but ... in some of those cases, we can “fool” the device into transmitting anyway ... basically, we can provide a “foldback jumper” to tie the RTS (Request To Send) signal back to the CTS (Clear To Send) signal ... most modern computers/PLCs/etc. don’t need that type of treatment ... we can USUALLY just specify “no handshaking” in the setup and the jumper wires become unnecessary ... your Omron? ... I just don’t know ... but I’ll know more as soon as you tell us how you got the Omron to successfully talk to HyperTerminal ...



hope this helps ...
 
Greetings Holmzy,



and just for kicks, I’ll add this ...



suppose that you hadn’t already told us that the Omron connections you showed above “worked” with HyperTerminal ...



in that case, I’d suggest that you try the following pinout ...



DB9/Omron -- DB25/Allen-Bradley

pin 2 ------------- pin 2

pin 3 ------------- pin 3

pin 5 ------------- pin 7



that’s the way MOST devices would work ... but Omron? ...
 
Excellent breakdown on this Ron!!

I think (?) I have attached the pin out for the Omron 9 pin port. Pin 9 is signal ground, and depending on how the PLC setup is configured, Pin 4 and Pin 5 are RTS / CTS, and may need to be jumpered (have run into this before).


OK, so the jpeg did not attach. I am working on that.
 
Last edited:
Ron:

Yes excellent breakdown btw.

First all the setting are the same for both PLC's

1)Both are set to 9600,8,1 par even error check BCC no Handshake

2)I can connect to the Omron PLC with straight through serial cable
and connect with hyperterminal and recieve the data that I send.( note only problem is this puts 5vdc on the pin 6 on my computer, which I did not notice until I recieved the pin out of the Omron PLC)

3) If I use the cable

DB9/Omron -- DB25/Allen-Bradley

pin 2 ------------- pin 2

pin 3 ------------- pin 3

pin 5 ------------- pin 7

I can send data to the Allen bradley with hyperterminal to channel 0.

3) The cable that I made

omronpinout.JPG


does not work when connected fro one PLC to the other.

I will try connecting pin 4 to pin 5 on the 9 pin side
next.
 

Similar Topics

I would like to send a simple ASCII string from a PanelView 550 Printer port with a button press. String Sample: ABCDF 1 Any Ideas?
Replies
3
Views
3,598
Good Evening Gentlemen, I have a 5 port RS232 switch connected to the serial port of my laptop. I need to be able to switch ports to use...
Replies
9
Views
2,158
Hello, Thanks in advance. How can I send more than 82 characters using AWA or AWT? to Zepra Printer via serial Rs232 communication? Normally I...
Replies
1
Views
737
I am very new to programming PLCs, and one of the first tasks I received was to create a program that creates a socket connection between my PLC...
Replies
5
Views
2,488
I am new to programming in PLC, i have Allen Bradley SLC 5/03. I tried using AWT inst. with data in ST9:0 file directly but in 3 inst. getting...
Replies
4
Views
4,004
Back
Top Bottom