Cardocea, I think you mis-understood, I did not mean write blocks which are limited, for example take two types of blocks, a standard valve handling & a motor handling, you code the valve block so it contains the control for limits, 3 port & 5 port etc. you then only need one block that caters for most types of valves, there will always be one that will need different control but as you say you build up a library that becomes a standard. There is no need to create a block that covers every valve type possible, it can confuse people. keep them simple so yes a block that covers a valve that has one or two solenoids with feedback & put in dummies for the functions not used, however, perhaps a motor control will have more than one type of FB there seems no point in creating one that controls DOL, Star/Delta, two speed & VFD.
I have been in this game for nearly 40 years & seen many flavours of code, using my own initiative & experience as well as pinching others (lol), I think I have built up a lib that covers most scenario's that I can use in most projects, of course, you will get end users that have their own ideas & possibly their own libraries that you are contracted to use (we had one customer (Major blue chip company) that insisted every OEM used their standard blocks, these were not simple, for example there were Ethernet coms to high level systems, instrument coms, task & process handling as well as standard blocks for valves/motors etc. TBH, by the time you had loaded all the standard blocks required it did not leave much room for your own code, but in saying that it did save a lot of time (if you understood how it all worked as they did not supply much documentation).
I worked for one of the chosen OEM's who were tasked with writing the standard blocks, we did provide documentation but many of these blocks were protected to stop other suppliers modifying them (Yes even on S5 if you knew how).