Multiple Red Lion Touch Screens, Crimson 3.0

[Elcan]

Hello all,
I'm working on a project using an AB CompactLogix PLC and 2 Red Lion HMIs (G3) running Crimson 3.0.
The PLC and the HMIs are connected to an Ethernet switch, this way establishing all the communications through Ethernet.
The HMIs run identical version of the same project, both reading from and writing to the (same) PLC.
I implemented Hand-OFF-Auto selector switches on the screen to run the motors. Each pair of selector switches (one on each HMI) corresponding to a particular motor is tied to the same tag on the PLC, so if one selector is changed on one of the HMIs, the identical selector will change on the other HMI(with a delay of 1 or 2 seconds, though).
Now it comes the problem. Let's start from the situation where the selector switch for a particular motor is at the "Hand" position (the selector switch on both identical screens on each HMI are at the "Hand" position ), so this motor is running. Then I change the selector switch on one of the HMIs to "OFF". What happens (randomly) is that the motor stops (as expected), but after a few seconds(1 or 2), it starts again, and then finally stops. I think that the reason for this unexpected re-start before the final stop is because the selector switch on the other HMI is still at the "Hand" position for a couple of seconds before changing to "OFF"(remember the delay).
Is there a good workaround for this issue?

Thank you!

 

[bkottaras]

Hello all,
I'm working on a project using an AB CompactLogix PLC and 2 Red Lion HMIs (G3) running Crimson 3.0.
The PLC and the HMIs are connected to an Ethernet switch, this way establishing all the communications through Ethernet.
The HMIs run identical version of the same project, both reading from and writing to the (same) PLC.
I implemented Hand-OFF-Auto selector switches on the screen to run the motors. Each pair of selector switches (one on each HMI) corresponding to a particular motor is tied to the same tag on the PLC, so if one selector is changed on one of the HMIs, the identical selector will change on the other HMI(with a delay of 1 or 2 seconds, though).
Now it comes the problem. Let's start from the situation where the selector switch for a particular motor is at the "Hand" position (the selector switch on both identical screens on each HMI are at the "Hand" position ), so this motor is running. Then I change the selector switch on one of the HMIs to "OFF". What happens (randomly) is that the motor stops (as expected), but after a few seconds(1 or 2), it starts again, and then finally stops. I think that the reason for this unexpected re-start before the final stop is because the selector switch on the other HMI is still at the "Hand" position for a couple of seconds before changing to "OFF"(remember the delay).
Is there a good workaround for this issue?

Thank you!

Elcan,

do all your controls (buttons.etc) in the plc.
Let the PLC dictate the status/state of the controls.
Use only momentary buttons on the HMI and code the functions in the PLC.
Use indicators to switch the state of the SSW on the hmi's.Since both of the HMI's are writting/reading to the same PLC it shouldn't be a problem.

 

[Elcan]

Use indicators to switch the state of the SSW on the hmi's.

Could you explain this to me (I'm a newbie with Crimson)?

 

[mjoubert]

2 HMS & 1 PLC. I would create a start tag with 2 different addresses in the PLC. Eg 50.00 for HMI_1 and 80.00 for HMI_2. In the PLC either one can enable an output and both HMI's can monitor the same output tag backround with no issues.

 

[rdrast]

Could you explain this to me (I'm a newbie with Crimson)?

This isn't any problem with Crimson, rather it is a typical problem with having multiple HMIs communicating to a single PLC.

When you have multiple HMIs talking to a single PLC, it's best to avoid completely the 'Advanced' controls on the HMI units, and simply use a momentary pushbutton (write), coupled with state indicators (read only, either controlled by the HMI, or by associating a visibility tag with the graphic/text).

HMI units, especially in the dedicated panel format, can be very bad at updating a state based on what another HMI changes. Internally, HMI-1 "KNOWS" that you toggled the state of SWITCH-1 from Off to On, and it reflects the change immediately. HMI-2 doesn't see any action on SWITCH-1, so it doesn't necessarily update it's indication. Perhaps later on a poll, it notices a discrepancy in the PLC between the switch state on HMI-2, and tries to correct it. That leads into ping-pong race conditions.

Doing the logic in the PLC implies that you have one or more momentary 'buttons'. In your HOA example, you can either have 3 momentary buttons that seal in the actual state in the PLC (seal in or latch), or one momentary button that will cycle through to a new state every press.

A little clearer?

 

[Elcan]

I think I got the idea.
Thank you very much!

 

[JeremyH]

Elcan

A better solution might be to have just one of the HMI's connect to the PLC. The second HMI could talk to the PLC but through a gateway block in the main HMI. This would eliminate any confusion in the commands sent to the PLC.

Jeremy

 

[Marc_U]

Elcan

A better solution might be to have just one of the HMI's connect to the PLC. The second HMI could talk to the PLC but through a gateway block in the main HMI. This would eliminate any confusion in the commands sent to the PLC.

Jeremy

Just a warning with this solution.

If the main HMI goes down for whatever reason, then the second HMI is unable to communicate with the PLC, as it's communication link really with the main HMI, not direct to the PLC.

Plus there are some communication delays (signal lag), as the signals are going via the main HMI, not direct to the PLC. This latter point may not be a problem, but it can cause problems, and even confusion, especially if the two HMIs are close enough to each other, that they can be seen at the same time.