Hello all,
I have been struggling for days to setup Modbus TCP between my Automation Direct HMI (model C5) as the master and a Yaskawa MP3300iec PLC as the slave. I have not found a step-by-step guide to walk me through this (and suspect such a guide specific to my hardware does not exist).

The MP3300iec PLC uses Yaskawa MotionworksIEC (version 3) software.
The HMI uses software "C-MORE" (version 8.22) from Automation Direct.

My immediate goal right now is to communicate ANYTHING between the PLC and the HMI using Modbus TCP. To start with, I am attempting to communicate the value of 1 discreet bit that toggles on/off/on/off. I can not accomplish this.

The Yaskawa MP3300iec (programmed using MotionworksIEC (version 3)) does not have a driver specific to the Automation Direct HMI. Therefore in the Motionworks Hardware Configuration I select "Generic" as the Manufacturer.

In this same Hardware Configuration screen I set the "Resource" to the name of the Yaskawa PLC ("Ganty_01"). Although currently the only option for "Resource" is the selection called "Retentive" and selecting "Gantry_01" is no longer possible. See attached file. Along the way I did rename the Resource from "Gantry_01" to "MP3300", so that could be part of the reason. Regardless, good or bad, "Retentive" is now the one and only selectable option for "Resource".

Anyway, when I export the tag list from Motionworksiec, the file format has little in common with the format used by the HMI. So, I edit the exported CSV tag list to a format that the HMI appears to need, and import it to the HMI.

Perhaps the biggest concern is that I added a tag (I added a row to the Global Variables in Motionworks) but this entry is NOT included in the exported tag file. The added tag is "HMI_INPUT...HEARTBEAT" (see image).

I share the images of the CSV files mainly so you can see the headers. I have edited and changed the contents of the CSV files many many times, so I know the images as shared are not correct.

On the HMI side, in the CMORE software, there are options to be selected in the "Protocol Manager" screen. Options I may or may not have selected correctly.
In "Protocol Manager" I have the choice of FC#05 or FC#15 and also a choice of FC#06 or FC#16. I assume CMORE DOES also handle FC#01, 02, 03, 04 as well and they are simple absent from this screen because... no setup is required?

Thank you in advance for any direction you can provide on any aspect of communicating Modbus TCP between these two devices.

 

I recommend starting by simplifying the problem. Split it in half by using a Modbus Client simulator on your computer and trying to establish communications with the PLC, reading only a single Holding Register. After you've succeeded doing this, then use a Modbus Server simulator on your computer and try to establish communications with the HMI, again reading only a single Holding Register.

Here are some recommended Modbus software tools:
ModScan (client) / ModSim (server)
https://www.win-tech.com/

Modbus Poll (client) / Modbus Slave (server)
https://www.modbustools.com/

Simply Modbus (client)
https://simplymodbus.ca/TCPclient.htm

I wouldn't think you would need to rely on CSV files, especially if you're trying to manually craft your own. The software for the HMI should allow you to create and map tags to the PLC's Modbus registers without having to import a CSV file. This video seems to show an example of that:

From that video, it appears that each tag has both a Tag Data Type (which presumably dictates the data type used for the tag in the HMI itself) and a Memory Type under the PLC Address (which presumably dictates the Modbus reference type). I would suspect that the memory types follow standard Modbus references, as follows:

1. 0 - Coils
2. 1 - Discrete Inputs
3. 3 - Input Registers
4. 4 - Holding Registers

For the PLC, it's possible that it uses a preconfigured or even fixed Modbus mapping to the internal variables (e.g. %IX, %IW, %QX, %QW). This link seems to imply this:
https://www.exorint.com/faq/2017/06...th-an-yaskawa-mpiec-controller-via-modbus-tcp

Keep in mind, not all devices uses the same register addressing scheme. Some need to start from 0, others from 1. Some require the register type offset (i.e. 40,000 for Holding Registers), others don't. Refer to this post for details:
https://control.com/forums/threads/modbus-register-numbering.49844/

 

Super helpful, thank you! Working on this now...

 

After many edits, I arrived at a point where my HMI has a few pushbuttons on the screen, that toggle a tag bit TRUE/FALSE when manually pressed... and it "works". I mean on the PLC side I can see the tag value update TRUE or FALSE to match with the 1 or 0 status of the tag in the HMI. Great. BUT...
1) perhaps 5% of the time when I press the HMI button the process fails. I mean the PLC will react correctly (by changing to TRUE or FALSE)... but the HMI does not display correctly. I specifically mean that normally the HMI pushbutton color changes between gray (off) and green color (on) with each press. But sometimes I make the press, the PLC tag value correctly updates, but the color of the HMI button does NOT update. So there is a mismatch: the button appears to be turned off (is gray), but the PLC sees the tag assigned to that button as "on". In the HMI software (C-MORE) I changed the communication "retries" from a value of 3 up to 9. This seemed to help, but did NOT eliminate the issue.
2) this communication between PLC and HMI only started to happen when I created the pushbuttons such that I could toggle the tag value, from the HMI side. Okay, fine, but I have a different tag (a "heatbeat") that is constantly toggling TRUE/FALSE every 1 second, on the PLC side. On my HMI screen the associated indicator graphic (that should be changing color every 1 second as the tag value toggles) never changes color. The HMI graphic color does change correctly, when using a simulator inside the HMI CMORE software, but in real life does not see the value from the PLC.
So my question: is there something I need to be doing to initiate the communication?? Supposedly there is not, because once the configuration is all set up correctly, Modbus TCP just starts communicating with no special prompt to do so?
Thank you!

 

#1 is odd and doesn't seem to be related to Modbus communications at all. It seems to be some issue/disconnect internal to the HMI between the graphics and the tag. Therefore, retries should not have any effect (perhaps seeing a positive effect was just a coincidence with a randomly occurring issue).

Do you have the ability to view the live values of the tags in the HMI via the C-More software? This may be helpful for narrowing down synchronicity issues between the graphics, HMI tags, Modbus communication, and PLC tags.

The HMI is the client, so it is responsible for initiating read and write requests to the PLC. I suspect, when you press the pushbutton on your HMI, this changes the corresponding tag in the HMI, triggering a write request to be sent from the HMI to the PLC. Regarding #2, for reads, they either need to be triggered manually or the HMI uses an automated scanning approach. If the latter is the case, there usually is some sort of configuration settings for how often requests are set (i.e. polling interval) or the amount of delay between each request. Some devices allow tags/registers to be write-only or read-only, so it's possible the tags/registers you have configured to read from the PLC are not enabled to read or not added to a scan list or similar.

As general advice, again, simplify and divide and conquer. Try using a Modbus server simulator on your computer with the HMI instead of the PLC. Many Modbus simulators allow you to view the Modbus traffic in real time. If not, you can always use Wireshark running on your computer to capture and analyze the traffic. This would tell you exactly what the HMI is doing, as far as Modbus communication goes.