Rant

I hate one size fits all programming. Working on a webhandling line. FlexLogix , 5 axis of PowerFlex 700 , point I/O, Standard Panelview, all on devicenet.

The guys that buil this system used the one size program fits everything. So there is parameters passing into subroutines then passing 3 more times.

I understand speed programming. So after my short rant. Why not write the code with the customer in mind? I started life as an end user not an OEM so I am biased ti start. Just wondering how other guys do it.

Rant over for now. Probably will be continued tomorrow.

I feel your pain Jeff. I have to deal with machines that the PLC Program is written by the OEM for every possible variation of their machine. Then they enable whichever portions are required for the actual installation. When you are looking for something, you have to wade through all the PLC Code that does absolutely nothing. Arghh!

I used to work for an OEM that had canned Programs for their machines, but they were divided into Subroutines. The Engineer would only insert the Subroutines that applied, and then set the Actual I/O Addresses for the installation.

In my view a much better and cleaner way to go.

Stu....

Yes definitely a better way to go. I am getting mad because of the size mis match of 32 bit and 16 bit. Flexlogix and DeviceNet. So I can't just look and see the value in the program becausethe copy blocks of data at a time that has the fault I want to look at.
I have not mapped out everything yet. So it is fun.

The corporate engineers at my previous employer did a lot of this craap too. They spent more time trying to make sure that the programs were all identical than it would have taken to trim them down for each machine.

Then, in each plant, we all kept a separate copy for each machine anyway so that specific adjustments could be saved. This completely defeated their original intent.

I, too, have waded through logic not realizing I was looking at a "dead" subroutine...I scrolled and scrolled and poked and peeked and finally saw a comment talking about an ABB robot unloader...wait a minute, we don't have ABB anything in the whole plant, let alone a robotic unloader!

JeffKiper said:

I hate one size fits all programming. ...
I understand speed programming. So after my short rant. Why not write the code with the customer in mind? I started life as an end user not an OEM so I am biased ti start. Just wondering how other guys do it.

Rant over for now. Probably will be continued tomorrow.

Click to expand...

I started life as an end user too, and often wondered the same thing, why convoluted code, why no "K.I.S.S" methods? Then I jumped the fence and and began to work for an integrator....it's all about reducing costs to stay competitive. Controls budgets seem to get stripped constantly as it's all seen by management and sales as "copy & paste" as management and sales everywhere thinks controls is a "magic wand", you think it it can happen...*poof*.

If you program for the end user, you'll lose every time. Customers that actually have programing specs and guidelines, kudos, shows they are vested in automation and making sure their people have a common platform. Those that don't have specs and guidelines, aren't vested, don't have a clue and will ask for more and more during commissioning and in the end the OEM and integrators need to be efficient and stay in business. Instead of catering to end users who really don't have backing by their management to put provisions in place to make that common platform.

I was following an unwind torque regulation signal. It took me 45 minutes at least to follow the signal to find out where it was mapped to. Then I find out the drive was running speed regulation mode.
The owner / engineer is hinting around at redoing the entire system. I like the idea it would keep me busy for about a month or so. Slow time of year coming up so I could use a winter job.

Paully's5.0 thanks I like to hear and see how others do it. The reasoning behind it makes it easier to understand.

I have done a similar approach for a machine that had minor variations on it.

I would say that it made life easy that i did the software once and could implement it over a couple of their modules. The benefit i see in this is that i only had to do testing for each machine once. Also they only had to keep one version of the software.

It did get messy towards the end with additions here and there. It also did save them money as they pushed out about 200 units and paid for programming and commissioning for a software engineer for about 10.

So there are benefits.

It's a tough position to be in at times. At the end of the day, if you supply equipment, commission it, and it's accepted by the end user as meeting the scope then there should be minimal action taken by the plant in the future. So, maintenance pokes around in the code every now and then for troubleshooting and the added time it takes them to sort it out is dirt cheap in comparison for an OEM/integrator to constantly "change" their code development to meet the needs of cheap labor on the customer end.

When a plant takes ownership, and begins to modify/improve/advance equipment w/o bringing the original OEM/integrator back then it's the cost of playing the game. Some OEM/integrators are no longer around, or the plant thinks they are getting ripped off(hell if they ever think they aren't)..if the plant doesn't see value in automation skills from the original OEM/integrator you'll never give them a product they will be satisfied with. Granted, some OEM/integrators produce poor products, but very likely that was the lowest bidder. "Its expensive to be cheap".

For my company, we have a great standard (best I've gotten to work with in my short career), but it's very complex, has lot of features already built in (much of which is background noise, it's proven to work and simply supports the main sequencing logic). It can be more than required for small systems but it's extremely scalable to large systems. I feel confident that if I can sequence the process, I can use our standard to program it, but it's a beast to pick up yet simple to trouble shoot if at minimum you understand the sequencing.

To be efficient we have standard excel documents that can auto-generate base code, base tags, descriptions, mapping logic, AOI routines, all kinds of stuff to make development easier and much more painless. Unfortunately, those are development tools we have created for internal use, and without those tools it's harder for our end-users to make substantial changes. But makes life for us 100 times easier. It is a balancing act, some customers catch on others don't. Again, if the plant isn't vested in qualified controls techs/engineers it's not the OEM/integrators problem.

I'm commissioning a project right now, very large project and the plant has no interest in improving the skill set of their maintenance team. They are used to PLC5 controllers and PanelView 550s. We're installing a monster upgrade using ControlLogix/Batching/Blending/Reporting/SCADA systems, their plant knowledge is out dated by 20 years and you simply cannot afford to program for the end user in situations like this.