Host Engineering Forum
General Category => ECOMs and ECOM100s => Topic started by: rkimble 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! :)
-EDIT-
Changed "Serial" to "TCP" in subject to be clear about network communications as opposed to local serial communications over a COM port.
-
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.
-
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.
-
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.
-
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.