# Software Quality

V

We are doing some work with Interbase in open source licence. It works well and all I have spent is 149$for the IBPhoenix Developer CD. I am just curious to know why Borland drop the product in the open source community and few months after, continue to sell it. Vincent QUILLET ASALOG FRANCE Tél.: +33 442 94 06 87 Fax : +33 442 94 06 88 e-mail : [email protected] J #### Jiri Baum Michael Griffin: > Where could he turn to for support with his software problems? No where > as far as I could see. He had to solve everything himself. Who *would* he > have talked to? The computer worked. The boards worked. Windows NT > worked. Visual Basic worked. They just didn't work together. > I guess the only solution to this sort of problem is "to have smart > people on staff". Have you got any better ideas? Community support - like this list, or the lists for whichever were the dominant parts of the problem. A couple of years back I think one of these actually won an award for best support'' or support of the year'' or something... > Should we have called Microsoft to complain about their software? Do you > really think that would have helped? It's been suggested that calling MS - and keeping good logs - might be a way of convincing management to drop the damned thing... which may or may not be so, and isn't applicable in the given situation anyway. > I don't know if we would have been any better off using open source > software in this sort of situation. I find it hard to imagine though how > things could have been any worse. The advantage would be that both he and whoever he turns to for support has access to the *whole* of the problem. With proprietary systems, even if you do get someone to look at the problem, Microsoft can't see what's happening in the board driver and the board maker can't see what's happening in VB or Windows. If all the source is open, anyone can look at anything. Jiri -- Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools C #### Curt Wuollet Only if you are ill prepared enough to go on site and try to install on random hardware. He can't possibly do that often or he would know that even with "built for windows" the occasional nightmare occurs. I wouldn't try this without a plan B. Either a known MB I could swap in or a bare bones spare. Anyone that you pay to do PC's should be prepared for this and at least know the configuration is going to work ahead of time. When I do this for business systems, I have them dump and fax the system info to prevent surprises. For testers I specify the hardware to be sure. They can buy it from anyone they want, but my sources are hard to beat. Linux is remarkably good about the basic PC, but most name brand PC's come loaded with Winjunk which isn't desirable even under Windows. I wouldn't spend more than a couple hours with the platform on a customer site. If time is tight, I might bring a hard drive with a working system on it. Unfortunately this doesn't often work with Windows. He should eat the time because he didn't do this homework. Of course, Windows being so much easier to install, I thought this never happened. And if all else fails, I just read the driver source to see what's going on and how to fix it. I would sweat a lot more if I had to depend on "hotlines". Linux and Open Source gives me the power to see that this doesn't happen if I do my part. > This example brings up an interesting question. It has been asked in > the course of this discussion as to where someone would turn to for support > with open source software. And answered unambiguously. For applications built on LPLC for example, your solution provider. For LPLC, the project. The application provider would know everything about the application and the project knows more about LPLC than anyone you will ever get to talk to knows about the commercial products you use now. You not only have greater access to help but the help is of a much higher quality. Quite often you can mail the author. > The fellow mentioned above was using Microsoft Visual Basic with > Microsoft Windows NT, which is of course "closed" and proprietary. Where > could he turn to for support with his software problems? No where as far as > I could see. He had to solve everything himself. Who *would* he have talked > to? The computer worked. The boards worked. Windows NT worked. Visual Basic > worked. They just didn't work together. > > I guess the only solution to this sort of problem is "to have smart > people on staff". Have you got any better ideas? Should we have called > Microsoft to complain about their software? Do you really think that would > have helped? The blame rests squarely on the integrator. Unfortunately, 99% of the project was beyond his control. That's one of the major reasons I use Linux and OSS. I can handle almost anything that can happen and whatever your code does, it can't run any better than the platform it's on. > I don't know if we would have been any better off using open source > software in this sort of situation. I find it hard to imagine though how > things could have been any worse. I have never gone more than 24 hours without a solution to platform problems or at least a definative answer. I very seldom have to ask anyone. Almost all the problems I've seen have been encountered before and the solution is on deja.com or another list. This is better than buying answers from Microsoft or other proprietary vendors. It might be 3 days before you talk to anyone who knows anything and in the meantime the lower echelons insist on doing things that might wreck your installation. Once you know how to use the OSS resources, it really works well. Just as an example, I was updating my standard tester platform and needed a driver for the DAQ card on the 2.4 Linux kernel. I found it and downloaded it, but it wouldn't compile. I politely emailed the author and had the patch and an apology in two hours. I was actually embarrassed by the apology but, this has been typical of my experience with OSS folks. Contrast that with the support you get after paying big bucks for 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. A #### Anthony Kerstens I stand corrected. I should have noted Canadian dollars. From the Rockwell website: RSLogix500 US$1100 -> CDN$1650 + TAX = CDN$1900
RSLogix5 US$3300 -> CDN$4950 + TAX = CDN$5692 If I were to buy the programming bundle that would be CDN$6900.

