Chiller handshake

[otrotabi]

I need to set up a configuration where two chillers are working in parallel with a common set point. We will be using TM172PD18S for this job.

Both chillers will have the same program and at HMI I will allow them to be configured as master or slave in this configuration so that eventually the customer may decide which one will play which role in this couple.

I am still not quite sure about how to implement it but I know I could implement this with Modbus, thus I would not sacrifice any inputs or outputs. This would also allow me to eventually compare temperature sensors, etc.

On the other hand, if communication fails, I will probably have the customer calling regarding how to solve a Modbus communication error.  I do not want to get too fancy and keep it relatively easy to troubleshoot over the phone or by mail.

How do you usually solve this ?

[LeTomas · Accepted solution]

Hi @otrotabi ,

One way to share information between M172P is to use Can Binding or Ethernet Binding. 

You will need to defined which variables you can share from PLC A to PLC B and which ones from PLC B to PLC A, you can take a look in the next presentation:

https://schneider-electric.box.com/s/8imqritcokbndw9aeystjt05ayum2wwn

If i am not wrong by doing this the configuration is fixed and if you need to make a change then a download is required.

Best regards,

Leandro

[otrotabi]

Thank you. This looks like a fine solution and fairly easy to implement.

You describe in pages 45 and ahead a way to test whether the communication is ok or not. My question is very obvious but I will do it anyway: you use this logic to drive the leds and then you would usually implement some alternative control logic for the PLC ? 

I mean, can I implement a master-slave logic and then in case communication fails I can have each chiller work as standalone ?

[LeTomas]

Hi @otrotabi ,

In the presentation it shows one possible code when one of the devices does not communicate with the other and that's it but in your case as you need them to work in standalone then you will need to create an additional logic once that variable of "alarm" is activated. 

Probably you will need to "play" with the assignation of the new setpoint for standalone when the communication fails.

One thing that you need to consider is how the migration is going to be from communication to standalone.. do you want that the operator do this or you want an automatic change? then in the other way from standalone to communication do you want a manual transition for safety or automatic? I believe there is a lot of thing to play with 😅

Best regards,

Leandro