automationtechies.com column for December is up

W

Thread Starter

Walt Boyes

It's been a busy week for Walt's pen...

My December column for automationtechies.com is up at:

"http://www.automationtechies.com/sitepages/art357.php":http://www.automationtechies.com/sitepages/art357.php

I've taken a really deep look at eBusiness and Manufacturing Automation and the Future of Automation Jobs.

I would love to have comment, discussion, critique or criticism.

We are at the point where information systems, business organization, the growth economy, the environment and quality of life issues are all colliding and making hash out of the hierarchically organized corporation, corporations with high growth as their only reason for existence, and 20th century consumerism. We are seeing the increased valuation of talent, and seeing talent follow good working conditions and the chance to grow.
Capital follows talent.

Best,

Walt::

---------------------------------------------
Walt Boyes -- MarketingPractice Consultants
[email protected]
21118 SE 278th Place - Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142 ICQ: 59435534

"Strategic marketing, sales and electronic
business consulting for the small and medium-
sized enterprise: http://www.waltboyes.com"
---------------------------------------------
 
B
Walt:

You have failed to address an area of the Instrument and Control or automation industry that has been largely ignored for the 50 plus years of machine control of industrial plants.

Tools developed for the design of the automation systems that control today's highly complex industrial facilities have barely changed since 1947. With the advent of the personal computer in the early 1980's, newer design tools have lifted automation development from the drafting board into a realm where it is easier to modify, transfer and copy information. These tools have made the job of the designer both easier and more complex. But, the business of design, information placed on drawings, information placed on spreadsheets all manually being moved through the business systems of design, has remained - leaving dead information in it's wake.

Industrial automation systems will not be complete until we have design tools which marry the real world with the virtual world. These systems will be incomplete until information flows unimpeded; not only from plant concept
to the plant floor but also back from the plant floor into a virtual representation of the plant facilities.

When total, unimpeded bi-directional integration happens, the dislocation that the automation world has recently endured will be a mere taste of what is to come.

With this total, unimpeded bi-directional integration, new and marvellous opportunities will also arise. New methods of designing industrial plants, new and improved work opportunities, new multi-functional engineering systems, new and improved preventative maintenance techniques, new systems of transmitting critical plant data to anywhere in the world where real time problems and production levels can be identified at a glance - all will be realized.

Bob Pawley
250-493-6146
 
W
Well, yes, that's true.

The fundamental problem in extending the business enterprise to the plant floor is that most business enterprise software deals with numbers, not making things. The plant floor, the shipping dock, the receiving dock, the stores, etc., all deal with actually touching and laying hands on and moving and making, as opposed to accounting.

So it was easy to automate accounting. It was even easy to automate simple plant floor operations. It was less easy to automate more complicated control systems. It is proving difficult but not impossible to connect controls systems to each other. It is proving more difficult, but still not impossible to connect some control systems to the business systems of an enterprise.

But the hard edge of the enterprise, the place that rubber meets the road, is still in the design of the physical systems...again, it's stuff you have to touch and feel, and the customer interface.

Both have not changed fundamentally...yet.

There are changes coming in both areas...there have to be.

Roughly 60% of the price of a control system implementation is "intellectual." That is, 40% is hardware, software and wire. 60% is design and labor.

In most cases, the hardware cost is breakeven or a tiny profit. In some cases, it is a loss.

The system integrator needs to make money on the "intellectual content" of the project. If it is possible to reduce the cost of design, and reduce the amount of labor, the integrator can either be more competitive (lower the
price) or be more profitable (keep the price the same and have lower costs) or a combination of the two...it is a continuum.

Obviously, the A&E or integrator who has the best automated design tools wins this part hands down.

Walt Boyes

---------------------------------------------
Walt Boyes -- MarketingPractice Consultants
[email protected]
21118 SE 278th Place - Maple Valley, WA 98038
253-709-5046 cell 425-432-8262 home office
fax:801-749-7142 ICQ: 59435534

"Strategic marketing, sales and electronic
business consulting for the small and medium-sized
enterprise: http://www.waltboyes.com"
---------------------------------------------
 
