Author Topic: Com port 1  (Read 15825 times)

can

  • Full Member
  • Posts: 160
  • I'm a llama!
    • View Profile
Com port 1
« on: May 11, 2015, 01:47:41 AM »
Hi. I intend to connect com port 1 of MD888 to a computer system 9 pin com port. The computer will output the following string:

send: run 1
recv: pass run 1
send: run 2 111
56789
999
no
yes

recv: pass run 2

1) Can I capture 56789 and 999 into string and send them through excel link?

support

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 3174
    • View Profile
    • Internet Programmable PLCs
Re:Com port 1
« Reply #1 on: May 11, 2015, 08:25:38 PM »
You certainly can use the INPUT$(1) command to receive CR-terminated ascii strings from the PC and then store the string inside a PLC's string variable (A$ to Z$). These string variables then become readable by ExcelLink.

Please note that the PLC doesn't "send" the string to ExcelLink. It is ExcelLink that read the string from the PLC.

Also ExcelLink will not work through the COMM1 port of the PLC since it is already being used by the PC. ExcelLink can however communicate via TLServer and the COMM3 port of the PLC or directly with the PLC via the Ethernet port.


Email: support@triplc.com
Tel: 1-877-TRI-PLCS

can

  • Full Member
  • Posts: 160
  • I'm a llama!
    • View Profile
Re:Com port 1
« Reply #2 on: May 13, 2015, 03:11:39 AM »
Hi. Is there any way to read non CR terminated ascii string sent from PC? Had open a hyperterminal on PC 1. The letters that I typed are not shown in A$ when Input$(1) is run. When I send a text file from hyperterminal and rerun input$(1), the letters and content of the text file appears in A$. Any idea how to work around it? Greatly appreciate it if there's a way to make it work. Thanks.

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Re:Com port 1
« Reply #3 on: May 13, 2015, 08:52:11 AM »
Can,

Simple answer:  InCOMM(1)

Long answer:

If you type characters  on your PC using hyperterminal, the function INPUT$(1) will assign "" to A$ if you call this function before the PLC receives a CR from the PC.  Once a CR has been received, then a call to INPUT$(1) will return the characters entered, but not the CR.

If the text string is longer than string variable can hold (A$..Z$ can hold 70 chars), INPUT$(1) will return the first 70 characters of the message.  Then next call will return either then remaining characters or the next 70 characters in the PLC's receive buffer.  Please be careful with this.

If the text string is longer than 256 characters, then data can be lost. The PLC's firmware allocates exactly 256 bytes to buffer data for each serial port.  If data comes into the PLC faster than your PLC code can read it, you will lose it and scramble the PLC receive buffer.

If your string is terminated with 2 characters (carriage return and then linefeed) as is typical with DOS text files, then INPUT$(1) will return the string correctly, but will leave the linefeed in the receive buffer.  The next call to INPUT$(1) will return a string that starts with the linefeed character left over from the previous string and then next string (if any) that has been received by the PLC's firmware.
INPUT$() works great if the serial device connected to the PLC sends printable ASCII characters and terminates these characters with an ASCII carriage return. Oh and the messages are shorter than 70 characters!!!

There are many serial devices that send data that does not fit this pattern:
1. GSM MODEMs for doing SMS text messaging.  These things send ASCII text but send both an ASCII carriage return and an ASCII line feed.  They use 2 characters to terminate the line.  And the messages can be longer than 256 characters.  And the GSM MODEMs will send data to the PLC at any time so the PLC code has to be very busy to not lose data.
2. MODBUS RTU sends binary data and does not use any line terminator.

If you need the PLC to handle messages that are not terminated with an ASCII Carriage return or binary data, then you can use the InCOMM() function.   InCOMM() returns a -1 value if there is no data in the receive buffer or a single character (8-bit value).

This is a snippet of what I'm doing to handle MODBUS RTU on an Fx series PLC :

Timeout = 100                        ' max to wait for response
ch = InCOMM(MODBUSPort)
while (ch = -1)
   delay 1                        ' kill and little time
   ch = InCOMM(MODBUSPort)            ' see if a character has been received
   Timeout = Timeout - 1               '  and keep track of time remaining            
   if (Timeout <= 0)
      return = MBTimeout               ' no response from the slave...
   endif
endwhile
 
' we have received the first character of the response, but probably
'  not the entire response.
'
delay 10   ' delay to allow the entire response from the MODBUS Slave
         '  to be transmitted and received by the PLC
         '
Index = 0   ' start at beginning of MBResponse buffer
while (ch <> -1)               ' response characters in buffer
   DM[MBResponse + Index] = ch   '  save this one
   Index = Index + 1
   ch = InCOMM(MODBUSPort)      ' get next character
endwhile
[/font][/color]

I know that this is a little overkill, but InCOMM() allows me to work around the limitations of INPUT$().

Gary D
« Last Edit: May 13, 2015, 06:13:15 PM by garysdickinson »

can

  • Full Member
  • Posts: 160
  • I'm a llama!
    • View Profile
Re:Com port 1
« Reply #4 on: May 18, 2015, 06:49:57 AM »
Hi Gary. It's very nice of you to offer me a solution. First time I'm using incomm and I'm still learning everyday. I'm planning to use md888 as a logger to log both tx and rx data from dte to dce. Any idea how to make a sniffer cable for the purpose? I've tried connecting pin 3 of dte to pin 3 of Dce and pin 3 of md together. I managed to get the data from dte. Now how do I get data from dce? An idea? Will diode in the cable help?

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Re:Com port 1
« Reply #5 on: May 18, 2015, 12:39:21 PM »
Can,

It's easier to snoop on data on an RS485 link.  Just wire a USB to RS485 dongle into the network.

RS-232 is a little trickier.  Yes you can build a "sniffer" with a few diodes and a resistor.  This is a link to a web site to describes how to build what you want:

http://www.marcspages.co.uk/tech/3104.htm

I've attached a schematic of "Marc's sniffer".  He has a good explanation of the circuit and I think that he's done a great job.
 

Gary D
« Last Edit: May 18, 2015, 12:45:11 PM by garysdickinson »

can

  • Full Member
  • Posts: 160
  • I'm a llama!
    • View Profile
Re:Com port 1
« Reply #6 on: May 19, 2015, 07:32:21 AM »
Hi Gary. Since switch is needed, I'm wondering if I can use a relay to control which line I want to sniff on.

Is it possible to put the i7017 on the same port and request data from it during a period when the serial port is not sending any data? Will the data from i7017 be corrupted?

garysdickinson

  • Hero Member
  • Posts: 502
  • Old PLC Coder
    • View Profile
Re:Com port 1
« Reply #7 on: May 19, 2015, 01:26:34 PM »
Can,

in regards to the use of a relay vs a switch, knock yourself out.

in regards to the I7017:
1.  It is an RS485 device and not RS232.  So your RS232 sniffer would be useless.
2.  The I7017 uses its own communication protocol and it would probably be "annoyed" if you sent it random serial data that was intended for another serial device.
3.  If you are attempting to "share" a PLC COM port with multiple devices that do not understand the same communication protocol such as MODBUS RTU and I7017 you will have problems.  If you need to have these devices connected to the same COM port, you may need to use relays to switch the COM port between the two different devices.
The PLC would have to switch between the devices.  


Gary D