Unable to link to Delta DVP-ES2 simulator

[dtefili]

Hi.
I am trying to use AdvancedHMI with a simulated Delta DVP-ES2 and later I want to use is with a physical device. I saw many cases of successfull comminication with real devices, but I have no yet seen any with the simulator.

I have previously communicated with both real (RS232) and simulated (TCP) DVP-ES2 by sending Modbus strings with Python. The message structure is like:

[dtefili]

Continuing...
The messages have the format :0103100002CS\r\n
start bit, 03 read register, 1000 address, 02 bytes to be read, CS checksum, \r and \n are the tipical end-message markers.
Both physical and simulated PLCs answer these messages properly in Python, but do not answer AdvancedHMI requests.

With Wireshark, I captured packages going from AdvacedHMI to the virtual PLC. This is the content:
    TCP payload (12 bytes)
Data (12 bytes)
    Data: 010700000006000310000001
    Text: \001\a

In Data field, I would expect something like :0103100002CS.

Does anyone have a clue on what I am doing wrong?

[Archie]

Which Modbus driver are you using and what Mobus address are you putting the PLCAddress of the control?

[dtefili]

I added ModbusTCPCom1 from native toolbox to the basic project and pointed it to 127.0.0.1:10012.
Read address is 404097, witch I saw in a video posted on the forum and it matches the PLC manual modbus address for D0.
I also tried other addresses and formats.
I still have not tried to connect to the physical device.
Screen captures attached.
Thanks.

[Godra]

Try changing the UnitID from 0 to 1 since slave devices ID should go from 1 to 247.

If this is all done on a Windows based computer then there is another test you can try:

 - Download the exe file from here: https://github.com/GitHubDragonFly/ModbusMaster
 - There is also a slave simulator exe file available for download but you can stick with your simulator
 - See the attached picture of how these communicate with each other

[dtefili]

I have already tried to change unit id, even though this device considers 0 as a broadcast address.
I was right now trying another modbus server simulator and it works. This is the raw data from wireshark.
01e100000006010300000001
01e1000000050103020001
01e200000006010300000001
01e2000000050103020001
01e300000006010300000001
01e3000000050103020001
01e400000006010300000001
01e4000000050103020001
01e500000006010300000001

Asking Wireshark to interpret this as ascii results in gibberish:
.A...........A..........B...........B..........C........


The ending of the packages (the content 0103020001) matches what I expect from the Delta simulator.
Here are packages of the communication between the programmer (ISPSoft) and the virtual plc in raw data:
3a30303033313346323030303146370d0a
3a3030303330323030303246390d0a
3a30303033313430303030303145380d0a
3a3030303330323030303146410d0a
3a30303031304246313030303130320d0a

and in ascii interpretation by wireshark:
:000313F20001F7
:0003020002F9
:000314000001E8
:0003020001FA

I also tryed to switch modes ascii/rtu in the PLC program. Seems like there is a difference between the way the softwares interpret the strings or bytes.

For comparison, this is the way I communicate with both physical and simulated PLC in Python, and it works:

            command = b'000310000001'
            lrc = libscrc.modbus_asc(command)
            start = b':'
            end = b'\r\n'
            message = bytes(start + command + lrc + end)
            sock1.send(message)

Thanks for the help. I will keep trying.

[Archie]

Can you download version 3.99y Beta from this forum and test with it? 3.99x is frozen from any changes, but 3.99y is still actively developed.

[dtefili]

With the new version, things are getting better.
This are TCP packages content in Wireshark:

Data: 010100000006010310000001 Text: \001\001
Data: 010200000006010310000001 Text: \001\002
Data: 010300000006010310000001 Text: \001\003
Data: 010400000006010310000001 Text: \001\004

All of then end with 010310000001, which is correct. Id, read register, address and quantity of bytes.
But all of then start with some kind of message identification and numbering.
PLC only answers with ACKs.
I may tweak with properties or try to find the code that generates the messages.

[dtefili]

It seems Delta communication protocol is simpler than the typical
Transaction ID: 0100
Protocol ID: 0000
Length: 0006
Unit ID: 01
Function Code: 03 (Read Holding Registers)
Data: 1000 01 (Register Address 1000, Quantity 1)

Delta does not use the first three fields.

[Archie]

But all of then start with some kind of message identification and numbering.

ModbusTCP packet has a transaction Identifier, Protocol Identifier, and a packet length that precedes the PDU.

It sound like the simulator is using ModbusRTU

[dtefili]

Advanced HMI ModbusRTUCom implementation only seems to work with serial ports.
I will try to conect it to the physical device.

[dtefili]

Not yeat.

Serial properties set/detected with manufacturer communication manager and set in AvancedHMI ModbusRTU:
COM3
Baud Rate 9600
data length 7
parity even
stop bits 1
mode ASCII/RTU (I tryed both in the PLC and both drivers in AHMI)

Packages captured with Wiresharck USB:

Frame 135: 35 bytes on wire (280 bits), 35 bytes captured (280 bits) on interface \\.\USBPcap1, id 0
USB URB
    [Source: host]
    [Destination: 1.1.2]
    USBPcap pseudoheader length: 27
    IRP ID: 0xffff938ba1040010
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
    IRP information: 0x00, Direction: FDO -> PDO
    URB bus id: 1
    Device address: 1
    Endpoint: 0x02, Direction: OUT
    URB transfer type: URB_BULK (0x03)
    Packet Data Length: 8
    [Response in: 136]
    [bInterfaceClass: Vendor Specific (0xff)]
Leftover Capture Data: 02031000000180f9

Frame 136: 27 bytes on wire (216 bits), 27 bytes captured (216 bits) on interface \\.\USBPcap1, id 0
USB URB
    [Source: 1.1.2]
    [Destination: host]
    USBPcap pseudoheader length: 27
    IRP ID: 0xffff938ba1040010
    IRP USBD_STATUS: USBD_STATUS_SUCCESS (0x00000000)
    URB Function: URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER (0x0009)
    IRP information: 0x01, Direction: PDO -> FDO
    URB bus id: 1
    Device address: 1
    Endpoint: 0x02, Direction: OUT
    URB transfer type: URB_BULK (0x03)
    Packet Data Length: 0
    [Request in: 135]
    [Time from request: 0.000133000 seconds]
    [bInterfaceClass: Vendor Specific (0xff)]

[dtefili]

Progress!
Physical device standart is Modbus ASCII, which was really not implemented in version 3.99x.
I am now able to communicate with it.
Thanks a lot, Archie.

And the simulator simply packes these messagens in TCP packages and ignores station id and modbus checksum.
So, I guess I would need to do some changes in the way AdvancedHMI generates the messages in order to use the simulator too.
Any tips on that will be welcome, but I am already installing AdvancedHMI in our computers and will try to increase the frame rate.
Great job! Congratulations and thank you!

[dtefili]

Hello.
I managed to make it work with a software called HW VSP3 - Virtual Serial Port.
It creates a virtual serial port and links it to a TCP port.
So I just need to point AdvancedHMI ModbusASCHIICom to the virtual COM99, for example.
It works fine with 8 elements at about 2 fps.

I am posting it here in case somebody else needs it.

My next step is to try to connect to Siemens S7 device and simulator. As I read, there seems to be a solution for this one in the forum.

Thanks a lot.