The challenge with In-Sourcing in any software discipline even when corporations deem themselves large enough to take on the technology industry by themselves, is multi-fold:

1. Often internal costs (wages ++) are not included in the total cost analysis, justified on grounds that these are fixed costs regardless of internal resource engagement in such endeavors or not. Why not use already paid internal skills? This view however distorts the true costs of implementation and the true bottom line value add potential.

2. Long term internal employees tend to stagnate over time, due to lack of technology exposure. In a rapidly changing tech world, it’s essential that external expertise and hands-on cross industry knowledge are thrown into the mix.

3. It’s not enough to be highly skilled in coding various platforms and systems. Process understanding, coding principles and best practice knowledge comes from having been exposed to, and being continuously involved with rapidly changing technologies, objective outcomes and projects across many industries.

4. If you are a producer, a non-technical business, why take on a whole new business model that hundreds of businesses and individuals have spent their career specializing in, gaining real practical knowledge of what works and what doesn’t.

5. Why compete to re-invent the wheel? The in-house development is local only and will never get a run for the money outside the business walls. Any missed technological opportunities (Bottom line value potential) will not even be realized.

6. Then there is the issue of when the key technical person inevitably leaves the business. What has been left behind can often be very intricate and complex or perhaps not even accessible, leaving the need to out-source after-all, and likely at much higher costs in retrospect.

In-sourcing or Out-Sourcing? In either case, make sure you compare costs in real terms, and most importantly ensure the legacies left behind are open source and using best practices that allow the next expert to take over.

Torben Kjaer

The post In-house, Out-Sourcing Conundrum appeared first on Alsinger Integration.

Process and machine builders or Original Equipment Manufacturers (OEMs) are market providers of mechanical equipment to product manufacturers. OEMs create and sell all kinds of mechanical equipment, including the electrical and software coding aspects, as complete systems.

OEMs practically span all industries where there is some form of stationary equipment – whether that involves the processing of raw materials pulled out of the ground or the refined manufacturing of electronic print boards in the very computer that runs the same process.

The process and machine-building industry, or OEMs, have been around for well over 100 years and have come a long way from the early inclusion of crude electrical components to the full-scale computerised systems of today.

Since the introduction of the computer to the industry, OEMs have done many things well and progressed with the advancement of electronic and computer technologies to meet the demands of a manufacturing industry that desperately needs to keep up with an agile, competitive and ever-changing consumer market.

The problem is you can use all the latest technology and still fail to benefit if any of the software layers are written poorly.

PLC (Programmable Logic Controller) code or software in general is the one thing that OEMs struggle with – they often fail to understand the importance of their written code that controls their machines and processes, and product manufacturers are often ignorant on the matter. Let’s take a look at some of the reasons for this lack.

Undermined Machine Potential

The lack of sound control principles and structures in the PLC code of machinery and processes has enormous impact on OEMs, on the potential of their machines and ultimately you, the end user. OEMs easily develop bad reputations and won’t enjoy repeat business if their equipment takes on customer perceptions of being poorly designed, even when their equipment is of high mechanical quality.

The real tragedy behind inferior control principles is the unreached potential many machines and processes operate under. Performance potentials are greatly undermined by spaghetti-style and ad hoc PLC coding practices, so often witnessed throughout the industry.

Although some are starting to catch on to the object-oriented and structured approaches that various vendor software has gradually included over the years, there is still a lot left to be desired.

I so often come across PLC code written in ways that indicate a complete lack of knowledge of both process and software principles by the writer. The ad hoc approach begins at the first line of PLC code and continues in one long exhausting section until the end, with manual, labour-intense, and random entries of symbolic naming, descriptions and section headings, or even a complete absence of any documentation.

There is a big lack of proper use of the object-oriented methods that would actually assist the PLC programmer tremendously in achieving effective use of personal time and consistent, repeatable functionality across all machines, processes and industries.

The ultimate result of these random approaches, after long, drawn-out commissioning times with repeated trial and error attempts at making it work, is a software mess left for the customer to deal and live with for years to come.

The “spaghetti-style” PLC code is somewhat akin to the “bird’s nest” wiring left behind in electrical cabinets in the days before the emergence of the PLC, when electrically-wired relays were the only form of automation.

Software can remain in a “clean” and maintainable state if tools available in modern vendor software are used as they were intended.

Insufficient knowledge and understanding of structured, repeatable and proven approaches by electricians-turned-PLC-programmers, completely undermines the ever-expanding and fluctuating needs of today’s manufacturers. This goes especially for the high production performers who need 24/7 production capacity to meet demand and remain competitive.

