Need Language for spec

TheWaterboy

Lifetime Supporting Member + Moderator
Join Date
May 2006
Location
-27.9679796,153.419016
Posts
1,905
I need some boilerplate language that I can have placed in the spec that will instruct a contractor that during final signoff of their cabinet project they need to provide just enough programming in the PLC to prove it all works from bit to action. Then I know when the cabinet is released to me I can install my program and it just works.

Historically we do our own programming for the resulting assembly and in that last 15 years I never had this issue because, I assume, it was generally understood it was needed to certify it works.

In in this most recent project the contract said, as it always has, "program by others" and they took that seriously. This meant to perform the functional test they hotwired all the IO never once running it through the PLC logic to test the PLC IO flow for bad modules etc. They also didn't provide SFP's for the network switch fiberoptic connections, and weren't even sure what they were, but that's for another time.

Maybe I have just been lucky but I've never had to spell this level of detail out before but it appears I have to going forward. Would anyone share the few sentences that have used to specify this with no ambiguity available to the contractor that I can incorporate into the specs for the next project.
 
Id say you've been pretty lucky in the past. Here, most panel builders won't even power on anything unless the client is present for a Factory Acceptance Test (FAT). Especially if there's free issued hardware, it's really not theirs to blow up!

Many also don't have anyone in house with automation software etc to do that kind of testing, other than 1 or 2 larger outfits that also have an automation arm of the business (i imagine it's different there)

I generally do this testing myself. I turn up with a test program, which is generally just all outputs driven from the HMI and all inputs displayed, then i go through with a multimeter / jumper wire and test everything point to point. If it's a big board then I'll randomly test maybe 50 / 30 / 10% depending on size.

That forms part of my FAT which the panelbuilder sits through, and we check all other operation as well, i.e. motor starters etc. If any issues, they power down and fix while i wait... unless it's a huge **** up. Haven't had any of those yet apart from one where the new guy didn't know a NC vs. NO contact symbol and wired every relay contact wrong. Ouch.

So unfortunately i can't help with any text on how to best specify this. Would doing so limit your available tenderers?
 
I don't have any language for you, but I can't say I agree with the stance. The ambiguity is the assumption that they put programming effort into it when it explicitly stated "programming by others". All the nuances of getting the hardware to work with the software should fall on the programmer IMO. Pretty cut and dry.

Are you willing to pay the added cost? How far should the wording go?
  1. Supplier needs a PLC to verify, even a basic program still needs someone to write it and do the work.
  2. Are you going to spec all the minimum firmware version requirements the cabinet requires? Require them to update?
  3. Do they need to supply any and all AOPs/EDS files for the hardware they provide?
  4. Are you going to spec the PLC and version that needs to be used for testing? "We used a L35E and it worked, so if it doesn't work on your L85E I am not sure what to tell you."
  5. Supplier now has to track and manage the test PLC/HMI program just for CYA.
  6. What if you add a local HMI? Do they have to create a test HMI program as well?

Probably simpler to have a requirement for you to perform an FAT at the panel shop before shipping to site.
 
Yes we spec the PLC, currently they are 5380's
These are not complicated boxes so all they need to prove to me is that:
  • a DO bit from a PLC program will set the interposing output relay
  • an input from the endpoint will set a DI register true
  • AI is read into module registers from whatever device it is attached to using simulation
  • and an AO will output correct 4-20mA into the endpoint.

For that they can use whatever FW version they have, but specifying it was a current one is not out of line.

They do all this manually and that is probably more difficult

Local HMI has not been an issue but if one existed and having this testing done using and displaying it, even in a simple fashion would not be out of line... maybe excessive but display something live.

Yes we pay for it.

By "programming by others" it is intended that a finished program to run the system to our needs is not expected, but enough of a program to functionally test the hardware is.

You think this is an unusual demand?
 
