there is a product called ProDef. Developed in Australia (we now use it extensively) and purchased by Invensys last year"

Well, I thought for a while that ProDef might be a competitor to ControlDraw - but it has disappeared from the face of the Internet.
Maybe that's what heppens when a company is purchased by Invensys :-} - so what happened to it. Does anyone out there know?

Francis

 

G'Day Francis,

I am sorry but Prodef is not existing anymore. But I am working for a companie call TNI-Software, which had developed since 20 years a product called Controlbuild. This product is an object oriented tool as prodef, who follow you during all your project, generating all your project documentation, generating the PLC programming code (not only in Ladder as prodef), providing an early validation to decrease the risk during the commisioning step, simulation of the all plants, export database to a scada...

This product is support all around the world by TNI or some distributor, you can have a look to the web site http://www.controlbuild.com or the corporate http://www.tni-software.com.

If you want more information you can also contact me by mail.

regards

jeremy Scherrer
[email protected]

 

so what does one do after the purchase prodef and it is sold? how are you guys handeling this situation? I happened to of worked in a place where prodef was used to generate the documentation and the ladder logic. I am trying to understand this technique in programming.

henry zamarron
[email protected]

 

Hi Francis,
Unfortunately, I'm still working with Prodef, as it's being used by my current customer, and frankly, it's the worst piece of software I've ever had to use. It is utterly and completely pointless, and adds no engineering value to the design and implementation of a PLC/SCADA project. There's nothing that Prodef does that can't be done in an easier, cleaner, more intuitive fashion by the native PLC programming tools (Concept, Unity, Step 7 etc) and Office software (Excel/Access).

I find it clunky and unreliable, and the hoops I have to jump through to make it work for even simple modifications is staggering. What should take me 30 minutes under normal circumstances takes about half a day in Prodef AND I can't even do it online, so I have to disrupt a process in order to make minor changes or enhancements (ie. do it offline, recompile the PLC code, stop the PLC and then download the whole program to the PLC). Either that, or I have to make the change online in the PLC, do it again in the Prodef, and update the SCADA manually (which defeats the purpose of having an "all-in-one" package I would have thought).

Unless you have absolutely no choice, or you enjoy making mountains out of molehills, avoid Prodef like the plague!!!

 

Thanks Tony for that.

It is no surprise to me either, as producing a generic PLC programmer is fraught with such problems. For your info, my software ControlDraw does not attempt to do that, it is for designing before you code and documenting what you have programmed yes. Given good design information in the Functional Specification, the system can be programmed quickly using conventional tools.

 

Hi Francis
It's a shame to hear people out there bagging probably the most innovative and superior product developed for this industry.

Prodef as a product for sale is gone, however the technology is far from gone and in fact is being incorporated into another major vendors platform

Controlbuild is now a new product that will do what Prodef did and much more.

We are a company which have successfully completed many projects in Australia and overseas utilising Prodef and we have as never before been able to actually make money on direct quoted software jobs, with no hardware or other sales to substitute for budget over-runs that often happens on the sensitive subject of plant floor controls software.

Prodef allows you a transparent approach with proven methodologies, that makes controls reliable and robust as supposed to every engineer and OEM comming up with their own controls methods that again and again proves to impose problems in control processes.

Somebody once said: "automation kills processes"
This is very true, hence the need for conform proven principles that can only be had through a non-human intervened compiler process.

Anyone thinking they can continue to use "good old ladder Logic" in today’s high technological and demand driven controls industry is going to be left behind.

There is a better way, and Prodef along with “Controlbuild” have and are still very much setting the precedence.

 

I have had the misfortune as well to have been forced to used this product in the real world. It is a total abortion in terms of productivity. Avoid this rubbish at all costs, it is infinitely better to do PLC/SCADA work native rather than multiply your time by a factor of 5 to 10, then alienate the plant operations people by constantly having to stop everything to make a trivial change (no online changes here folks!). Worst product I have ever seen, ever.

 

I don't know if anyone's still reading this thread two years after it started, but out of morbid curiosity, I decided to look it up again and found this message. I felt compelled to reply.

>It's a shame to hear people out there
>bagging probably the most innovative
>and superior product developed for this
>industry. <

Actually, it's really not that innovative. Engineers have been creating device templates using ladder, FBD, or even Microsoft Word's Mail Merge for years. To go on and label it as "superior" is laughable.

>Anyone thinking they can continue to
>use "good old ladder Logic" in today’s
>high technological and demand driven
>controls industry is going to be left
>behind. <

Have you even used Prodef?!? Prodef actually GENERATES ladder logic (and that's if you're lucky - the Siemens compiler I've seen spits out structured text!) - only it's not put together by a programmer with some sense of how the human brain might best interpret the code, it's jumbled together by a compiler optimised for the lowest common denominator, with (I'm sure) a random number generator thrown in for good measure. Yes, a lot of it is based on ladder that's entered by a user, but it's usually "augmented" with other code to complete the mutation from SFC to ladder in a really obtuse way.

>There is a better way, and Prodef along
>with “Controlbuild” have and are still
>very much setting the precedence. <

From what I hear, Controlbuild is pretty much the same garbage, just a different smell.

The precedent has already been set many years ago. The best way to put together a PLC/SCADA system is to use standard templates for devices, screens, popups, controls etc. Write modular code that can be re-used and re-applied across your plant. Develop systematic naming conventions and programming practices and STICK to them. Spend a bit of time developing the essential building blocks like tag names, and device templates, typical program structures and the rest will grow from there.

All of this can be done with the native programming tools that were SPECIFICALLY designed to work with the PLC/SCADA system in question.

