Need Help trying to setup AVEVA Edge 2020 to Communicate with TM241CE40R via Modbus

[DellAnno]

Title summarizes the overview of the problem. I am trying to make AVEVA Edge 2020 and a Schneider TM241CE40R to talk to each other via Modbus TCP/IP Ethernet.

What I have done so far:
1. I have declared the Variables (%MDs) on the PLC
2. Those said variables show up on modscan with a "live" value (it's connected directly to sensors, Pressure, Temperature, Weight so the value "breaths around" constantly). So from this step I know that the PLC is outputting the Modbus TCP/IP signals and they are consistent with the values when monitored on the PLC directly using USB-B via Machine Expert.
3. I try putting in the addresses of the Holding in AVEVA and nothing seems to work. Here are the steps I took in AVEVA:

Comm -> Add/Remove Drivers -> Add MOTCP -> Tags, Station (i.e. 192.168.65.85:502:1), Address (i.e. 4X:*insert holding address here*)

The tags should be fine. They are already in place at the screens. I'm guessing that this is a me problem not understanding how to modbus too well.

I have tried adding and subtracting the Holding address by 1 in AVEVA. But other than that, I'm not too sure what went wrong. I have done MOTCP before, but it is on a different software (Weintek, EasyBuilderPro 60802) that went pretty straightforward and also connects to a Honeywell C70 900. So completely different systems but the logic should be mostly the same right?

Sidenote (optional, maybe relevant):
My prior experience in the world of PLCs is:
- TM221s, Machine Expert - Basic with HMiGXUs
- Pure Honeywell C70 900 System (Quickbuilder, HMI Webdesign, Designer Software, etc.)
- The Weintek one was recent and new but it was pretty simple so it was easy to pick up.
- Siemens PLCs & TIA Portal (very rare occasions)
- I've only used AVEVA a handful of times (pretty sure less than 5 times)

 

[Lare]

M241 and M221 modbus offset for %MD is different.
If I remember it correctly for M241 you need to divide %MD address by 2 getting modbus register address. So %MD2000 isn't on modbuss address 42000 or 42001.
Try 41000 and 41001 instead.


Still for %MW addresses it is still same than normally so %MW2000 is located to 42000 or 42001.


Sidenote
Modbus bits (%M range.) Well you maybe don't wan't use them on %M241 as they are located to bytes and one %M takes 8 modbus addresses then.



Modbus mapping on M241 is different than all others schneider PLCs.



p.s Welcome to forum

 

[DellAnno]

@Lare Thanks for the Reply

I'll try that. At this point my only options are trying that or use CodeSYS. Problem with that is to use CodeSYS you need to disable user rights which my boss told me an expected "no".

However it makes me think what ModScan was picking up then. Since the values were consistent. with the addresses.

P.s. Thank you for the welcome. I have a feeling I will be here more often asking questions in the future.

 

[DellAnno]

Bruh nothing seems to work

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.

CodeSYS doesn't work. Can't disable the User Rights.

Modbus doesn't work either. No idea why.

In a desperate attempt, I downgraded the M241's firmware to a 4.0.-ish so I can use SoMachine V4.3 since AVEVA has SoMac compatibilities. That doesn't work either.

Not sure what else is there to do. I feel like I'm missing a step somewhere.

 

[drbitboy]

I don't know if it is in your toolbox, but at this point I would find a way sniff the packets from and to the Modbus clients (Modbus masters): first see what Modscan is sending and getting back; then see what Aveva is sending (and getting back, if anything).

The Modbus protocol is simple to parse: see the Technical Documentation at https://modbus.org/. There are a few bytes wrapped around the Modbus PDU message for TCP/IP, but I suspect it is the PDU request message itself (function code, starting address, quantity of registers) where the light will come on. Facility with hexadecimal is a useful skill here, if you have it.

One thing I noticed in your configuration is the ":1" at the end of the address. I have no experience with Aveva, but I wonder what that value is. Its presence immediately after the ":502," which is presumably the Modbus server (Modbus slave) device port, makes me wonder if :1 is the client/master port, in which case 1 might be invalid and so would not be my first choice. Usually a ":0" or ":*" for client port would allow the software to find an available valid port, but again I don't know Aveva and I suspect that ":1" is actually summat else.

 

[Lare]

Have you configured variables on GVL (global variable list) this way


MyIntVariable AT %MW50 // int varible at modbus 40051 address


MyDintVariable AT %MD1000 // DINT variable at modbus 42001 address




My mistake, you need to multiple by 2 to get modbus address for %MD range.

 

[DellAnno]

@Lare

Thanks for the confirmation.

 

[DellAnno]

@drbitboy

At this point, if I need a bachelor's degree for Network Engineering just to understand how modbus works I might have to. I'll give that website a look.

 

[DellAnno]

One thing I noticed in your configuration is the ":1" at the end of the address. I have no experience with Aveva, but I wonder what that value is. Its presence immediately after the ":502," which is presumably the Modbus server (Modbus slave) device port, makes me wonder if :1 is the client/master port, in which case 1 might be invalid and so would not be my first choice. Usually a ":0" or ":*" for client port would allow the software to find an available valid port, but again I don't know Aveva and I suspect that ":1" is actually summat else.

On this topic, 502 is AVEVA's way of saying that the address attached to it uses the MoTCP protocol. The ":1" apparently according to a colleague is that it refers to the 1st rack for Honeywell HC900 C70. I find it odd myself but hey if that address format is working for other AVEVA I wasn't complaining. I am at the monkey see monkey do stage. I'll try your recommendation though.

 

[drbitboy]

On this topic, 502 is AVEVA's way of saying that the address attached to it uses the MoTCP protocol. The ":1" apparently according to a colleague is that it refers to the 1st rack for Honeywell HC900 C70. I find it odd myself but hey if that address format is working for other AVEVA I wasn't complaining. I am at the monkey see monkey do stage. I'll try your recommendation though.

I know what the 502 is. However, I think am wrong and your colleague is probably correct, that the :1 is most likely the Server ("Additional") Address of the Modbus protocol.

TL;DR

The Modbus Server Address is probably* a holdover from the time of multidrop serial (RS-485/RS-422) networks, to distinguish between multiple Modbus Server devices that would see the same Modbus Client request; this was before Modbus was expanded to the TCP/IP network layer.

With TCP/IP, the IP address and port, which is how a TCP/IP Client connects to the TCP/IP Server, is part of the IP (Internet Protocol) and external to the Modbus Protocol. So with TCP/IP the Modbus protocol's Server Address is usually* unnecessary because one IP address already narrows down all TCP/IP Modbus Server devices to the single Modbus Server of interest. Since most TCP/IP Modbus Server devices are single servers, the Server (Additional) Address is often hardcoded as 1, and even ignored, within the device firmware, because by connecting to that IP address on port 502, the Modbus Client has implicitly declared its intention to communicate with that TCP/IP server using the Modbus protocol.

* I say "probably a holdover" and "usually unnecessary" because there could be multiple Modbus Servers "behind" one IP address, for example when the IP address refers to a Modbus TCP/IP-Serial interface device that provides a connection from a TCP/IP node to a RS-485/-422 network, where the Server (Additional) address is again necessary to distinguish between multiple Modbus devices. Another possibility is that one TCP/IP Modbus device at a single IP address could implement multiple Modbus Server (Additional) Addresses e.g to effectively expand its address space or to access different sections of the overall device; this appears to apply to the current case for the HC900 C70, where there may be multiple racks.

 

[drbitboy]

At this point, if I need a bachelor's degree for Network Engineering just to understand how modbus works I might have to. I'll give that website a look.

Most protocols are very simple, and Modbus is no exception.

That said, if you can

• find and install a packet sniffer (e.g. WireShark),
• capture two packets of request-response for Modscan that works,
• capture two (or one) packets of request-response (or request only) for AVEVA that does not work,
• post those packets here,

then the solution might be readily found.

Remember, I said might, so no promises .

 

[DellAnno]

@drbitboy Dang, I don't have a Wireshark.

Nor do I think IT Department would appreciate me having Wireshark. I should still probably get it. The question is will IT let me install it on the control computers. Like I get it, cyber security is your job but come on I'm trying to do my work here. I'll have to ask their permission first.

 

[DellAnno]

Nevermind, they have a portable version. Hopefully this will circumvent the installation permission

 

[DellAnno]

Nevermind, still need to install NPCAP anyways.

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

 

[DellAnno]

Most protocols are very simple, and Modbus is no exception.

That said, if you can

• find and install a packet sniffer (e.g. WireShark),
• capture two packets of request-response for Modscan that works,
• capture two (or one) packets of request-response (or request only) for AVEVA that does not work,
• post those packets here,

then the solution might be readily found.

Remember, I said might, so no promises .

I got the packets here:
https://drive.google.com/file/d/1LyxvAYnby6L2H-Q-kWZ_Q1LtONYR6yQh/view?usp=drive_link
Because the file size is too big to upload in this website.

And I uploaded what ModScan is able to find in a picture (that is posted in this website as an attached file). It might not be those exact numbers but it should be well +1% tolerance as those values "breath" up and down.

For context, the 192.168.65.82 is the PC and 192.168.65.85 is the TM241.

I hope this was what you're looking for because I'm still learning how to understand what's in front of me.