The post Book Extract (Lesson 1) appeared first on Alsinger Integration.

Tooheys is a high performance manufacturer of well know beer brands, operating 24 x 7 at Lidcombe NSW, so their need for continuous improvements is a major focus. A percent here or there can have major impact, especially at filling speeds in excess of 1,200 bottles per minute.

Alsinger Integration have previously improved performance of their inline equipment, the latest being a 25 year old underperforming depalletiser that supplies one of their main filling lines.

With a cycle time of 5 minutes per pallet on a good day, it was (pardon the pun) a bottleneck! To really keep up with the line its cycle time had to be sub 4 minutes.

Over the years many internal and external software engineers have tried to improve the performance using ad-hoc approaches, all the while creating a tangled software environment, for minimal improvement.
Slightly improving one function would often adversely affect another.

Our first analysis confirmed once again we had found another Spaghetti Junction: poor structure, absent documentation and scattered ‘latching’ logic, all contributing to lack of performance and issue resolution.

We recommended a complete re-write of the software to a fully structured object-oriented standard. After all you can’t make a silk purse out of a sow’s ear. Sometimes however, production pressures require that you have to do the best with what you have, so instead of a full rewrite it often becomes a case of consolidating, structuring and documenting parts of the program where the most gain can be made in the shortest amount of time.

In the case of Tooheys a complete rewrite was impractical, especially leading into beer drinking season. A pragmatic approach, improving logic, documentation and structure, untangled the spaghetti to a comprehensible level where it can be now be maintained and further improved.

The Depalletiser now performs at a cycle time of 3.25 minutes per pallet, which is an extraordinary 35% improvement!

The improvements also mean the depalletiser is more capable of self-recovery, leading to significantly reduced downtime.

A double bonus.

Finally, the fact that absolutely no mechanical modifications were made might start you thinking about what possibilities and opportunities are hiding in all the lines of code in your factory.

Are you spending your improvement dollars wisely and sweating your old assets?

The post SWEATING YOUR OLD ASSETS appeared first on Alsinger Integration.

As many ways as there are software Engineers of cause

As with all things, people have different takes on how to go about it.

Are some methods better than others? Absolutely and there are many reasons why coding must follow good practice. The equipment the vendor sells must add significant value to the manufacturer through the installation of continuous money producing cash cows, which is imperative to the long term cost effective and competitiveness of the Australian manufacturing sector.

For the Vendor to be cost effective and stay in business which is crucial to the continuous servicing of the cash cows, the vendor must maximise profitability by reducing implementation costs and minimise the post-handover warranty claims that is eating away the profit earnings on projects.

Robust coding leads to reliability, maintainability and transparency which in turn lead to the one thing all factory owners are after – more production uptime – more $ to the bottom line.

Crap code leads to unreliable machine behaviour and makes the otherwise mechanically well designed machinery look — well crappy too

Every man and his dog can learn how to write code but it takes a particular skill to produce effective programs that are solid, repeatable and add to the bottom line of both the vendor and the end user.
Imagine the pilot in the cockpit using a pre-flight checklist from yesterday’s take-off! That most certainly would lead to a fatal crash. Although not as devastating this is often what goes on in the software that runs production lines.

Programs using memory latching of past events often lead to either machine crashes or hung systems. Hung systems are when operators see a healthy “running” machine but no throughput. What’s going on? No alarms, no info, no nothing. The software memory is out of sync with the actual state of the machine. The weather is thunder, high winds and heavy rain, but the check-list (past memory) says blue skies and a mild summer breeze.

When production is running smoothly all is well and the line is ticking away until a stoppage due to an abnormal situation has devastating impact on re-start, the all too familiar frustrating and costly situation for operators, factory owners and vendors alike.

For the majority of people the machine controller is a black box and only few people, the programmers knows what goes on inside in the brain and even that statement is often a stretch.

Without good code structures and the use of more real time logic and less memory latching your machine is built on a poor foundation that will haunt you for the life of the machine and will pull down your line OEE numbers.

Do you know the true cost of Crap code in your machines? We don’t either but it may be worth a look
Want to know more? we are here to help you achieve Manufacturing excellence on all levels

The post The true cost of Crap Code! appeared first on Alsinger Integration.

The post Value for money appeared first on Alsinger Integration.

The post EXPENSIVE ? Compared to what? appeared first on Alsinger Integration.