In sum, I'm about CDN$400 off for separate purchases, and off$1100 for the bundle. That only 14 percent off the mark...

My point is still valid. A big chunk of change has gone out the door for two programs that are not inter-compatible. A third must now be purchased for another big chunk of change, and it
doesn't have the features built into the first two.

Rockwell is just as bad as Oracle.
Hello Rockwell. Is anyone there listening??????

Anthony Kerstens P.Eng.

J

#### Jeffrey D. Brandt

FOUL!
We all should remember the 'triangle of truth' here, if nowhere else. The story below: 'in a hurry' & 'duplicated' (=fast & cheap). So the triangle (good, fast, cheap: pick two, give up the other) is met, and you have CHOSEN to give up GOOD. YOUR CHOICE!
The poor integrator is simply doing what you tell him. He is eating all the costs to make the job work, so he gets a chance to do the next one. NO FAIR picking on this integrator, IMhO.
jDb

A

#### Alex Pavloff

Curt, some of what you say has merit, but I've got some issues with the rest...

> Only if you are ill prepared enough to go on site and try to
> install on random hardware. He can't possibly do that often or he would
know that
> even with "built for windows" the occasional nightmare occurs. I
> wouldn't try this without a plan B. Either a known MB I could swap in or a
bare
> bones spare. Anyone that you pay to do PC's should be
> prepared for this and at least know the configuration is going to work
> When I do this for business systems, I have them dump and fax
> the system info to prevent surprises. For testers I specify the hardware
to be
> sure. They can buy it from anyone they want, but my sources
> are hard to beat.

This advice should be followed by everyone using PCs!

> I wouldn't spend more than a couple hours with the platform on a
> customer site. If time is tight, I might bring a hard drive with a
> working system on it. Unfortunately this doesn't often work with
> Windows.

Get a system like Ghost, and it works EVERY TIME. Curt, you know about Linux, but your Windows knowledge, understandably, is lacking. You say you haven't used Windows since what, 1997. Your qualifications in this area are slim, and when you turn around to bash Windows for sucking, you miss the mark sometimes.

> Just as an example, I was updating my standard tester platform
> and needed a driver for the DAQ card on the 2.4 Linux kernel.
> I found it and downloaded it, but it wouldn't compile. I politely
> emailed the author and had the patch and an apology in two hours.
> I was actually embarrassed by the apology but, this has been
> typical of my experience with OSS folks. Contrast that with the
> support you get after paying big bucks for it.

I don't think everyone is willing to slap a two-hour fix into their system without testing. I don't know of your case, so it might have been a simple fix that didn't need it. However, keeping up with the 0.1,0.2,0.3... etc revs of many Linux projects can cause problems too.

Alex Pavloff
Software Engineer
Eason Technology

V

Hello List,

Excellent article. Thanks.

Just a remark:

