Reliability issues in using Automation Direct Cmore with ContolLogix over Eth I/P

[puravdagli]

Hello everybody,

I am developing an application with CLogix that involves a lot of discrete I/O such as selector switches, pushbuttons, indicator lights, etc. For the user interface, I chose the new, highly publicised Cmore touchpanels from Automation Direct. These talk Eth I/P and so I figured that it would be the best way to communicate to the PLC. However, I have discovered some serious reliability issues here.

Firstly, I am using implicit messaging in the CLogix where the touchpanel is a generic ethernet module with its own I/O tags. Now, say I have a three position selector switch on the touchpanel and I change it to position 3 (say position 1 is the default 'off' condition). Then, say I lose power on the touchscreen due to some power supply failure. The touchpanel does not retain the previous state of the I/O when it is powered back up. Moreover, for discrete I/O it does not provide for any handshaking signals (such as a notify bit and a handshake bit for numeric entry objects). This means that now the touchpanel will write a 0 to the corresponding bit inside the PLC and this is disastrous since the entire controlled process will shut down.

I spoke to Rockwell support. I was told that the only way to overcome this would be to detect loss of communication (using GSV) during powerdown and ignore further data from the touchpanel and then write an explicit message to rewrite all previous states back to the touchpanel. This seemed to be a good technique but the only problem is that the touchpanel will not let the PLC write to its output tags.

As you can see, this is very serious. Can anyone else come up with a solution to this problem?

How about going over serial AB-DF1? The touchpanel has a serial port and does support DF1. I just dont have the correct cable right now and so cannot experiment that.

 

[OkiePC]

As a stop-gap measure, how about using momentary pushbuttons and putting the logic to hold states exclusively in the PLC?

Maybe the C-More manuf. can fix the non retentive problem as a more long term solution...however, it's still a HMI device communicating with a PLC.

As a general rule I just don't put human or machine safety at risk in these situation. Even though it's ethernet I/P, stuff happens, comms fail, buttons get stuck on...you know the rest.

Paul C.

 

[cjh]

My opinion would be that you should change over to DF1. You can use the Cmore SLC cable and then do SLC mapping in ControlLogix.

Interfacing to the HMI in the manner that you are attempting (Panel is Slave instead of typical Panel is Master) requires a whole different mindset and does not sound conducive to your application. Some people like, some people don't.

If you go to DF1, you will be back to the traditional method.

 

[RSL]

As a matter of practice I never use "maintained" push buttons on an HMI. I use momentary buttons. All "latched" conditions should be in the PLC.

You can/will have issues like this with any brand of HMI using maintained switches and push buttons.

I would not use DF1 over Ethernet IP. There is no need to.

RSL

 

[cjh]

I'm not talking about DF1 over ethernet. I'm talking about serial DF1. It is the only way Cmore can talk to the contrologix as a master.

 

[RSL]

I just meant I would not use a DF1 connection instead of Ethernet IP. Ethernet IP avoids the hassle of mapped SLC/PLC tags.

The IO style connection he is using is excellent and actually removes all the communications workload from the PLC and puts it on the Ethernet module. It will also out perform DF1 by a country mile.

This problem will probably be there using DF1 too. The issue is the initial state of the tags at power up in the HMI. You can avoid all of this by using momentary push buttons to trigger logic that sets bits in the plc code. It is quite easy to control the behavior of the data in the plc.

I do not think it is wise to rely on the HMI to hold a bit that directly controls the behavior of a piece of equipment. This gets even worse if more than one HMI is attached. It is just an opinion.

These issues may also be related to the brand/type of HMI. I have never used Cmore before. Maybe there is an issue. I would be really upset if I paid for Ethernet IP and had to use serial because the HMI was quirky.

RSL

 

[TimWilborne]

DF1 bad idea and two steps back, and solves nothing. Your on the right track with Ethernet/IP

On other thing that hasn't been mentioned is do you know how to tell when your touch screen is not communicating? Rockwell mentioned it but I didn't know if they got into the details with you

GSV
Class Name - MODULE
Instance Name - (Name of Touchscreen)
Attribute Name - FaultCode
Destination - (Tag Type DINT)

When this value is NEQ to 0 the Panelview is faulted. The specific code returned is the fault.

You mention speaking to Rockwell, have you spoke to Automation Direct about this.

I don't know how much cost saving there was but the STANDARD Panelview works extremely well with Ethernet/IP.

 

[cjh]