B
Merry Christmas and Happy Holidays to all on the list.

Dear Mr. Boyes:

I would like to explore the thoughts in your article as well as my observations of total integration and by using our knowledge of history try to project the future.

Is the dislocation that Mr. Boyes outlines an inevitable consequence of progress? It would appear so.

For the first three millennia of the Agricultural Age, 90% of humanity tilled the soil producing little more food than was needed locally.

The coming of the Industrial Age created such efficiencies in both the production and the transportation of food that a huge dislocation occurred. By the end of the twentieth century approximately 10% of the world's population could produce enough food for all. These efficiencies allowed the vast majority of us to seek other employment, producing food only as a
hobby. The Age of Agriculture had matured. The coming of the Information Age is just beginning to lock in this higher production to the point that the world, at large, will soon be awash in food producing capabilities (geo-political restraints notwithstanding).

The Industrial Age, barely two centuries old, is presently undergoing the dislocation leading to a maturity similar to the agricultural industry. The coming of the Information Age, known first as Instrument and Control or Automation, has introduced efficiencies of scale within all industries leading to the present dislocations. The advent of digital control, and lately the Internet is merely hastening this trend.

Up to this point we have gained significant scales of productivity when man was able to step-up and let machines do what machines do best. The
Industrial Age allowed man to control machines that do the work once done by humans. The Information Age has allowed man a further step-up, to control the systems that control the machines that do the work once slated for human
effort.

What will be the next Age? Whatever it is called, it will require Digital Assistants, guided by man, that will control the systems that control the machines that do the work of man. These assistants will monitor the factory,
ensure information retrieval and processing for the whole plant, identify problems, assign hardware solutions to others, correct operation and control problems within the virtual world by itself - all with little or no human intervention. This, then will be the third advance of productivity in our manufacturing facilities and a corresponding increase in the world's standard of living.

When will this next leap come about?

Not until we create an environment in which this Digital Assistant can thrive. The DA will require total information fusion (knowledge) from plant concept to project completion and beyond. The tools to start this process are available now. Unlike previous ages the Information Age will be measured in decades. We must start this process today.

"Civilization advances by extending the number of important operations which we can perform without thinking about them"
Alfred North
Whitehead

Bob Pawley
250-493-6146
 
C

Curt Wuollet

Hi Bob.

But only if electricians can understand it. :^)

Regards

cww

--
Free Tools!
Machine Automation Tools (LinuxPLC) Free, Truly Open & Publicly Owned Industrial Automation Software For Linux. mat.sourceforge.net. Day Job: Heartland Engineering, Automation & ATE for Automotive Rebuilders.
Consultancy: Wide Open Technologies: Moving Business & Automation to Linux.
 
B
Ahh Curt, don't rag the electricians too much. Most of them have things to do other than sitting around dreaming up code.

Bob
 
C

Curt Wuollet

Hi Bob

I wasn't ragging on the electricians. My point was that on one hand we have people talking about the advent of total integration and the factory as one system (One Microsoft system, I assume :^) ). On the other hand we have people asserting that nothing that can't be fixed by the shift electrician belongs in automation. What's amazing it that these are all (I assume) successful practitioners. That's a fairly broad divergence in worldviews. As someone who is advocating one of the very few systems that can span that range with the requisite scalability and reliability , I find a very interesting but very large void in the middle betweem device control and enterprise systems. Some would fill this void with dozens of servers of limited scope. Others would use a single large system. But who is going to write this "middleware" and how would it ever be generalized enough for the shrinkwrap future we are being forced into? I can't see it addressed by the ES vendors working down or the automation vendors working up as they make their money selling generalized systems. Only the company being served has the knowlege to do this.

Pictures at 10:00

Regards

cww
 
B
Hi Curt:

Which path the industry travels has little to do with individual practitioners. Rather, the path taken will be dependent on the broader sweeps of history and the technological developments that will open up that path in front of us.

You seem to have a bias against Microsoft. Microsoft probably deserves this anti-bias, at least in some part. But remember all Microsoft products are merely tools. We, as humans, will replace tools as they wear out or become
redundant. I don't think Microsoft is quite at that point yet.

