Hostlink

[tobor0216]

I have been working with Shaun from tech support, and he has been great, but I am having some trouble getting started.

I am trying to connect an Elk M1 gold security panel to a Maple Systems 550H HMI. Since I cannot directly connect these 2 devices, I decided to use an F1616-R.

The devices will be connected via TCP/IP, and communicate via ASCII protocol.

Would it be possible for someone to provide a example to get me started. Below is what I have that does not seem to be working correctly.

PRINT #4 "<TCPCONNECT 192.168.1.101:2101>"

FOR I = 1 TO 10000
 C$ = INPUT$(4)

 IF LEN(C$) > 0
  D$ = C$
 Endif

Print #4 "</>"

[support]

It wasn't very clear what interface each device is connected to the F-series PLC:

1) Elk M1 gold security panel to PLC - Ethernet or RS232/RS485?
2) Maple Systems 550H HMI to PLC - Ethernet or RS232/RS485?

If both Elk M1 Gold security panel and Maple Systems 550H HMI are using Ethernet interface, that means you need a protocol translator between the two devices. However, which device is the client and which device is the server? What communication protocol do you want to use for each device you mention? You mention ASCII protocol - are these just plain ASCII strings and how are the strings terminated?

[tobor0216]

Sorry about that. The connection between the Elk and the PLC will be Ethernet, and the connection between the PLC and the HMI will be RS-485.

I know how to make the PLC and HNI work together, I am looking for help on getting the Elk and the PLC working together.

Thanks

Paul

[support]

So from your code fragment I assume that ELK has a server and the PLC is the client that is making a connection to the server. So what does the ELK return when the PLC first makes a successful connection to the ELK? Does it require any kind of authentication (username/password) for login?

Is the ELK expecting some kind of ASCII string command from the PLC and will send a response when a correct command is received? What kind of response if a wrong command is sent? It takes two hands to clap so the PLC has to know what to expect in order to send the correct commands.

[tobor0216]

The Elk does not have a server, so nothing is returned. Suport suggested to use the code below, but it did not work, so I tried to write my own code.


PRINT #4 "<TCPCONNECT 192.168.1.101:2101>"

FOR I = 1 TO 10000
 C$ = INPUT$(4)

 IF LEN(C$) > 0
  D$ = C$
  EXIT    'new command available in TRiLOGI 6.4 and higher
 ENDIF
NEXT

IF STATUS(3) = 1
 'ADD CODE

ELSE
 RETURN    'connection failed,  exit function
ENDIF

Print #4 "</>"

[support]

If it does not have a server, how is the PLC supposed to connect to it? If ELK has an Ethernet port it either has a server or a client or both. You really need to know what's the ELK is capable of doing  in a TCP/IP communication before you can ask the PLC to communicate with it!

[tobor0216]

Below is what Elk told me their panel can do.

Good afternoon Paul,

 

The M1XEP does connect to Serial Port 0 on the M1 Gold. If the Maples Systems can communicate over LAN and if you understand "socket" programming and TCP/IP connections, it is a fairly simple process.


As you know, the M1 requires our M1XEP Ethernet Expander module to connect to a local network and the Internet.  Look at the M1XEP as a simple "pass-through" device.  Once you make a socket connection to it, your remote application can send and receive packets to/from the M1 using the M1's ASCII Protocol.  These messages simply pass through the XEP to the M1 and vice-versa.  

[tobor0216]

Not sure if this will help, but here is the entire email.

The M1XEP does connect to Serial Port 0 on the M1 Gold. If the Maples Systems can communicate over LAN and if you understand "socket" programming and TCP/IP connections, it is a fairly simple process.

 

As you know, the M1 requires our M1XEP Ethernet Expander module to connect to a local network and the Internet.  Look at the M1XEP as a simple "pass-through" device.  Once you make a socket connection to it, your remote application can send and receive packets to/from the M1 using the M1's ASCII Protocol.  These messages simply pass through the XEP to the M1 and vice-versa.  

To demonstrate:

1) First, enable G35 - G40 in the M1, either through the keypad programming menus or using ElkRP.  This causes the M1 to send ASCII messages for all status changes out its serial port to the XEP.

2) Connect the M1 to an XEP and connect the XEP to a LAN.  Using ElkRP, set up the XEP's IP address, etc.

3) Open HyperTerminal and make a Winsock connection to the IP address of the XEP, on the non-secure port (2101).

4) You should see ASCII messages appear in the HyperTerminal window as things happen in the M1 (zones open, arm/disarm, etc.).