All Prodef (and probably ControlBuild) manages to do is take a good idea (standardisation) and completely botch it up.

 

>Actually, it's really not that
>innovative. Engineers have been
>creating device templates using ladder,
>FBD, or even Microsoft Word's Mail Merge
>for years. To go on and label it as
>"superior" is laughable. <

Possibly the innovation can be seen in the application of a meta language to solve the problems that occur when "creating device templates using ladder, FBD, or even Microsoft Word's Mail Merge for years." Maybe its the ability to deliver thousands of template combinations in a single template. Maybe its the extensibility of the meta language (as shown by the HMI generation). Maybe its the ability to simulate on one brand of PLC and deploy to another. Maybe its the level of optimisation that can be achieved in the PLC code (more on that below). Maybe its knowing that tested device code cannot be corrupted by typo's or bad translation (i.e. once tested the user can be confident an error during commissioning is field based and not code based: this is rather significant when a PLC programmer can not easily demonstrate that the code is not at fault). Maybe it's none of the above. ;-)

>Have you even used Prodef?!? Prodef
>actually GENERATES ladder logic (and
>that's if you're lucky - the Siemens
>compiler I've seen spits out structured
>text!) - only it's not put together by a
>programmer with some sense of how the
>human brain might best interpret the
>code, it's jumbled together by a
>compiler optimised for the lowest
>common denominator, with (I'm sure) a
>random number generator thrown in for
>good measure. Yes, a lot of it is based
>on ladder that's entered by a user, but
>it's usually "augmented" with other
>code to complete the mutation from SFC
>to ladder in a really obtuse way. <

The optimisation complexity and language output criticism indicates a lack of understanding as the output can be configured entirely by the user (probably the most significant element of the Meta Language concept used by ProDef). The level of complexity in the optimised output has been purely customer driven (hence the simplicity of AB and complexity of S7).

>From what I hear, Controlbuild is
>pretty much the same garbage, just a
>different smell. <

Maybe first hand experience would be more appropriate.....

>The precedent has already been set many
>years ago. The best way to put together
>a PLC/SCADA system is to use standard
>templates for devices, screens, popups,
>controls etc. Write modular code that
>can be re-used and re-applied across
>your plant. Develop systematic naming
>conventions and programming practices
>and STICK to them. Spend a bit of time
>developing the essential building
>blocks like tag names, and device
>templates, typical program structures
>and the rest will grow from there. <

Regarding the earlier comment: "Engineers have been creating device templates using ladder,
FBD, or even Microsoft Word's Mail Merge
for years.":- ProDef was developed to overcome the wasted time and cost associated with each engineering house creating the these templates and methods.

>All of this can be done with the native
>programming tools that were SPECIFICALLY
>designed to work with the PLC/SCADA
>system in question.
>
>All Prodef (and probably ControlBuild)
>manages to do is take a good idea
>(standardisation) and completely botch
>it up. <

I would like to try ControlBuild. Seems a shame to can a product without seeing it.

 

One has to wonder how some people look at a paradigm and actually completely change around their business profitabillity, while so many are so much more interested in bagging than in getting to know how this was achieved.

 

well i don't know, by what i heard Prodef was sold and the people who paid peanuts for it just shelved it because it made there stuff look like crap. It's like all good new technology, if you have the money to suppress it for as long as your selling your technology you do it. The only trouble is one day that technology will get out of the bottle (ie: copy or replicate) and then it turn will be crap. I hope it comes around again as i used it once on one job that made me a packet.

 

I am currently experiencing the pain of ProDef. After 33years in process control, I can assure you that ProDef is worse than the worst comments in this blog.

In trying to be all things to all men, it becomes unwieldy. I am not directly using ProDef but working with a team to engineer a reasonably large control system. The end user of this system is to my knowledge the only user of ProDef in 2016.

The PLC programming environment does NOT have online monitoring. The project I am working on is a Siemens/SCX SCADA system. The ProDef compiler as described above spews forth ONLY Siemens Coding Language (SCL), a variant of structured text. ProDef does NOT include array variables, which makes shift register operations all but unthinkable.

In the end, programmers manipulate the SCL code online to fix any short comings in the commissioning phase and then have to modify the ProDef source code, recompile and download again. Some try to defend such a cumbersome approach as achieving standardisation, but when the code that ends up in the PLC can only be monitored by the native PLC programming package, and the code generated is so obtuse, one wonders what the benefit could possibly be!

I am in complete agreement with one of the earlier contributors who summarised that all that is needed is to have standardised PLC function blocks for devices such as motors, valves, instruments etc and to have the SCADA templates for the various types also functionally and graphically defined. If you standardise the function and philosophy of all of these devices and SCADA graphics and pop-ups, then you can forget the concepts of ProDef.

As an aside, I am also an Engineer who hates Sequential Function Chart. SFC is a construct of people who think that sequences look nice in diagrams. In my vast experience of dealing with SFC, this is the greatest tool for writing "Fair Weather" sequences. It is really easy for a novice to write something that does a set of steps. The problem is that it becomes unwieldy when you start trying to add in all of the things that make it capable of dealing with rough weather, and being able to restart after a fault. Once you start adding in the rough weather triggers, anything but the simplest sequence looks like gobbldygook! I use a STATE machine with a number for the step number and I have a very specific approach to documenting (Functional Specification format) the sequence complete with checking the condition of ALL devices at EVERY step, only considering devices which are important in the phase that is being executed and providing sequence resumption where there is a sequence failure.

I will try to put this up on this site one day when I get the chance.

Unfortunately I am a Schneider devotee, function block coding of course.

Cheers
Schneiderman