RS232 Question

[thecarb]

Hi all,

I want to use a V700 and a device which also use RS232 connection protocol. There are some datas that should be read and controlling of ON/OFF status of the device. However, this will be the first time that I will use RS232 communication.

How can I program this? 

For example, there is a command that I need to use below. I need to read those values and seperate the temperatures to different MI's. I believe I succeed to initialise communication port but not really sure.

$TEA: Read all temperatures
Command with checksum and carriage return = $TEAA4B9<cr>
Response: $TEA,T1,T2,T3,T4,<crc-16><cr>
 

[DanT]

Hello TheCarb;

 

You will use the Function Blocks  Protocol Scan  and Protocol Receive.

There are a few examples to work from in the Help/Examples/Version900Communications/FB Protocol

The Baldor Example shows  the Protocol Scan and Protocol Receive  and the Serial Com Setup.

Have the temp controller handy for bench testing.

 

Dan Thomas

 

[thecarb]

@DanT,

Thanks for your answer, however I have tried different things with examples but couldn't make it right.

 

@All

Let me explain the connection first.

There is a RJ11 socket on V700 with 6 pins. My device has a DB9 connector but it has just active 3 pins. So I made a connection as attached. V700's DIP switch settings are as factory settings, which is set for RS232. Are these steps right till now?

 

Device's book says that device doesn't send unsolicited messages, it only responds to commands from a host. And as I wasn't sure that I can send commands, I just tried to send ON command so I could see if I could do that when it starts. I couldn't get any results.

 

Here is the initializing of COM1 port. Pls see "init.png" file.

Here is the ON command send ladder that I made. Pls see "sendONcommand.png" file.

And please see CommandStructures and CommandsON files for the example and explanation of that Command from the Device's book.

Could you please let me know where am I doing wrong

 

 

 

 

 

 

[Joe Tauser]

You didn't show it, but I'm assuming you're calling your COM INIT and Protocol config with a NO of SB 2.  If you call them continually it won't work.  

Start by connecting a terminal program on a PC to your device to make sure your strings are right and you get the proper response from it.  Then transfer what you've learned to the Protocol block.

I like this one- https://sites.google.com/site/terminalbpp/

Joe T.

[thecarb]

2 hours ago, Joe Tauser said:

You didn't show it, but I'm assuming you're calling your COM INIT and Protocol config with a NO of SB 2.  If you call them continually it won't work.  

Start by connecting a terminal program on a PC to your device to make sure your strings are right and you get the proper response from it.  Then transfer what you've learned to the Protocol block.

I like this one- https://sites.google.com/site/terminalbpp/

Joe T.

Hi Joe,

 

Actually, COM INIT is connected to a SB2 as a direct contact. As SB2 is active just for 1 cycle, I believe this is right.

 

If you could take a look at the "Protocol Send" image and the examples of the device, could you say am I doing right?

[Joe Tauser]

Yes, you are doing it right in the PLC if I read the documentation correctly. 

The most difficult thing with serial communication is making first contact.  Since it's not working, you need to go outside the PLC to figure out why.  This is why I almost always use a terminal program to work out the kinks - it's near impossible to troubleshoot low-level stuff with a Protocol block.  Every time you want to change something slightly you have to download your program, and you don't have access to viewing a history of the serial buffer .

Trust me on this.  I've done it many times.  Use the terminal program first before you beat your head on the PLC and get angry at it.

One of these reasons is why it doesn't work:
1.  The cable is wrong.  You don't have TX and RX connected correctly or your handshake jumpers aren't there.

2.  The baud rate and/or parity and/or handshaking isn't right.  Once again, this is why you use a terminal.  If there's anything coming through at all it will appear as garbage on the terminal.  Unitronics will not display it unless the COM settings are perfect.

Good luck.

Joe T.

 

[thecarb]

I made the connection with Terminal program and it worked normally. I have attached a print screen of it. I just needed to add a $ sign before the command, otherwise it doesn't send the right command. I have also send all commands to set it ON and read the other variables. There was no problem.

I have created a Vision program file. Could you please take a look at it? To RUN the device, I need to send      $ON177CF<cr>     command to the device from the PLC.  So when we touch to the button on the screen, it should send that command to the device.

 

 

 

[Joe Tauser]

Loaded your code into a V570 (it's what I have handy  - really need to appropriate myself a V700) and connected it to the PC running the terminal program.  This is what came out:

So it appears to be working.  I added a Scan block and a field on the display to show the raw value of what comes back.

Load this in and let us know what you find.

Joe T.

 

 

 

 

 

rs232send_JT.vlp

[thecarb]

Yes I made it. The problem was the programming USB cable. When it is connected, PLC doesn't send or receive any data from RS232 (COM1). Now it is working.

But I have some questions. Will there be a problem if program needs to send ON command while PLC is reading temperature values? As PLC will automatically send ON command according to other system parameters, I don't know what will happen if ON command  will be triggered while PLC is reading temperatures from the device.

 

On the other hand, how can I change the ASCII hex to binary? Device sends 4 digit ASCII hex to binary and seperate every bits to 16 different MIs. And also when I tried to add one more send and scan protocol, plc doesn't send and scan the message. It only runs for the first send&scan.

Read Status bits
Command with checksum and carriage return = $STA3504<cr>
Response: $STA,status bits,<crc-16><cr>
T

[Joe Tauser]

 

13 hours ago, thecarb said:

Will there be a problem if program needs to send ON command while PLC is reading temperature values?

Theoretically no, since transmit and receive are separate lines.  Testing while connected should answer the question and if you want to block the Send block while it's busy receiving use a NC of SB135.  

 

13 hours ago, thecarb said:

On the other hand, how can I change the ASCII hex to binary?

Think about it.  The ASCII hex values of the string are landing in MI registers, which are themselves numerical representations of binary values.  If you know which MI contains the hex status value you can convert it to bits using the Numeric to Bits function.  The block doesn't care whether it's being fed decimal or hex data, it's simply transposing the word to individual bit values.  You will have to deal with the endianness of the bits in your logic.

 

Joe T.

[thecarb]

Joe, Thank you very much for your great help.

[thecarb]

I made something derived from the example "V130_send_strings_in_sequence". I put "SB3 1 sec pulse"s positive transition contact to trigger communication for queries. PLC sends commands and reads answers every 1 second.

[Joe Tauser]

You probably want to put everything in one Scan block.  I would look at the format of the different responses and maybe put the first couple of characters in followed by a variable for different scan block entries.  Can you list examples of the different responses you're getting?

Joe T.