5) If you were to QUICKLY type an ASCII command, including CRC, and press enter, it would be sent through the XEP to the M1.  Timing here is tricky, because you must type the whole command in-between receiving messages.  A program could easily do it, though.

 

This demonstrates communication via a LAN.  Communication via the Internet is similar.  In that case, the XEP would be connected to a router which has a cable modem or DSL connection to the Internet.  The router must be programmed to forward port 2101 from the Internet side to the XEP side.  Then, any PC on the Internet can use HyperTerminal to connect to the router's IP address on port 2101.

 

HOWEVER: Since port 2101 is "non-secure," we do not recommend forwarding it on the Internet.  You could do so temporarily just for testing and set-up, but it is not a permanent solution - it allows ANYONE to connect to your XEP and thus, your M1.  Therefore, the XEP has a "secure" port - port 2601 by default.  If you connect to this port, the XEP will negotiate a secure SSL/TLS connection with the remote connecting site.  The remote site will need to accept the XEP's certificate.  Then the XEP will prompt for a username and password (these are set up using ElkRP).  If the remote site responds with the correct username and password, the connection is allowed and everything works from there on as described above, except that the data sent over the wire is now automatically encrypted.  If you intend to write a program to do this, you will need to already know or learn about the SSL/TLS protocol and how to implement it in your chosen programming language.  Helping you learn that is beyond the scope of what Elk Products can do.

 

I hope this helps.  If we can be of further assistance, please let us know.

[support]

OK so the Ethernet Expander is really just a dumb serial-to-Ethernet pass through adapter. Basically your ELK is just a serial device and has RS232 or RS485 port but no built-in Ethernet capability.

If the ELK is not far from the PLC you may save yourself some headache by connecting the serial port directly to the PLC. Since F1616-BA has 3 serial ports it can easily connect to both the Maple system and the ELK at the same time.

If you prefer to connect via Ethernet port, then you have to experiment using the Telnet console or HyperTerminal operating in Telnet mode and see what message the ELK returns when there is an incoming connection from Ethernet. From the emails provided by ELK it sounds like the XEP will send some messages when connected. You need to know how many lines of these will be received and you can use the INPUT$(4) command to receive all the strings sent by the XEP upon connection. Your PLC program can check for the expected response string and that way your program knows that it has made a good connection to the ELK. It can then start to send commands to the ELK using the PRINT #4 command and receive response from the ELK using the INPUT$(4) command.

The email you enclosed in your last post mention CRC - does the ELK protocol require CRC? If so is it CRC16 or CRC32? The TBASIC language has built-in command to compute the CRC16 but no support for CRC32. If you can disable the CRC on the ELK that it will make communication much easier. Ethernet protocol stack itself already uses the highly reliable CRC32 to handle the TCP/IP messaging and there is really no need for your ELK protocol to use any CRC.

[tobor0216]

I will have to check with Elk regarding the CRC. Here is what their RS_232 Protocol document says " Error Checking
The transmission contains checksum and packet length error checking. No acknowledge or re-transmission capability is implemented."

Unfortunetly the serial port is how i connect to the Elk panel with my PC. So I have to use Ethernet.

I have the following code working and I am receiving a 1 and a 6 indicating I am connecting to the ELk panel from the PLC, I think.

How do I read the data from input 4


FOR I = 1 TO 10000
 C$ = INPUT$(4)

 IF LEN(C$) > 0
 D$ = C$
 Endif  'new command available in TRiLOGI 6.4 and higher
 
NEXT

IF STATUS(3) = 1
 
A = 1

ELSE
 A = 6    'connection failed,  exit function
ENDIF

Print #4 "</>"

[support]

what do you see in D$?

Your code returns A =1 if there is a successful connection and A = 6 when there is a failure. If you are receiving one or the other it just means sometime you get a connection and sometime you don't. Status (3) is use to return the status of a recent connection but it is what you are going to receive from ELK that matters (i.e. what's in D$) to your application program.

[tobor0216]

D$ is showing ERR:05 Prev Conn On.

I am trying to get the communication established and to transfer data ( it does not matter if the format is wrong, once I get the data flowing I can work on the format)


A is toggeling betwen 6 and 1.

[support]

It shows that there was a connection (WHEN A == 1) but because it was not properly disconnected before you attempt to re-connect again, and the connection failed the second time because the client socket has been used. The PRINT #4 "</>" closes the connection but the process takes time so you need to coordinate the command/response timing in order to get good communication.

[tobor0216]

How do I keep the connection open all the time?

[support]

If you need to keep the connection open then don't run the PRINT #4 "</>" line. Only run this statement when you are ready to close the connection.