The discussion rolls mostly around M$vs Lynux topic... but it seems to me, the problem is more deep... 1. Base economic problem: to survive the vendors need to make _bad_ enough software... to keep their users in the unsatisfied state... etc. 2. Revolution problem: MS has begun Revolution. XP(eXtreme Programming), - the "new paradigm", - establishes the "bad enough software" philosophy as an official religion. Vladimir. == OK. Hayek rulez... but what is the direction? -- Best regards, Vladimir A #### Alex Pavloff > 1. Base economic problem: to survive the vendors need to make _bad_ enough > software... to keep their users in the unsatisfied state... etc. Well, again, what we have is hardware companies selling software. The software is secondary to the tasks, so "good enough" usually means things that will work. Fixing those 5 year old bugs that "everyone knows about" and improving usability isn't a priority for something that's traditionally been an afterthought. "Bad software" is very rarely intentional. > 2. Revolution problem: MS has begun Revolution. XP(eXtreme Programming), - > the "new paradigm", - establishes the "bad enough software" philosophy as an official > religion. The XP Microsoft Windows XP and Office XP is a marketing shorthand for "eXPerience". This has nothing to with the "Extreme Programming" methodology, which is also known as XP. We're running out of acronyms. We'd better start using non-english characters to avoid confusion. D #### David McGilvray Michael, Yes, I agree, most if not all consumers are better off buying a complete system. The fact that choice is available, however, I would argue, contributes to greater competition and leads to better products at a lower price. And, of course, if some of those components are free to the vendor, the overall system price can be expected to be that much lower. For those hobbyists, or systems integrators, to put things into perspective, downloading software, or purchasing on CD, ("scrounged" from your local sales rep, distributor or other normal channels that any other product is procured) and buying a computer separately (I suggest buying new rather than going the surplus route) is about the same effort as loading any popular word processor package on separately purchased PC hardware (or similar to the effort required to integrate a PLC, MMI and PC system). That is, not much. David McGilvray M&R Automation M #### Michael Griffin We asked the integrator if they could do it in the time window allowed to us by our customer. The integrator said "yes, they could do it". We proceeded on that basis. It may have been "fast", but it was definitely not "cheap". The integrator was very generously paid for quick turn around. If you say you can do something, and demand a stiff price for it, don't complain when you are asked to deliver on your promises. The integrator's mistake was to assume that the PC and operating system would not be the source of any problems. They picked up the PC (from their supplier) on the way to our place. We didn't like them leaving the testing of the PC until the last moment, but it was a rush project and we assume that they know their business. They don't need us driving from the back seat. The problem arose in that Windows NT had various unexpected compatability problems with the combination of hardware (it appears to be related to the particular model of motherboard used - one which they selected). I think there is a lesson to be learned from this. It seems to be a mistake to assume that just because Windows NT is fairly common as an operating system and that Visual Basic is a common development package, that any problems involved in using them have already been ironed out long ago. This does not seem to be the case. This is not the only minor disaster I have seen due to Windows "mysteries". If you are developing applications in Visual Basic for Windows NT, you had better have "good people on staff" (to paraphrase a previous writer). You can probably whip something together without really knowing what you are doing and not have any problems, but you can't count on it. I think the story I related is a good example of what can go wrong. The biggest complaint I hear from integrators is the lack of useful information about how Windows actually works. Most of them are reduced to guessing and poking in the dark. There may be a thousand books at the local "Chapters" book store on Windows NT, but not a single one of them has proved to be of any use to someone constructing the sort of applications we need. Perhaps our applications are asking too much of the operating system (Windows) our integrators have been using for us. We began as adherants of the conventional philosophy of using "readly available" office PCs and operating systems. DOS seemed to work satisfactorily in its day. The more recent results have been discouraging. This has caused us to question our original assumptions. So far we have not tried any alternatives, but we are thinking about them very hard indeed. It is no good as you have done to simply blame the schedule. This is the world we have to live in. We have customers too, and they have no patience what so ever. One of our customers in Europe wanted an immediate turn around on a very large order. We have an obligation to serve our customers which we take very seriously. This equipment was to deal with that. We also have our component suppliers, and they have their own delivery problems. We have to work around those as well. One of our component suppliers (located in Taiwan) encountered quality problems with one of their suppliers of chemicals (located in the USA). The normal solution would have been air freight, but due to recent events in the United States they discovered that they are no longer allowed to ship large quantities of flammable chemicals in aircraft from American suppliers. The gentleman who created that particular situation neglected to inform us of it in advance. An oversight, I'm sure. Welcome to the global economy. ********************** Michael Griffin London, Ont. Canada ********************** K #### Kinner, Russ I certainly agree with Jeffery that ICOM was very good, but I worked with an even better programming package before ICOM. WRB Associates marketed their "LADDERS" package in the early 80's which allowed up to 15 lines of 13 characters for every logic element, free space commenting (anywhere there was a "white space" you could add comments), compatibility with multiple vendors and the ability to copy logic between vendors (what many thought IEC 1131 was going to do), and there was more. Unfortunately, they used the best and quite expensive computer available for the task at the time, a PDP-11/34. Between the$20K price tag and a platform that was
not mainstream, they quietly faded away by 1990. They just were too far ahead of the curve for most management to accept the cost vs. performance.

