Host Engineering Forum
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
May 21, 2012, 06:51:51 pm


Login with username, password and session length


Pages: [1]
  Print  
Author Topic: Direct TCP Communications to ECOM100  (Read 1590 times)
rkimble
Newbie
*
Posts: 2


« on: August 25, 2008, 01:09:12 pm »

Hi all,

I am interested in writing a small .Net application which will automate a process of writing a single memory register in a DL260 at the demand of a mainframe.

I would like to avoid utilizing the unmanged C++ API which is referenced by all existing "VB" examples.  It would appear to me that the API is not specifically "necessary" for communication with the PLC.

I want to ensure that I can use standard TCP socket functionality to communicate directly with the ECOM (rather than through the wrapped API).  I realize that I would be responisble for constructing the entire packet between my app and the ECOM, but from what I've seen, it is not a complex set of headers.

I am quite well versed in .Net and have no fear of direct socket coding.  In fact, if I am correct, I would not be opposed to expanding my simple need into a well rounded, fully managed, .Net API - if there was a community interest in doing so.

At any rate, I thought it prudent to begin with this simple question and get the thoughts of the experts.  Thanks in advance to anyone who puts some thought into this!   Smiley

-EDIT-
Changed "Serial" to "TCP" in subject to be clear about network communications as opposed to local serial communications over a COM port.
« Last Edit: August 25, 2008, 01:11:22 pm by rkimble » Logged
Greg
HOS†ech
Host Moderator
*****
Posts: 320


Hmmm...


WWW
« Reply #1 on: August 29, 2008, 03:05:58 pm »

Sounds like you need to get our Ethernet SDK and manually change it over to .NET.

http://www.hosteng.com/Ethernet_SDK.htm

At the bottom of that page is a request form for the source code. It's all free.
Logged

"You have to believe in free will. You have no choice." -Isaac Bashevis-Singer
rkimble
Newbie
*
Posts: 2


« Reply #2 on: September 05, 2008, 02:31:25 pm »

I already have the source of the SDK.  From what I can tell, most of it should not be translated to .Net - most of it has to do with handling I/O and should be replaced with native .Net functionality.

What I need specifically, and am having trouble extrapolating from the source code is the following:

CCM Request Packet Definition
CCM Response Packet Definition
Function/Control Code list

I think I have the function list in the form of the #define FUN_NNNNNNN definitions in HEI.H.  And from what I see in the HEICCMRequest function it looks like packet layout is:

1:[Function]2:[Unused]3:[Request Code (always 1?)]4:[Read/Write]5:[Data Length (max 255)]6:[Address LSB]7:[Address MSB]8:[Data Type][Data to Follow...][...]

I haven't figured out exactly where the DataOffset value come from.  The Buffer size is 321 bytes, and the 8 bytes of command listed above are inserted into the 321 byte buffer at DataOffset.  DataOffset is retreived from the HEIDevice structure, but I'm not sure how it is determined - queried from the device perhaps?

In any event, my problem is mostly with the response packet definition - I haven't found a layout for it.  Page 32 of the Ethernet Interface Specification document, in conjunction with the source of HEICCMRequest gives the layout for the request packet, but I'm having difficulty inferring the response packet structrure from the code.

With a clear definition of the Request/Response packet for each of the "HEI Common Functions", a fully managed .Net API would be pretty easy to build...

I'll keep digging through the source, but it would be wonderful if someone could give me a jumpstart with those packet definitions.
Logged
Peng1
Newbie
*
Posts: 3


« Reply #3 on: October 07, 2008, 02:11:54 pm »

rkimble,

I believe that you will find some useful information in the DirectNet(CCM) Manual provided by Automation Direct.  In fact I have already used this manual to write a .Net application that communicates over a serial network ( An application that if this is the same rkimble from the MSDN forums you have personally helped me with.).  I can hit ya with a the protocol that I have written if you wish, I sure you can vastly improve on it.

I to am trying to port the SDK into a fully managed  version and running into some of the same issues.  While searching I noticed that when you Open a device through the HEIOpenDevice function it sets the DataOffset to the PACKET_HEADER_SIZE.
Logged
MikeS
Host Moderator
*****
Posts: 176



WWW
« Reply #4 on: October 08, 2008, 02:19:09 pm »

I think Peng1's correct in that the DataOffset value doesn't apply to the HEI layer, it's pertinent to the underlying CCM request layer - which should be discussed in the CCM (DirectNET) manual.
Logged

Good design costs a lot. Bad design costs even more.
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.16 | SMF © 2011, Simple Machines

Valid XHTML 1.0! Valid CSS! Dilber MC Theme by HarzeM