You may want to explore my version of what the future can bring by re-reading my two recent postings which I have copied below. Further insight into a possible future can be gleaned by visiting www.najmah.com

Bob Pawley
250-493-6146

True object based software is dynamic, intelligent and aware.

A true object will have a string if attributes attached to it, attributes that are assigned depending on the environment in which it is placed, the ability to use these attributes to satisfy the conditions of the environment in which it's placed, the ability to "know" its place within that environment, the ability to gain "knowledge" by knowing its place within
that environment.

Collections of objects within a structure will develop knowledge of that structure, leading to a gaining of further knowledge - automatically.

True object based software is the next wave.

Bob Pawley
250-493-6146

For the first three millennia of the Agricultural Age, 90% of humanity tilled the soil producing little more food than was needed locally.

The coming of the Industrial Age created such efficiencies in both the production and the transportation of food that a huge dislocation occurred. By the end of the twentieth century approximately 10% of the world's population could produce enough food for all. These efficiencies allowed the vast majority of us to seek other employment, producing food only as a hobby. The Age of Agriculture had matured. The coming of the Information Age is just beginning to lock in this higher production to the point that the world, at large, will soon be awash in food producing capabilities (geo-political restraints notwithstanding).

The Industrial Age, barely two centuries old, is presently undergoing the dislocation leading to a maturity similar to the agricultural industry. The coming of the Information Age, known first as Instrument and Control or Automation, has introduced efficiencies of scale within all industries leading to the present dislocations. The advent of digital control, and lately the Internet is merely hastening this trend.

Up to this point we have gained significant scales of productivity when man was able to step-up and let machines do what machines do best. The
Industrial Age allowed man to control machines that do the work once done by humans. The Information Age has allowed man a further step-up, to control the systems that control the machines that do the work once slated for human
effort.

What will be the next Age? Whatever it is called, it will require Digital Assistants, guided by man, that will control the systems that control the machines that do the work of man. These assistants will monitor the factory, ensure information retrieval and processing for the whole plant, identify problems, assign hardware solutions to others, correct operation and control problems within the virtual world by itself - all with little or no human intervention. This, then will be the third advance of productivity in our manufacturing facilities and a corresponding increase in the world's standard of living.

When will this next leap come about?

Not until we create an environment in which this Digital Assistant can thrive. The DA will require total information fusion (knowledge) from plant concept to project completion and beyond. The tools to start this process are available now. Unlike previous ages the Information Age will be measured in decades. We must start this process today.

"Civilization advances by extending the number of important operations which we can perform without thinking about them"
Alfred North Whitehead

Bob Pawley
250-493-6146
 
C

Curt Wuollet

Hi Bob

It's not really an anti anything bias. It's a pro-customer, pro-computer-user bias. It's unfortunate that it conflicts with the way proprietary software vendors conduct business. And replacing those tools with tools that don't enslave people is one of my current goals. As a fairly accurate amateur futurist, I'm interested. However, the future for automation is inhibited by the tools chosen. among other things. Actually, as I see it, advancing the state of the art in the automation field is merely stretching one end of a continuum that reaches from the current back beyond even the advent of electronics. As the current extreme trudges forward at a fraction of the rate of the advances in technology, the center of mass changes very little. That is to say that the frequency at the leading edge becomes smaller and smaller. To have an appreciable market for new advances, we must do something to facilitate the uptake of past advances. Indeed the infatuation with office technologies is a holding pond on the path of advancement, this in the flood plain of lack of standardization which spread the trickle of impetus miles wide and effectively stopped forward progress. To begin moving forward again en masse will require convergence on a smaller set of common technologies and standards. The PLC converged a lot of disparate methods and technologies for a while and progress was made. As often happens, acceptance and uptake was sufficient to drive an even broader divergence with much slower progress to date. The divergence was so broad that many, many automation entities have insufficient volume to foster any progress at all. The market stagnates. This situation should eventually correct itself with a fairly massive shakeout. We could preserve more entities and thus competition by standardization and commonality. The alternative is fewer and fewer entities capable of making progress and ultimately perhaps even monopolization through decimation of competition. One could gain much insight by tracking sales, my gut would be that sales figures heavily favor the trailing edge. In summary, it's hard to predict the future, but fairly obvious that we're stuck. Time to do things differently. We can move five platforms forward much more rapidly than 500. And that may well require that we break lockstep with Redmond and adopt purpose built systems that can be advanced in the directions we want to go today.

