EB Pro: Working with two HMI's

[drbitboy]

So, the HMIs should both be clients, and one will respond to a request from the other? And each device or HMI on the system has a client or server attached to it, right? And it looks like it has to be two EB projects!

All communications are between a [client,server] pair. Not all TCP/IP protocols use the client-server terminology, but I know of none that do not use the client-server model.

Bottom line: clients cannot communicate with each other. [@AlfredoQuintero beat me to it!]

 

[EngNate]

OK, thanks for that. It seems counter-efficient. Wouldn't it be good if a server could broadcast a notification and then the polling would only happen when something changes...

 

[AlfredoQuintero]

OK, thanks for that. It seems counter-efficient. Wouldn't it be good if a server could broadcast a notification and then the polling would only happen when something changes...

Well, the meaning of "server" functionality is that it responds to client requests. There are other protocols that support other kinds of messaging perhaps closer to what you describe, but his is not the case of Modbus TCP specification. This specification is an open standard and can be downloaded by anyone and easily found by Google search. Perhaps it may be helpful to have a look at this document so you can know what is, and what is not, possible with Modbus TCP.

 

[drbitboy]

The hall light was just to illustrate. I have 2 HMIs, each with 15 switches (same on each) that control respective outputs on two Zelios, all connected thru a hub. So, the com between the two HMIs is to synch the switch states in both locations, option a keeps it simpler.

Let's say Zelio A and Zelio B have the same value, say 10 (base 10) = 0x000A (hex) coming in to J1/XT1 and two lights are on, i.e. output coils Q1 and Q3.

Then the operator pushes a button on HMI A to turn on output coil Q5, which sends the integer value 42 = 0x002A to Modbus register 17 on Zelio A, which now puts a value of 1 on three output coils: Q1; Q3; Q5.

What do you want to happen on HMI B and Zelio B? E.g. do you want the same bit to come on i.e. the value 42 = 0x002A on Zelio B pin J1/XT1?

And after that, if the operator at HMI B turns off Q3, so the value 34 = 0x0022 is sent to Zelio B pin J1/XT1, then do you want HMB A to pick up that change and send the value 34 to Zelio A pin J1/XT1?

 

[EngNate]

Let's start at power up, all switches and outputs off. Notes: Zelio1 uses input XT1 and Z2 uses XT2; On the word-bit converters the LSB is not used, I don't know why. So these inputs are initialized 0 and all bits are off. HMI1-S1 is touched ON, it controls the output of Z1-B02(Q1). HMI1 sends the integer 2 to the Z1 input and makes that happen. There is no action regarding Z2, we just have to have the HMI2-S1 changed to the ON state. Then HMI2-S1 is touched OFF and sends 0 to Z1 and the HMI1-S1 now is to change to OFF.

All of the switches except one are dedicated to one output on one or the other Zelio. The exception is one that controls one output on each but isn't of consequence.

So, I see there may be two options handling the output state data - bit by bit or one word. But I'm not at that junction yet.

The original setup is Schneider HMIs (HMISTO735) programmed with SE Operator Terminal Expert. Possible something done different between these two?

 

[drbitboy]

So let's say HMI1-S1 is pressed, and then HMI1-S2 is pressed, so the integer value 6 (= 2 + 4 ≡ Q1/B002 and Q2/B003) has been sent to Z1 XT1.

Now HMI2-S3 is pressed, which is intended to turn on Q3/B004.

Is the fundamental question from the original post "How does HMI2 know that Q1/B002 and Q2/B003 are already 1 (i.e. on), so that HMI2 needs to send the integer value 14 (= 2 + 4 + 8 ≡ Q1/B002 and Q2/B003 and Q3/B004) and not just the integer value 8 (≡ Q3/B004 only)?"

 

[drbitboy]

I have another question: do the HMIs have, or need to have, an indication of the current state of the Zelio outputs?

 

[EngNate]

So, HMI1-S1 is touched, updates its address and triggers a macro which gets the state of all the switch bits and sets a word address accordingly and that gets sent to the appropriate relay. This task I assume will be completed before the HMI will process a subsequent touch. It's as you said, but a 2 has been sent by the S1 touch, then a 6 on the S2 touch. The two HMIs function identically and independently.

We don't care if there's an indication of the actual output state, we can go by the commanded state and assume the output is such. That said, I think it's going to be simpler overall to use the output bits. So, the fundamental question of post 1 is how do we notify HMI-2 when a state change occurs on HMI-1 and vice versa.

I gather both the HMIs will have to query both relays periodically to stay in synch with each other. So, next topic, how does that happen from within a macro?

 

[AlfredoQuintero]

EngNate, I should have asked this question before. What is the HMI that you are using? Many Modbus TCP/IP capable devices support both client and server function. Let me know the model and maker and I can check the specification. I have been thinking based on the assumption that the HMIs cannot communicate with each other.

 

[EngNate]

Alfred, they haven't been bought yet, any 4.3" that works is OK. The Weintek MT8051IE is a selected candidate.

 

[AlfredoQuintero]

OK, it seems the software for this device supports both, Modbus TCP client and Modbus TCP server. You should double-check with the vendor.
if I am right, then for your setup, one of your HMIs should be the Modbus TCP client of othe other. The "other" will work simultaneously as the client of the Zelio device and as the server of the other Weintek MT8051IE. On the server side you would define registers to get commands or status of the other HMI and other group of registers to indicate the other HMI its own status.

 

[AlfredoQuintero]

I found this manual...

https://dl.weintek.com/public/PLC_Connect_Guide/MODBUS_Server_COM_Ethernet.pdf

 

[drbitboy]

Wouldn't it be simpler to send just the bit of the output that needs to change (e.g. send an integer value of 8 for Q3/B004), then send an integer value of 0 a fraction of a second later.

Then use the rising edge (pulse) of any bit and an XOR to toggle the state of the output.


This way neither HMI needs to know what the other HMI does.

 

[AlfredoQuintero]

Then use the rising edge (pulse) of any bit and an XOR to toggle the state of the output.

drBITboy, I am a bit lost. With regards to the above explanation, is this logic running in the Zelio device itself?

 

[drbitboy]

[Edit: fix typos]

drBITboy, I am a bit lost. With regards to the above explanation, is this logic running in the Zelio device itself?

Yes. See images below. HMIx-Sy refers to any Button S1-S10 on either HMI1 or HMI2. This assumes the HMI selected can execute separate operations (macros?) on button depressed and button released events.

If the two HMIs try to keep track of what the other is doing, there is a potential concurrency issue:

• Operator A presses HMI1-S1,
  • which sends a 2 to J2/XT1 and turns on Q1,
  • but before the updated state can be sent to HMI2,
• Operator B presses HMI2-S3
  • which sends an 8 to J2/XT1,
    • because the update from HMI1 has not yet been received on HMI2,
  • which turns on Q3,
  • but which also turns off Q1
    

All of that is eliminated in the implementation below, although there is only one HMIx-S1 button for each output; there are not separate buttons for ON and OFF for each output.

​