PLC to PLC communication

[tharun]

How to send a value from one PLC and receive with the other one? Here I use SCADAPACK 32 and SCADAPACK 357. The firmware I use is Telepace studio 5.4.2. I connected those two PLCs with an ethernet cable. I connected the receiving end PLC to the PC through MODBUS RTU. But it isn't receiving.

[BevanWeiss]

For peer-to-peer communications you need to pick a common protocol and then configure BOTH ends to utilise it correctly.

For a protocol like DNP3, then you would need one end to act as a Master and either perform a Read, or an Operate command (Operate is more common in this application).  The other end would then act as a Slave.

For a protocol like ModbusRTU then you would also have one end as a Master, and either issue a read request, or issue a write request against the Slave (in this situation it is more common to have the Master perform a read operation).

For ModbusTCP, then you would configure one end as the Client, and the other as a Server.

You should put together a diagram of the data transfers, and try to isolate where your communications isn't working.  When you find a high level link that isn't working, then you should be able to drill into it a little more to break it into further parts that you can inspect to identify the underlying issue.

[tharun]

Glad you replied. I've configured both PLCs appropriately to the Telepace Studio (Firmware) on a workstation. I've downloaded a simple program in slave PLC which sends signal to other PLC (master). The data sent from the slave PLC isn't receiving at the master PLC end. Does anything needs to be done at the firmware side? I am using MODBUS tcp at the receiver end. An Enthernet cable bridges the 2 PLCs.

[Joel_Weder · Accepted solution]

Hello,

I have attached an exercise from the Telepace training manual. It is for the serial MSTR function block, but the functionality is somewhat similar. There are some differences, so be sure to read the Help on the MSIP function block also. But for learning to make the MSIP block work, you might try using this exercise. (with the appropriate changes) Other comments:

- Each RTU must have an IP address within the same subnet, and subnet mask must match. These and other parameters are configured in the IP settings, either the LAN or the Modbus items.

- Each RTU must have a different Modbus Station number. Example the SP357 could be 1 and the SP32 could be 2.

- Ensure that Modbus/TCP is enabled in both RTU's. This should be enabled by default, but verify it.

- Ensure the Ethernet cable is correctly built. Try another if not sure.

- Also, this may seem silly but make 100% sure you are plugging the Ethernet cable into the correct RJ45 connector !! Serial ports also use RJ45 so this can be confusing.

- The MSIP configuration block is longer than the MSTR config block, so ensure you do not overlap registers

- Make sure you are enabling the Open input of the MSIP block, as well as the Send Message input.

- ONLY the SP357 will require an MSIP function block, as you have stated it is the one sending messages to the SP32.

- In the MSIP config, ensure you correctly enter the other RTU's IP address and other parameters. Eg specify correct function code, correct slave RTU station number, desired registers to read from or write to, quantity of registers.

- Timeout value can be fairly brief if a hard-wired connection, but don't set it too short. Start with 30 = 3.0 seconds.

After you have ensured all of the above items:

- Go Online with the RTU to watch the MSIP block activity

- Make sure the function block is being properly triggered. Check the outputs - is the Done or Error output going on?

- Monitor the Status code that is generated. This is documented in the MSIP help documentation.

- Watch the LAN port LED's on the front of both RTU's. The activity LED on the RTU that is generating the messages should flash at whatever rate you have specified, and the other RTU's activity LED should also flash.

[BevanWeiss]

---

@tharun wrote:

... I've configured both PLCs appropriately to the Telepace Studio (Firmware) on a workstation. ...

---

When something isn't working, it's generally best not to start from the position of "I've configured ... appropriately" or "I've configured ... correctly".  Because if it was all correct, it would work 😉

So provide us all of the configuration settings that you have done, and what it is that makes you think that it's correct/appropriate.

If you're using serial, do you have the correct cable connections (PROVE IT), do you have the correct baud rate, start / stop / parity bits (PROVE IT), do you have the correct master settings to connect to the slave (PROVE IT), and are you trying to read/write the correct registers (PROVE IT)

Ditto for using ethernet.. but then IP addresses get involved too.

If you say that they have the right IP addresses.. well tell us what your ping results were.  If there is a firewall in between, tell us how you verified that it wasn't the problem.

You've said "The data sent from the slave PLC isn't receiving at the master PLC end".  That implies that you know the Master has sent the request to the Slave successfully (PROVE IT).  If the Slave is just sitting there not being asked for data, or told to update data, then it won't send anything.  It's a Slave.  It does what it is told (by the Master).

[Joel_Weder]

Hello again,