Regards

cww
 
Curt:

Predicting the future can be a fools errand. But, I do think that predicting trends based on an historical perspective, recent and ancient, coupled with present development can be insightful.

Let me present the full quote from my favourite philosopher-

"It is a profoundly erroneous truism, repeated by all copybooks and by eminent people when they are making speeches, that we should cultivate the habit of thinking of what we are doing. The precise opposite is the case. Civilization advances by extending the number of important operations which we can perform without thinking about them. Operations of thought are like cavalry charges in a battle - they are strictly limited in number, they require fresh horses, and must only be made at decisive moments"

Alfred North Whitehead

This is as true today as it was when Whitehead first penned it some 80 years ago.

I would suggest that any successful forecast of the future would need the concept of 'doing more with less effort' as its root message.

A common platform such as provided by Microsoft falls into this category. Microsoft also provides part of the industry standards of which you speak. How well Microsoft products accomplish all of this I'll leave to individual judgement. How well other products perform these functions, can be similarly judged.

I will leave you with one more quote-

"Engineering needs tools that don't require a second career, that work like a well-designed transit or wrench. Make them easy and natural to use.."

Joel Orr, consultant, writer and futurist focusing on engineering automation.

Anything less is travelling back, not forward.

Bob
 
B
Curt:

You wrote - "However, since nothing other than closed, monopolistic systems have been offered in this market, with one exception, it seems highly unlikely there can be any judgement or even comparison"

You will need to help me with this but - it seems that the monolithic system, Microsoft, allows a higher degree of third party input to control solutions than the old proprietary system allowed. Your one "open" exception, I'll readily admit that I know little or nothing about it, still seems to me to be a step in the opposite direction.

Allow me to make a simplistic comparison only in order to make a point. If a carpenter needed to make changes to, or even needed to understand, the metallurgic composition of his hammer, houses would be very expensive indeed.

If the technology isn't advanced enough, or no company has offered a hammer that meets all requirements, I don't see how you can place the onus on the company that has provided a solution to some problems, regardless of how flawed that solution may be.

If the only answer is to force the carpenter to ensure that the hammer, and the nails, meet the requirements of the job, each and every time he buys new, seems to me to be quite an expensive way to go. This is Joel Orr's point.

Even with the Microsoft platform the carpenter needs to do a lot of learning and ensuring prior to using a new tool.

Bob
 
C

Curt Wuollet

> Curt:
>
> You wrote - "However, since nothing other than closed,
> monopolistic systems have been offered in this market, with one
> exception, it seems highly unlikely there can be any judgement or even
> comparison"
>
> You will need to help me with this but - it seems that the monolithic
> system, Microsoft, allows a higher degree of third party input to control
> solutions than the old proprietary system allowed.

Granted, but the only third parties who are included are Microsoft "partners" who merely substitute closed applications for other closed applications. Which means this new "openness" isn't remarkably better from a customer/user/integrator viwepoint than the old days. You still can't do anything that isn't provided or allowed, like integrating across product lines and vendors, using the database _you_ want, etc.

> Your one "open"
> exception, I'll readily admit that I know little or nothing about it, still
> seems to me to be a step in the opposite direction.
>
No it's a half-step in the right direction, it's still proprietary and closed but at least it runs on Linux as well as Windows. Even this adds
a great deal of flexibility and no doubt, reliability. But you're right that it doesn't solve the whole problem.

