WattUp

Standardize PLC code for new machines

16 posts in this topic

This is more general topic, but I think the brand specific forums get a lot more traffic. And since we only have Mits PLC in our plant this fits best. 

 

When you are quoting a new machine, do you have some form of default PLC program that you can give to suppliers to use as a base point?  Or do you simply learn the program as its given to you for each machine?  

Also, how detailed of a standard parts list do you have? This is another part of the process I find our plant to be severely lacking.

1 person likes this

Share this post


Link to post
Share on other sites

, software like GT designer/GXWorks2 Hi WattUp,

 

We do work with a 'preferred component list' that is leading in the purchase proces of new machinery that is built for our company. It discribes brands of components for controlpanels, pneumatics, software like GT-Designer/GX-Works2 etc. and an approved alternative choiche as well however if an alternative is selected the supplier needs to get approval before using the alternative component. It included that the supplier needs to provide drawings, PLC/HMI software when a project is finished. At each purchase.

Sometimes if you buy machinery out of the standard catalogue you don't have much choiche. The supplier is most of the time not willing without extra costs to change the controlpanel.

We decide based on who will maintain the machine if this non-standard suits for us. If a machine is maintained by an external company and their engineers are used to use Siemens or Hitachi PLC we still approve the purchase.

I hope this gives you some directions to think about for writing your future terms of purchase.

 

Best Regards,

Theo V.

Edited by Theo V

Share this post


Link to post
Share on other sites

We use a set of standards that "lay out" the programming. Usually they will request a sample program. We provide some spread sheets that lay out the address map and flow of the program as well of how we want it structured. 

As a small example we would say you have to use M1000-M1999 for anything that goes to a remote device like cc-link or Melsecnet an so on... M3000-M5000 for alarms These are not the actual standards just an example. 

Keeping all of our programs uniform help to make troubleshooting and editing easy because you can look at an address and instantly know a lot about what it is from. 

Share this post


Link to post
Share on other sites
50 minutes ago, Mitsm83 said:

We use a set of standards that "lay out" the programming. Usually they will request a sample program. We provide some spread sheets that lay out the address map and flow of the program as well of how we want it structured. 

As a small example we would say you have to use M1000-M1999 for anything that goes to a remote device like cc-link or Melsecnet an so on... M3000-M5000 for alarms These are not the actual standards just an example. 

Keeping all of our programs uniform help to make troubleshooting and editing easy because you can look at an address and instantly know a lot about what it is from. 

This is exactly what I am looking for.  Do you have an dedicated example program that you send also? One that is mocked up for all your spreadsheets?

Share this post


Link to post
Share on other sites

I have a generic program for most of the machines I will order. I will specify that they use a certain type of hardware for the flame safety and a familiar processor as my people must be able to use the programs and understand the flame safety equipment for troubleshooting etc.

I will specify that certain aspects of the machines must work in a certain way that we have found through the years to work the best. This will sometimes lead to some lengthy discussions because they have their canned ways also. Stick to your guns because you are the buyer and they want what you have, (money).

If their are proprietary aspects of your programs that you wish to keep to yourself merely cut them out of the program you provide to them and reinstall when the machine is in house. This will entail accepting a base operating machine at delivery with the contractual addendum that your company will complete programming.

Good Luck.

 

Share this post


Link to post
Share on other sites
1 hour ago, Mortoch said:

I have a generic program for most of the machines I will order. I will specify that they use a certain type of hardware for the flame safety and a familiar processor as my people must be able to use the programs and understand the flame safety equipment for troubleshooting etc.

I will specify that certain aspects of the machines must work in a certain way that we have found through the years to work the best. This will sometimes lead to some lengthy discussions because they have their canned ways also. Stick to your guns because you are the buyer and they want what you have, (money).

If their are proprietary aspects of your programs that you wish to keep to yourself merely cut them out of the program you provide to them and reinstall when the machine is in house. This will entail accepting a base operating machine at delivery with the contractual addendum that your company will complete programming.

Good Luck.

 

Thank you so much for sharing your experience. This is exactly what I am hoping to achieve 

1 person likes this

Share this post


Link to post
Share on other sites

We usually try to send one of the regular programs that is from a machine close to what the builder is designing. So if its a machine that is attaching and torquing widgets we will send a copy of one of our current widget torquing machines, we just strip out all the network address and stuff like that. Confidentiality contracts handle all the proprietary stuff.   

I suppose if you had a lot of similar machines that you needed like a press shop or something, then you could make up an example program to send every time. 

 

   

Share this post


Link to post
Share on other sites
On 10/13/2017 at 6:52 AM, Mitsm83 said:

We usually try to send one of the regular programs that is from a machine close to what the builder is designing. So if its a machine that is attaching and torquing widgets we will send a copy of one of our current widget torquing machines, we just strip out all the network address and stuff like that. Confidentiality contracts handle all the proprietary stuff.   

I suppose if you had a lot of similar machines that you needed like a press shop or something, then you could make up an example program to send every time. 

 

   

That is what we have done in the past, but I was hoping to build a better process for going forward. 

Share this post


Link to post
Share on other sites

Understand that confidentiality agreements are only as good as the people on both sides of the agreement. The country where I spend the majority of my time working is notorious for stealing and reusing anything they get their hands on.