I don't think it is too much to ask a controls supplier to verify that their wiring is correct. I have had to make MANY corrections to enclosures because a dc common was missed on an I/O card or drive or a jumper was missed for an analog output. You don't have to fully program a PLC to test I/O. I do it all the time. You do have to create the program, install the cards in the I/O tree and may have to do some basic configuration (like setting analog outputs from default to mA output). You could provide that file to them if they don't have people with the skills to program but know how to use the basic software. As far as boiler plate phrasing, I do not have any but am following this so maybe I could use it in the future. ;-)
 
The 2 I remember (on the same panel) were for a new installation at a shop I was working for. The tech installing it couldn't get it to turn on and gave up, telling me to call him when I figured it out.

Turns out one wire going between the incoming terminal strip and PLC input wasn't stripped and the terminal just compressed the vinyl.

Then everything worked in Manual but in Auto only ran 2 or 3 strokes of the 1200 ton stamping press (basically a reliably timed earthquake that makes parts) connected to it and shut down. That turned out to be another wire on the same terminal strip that was stripped, but the terminal screw never tightened so when the thing started shaking the connection faltered.

The panel was made by a big-name controls company in the Detroit area, not some little shop in some guy's garage.
 
The 2 I remember...

The panel was made by a big-name controls company in the Detroit area, not some little shop in some guy's garage.


Wow. The mistakes themselves are not too surprising, but 1) having it leave the builder's shop like that, and 2) the installation tech not being able to figure it out, are what really surprise me.
 
Programming by others seems pretty clear, the functional system will be made by someone else. Providing and installing working hardware that is free from faults or hardware errors could arguably be as simple as "the rack powered on and there are no faults on the cards" all the way to "every input works and every output works by programmed method".
 
How's this?

This give anyone heartburn ?

The PLC will have a version of firmware installed that is compatible with [COMPANY] current capability. Additionally a minimal PLC program will be provided which would make possible the testing of all associated PLC I/O from logic to endpoint once all on site wiring has completed. This includes any devices connected by Ethernet or serial protocol or any HMI displays. This program only has to demonstrate that PLC can issue commands, energize outputs, read inputs or other endpoint data and, if applicable, that the the HMI can display live PLC data. This program will not be restricted or protected and will become the property of [COMPANY] . There will be no obligation for the contractor to retain, maintain or warranty this program beyond final acceptance of the project.
 
The panel was made by a big-name controls company in the Detroit area, not some little shop in some guy's garage.

Perhaps this is the issue.
I consider myself that "guy's garage" guy and never have the issues that I see when I do get machinery from "The big guys". They all cry too busy to fully test and ensure accuracy and more often than not, the wiring looks at about a grade 3 level and the drawings are incomplete and messy. I rarely find a mistake after installation on my cabinets. Its so much easier to ensure its right when sitting in front of the panel during the build rather than wait ill its on a floor somewhere to realize the incorrect outputs are firing. Plus, I'm the only person with hands on the cabinet so its a lot easier to know who did what!
 
This give anyone heartburn ?

Maybe I'm overthinking this, but aren't you effectively looking for a fully configured PLC rack? You can force outputs and read inputs, so the wording of programming will imply an additional cost and time spent to possibly make it "neat" where a correct configuration will do. Similarly for an HMI, the program could literally be a display of the IO variables (which is perhaps programming rather than configuring).

The wording seems ok, perhaps very detailed to explain that you want to prove the wiring field connections by verifying the IO signals from an online PLC.
 

Similar Topics

I Need Allen-Bradley GML(Graphical Motion Control Language) software to program an allen-bradley IMC-S/23x motion controller. the motion...
Replies
1
Views
4,115
We are trying to poll data coming from a PLC for remote monitoring we have the IP address of the PLC and the default port number and the path is...
Replies
25
Views
406
The idea here is to provide for a brief rapid influx of message codes while preventing sequentially repeating the same message. i.e. if two...
Replies
22
Views
426
Hi all Trying to remotely connect to a TIA Portal PLC. I can ping it without a problem but can't get my software to connect. I've opened port...
Replies
8
Views
278
Hi all. That will be a stupid question for a lot of you guys. I'm talking with ProSoft support and he sent me an example late yesterday: XIC...
Replies
9
Views
331
Back
Top Bottom