While proprietary applications running on Linux is sub-optimal it is still much better for integration than an all closed platform. On Linux
I can at least work around the limitations and write glue code to the software of my choice and write system code if neccesary to make things
work. And software running on Linux is much easier to integrate with anything other than Windows because Linux uses truly open standards
API's, networking, everything. And Linux supports things like Java that MS spitefully ignores but everyone else uses.

> Allow me to make a simplistic comparison only in order to make a point. If
> a carpenter needed to make changes to, or even needed to understand, the
> metallurgic composition of his hammer, houses would be very expensive
> indeed.
>
> If the technology isn't advanced enough, or no company has offered a hammer
> that meets all requirements, I don't see how you can place the onus on the
> company that has provided a solution to some problems, regardless of how
> flawed that solution may be.

But if there's no way he can see or try another hammer that would be better for the work he's doing, that's a bad thing. Most craftstmen have a variety rather than trying to make do with only one. To an extent, a hammer is a hammer, if you've used one, you can pretty much skip the instructions. That doesn't mean the tack hammer is good for splitting rock for the facade. Of course, if the tack hammer company had exclusive license agreements with every hardware store in the country, we'ed all have to make do with tack hammers. Pole barn spikes would all but dissappear no matter how useful they are. They are too hard to use when you have the wrong hammer. Tacks would be popular for every purpose. Just don't go in the pole barn.

>
> If the only answer is to force the carpenter to ensure that the hammer, and
> the nails, meet the requirements of the job, each and every time he buys
> new, seems to me to be quite an expensive way to go. This is Joel Orr's
> point.

But as any roofer or framer will tell you, the right hammer makes a lot of difference in how much work you can do in a day. He will find the right hammer if he's got a choice and his boss will let it on the site. And the difference in knowledge required between Windows and Linux at the level we operate at has been grossly exagerated. For the work most of us do, you have to know quite a bit about either to cruise. The "extra" knowlege needed over say an operator, tends to be common between the two as it relates to hardware, memory, etc. Many of the problems discussed here would be "special" knowlege in either case. Such knowlege is much easier to come by with an Open OS. No credit card needed.

>
> Even with the Microsoft platform the carpenter needs to do a lot of learning
> and ensuring prior to using a new tool.

But he doesn't get any new tools, just the tack hammer that "everyone" uses. The trim guy is okay with that but the framer thinks maybe
something's wrong.


>
> Bob

Regards

cww
 
B
Curt:

It would seem we are both agreeing on the problems from slightly different viewpoints.

What do you think the answer would be if we were in a perfect world and we agreed that any tool should strive to be as easy to use as a hammer?

Bob
 
C

Curt Wuollet

Hi Bob

That's fairly simple. PLC, SCADA, etc vendors would add Linux to their supported platforms and those interested would start working on an automation specific Linux distribution family.

The distribution would consist of a carefully selected workstation version which would also serve for display and operator terminals. This would be fairly barebones to eliminate bloat and provide good performance with minimum resources and bells and whistles could be added or subtracted as needed. Linux is structured this way and has package managers that make this easy. Gets rid of a lot of security issues that come with the all-in-one approach, not to mention saving hundreds of megabytes of disk space. Utilities and tools could be selected for their relevence and applicability to automation from the vast array available. This could scale from SBC's to Mainframes.

The second part of the distribution would be a kernel and facilities for actual control, either soft realtime with the various latency and scheduling patches available or hard realtime with RT Linux or similar. All facets would be compatible with the rest of the family wherever possible.

Other specialized versions could be added at need.

This distribution would not be a huge effort as any popular existing distribution could be used as a starting point, the primary reason for
having a distribution would be to serve the automation community and issue stable fixed distributions that can be maintained for the life- time of the equipment and tools built with them for investment protection.

With a little work, a great many apps could be run on Linux NOW. This through the use of dosemu and WINE. This can and has been done with one code base for both Linux and Windows. IBM and Corel have released major works done this way. Immediately the churn and version nightmare diminish as the OS release dates and versions are no longer a revenue item but can be planned for maximum value.The cost savings should pay for the migration and everybody can relax a little more.