You are correct. Puravdagli could most likely solve his issues by not using maintained states in his Bit entries. Using momentary buttons and then triggering logic or Sets and Resets in his code should get him around these issues. In other words, don't look for 'off' states from Cmore, look for 'on' states.

But I still think that the DF1 serial connection is a viable option. I believe that the SLC mapping is pretty easy. Create some INT arrays and map them over to N data files in Cmore (don't use Binary data type, there is some weirdness with the word boundaries in Clogix with this, AB has an app. note on it). The throughput at 38400 baud is plenty fast enough for most applications.

I have done this several times and have been pleased with the performance and behavior.

I 'believe' that your guys' perspective is coming from using the HMI as a Client with Ethernet/IP and the PLC as a Server and pulling in the Clogix Tags into the HMI.
Cmore does not have this driver yet. When they do get this driver, this will most definitely be the optimum way to communicate to Clogix.

 

[TimWilborne]

Chances are the Cmore can use traditional SLC addressing over Ethernet/IP. Most can for compatibility with the SLCs, Micrologixs, etc. The thing is this does not solve the root problem of the Cmore not retaining it's previous values and brings up other issues with knowing if the touchscreen is connected or not which will cause bigger problems with this retentive data problems

 

[TimWilborne]

I 'believe' that your guys' perspective is coming from using the HMI as a Client with Ethernet/IP and the PLC as a Server and pulling in the Clogix Tags into the HMI.
Cmore does not have this driver yet. When they do get this driver, this will most definitely be the optimum way to communicate to Clogix.

Absolutely not. That is how accidents happen. The PLC should always be in control of managing its communications instead of other devices blindly writing to it such as the DF1. Wait until you get about 20 touchscreens communicating to one PLC and you see what I mean

That is the advantage of the Controllogix's I/O messaging.

 

[cjh]

Sigh...
You guys are just making guesses.

Chances are the Cmore can use traditional SLC addressing over Ethernet/IP.

It does not have this capability. I would have mentioned this, obviously, if it did.

brings up other issues with knowing if the touchscreen is connected or not

You do get an error if Cmore is not connected with Clogix with Ethernet/IP.

this does not solve the root problem of the Cmore not retaining it's previous values

Agreed. Life would be much easier if Cmore could retain the Input Data with this driver.

Hence the reason, I am suggesting using the DF1 serial driver to puravdagli.

 

[TimWilborne]

CJH - Whatever floats your boat. Your the genious here who know it all and set on your solution. The thread is yours

 

[puravdagli]

I love this debate guys. Its amazing to see strong contrasting opinions amongst pros and how they hold their ground and defend their views.

Now about using momentary inputs on the HMI:

I not only have pushbuttons but also selector switches on the touchpanel. The illuminated pushbutton objects in the panel designer have different tags for the button and the indicator light (which makes some sense) and so I can use momentary buttons and latch a bit tagged to the light. This will work perfect. I can use this same bit for all logic. The primary issue is with the selector switches.

If I go over DF1, I think the problem is worse. First, I cannot think of a reliable method of detecting when communication is lost. Second, even if I do dectect loss of communication and latch all the inputs, I have no means of writing them back to the panel when it powers up again. I will still experiment this out and see the differences on the touchpanel side when I use serial comms. With ethernet, it made me specify if a tag was input or output. With serial, it might not make me do that and might let me write back to the input tags too.

However, this is a great eye-opening debate that we have going on. Thank you guys for all your comments.

Appreciate it.

Purav

 

[ahackwor]

So get rid of your selector switches. Let's say you have an AUTO/MANUAL selector switch. Delete the selector switch, create a momentary PB to select AUTO, then crete a momentary PB to select MANUAL.

 

[RSL]

I use momentary push buttons to trigger a bit that passes through a one shot and moves a number into a word.

So I would push the auto button on my HMI then it would change a bit in the plc to a 1, my one shot will go high for one scan, my logic moves a 2 into the status word. Then in my HMI my indicator looks at the value in my word.

I use a word so I have more than 2 status conditions possible. 0=OFF,1=hand,2=Auto,3=Faulted,etc.....

I would get rid of the selectors if you have to.

I have never had an issue like this with a PanelView or a PanelView plus. So I am not full of options for you. You might be able to condition the Logic so that it will work. You will need to get that status bit from the Ethernet connection and use it. You might be able to work it out?????? Your HMI should only write it's initial value once after power up. If that's the case you can buffer the values and move them into your logic after your panel is powered up. You will need to play with this a little.

RSL