Modify DF1Com or EthernetIPforPLCSLCMicroCom drivers to access COM over ethernet

[Godra]

Related to this topic: http://advancedhmi.com/forum/index.php?topic=899.0

Would it be possible to convert either of these 2 drivers to be able to access COM based PLCs over ethernet?

The SerialToIP server provides transparent access to a PLC connected to COM port so it would have to be the driver to properly access the PLC and issue correct commands.

[Archie]

You would essentially have to get the protocol specifications for the Ethernet to Serial converter and write another driver layer.

[Godra]

Archie,

If I try to do this on my own that could take quite some time.

Since you know your drivers "by heart" could you let me know which part of EthernetIPforPLCSLCMicroCom driver is actually establishing connection before sending a packet?
Is it possible to have that part included in DF1Com driver so it could route its packets to ethernet port instead of COM port?

Kind of trying to combine and make 1 driver out of 2 existing.

[Archie]

At the lowest level in the DLL file is a EIPTransport class that ultimately handles the transfer of the packets to the Ethernet port.

What would probably need to be done is a new DF1DataLinkLayer class be made that would accept the packets, wrap them in the protocol for the particular converter, then send the via Ethernet.

The Allen Bradley 1761-NET-ENI module will do all of this. It will let you use the Ethernet drivers to talk to a serial based PLC.

[abslcplc]

I have a Moxa N-Port Ethernet serial port on my network, and on 2 desktops & a laptop it is configured as a COM port  & I can use the regular DF1 driver to access it from either of the desktops without any modification of the driver.

[Godra]

The change to the driver is not required at all.

As shown in this topic: https://www.advancedhmi.com/forum/index.php?topic=899.0 the driver works fine together with com0com and SerialToIP programs to provide access to a serial device over ethernet just by using 2 computers (most users might have an old computer sitting around that they could use for this instead of purchasing physical serial to ethernet device).

The change to the driver would only help those who would be looking to avoid hassle of installing/configuring com0com and running SerialToIP software on client computers. They would still need to run SerialToIP server program on the server computer.

Additional feature can only provide additional options to users.

[Archie]

I may not be completely understanding everything here. I read the other post in more detail and this is what I am interpreting. You have 2 PCs. One is connected to the PLC via serial port (or with a USB-to-RS232 adapter). The other PC is used to communicate to the PLC via Ethernet.

The 2nd PC sends data to a virtual COM port that is then transmitted to the 1st PC over Ethernet. The 1st PC receives the packet and relays it through the COM port to the PLC.

What you want to do is to bypass the software on the 2nd PC and send the packets directly to the server on the 1st PC that is connected to the PLC?

[Godra]

That would be correct.

[Godra]

The PC connected to PLC actually behaves as Allen Bradley 1761-NET-ENI module, which connects the serial device to ethernet network.

If DF1Com driver could send its packets directly then there would be no need for either com0com or SerialToIP software on client computer.

[Archie]

This is what I think would have to be done. In DF1Com.vb, this defines where the packets go:

    Private Shared DLL As System.Collections.Concurrent.ConcurrentDictionary(Of Integer, MfgControl.AdvancedHMI.Drivers.DF1DataLinkLayerR1)

There is a SendData method as part of the DF1DataLinkLayerR1 class. Essentially a new class would have to be written that implements the SendData to transmit the data to the UDP port that is listening on the server side.

Part of the DF1DataLinkLayerR1 class is an event of Df1DataLinkLayerDataReceived.

[Vitor]

Godra
Ethernet/IP and DF1 are diferent protocols.
The sugested 1761-NET-ENI is a piece of skilled hardware+software that makes the translation between the two, like the 1747-UIC makes the same between DF1 and DH485.
I think its possible to do what you want at software level, but also i think in the mighty effort it will be...

[Godra]

Vitor, you might be right.

Currently, SerialToIP software is handling the transport of DF1 packets from COM port to ethernet and it works just fine so I will stick with it.

Arrchie does seem to understand the idea I suggested but for me to realize it goes currently beyond my knowledge.

[Archie]

As I thought more about this, I wonder if the solution is to make a server component that can receive PCCC Ethernet/IP messages and relay them to a serial port. Essentially this would make a PC act like an ENI module.

The PCCC packet is essentially the same whether wrapped in an Ethernet/IP packet or sent over serial. The only difference is that it has 2 additional bytes for the source node and target nodes (always 0 for point to point), the checksum, and STX/ETX bytes.

[Godra]

I don't completely understand your point. Would it be a server component within AHMI?

The SerialToIP software can act as a server and is already programmed and free to download (along with the source code).

This server seems to accept any packets that come to its port and just sends them to PLC. If packets were in correct format then PLC will respond. You can see the attached picture of 2 drivers that I tried and their routes as well as response of the server to both of these. The Route 1 is working fine but the Route 2 has 28 Bytes reach the server but get no response from PLC.

If DF1 driver could wrap its packets and send them directly over ethernet that would probably be the best solution. I did try just opening a server socket and/or using TCPClient from within the DF1Com driver and sending its packets <-- the packets did reach the server but I din't know how to go about getting a response (and still not sure if packets were in correct format, all I know is that 7 bytes were received by the server).

[Godra]

The PCCC packet is essentially the same whether wrapped in an Ethernet/IP packet or sent over serial. The only difference is that it has 2 additional bytes for the source node and target nodes (always 0 for point to point), the checksum, and STX/ETX bytes.

Archie,

Could you provide some more information about these additional bytes?

From your driver code, I can see that you are adding source node and target node values to "datawithnodes" but what variables are holding the checksum, STX/ETX bytes. Would TNS and MyObjectID need to be included in the packet as well?

Code: [Select]

    Friend Overrides Sub SendPacket(packet As MfgControl.AdvancedHMI.Drivers.PCCCCommandPacket, ByVal TNS As Integer)
        Dim TNSByte As Byte = Convert.ToByte(TNS And 255)
        RawRequests(TNSByte) = packet
        RawRequests(TNSByte).Responded = False

        Dim data() As Byte = packet.GetBytes
        Dim dataWithNodes(data.Length + 1) As Byte
        data.CopyTo(dataWithNodes, 2)
        dataWithNodes(0) = m_TargetNode
        dataWithNodes(1) = m_MyNode

        DLL(MyDLLInstance).SendData(dataWithNodes, TNS, MyObjectID)
    End Sub

If the following packet is captured from serial port:

HEX 10 02 01 00 06 00 AC 24 03 10 03 E0 00

Would a packet sent directly from driver to server socket have to be the same format?