I believe you may be in the region of India. It seems best at this point to save your SP 357 and SP 32 programs, and send those (along with a description of exactly what you're trying to accomplish) to our support team in that region. Here is the contact information:   Customercare.in@se.com

[tharun]

The issue hasn't solved yet. I've attached the concerned file. These are program files of two SCADAPACKs among which the communication needs to be established. These SCADAPACKs communicate through MODBUS RTU (null cable) RS-232. I've set configuration settings to the best of my knowledge. If there is anything wrong kindly reply as soon as possible. These two are monitored through MODBUS tcp.

[MartinChartrand]

Hello Tharun,

I don't see any attachments. Could you please verify that you have successfully attached them?

Thank you.

You say that the communication is serial Modbus RTU via a null cable. Can you verify what the serial port LEDs are doing on the sending port (Master RTU) and the receiving port (Slave RTU). This will also help determine what's going on.

Regards,

Martin Chartrand

[Joel_Weder]

As mentioned previously, because of the many detailed questions involved in this project, it would be best for you to contact the Customer Care team. They will be much better able to work with you, as their primary role is full-time support of customer issues. They may be in a closer time zone to you, and they may even be able to phone you. Please do make sure you send them the configuration files and a full description of the issue.

You can contact either:

Customercare.in@se.com  (based in India)

OR

SupportTRSS@se.com (based in Canada, may just refer you back to the first team)

[tharun]

Hello sir, we mailed the customer care team. There is no response from their side. This issue here needs to be solved as soon as possible. 

[tharun]

I couldn't attach the files. I think the web page doesn't support the file type. Can you please share your mail ID sir? I would send you through mail. And only CTS LED of com port is glowing. 

[MartinChartrand]

Hello Tharun,

You should be able to zip the files together into one .zip file and upload. Once I have them I will do a quick review of the programs to see if anything is obviously incorrect then I will forward the case to our tech support team for follow up if I don't find anything.

I am not tech support but have some past experience with these devices so I might have some comments for you. But as Joel has said, it's best if our support groups assist you.

Thank you.

Regards,

Martin

[Joel_Weder]

Hello Tharun,

I just spoke with our Tech Support team leader. He has sent a note to the support team in your region to please reach out to you as soon as possible. We do feel that it would be best if you work with them, to avoid further delays in response time. If they have not contacted you within a couple of days you may wish to communicate back to the team leader of our support group, at this address:  SupportTRSS@se.com  But please do first wait for the regional support team to contact you.

[tharun]

Hello sir, glad you replied. Here is the file.

[tharun]

Hello sir,

It has been couple of days since we mailed the regional support team. The case reference token has been generated. But there is no response from them. I would consider getting in contact with the team leader of your support group. And thank you for your support sir.

[MartinChartrand · Accepted solution]

Hello Tharun,
My comments below are not intended as an official Tech Support response as I am not on that team, I am only assisting as a member of the forum community using my past experience.

My comments are also based on my assumption that you are doing a Com2 to Com2 serial wired connection between the two SCADAPack controllers.
Please note that I do not have the required SCADAPack hardware to test my assertions, I am attempting to recall how I did this in this past when I used to program SCADAPacks.

I did a brief review of your Telepace programs:

1- I think the SCADAPack 357 program is ok to receive Modbus messages from the SCADAPack 32.

2- I think your SCADAPack 32 program was OK too but I have done a sample for you to try instead. This sample simplifies the MSTR block to send messages continually, based on it receiving a good response from the slave, or a timeout signal if the slave does not respond; in order to trigger the next MSTR message. I also removed the PULS block because it's not needed in this new scenario.

I then reconfigured the MSTR block to read digital input register 10006 in the SCADAPack 357 and to place this value directly into digital output 00004 on the SCADAPack 32 so that it will light up its LED. And finally I increased the timeout value to 2 seconds.

- First thing to do is to disconnect the serial cable between the two SCADAPacks.

- Cold boot or initialize the SCADAPack 32 to clear out the old program.

- Download my sample SCADAPack 32 program and put it into run mode.

- Watch the Com2 serial port LED activity on the SCADAPack 32. You should see the Tx LED briefly flash every 2 seconds because it's not receiving any response from the SCADAPack 357 and it then sends another MSTR message after the 2 sec timeout has elapsed. If this is what you see then on to the next step.

- Important: Make sure that Jumper J13 on the slave SCADAPack 357 is in the RS-232 position.

- Connect a 3-wire (Tx to RX, RX to TX, Gnd to Gnd) crossover cable between Com2 on the SCADAPack 32 and Com2 on the SCADAPack 357.

- Watch the Com2 LEDs on both SCADAPacks. If all is correct, the Tx and Rx LEDS on both SCADAPack Com2 ports should be flashing continually, indicating good communication.

- Toggle digital input 10006 on the SCADAPack 357. You should then see the SCADAPack 32's digital output 00004 turn on.

Good luck!

Martin

[tharun · Accepted solution]

Hello sir,

Thanks for your concern sir. The program that you gave worked 👍. 

[MartinChartrand]

That's good news! Good luck with your project.

Regards,

Martin Chartrand