Eventually, (hopefully soon) the vendors would want to produce native ports of their tools to Linux, possibly using a framework like that donated by IBM. DOS tools would port fairly easily and run very efficiently, now in a multitasking environment with effective memory protection Most would benefit greatly from unlimited virtual memory and the flexible I/O structure with excellect serial port support. From this viewpoint Linux looks like DOS on steriods with the limitations that produced myriad workarounds, hacks, tsr's and other mickey mouse programming permenently banished. DOS tty type screens come across easily and well in most cases and support exists for vga graphics with or without windowing. This would be largely a one-shot effort. With care, these would require little work to stay current. And these useful legacy command line and simple GUI apps will be strongly supported _forever_ in Linux. In many cases nothing more is needed or could be wanted. Retired apps could be opened up for community support and education. For Windows apps, conversion would be somewhat more problematic but still doable. The tools and libraries exist and are stable and for the effort of perhaps a couple of Windows revs, the result would be stabilized under a much more rational release schedule. I am not much of a GUI programmer so I'll not elaborate. I'm sure we probably have at least one reader who has done this and could comment more intelligently.

Having the OS and environment under community/industry control on an Open Source, low cost platform would dramatically lower programming costs, upgrade costs, license tracking costs, and deployment costs. The distribution could be moved in directions that fulfill the rather specific needs of the automation industry. Support can be added for facilities that will never show up in Windows and the things we need would never be obsoleted. It is my informed, considered, opinion that the industry driving the platform would be much more efficient and definitely much more favorable in every way than the existing situation of the industry chasing after a platform that is going in the wrong direction. The new efficiencies and directed purpose could restore the impetus and get people working on automation issues, not desktop support. And this would be an ideal foundation of Open standards. protocols and commonality to build upon to debalkanize the industry. It's inevitable. Now will cost much less than later. Open could become the watchword rather than simply a buzzword.

These are but a tiny fraction of the ways that a community based Open platform for our industry would make life easier. I've already mentioned in previous posts some of the more obvious. If there is interest I can get into how this would or wouldn't affect the problems and opportunities that exist

Regards

cww
 
J

Johan Bengtsson

For those interested in what effort it would take to support more than windows:

As Curt state a lot of programs could be easily converted. I have made several command line tools that are identical at source level between WIN32 command line and linux - that part is very easy in C/C++

No, also as stated, GUI programs using windows is a little bit trickier but not as hard as I think a lot of people think (hmm, I think I got that right...).