Just saying the only true way to insure proprietary security is to keep it in house.

Share this post


Link to post
Share on other sites

A bit late in the topic, but to jump straight into the  discussion:

I'm not sure I understand the "question", or the topic. I have a "double-role" in my work as I am both an employee at a plant (end-user) and at the same time I'm working as a freelance consultant for machine builders and superusers. I would say I have pretty good knowledge of "both sides of the table". I can understand an end-user specifying any given manufacturer of hardware, but if I understand the topic correct you would also specify how the code should be developed? If that's the case, please explain what kind of equipment you are talking about. Are we talking about "off-the-shelf" machines or customized machines? Do you hire consultants to be present on-site for debugging/development of existing plants/machines? Are you getting support for any equipment after the initial purchase? Please elaborate.

I'm sorry, it might just be my English (probably my fault since I can there are some other U.S. members that fully understands you), but I would need some more information to be able to give my opinion. If you have the time, please explain more as I find this very interesting!

Share this post


Link to post
Share on other sites
15 hours ago, kaare_t said:

Please elaborate.

You were understanding correctly, I am looking into creating a basic PLC example to give to suppliers for them to base off of.  Our machines are all 100% custom applications, developed by integrator both in the US and Japan.  The integrator is available during the initial machine start-up, but then myself, and my Maint team are responsible from there. 

Initially this came up because we had a new supplier that felt like they were trying to show off by making code overly complicated, either that or they had a very limited knowledge of the Mits functions.  So we thought we would create examples that could be used to build on; basic stepper logic, faults, and even some standard HMI design

 

 

Share this post


Link to post
Share on other sites

Be aware that I personally find this topic a bit "complex" in terms of language so if anything is unclear, or just far off in my post feel free to let me know and I'll try to explain in a different way.

I can understand your issue. Regarding the HMI I think that layout designs should be easy to specify when dealing with a machine builder. However, examples of code might be a bit more difficult. The biggest challenge is of course that the developer(s) dealing with the code have their own way of doing their job. I've debugged a lot of applications coded by other developers and all have their own way of thinking. This, of course, makes everything harder to understand and debug. My point here is that the code itself might be hard to specify.

Basic circuits can be specified of course (code itself). Logical units of code (like physical I/O, fault handling, HMI code, communication code, machine units and so on) should be separated to files/POU's which in should be structured as specified (by you). Again, the HMI layout should be easy to specify.

You should be specific in regards to the logical "unit layout" of the code. Make sure the producer separates code into units and subunits. I highly, highly recommend to make use of labels (even if you don't use names in your main program) just to be able to use functions and function blocks. That way the code can be further segmented into pieces for easier debugging (and more importantly reuse of equal code). Structure in the code together with good documentation will make debugging and/or modification a lot easier, and honestly I think that is what you can expect to get from a supplier.

3 people like this

Share this post


Link to post
Share on other sites
13 hours ago, kaare_t said:

Be aware that I personally find this topic a bit "complex" in terms of language so if anything is unclear, or just far off in my post feel free to let me know and I'll try to explain in a different way.

I can understand your issue. Regarding the HMI I think that layout designs should be easy to specify when dealing with a machine builder. However, examples of code might be a bit more difficult. The biggest challenge is of course that the developer(s) dealing with the code have their own way of doing their job. I've debugged a lot of applications coded by other developers and all have their own way of thinking. This, of course, makes everything harder to understand and debug. My point here is that the code itself might be hard to specify.

Basic circuits can be specified of course (code itself). Logical units of code (like physical I/O, fault handling, HMI code, communication code, machine units and so on) should be separated to files/POU's which in should be structured as specified (by you). Again, the HMI layout should be easy to specify.

You should be specific in regards to the logical "unit layout" of the code. Make sure the producer separates code into units and subunits. I highly, highly recommend to make use of labels (even if you don't use names in your main program) just to be able to use functions and function blocks. That way the code can be further segmented into pieces for easier debugging (and more importantly reuse of equal code). Structure in the code together with good documentation will make debugging and/or modification a lot easier, and honestly I think that is what you can expect to get from a supplier.

I wholeheartedly agree with the labeling. Make them label, and I even specify that the labeling conforms to our standard. It is a big pain to have wade through a program of ambiguous labels trying to find what each does and then relabeling, especially while troubleshooting.

Share this post


Link to post
Share on other sites

I think i am going to create a similar solution to @Mitsm83, a spreadsheet with addressing scheme and a small sample program of how we like stepper logic and faults. Perhaps an HMI design template also. 

2 people like this

Share this post


Link to post
Share on other sites

Feel free to upload a sample of the sample(s) and we'll sure give some pointers if needed. It's often easier to provide help on something that is already started. Good luck :-)

1 person likes this

Share this post


Link to post
Share on other sites

If you have been at it long enough you find that you naturally develop a spreadsheet like the one you are talking about.  From a contracting point of view there is no point in re-inventing the wheel.  A customer would not appreciate you taking the time to do that. 

Having said that, the documentation that you get from the equipment supplier should outline all of the groupings for you.  Admittedly the documentation is rarely to hand when you need it so in that respect a common format would be beneficial in the long term even if it cost more for the first job in the short term.

 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now