How to convey operational characteristics.

[ajbachhuber]

I guess this is mostly directed at those of you who do contract type work but it could also involve those of you who are maintenance professionals.

When you undertake to build a new machine, how do you prefer to have the machine's basic operation conveyed to you?

For instance, you are asked to program a machine that does something... anything, and you have never seen a machine like it, maybe no machine exists like it on Earth. Do you ask for an I/O truth table? Do you ask for a textual, conversational description of the operation step by step? How do you go about deciphering fault conditions and the appropriate reaction?

I was just curious because my boss and I speak different languages when it comes to explaining the way things work. It makes development a real pain.

 

[Kidblue]

I don't think there is a text book answer for this one Aj. It really depends on the customer you're building for. You will find varying degrees of knowledge from the people you deal with. Some customers are very organised, well structured with their requirements and know the machine/product they require, and demand several levels of documentation submitting before even a thought to build can take place. Whereas the other end of the scale, you have the customer that really has no technical bias at all and expects you to fill the blanks in, and make the decisions on system philosophy, fault reaction, safe operation etc. Can be difficult if you are not fully familiar with their process as they are.

I think most people have the problem you've got with your boss...They all seem to speak a different language!!

 

[rsdoran]

I am a maintenance person but I have a job now building machines.

Yes, you will need a list of the I/O devices or at least a list stating what devices will be used even if you have to determine if the device is an input or output.

I would ask for a drawing (if they have one) and a text concept of what the machine will do. It gets kind of hard to know how to sequence the events if you dont have some idea what the machine does.

If you can get the I/O list and at least an idea of what they are doing then you can make a start.
List the Outputs

                                  pump motor1
|-                                   ----(  )---|

                                       valve 1
|-                                   ----(  )---|

Kind of fill in the blanks for the inputs needed to turn on the outputs as you go. Add any other equations as needed.

I got this from Allen Nelson and Terry Woods to describe BEFORE PROGRAMMING: http://www.patchn.com/b4programming.htm

Yeah guys I definitely listen to you.

Hope this helps

 

[The_Wanderer]

It depends...

As Kidblue said, it really depends on your customer.
As an OEM, there is very rarely anything existing that does what we want our machine to do. Most of the quotations we do are mainly guesswork, as you can't design the machine until you have a purchase order, and you can't get a purchase order until the customer knows what they are getting.
I don't think I have ever had a customer come to me with an I/O list. The best we get is a detailed spec, listing all the actions/ tests/ movements that need to happen and in what order. the worst (although sometimes quite nice) is a customer that says "just give me a machine that puts my parts together, I don't care what it looks like".
Either way, before we start designing, we get them in for a face to face talk and tell them exactly what we are going to do. No design is done until their signature is on paper next to our description of the final product.

Of course, they always change their minds halfway through the project...

 

[ajbachhuber]

That's what I thought...

Once we had an contract programmer come into the plant to build a machine. We gave him a text description of the machine and the basic operation we expected. He spent the next 5 or 6 days here in the plant making it work the way we wanted. I didn't want to believe this was typical but like Kidblue mentioned, unfortunately, we are not one of those well organized facilities. We are trying to gain an advantage by having a PLC programmer here in the plant in order to eliminate some of the return visits. That's my job by the way.

We're looking to commission our next machine and this one is a little more complicated than the ones I have done previously. (Lots of user settable timers and cascading menus.) In the past we probably would have contracted it out but I've been working hard to hone my skills so I can do it myself. The boss gave me a description of what the machine is supposed to do and now I completely understand where the other guys confusion came from. I work here and know what the machine is supposed to do and I am confused by the description. That's why I figured there must be an easier way.

rsdoran,
Yeah, those guys have it all figured out. I checked out the link you provided and Allen and Terry gave some good advice. I also wanted to include maintenance practitioners in the mix too because they deal with "internal customers." IOW, the various departments and fellow coworkers. It frequently helps to view them as customers too.

I figured it was mostly customer dependent. We have customers (huge corporations) who use extensive program development systems according to QS-9000 standards with team problem solving and different levels of approval and review and re-approval and re-review and on and on. I'm sure they could provide a decent description of what was expected of a completed machine but that's not what we do for them. The machines we build are for internal use only.

I guess the question was more of a query for opinions. If you could request a description of your choice, what would be the easiest way? Flow diagram maybe?

How much time do you usually anticipate spending with a customer tailoring the program to fit their needs? Is it a relatively fixed percentage of programming time?

Thanks.

-AJ-

 

[rsdoran]

As you can see the OEM builders aspect will be different from the end user aspect. The end user should have more of an idea what is needed...ie if you work in a plant and they want to make or modify something then you can go on the floor and get a feel or idea of what is needed.

Get a written concept from "whomever". Flow chart would be good. Then MAKE an I/O list from the information gained...ie develop a "plan" for the machine.

NOTE: Those guys that come in and spend 5 or 6 days may already have gotten or developed the concept of what to do...it sometimes still takes a week or longer to IMPLEMENT it. I usually spend at least a day or more (depending on size of system) just verifying connections, I/O wiring, etc...mainly a THOROUGH check to make sure everything is connected properly and that includes non-electrical items that are activated by the plc.

There are multiple threads here about HOW TO organize these things. THE key is DOCUMENTATION. Write down, draw, and make notes..keep them for later reference. With the PLC DOCUMENT everything and keep a printed copy. DOCUMENT and KEEP the written concept given to you..use it constantly as a reference, if there is an area that you arent sure about get "whomever" to clarify it.

Overall this gets kind of into the category of "Who's job is that to do?" Are you expected to be the Engineer and DESIGN the system? I know you have done some programming but is your background strong in mechanical and electrical...are you an Engineer? If so then you should be able to at least take their concept and develop (on paper) an idea..then let them look at that and get their intake. Since you are in a plant (end-user) goto the FLOOR and talk to supervisors, operators etc and see what they think. You can learn alot from them.

Good luck.