A lot of modern windows applications are done using C++ and MFC. Several options to this exist, one example is wxWindows (http://www.wxwindows.org)
and yes this is but one example - there exist more similar frameworks.

WxWindows is a framework replacing MFC, but it is built in a very similar way. It currently exist in versions for:
- windows (3.1, 9x, ME, NT, 2000, XP)
- unix (linux as well as other unix versions)
- macintosh (MacOS 9.x, MacOS X)
(and I do at least expect it to grow) And since it is open source with the additional thing that you are allowed to build proprietary software with it support won't likely dissapear, not before support for MFC anyway.

Most (if not all) of the non-GUI code is of course just to recompile, at least if it is written in C or C++.

It is of cource a cost, especially should of course the cost of getting used to another framework be considered, but I think a lot of people think the cost is higher than it is.


/Johan Bengtsson

Do you need education in the area of automation?
----------------------------------------
P&L, Innovation in training
Box 252, S-281 23 H{ssleholm SWEDEN
Tel: +46 451 49 460, Fax: +46 451 89 833
E-mail: [email protected]
Internet: http://www.pol.se/
----------------------------------------
 
A
Actually, yes.

The MFC application that has been created (WinBuild 2000) for the purpose of configuring our hardware (customizing the GUI, writing the BASIC code, setting up the various drivers) has the following components:

A communications serial & ethernet library that I do not have source for The XCeed Zip library for zipping files -- not available for Linux Stingray's (now Rogue Wave) Objective Toolkit & Objective Grid, which I do not have the license to compile for Linux Sandstone's Visual Parse -- not available for Linux Microsoft Excel for our recipe system editing (not available for Linux) Plus, it uses Microsoft's DAO as its save files

In addition -- I have added a COM interface to my application so that I (and other people in our company) can write tools (Wizards, mainly) in Visual Basic, not C++. Will that work under Linux? Does COM work at all under Linux?

Whats my point? Many applications have dependencies like this. I look at the various Windows applications various vendors and notice that nearly all of them use libraries like I do -- editors, parsers, networking, etc. There are very few "pure" MFC apps out there.

Converting my application to Linux would require a massive investment in time. I have never been asked about a Linux version of this software. There are no plans for this. Ever.

But using Linux for a future HMI project though? Sounds like a good idea to me <g>.

Alex Pavloff
Software Engineer
Eason Technology
 
C
Hi Alex

Fair enough.
One last question. If you were starting fresh, would Linux be a reasonable option?

Regards

cww
 
A
Its an option, but I still don't think that configuration software for Linux would bring in loads of business. Lets take you, for example. Lets say someone came along and said "Mr Wuollet -- I have a job to do, but XYZ HMI panel doesn't do what I want. What can I do?" I don't think you would buy my smart HMI product, because, well, you're the type of person that would pick off the shelf parts, install their preferred flavor of Linux, and slap together a Tcl/Tk app with some C code and make it go. I think most of the Linux-using automation market folks out there are like you.

You could look at my product and go "pshhh! I can write my own C code and install my own linux system and buy everything off the shelf and write my own serial drivers and save money and do everything you did plus bring about world peace!" (Ok, so that last one was a stretch). But do you see my point? For you, its easier to write C code and stick together existing pieces than it is to learn someone else's configuration software.

But this isn't true for the great majority of people out there. Most of the people that we talk to are mechanical engineers of some sort, and their focus is making the motors turn and conveyors belts go and the knives cut. They just want an HMI which gets the job done in the shortest amount of time possible.

Alex Pavloff
Software Engineer
Eason Technology
 
Alex makes a point.

I've been in the automation/computer business since 1968, starting by writing simple code then moving into systems work. I shunned personal computers for years as I wanted tools, simple tools, to do the work I most enjoy. I did not want, and never will want, to make writing code a life long work. For me there are many other interesting things to accomplish.

However, I have noticed that there is a hard group of people in automation who enjoy working code and by so doing are very good at providing unique solutions to unique problems.

An amalgam of the two worlds might be the answer.

Provide tools which can be used easily by everyone without the need of learning and working code, tools that also have the openness from which gifted people can extract unique solutions to unique problems.

Bob Pawley
250-493-6146
 
C
That, Bob, is exactly what we are attempting to do. Exactly! But because of lack of familiarity, misperceptions and a good deal of FUD, the feedback I get is that something hosted on Linux can't possibly be easy to use. And any software that someone is willing to give to you can't have any value. And that Windows is somehow important to, and good for, automation and control when it's the least reliable, most problematic OS ever offered and has been for it's history. And lately they are bent on exploiting their monopoly to greatly increase cost. Fortunately, some companies most notably IBM, see this and are busy porting their crown jewels to Linux to offer least cost, Openness and reliability. Their reasoning is that, if given a choice between a Free, Open and reliable OS or an expensive,kinda good enough, but very popular OS, people will do the sensible thing. Bearing the fresh scars of that battle, I think they overestimate people in general. I have been hoping that engineers and technical people are more likely candidates. It's an indirect sell because most folks here use Windows for editing and peripheral functions but use PLCs for control. The combination is "good enough". And they address the Openness issue by simply folding and having all <vendor> shops and simply not doing what <vendor> doesn't want them to do. That leaves cost. Cost is what is responsible for the slump. Cost is responsible for putting out quotes and losing the jobs. And cost isn't very important until no one is doing any capital investment or improvements because it costs too much. Now it's important. How much can you charge people before they say no? How much off the bottom line before you get the job? Would taking all the licenses and software costs off do it? Would commodity networks do it? Would generic hardware do it? Wouldn't charging what was left plus your billable hours do it? And wouldn't _your_ profit be the same? Seems like an idea worth supporting to me.

Regards

cww
 
Top