Plc suggestion

Sounds like your specs are right from Siemens S7 400 H
To me

Go to the Siemens web site

I agree that this specification probably indicates that the user has a make and model of controller in mind and is using the Specification as a tool to get what they want while avoiding a rule that says they must use competitive bidding.

I also agree that you should ask if they have systems already running of a particular brand and model, or if they have something already in mind.

In my experience, if a customer is candid with their needs, it means you are a legitimate contender for the contract. If they refuse to be helpful and tell you "bid to the spec !" it means they are using you as a negotiation tool with someone else. The worst use of a specification like this is when they intentionally build the specification so that it can either be met by overbuilding the system or by ignoring a critical item, the agree with their preferred vendor not to enforce that critical item.

Ken Roach said:

.... If they refuse to be helpful and tell you "bid to the spec !" it means they are using you as a negotiation tool with someone else.

..... The worst use of a specification like this is when they intentionally build the specification so that it can either be met by overbuilding the system or by ignoring a critical item, the agree with their preferred vendor not to enforce that critical item.

Click to expand...

Your experience isn't too different from mine, Ken. Regarding the first item, another scenario that I've run into is that the specifier doesn't understand what he wrote, and simply copied specs from someplace else. Rather than admit ignorance, the say "Bid to the spec."

The second scenario is against the law for publicly bid projects (collusion). That doesn't mean I haven't seen it done, or suspected it was being done, though!

Anyone that's been in this business for any length of time
Has seen specs written around a certain brand.
This one isn't different

You have a suggestion to follow up. Omron have dual processor/dual power supply PLCs as well. May be worth getting them to quote too. The model is CS1D. Better to have a choice of 2 if you can.

The mystery is "which one !"

Some of the vagueness makes me think that this is a mix of specifications, though I'm happy to be incorrect.

My favorite platform, ControlLogix, is pretty much out of the picture because of the very small I/O count.

Section iii is particularly interesting to me:

iii. Failed modules within the PLC system shall automatically detected, identified and alarmed via output contact(s), diagnostic status words & LEDs without interruption of normal processing functions.

All PLC systems I am familiar with have diagnostic status words and LEDs, but "via output contacts" sounds like it means at least one output contact per module, and an argument could be made that these must be onboard contacts because a module full of failure annunciators wouldn't work if that module itself failed. I might be reading too much into that, but at the very least you're going to need to provide a separate relay output module to act as a "fault annunciator" to meet his section.

The fact that the specification refers to multiple communication ports (Two Ethernet, one RS-232, one RS-485) and communication features (report-by-exception, report-on-demand) but does not specify an application protocol (Modbus, DNP, etc) is suspicious. It wouldn't matter if the SCADA and PLC were being provided by the same vendor, but if I'm being asked to provide the PLC only, the communication protocol details are vital.

There are many parts of the spec that don't make sense. For example:

2. CPU:

CPU shall be redundant.

When PLC failure occurs, the discrete outputs shall freeze to its current state or turn off.

Click to expand...

What's the point of having a redundant CPU if you want the outputs to hold their last state when a failure happens?

3. I/O DETAILS:

Click to expand...

Digital ip – 31
Digital op – 7

Click to expand...

A redundant CPU for seven outputs, some of which are

outputs that drive solid state inputs, i.e annunciator points

Click to expand...

???

i ask the same thing about the descrete output state Steve,
But it says shall stay on or off - which one
If it said shall keep its last state - no issue.

come on shawn_75 - I is catching you

^HA!!

I realized yesterday that I feel like I'm posting too much...too much free time on my hands I guess. Just finished up a pretty big project (for me anyway). Things will be picking up after the first of the year so you'll be senior soon enough young man.

Shawn

:beerchug:I needed that
Been having a lot of Nanny Naps recently

Have a great New Year you old bgger

ONLY ONE POSSIBLE WAGO

haha
only why you need a redundant processor?
make a redundant PLC cost is three times of one.
and yes i can program them.

shooter said:

only why you need a redundant processor?
make a redundant PLC cost is three times of one.
and yes i can program them.

Click to expand...

"Redundant Processor" is one of those terms that gives people a warm, fuzzy feeling. It sounds nice and safe and reliable, right? Until they think the system through, that is.

In my experience the causes of failure in control systens, in order of frequency, are:

1) Programming error. Redundancy does nothing to improve this, and actually makes it worse by adding complexity.
2) Wiring issue. No help here from redundant processors.
3) Field deivice fault - transmitter or actuator fault, often as a result of installation error. No improvement in reliability here, either, from redundant processors.
4) I/O module fault. To help here you would need a whole redundant PLC, which can be done. But then you need to make sure the module knows its failed so you can switch over. And pay for it, of course!
5) CPU fault. Not common, and when it occurs is usually the result of power surges etc. So, how do you know that both CPUs won't be fried?

When aerospace went to fly by wire I believe they used redundant controllers. I also think they went with three units, not two, so there could be a "voting" process to decide which one was brain dead. Lots of $$$$$$.

Tom Jenkins said:

This kind of spec drives me insane! We see it all the time on municipal projects in the US. Sometimes it is cutting and pasting one manufacturer's suggested specs, and sometimes it is an engineer taking the features he likes from many different PLC brands and creating a spec for something no one makes.

In addition to contacting suppliers as indicated above, I suggest you contact the potential customer and ask him if he has a brand preference and if he had a specific PLC in mind when he created this spec. You may have to submit a request for information in writing, and the engineer may not give you an answer, but it costs nothing to try. More times than not when I did this the engineer was glad someone cared enough to ask his opiniion.

Click to expand...

Tom's right. The person who cut-and-pasted this might actually know what he wants. I think the ultimate better question would be: "What do you really want? How much of this can I take exception to, when you beat me over the head to give you a lower price?"

"viii. The PLC shall be capable of being rebooted via a remote SCADA sign"
Something about that makes me think that the URS is deeply flawed.
It sounds like a really bad idea to me.
Are there any installations around that comply with this?