I worked on a Modicon 584 installed in a steel plant programmed in LADDERS and was able to combine the work from 6 different programmers into one processor. Today that is expected from a decent programming package but in 1984 it saved countless hours and our tight schedule I was able to have a number of programming tasks happening in parallel and combined them at the last minute.

I never heard what happened to Bill Boyd and his staff after the PC took over and the company folded. Anyone who might have an idea where the guys are can contact me off list.

Russ Kinner
AVCA Corporation
Maumee, OH, USA

J

#### Johan Bengtsson

So if you buy a PLC and you get the source code for the PLCs internal operation with it (or even you didn't get it but you got a link to where you could download it if you like) would that PLC be worth less and harder for you to use because of that?

/Johan Bengtsson

----------------------------------------
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/
----------------------------------------

J

#### Johan Bengtsson

So if you buy a PLC and you get the source code for the PLCs internal operation with it (or even you didn't get it but you got a link to where you could download it if you like) would that PLC be worth less and harder for you to use because of that?

/Johan Bengtsson

----------------------------------------
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/
----------------------------------------

M

#### Michael Griffin

>Only if you are ill prepared enough to go on site and try to install on
>random hardware. He can't possibly do that often or he would know that
>even with "built for windows" the occasional nightmare occurs.

This was their mistake - with the mitigating circumstance of the limited time available, and their PC supplier was late (of course).

>I wouldn't
>try this without a plan B. Either a known MB I could swap in or a bare
>bones spare. Anyone that you pay to do PC's should be prepared for this
>and at least know the configuration is going to work ahead of time.
<clip>

A known motherboard? How do you do that? If you use "standard" office PC style motherboards, you generally find that they go obsolete so fast you can't buy two in a row that are exactly the same.
You must either have a source of motherboards that changes their design very little over time, or you must have an operating system that is very tolerant of different hardware. I find Windows NT's fussiness particularly surprising considering that the motherboard suppliers (and the chip designers) are designing their products with Windows in mind.

>The blame rests squarely on the integrator. Unfortunately, 99% of the
>project was beyond his control. That's one of the major reasons I use
>Linux and OSS. I can handle almost anything that can happen and
>whatever your code does, it can't run any better than the platform it's
>on.

Yes in one sense, the blame lies with the integrator. However, I see the problems they routinely face, and they are not what I consider to be "value added" activities. These guys are supposed to be solving *testing* problems, not Windows problems. It isn't just one company, or just integrators. I see OEMs having the same difficulties.
For example, they want to fix a bug, but they upgraded their compiler since the last time they worked on it. Now it's no longer compatable with the database, so that has to be upgraded. That in turn affects something else, which also needs an upgrade. Now we need a memory or hard drive upgrade because of all the software upgrades.
One minor software incompatability leads to a chain reaction of cascading upgrades through the whole system. They plan on one "minor" change and find themselves being pulled in by an undertow whose existence they never suspected. How do you plan anything in an enviroment like that?

**********************
Michael Griffin
**********************

B

#### Bill Sturm

> A known motherboard? How do you do that? If you use "standard"
>office PC style motherboards, you generally find that they go obsolete so
>fast you can't buy two in a row that are exactly the same.

I have started using Avantech CPU boards with Intel's "embedded" chipset and CPU. It has been pledged for a minimum of five years supply. It is a 266MMX and a TX chipset. It works fine with our software. The CPU is surface mounted and doesn't require a fan. The price is reasonable also. Very cool. No pun intended...

I think Contec also has long design life systems like these. More vendors should do this.

Bill Sturm

A

#### Alex Pavloff

No, but if "the source is available" is used as an excuse to skimp on documentation, then it is worth less and harder to use.

I think I speak for many people on this group when I say "Give me a big thick paper manual."

Alex Pavloff
Software Engineer
Eason Technology

P

#### Paul T

I agree with Bill- I used to do something similar at my last job. Every year, we would select and document a motherboard and supporting hardware
(video card, drives, modem, NIC, etc.) for machines used that year. At least that way, we knew what the base was in future and had a starting point for upgrades or compatibility issues. In a couple of cases, I supplied spare motherboards and CPUs to some customers that they stocked as spares in their facility.

Paul T

M

#### Michael Griffin

Are you sure you were replying to the correct message? I believe the discussion was on the cost of assembling, configuring, testing, and
documenting your own controller versus buying one with that already done (e.g. as with the PLC you mentioned).

My original message (from which Mr. McGilvray quoted) made the point that someone using a controller which has open source software would probably be better off buying an off the shelf system rather than putting their own together (at least for typical PLC type applications). This means there should be a market for OEMs (although not necessarily traditional PLC manufacturers) to build these systems. I'm sure I could do it myself, but why would I want to - or rather, why would anyone want to pay me to do so?

Perhaps in the types of industries which Mr. McGilvray serves (mining, smelting, and forest products if I recall), the economics may be
different. However, for most of my applications I need to be able to flip open a catalogue and pick out a controller by I/O and features count and
have an electrician install it after it arrives. The only software I should have to worry about is writing the PLC program to make the machine go. It
just isn't economic to spend any more time on it.

The last time I bought a car, I just went to the dealer and bought a car. I didn't shop around at the wreckers' to find the parts to make my own. I think that most people would do the same.

**********************
Michael Griffin
**********************

J

#### Jiri Baum

Alex Pavloff:
> No, but if "the source is available" is used as an excuse to skimp on
> documentation, then it is worth less and harder to use.

Obviously. At the MAT project are well aware that this is our greatest weakness at this point, and the biggest task we must address before a full
release.

> I think I speak for many people on this group when I say "Give me a big
> thick paper manual."

The PDF file is at 32 pages right now. I guess 10-20x that much would be about the right thickness?

Jiri
--
Jiri Baum <[email protected]> http://www.csse.monash.edu.au/~jirib
MAT LinuxPLC project --- http://mat.sf.net --- Machine Automation Tools

M

#### Michael Griffin

Bill Sturm wrote:
<clip>
>I have started using Avantech CPU boards with Intel's "embedded" chipset
>and CPU. It has been pledged for a minimum of five years supply. It is a
>266MMX and a TX chipset. It works fine with our software. The CPU is
>surface mounted and doesn't require a fan. The price is reasonable also.
>Very cool. No pun intended...
>
>I think Contec also has long design life systems like these. More vendors
>should do this.
<clip>

I have just spent the past couple of days going over various catalogues and web sites for information about industrial computers. I have
been asked to research industrial computers to set some sort of standard for our custom applications. We are fed up with office type desk-top computers, regardless of what type of box they get put in. The latest fiasco was the
last straw for us.

So far I liked what I saw in Advantech's literature the best. I am looking at:

a) passive backplane (14 slot - some mix of ISA and PCI),
b) (I forget the chassis prefix) 616 chassis,
c) redundant 250W power supplies,
d) a 6178 or 6179 (I think those are the numbers) full length CPU card,
e) the hardware RAID package (mirrored drives).

I haven't added it up yet to see if it all goes together, and if the power supply is big enough. However, I have a few questions which I wonder if you might anwswer.

Have you used any of the above hardware, or at least anything similar to them (from Advantech)? If so, would you do the same thing again?

What would you generally say about Advantech in terms of how good is their

1) reliability of hardware,
2) support,
3) delivery on new systems,
4) delivery on spares,
5) etc.?

I was asked to look into passive backplane because of the difficulty of getting conventional motherboards with enough slots, and slots of the right type.

The 616 chassis looks good for features and diagnostics (and I think it fits into our existing equipment). The redundant power supplies are intended to make power supply replacement easier (we don't really need the redundancy). The CPU cards had the right features and looked modern enough to be around for a while.

The hardware RAID package looks interesting (if we can use it). It fits in one full height bay and is operating system independent.

We have found that just keeping a back-up hard drive on the shelf doesn't work, as making the back-up after any changes (e.g. software
versions, parameter changes, etc.) is such a pain that people will always do it "later" (i.e., never). We have never yet found a back-up hard drive to be up to date when we needed it. The RAID system ought to solve this, as the "back-up" is always installed and up to date.

**********************
Michael Griffin