Dear List,

We are just about to replace an old control system and we would like to use GE Genius I/O cards for driving solenoid valves. We want to use as much valves as possible per each card. Who out there uses this configuration? We will have to replace the old solenoids by new ones so we can choose the voltage. We want to use all diagnostics available for the Genius cards (open wire/coil, short circuit, overload, etc). For
those of you who are Genius I/O users what would be your suggestion?

Thanks in advance,

Ricardo Ribeiro - Alcan
[email protected]

 

Ricardo,

Do you want to retain the Genius bus but not the PLC processors? Also, do you need an HMI as well? We did some work for the Alcan Kitimat plant and for a retrofit proposed a system that would retain all existing I/O, run the entire machine in a server and reduce system complexity by 66%.

Paul Jager
CEO
www.mnrcan.com

 

I work at a 2477 Megawatt coal fired power plant. We have over 2700 GE Genius I/O blocks in service at this time. I can say that they are built like a tank and have been very dependable over the years. For driving our 120 VAC and 125 VDC devices such as motor starters, solenoids, etc, we use the Genius 8 circuit isolated I/O block almost exclusively. It uses electronic switching (triacs) and has built in resettable overload protection for each channel.

Genius I/O is a little more expensive than other blocks out there. But no other brand of blocks that I have seen have the diagnostic and protection features that a Genius block gives. For example, most other manufacturers' output blocks use relay contact outputs instead of electronic switching. That type of block gives no current protection and very little diagnostic capability, but this allows them to be produced cheaper. Even GE has a cheaper line of I/O but it is a "watered down" version of the Genius block.

The bottom line is, if you want to cut cost, don't do it at the I/O level. You will generally get what you pay for.

And NO, though I might sound like it, I am not a GE salesman. I am speaking from my own personal experiences with the product.

Steve Lowery
Senior Analyst
[email protected]

 

Ricardo,

About 2 yrs ago I implemented a Mill Stand Spray Control System on a continuos 5 stand mill. In that system we were able to drive 16 solenoid valves from one Genius Module. We did not have the luxury of choosing the solenoids so I don't know if there is a 32 bit output / solenoid combination that would work for you. The amount of current required to drive the solenoid I think would be the limiting factor?

I am curious about the second part of your question because I used to work for one of the inventors of Genius I/O, at General Electric in Salem VA. He talked about the diagnostic abilities of Genius all the time but I observed
that they were seldom used to their fullest extent. I believe this is because in a PLC environment the I/O and associated ladder logic required to deal with the diagnostics would consume 20 times or more resources (memory, I/O, code, development, etc..) than the control
application. The necessity of explicitly writing diagnostic code for each I/O point in the system is enough of a burden to discourage most people.

On a more recent project at Kaiser Aluminum we developed Genius drivers for a VME/VXWORKS platform. In that system the diagnostics were included in the drivers and were accessed by the Alarm and Diagnostic System. An automated
pre-processor scanned the I/O definition and other
configuration files to generate thre Alarm and Diagnostic system. This resulted in a collection of operator screens showing the status of each Genius Block, the state of each I/O point, and the status of each I/O point. In addition it
was planned to be able to extend this concept to actuator and transducer type where multiple I/O points were involved.

I am curious about your approach to defining system wide diagnostics? Would you be kind enough to share your ideas with us?


regards

Rick Jafrate
CEO Mitek

P.S. Please feel free to contact me off list if you wish. I will be happy to share any information I may have that would be of use to you.

[email protected]

 

Dear Mr. Jafrate

Firstly thank you very much for your attention in replying my question.

Well, when I look at the comments on this list I can see the wide variety of complexity, needs, features of the companies/people involved. I'm
sure each of them has its own way of working and see the world with his business eyes. The main reason for justifying the change I'm proposing is
improve diagnostics facilities. I'm mostly a maintenace guy. I see millions of dollars being invested in automated system and simple
functions like saying to the operator or electrician that a fuse is blown is not provided. On the other hand I see everyday precious minutes, even hours, being lost because someone could not find a circuit breaker tripped or a solenoid valve with a blown coil. Here is were I want to get the most from Genius. With all those years of experience in our equipment, we are
able to say which parts are more suceptible to have that kind of problems. In our case, a rolling mill, solenoids located on stand valves and limit switches inside the mill are our trouble. We don't want spend lots of money in diagnostics in places we know there is no problem.

If these needs require more programming effort, let's do it. That's why all that stuff exist.

Hope this make you better understand what we intend to do and why.

Regards,

Ricardo Ribeiro

 

Ricardo,

I have been designing controls systems for almost 20 years now and I couldn't agree more with you about the value of good diagnostics. Actually diagnostics have been one of my crusades over the years. I have personnaly seen electricians and engineers spend hours locating a failed device that the control system already knew was failed or
could have easily made the determination.

However, I stand behind the notion that a traditional PLC (i.e. Relay Ladder Diagram) environment is not an efficient or effective way of handling Genius I/O diagnostics. I am
still curious about what platform you are are going to use?
Are you upgrading to a new platform or are you going to use the one you have? Are you using GE DMCs?

Ongoing maintenance of the diagniostic software will be one of the biggest difficulties you will face (not that there aren't others). May I make the following suggestions:

1. Involve the maintenance guys (and the mill operators) in
the design of the maintenance system.

2. Select a good HMI package and make sure the maintenance
guys know how to create diagnostic screens and make sure
that they are encouraged to do so.

3. Develop a diagnostic screen schema so that all of the
diagnostic screens have a similar look/feel etc. For
example, the mill could be divided into sub-systems
having a number of standard views. These included an
operator panel, programmable stripchart, documentation,
help, tune-up, state logic, online diagrams, alarms,
diagnostics, hardware,... A navigation scheme was
created that allowed navigation from sub-system to
sub-system. Screen elements had a magic spot in their
upper right hand corner that, when clicked, would bring
up a help window describing the function and operation
of that element.

4. Make sure the maintenance guys are comfortable
maintaining and adding diagnostic code to the software.
Again they should be involved from the start.

Please keep me/us updated on your progress. I am very interested in what your are trying to achieve and hope you succeed.

Best of luck

Rick Jafrate
Mitek

 

Dear Mr. Jafrate,

Thank you very much for those indications.

Regards,

Ricardo Ribeiro