Troubled by rigorous theory vs. "seat of your pants" control

[Tim Wescott]

Terry Given wrote:

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109i3cibrv4brb9@corp.supernews.com...

Terry Given wrote:
-- snip --
yes. many companies have gotten in the crap by sampling too fast, either
because of the required filter resolution (well spotted!) or computational
overhead.

cheers
Terry

Well spotted? It's an issue that only seems trivial to those who have
yet to be bitten by that particular dog.

Note that the advise was for a (presumed) high-volume application. For
a low-volume application you should just spend tons of money on the
processor, sample fast, and pay for it all with the reduced engineering
time.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Terry Given]

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109j5p5cok7io6e@corp.supernews.com...

Terry Given wrote:

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109i3cibrv4brb9@corp.supernews.com...

Terry Given wrote:
-- snip --
yes. many companies have gotten in the crap by sampling too fast, either
because of the required filter resolution (well spotted!) or
computational
overhead.

cheers
Terry


Well spotted? It's an issue that only seems trivial to those who have
yet to be bitten by that particular dog.

had I been less lazy, I would have written (well worth mentioning) instead.
I certainly wont forget my run-ins with this particular dog.

[for edification of others:]
Its not just filters, of course. Any integrator has this problem - for the
same time-domain response, as an integrator runs at a faster rate, the
amount it accumulates each time must get smaller. A simple hand calculation
shows this:

y(k*Ts) = x(k*Ts) + y((k-1)*Ts)

is a discrete integrator at sample rate Ts (often the *Ts is left omitted,
for "clarity" ie spreading confusion)

choose y(0)=0, x(k*Ts) = 1

the output is of course:
1 t=1*Ts
2 t=2*Ts
3 t=3*Ts
4 t=4*Ts
5 t=5*Ts
6 t=6*Ts
.....

sample at twice the rate Ts' = Ts/2, and the output is
1 t=1*Ts'
2 t=2*Ts' = 1*Ts
3 t=3*Ts'
4 t=4*Ts' = 2*Ts
5 t=5*Ts'
6 t=6*Ts' = 3*Ts
.....

which can be written as
2 t=1*Ts
4 t=2*Ts
6 t=3*Ts
.....


so for the same output response with twice the sample rate we would need:

y(k*2*Ts) = x(k*2*Ts) + 0.5*y((k-1)*2*Ts)

presuming I havent made a mistake, the general solution for some new sample
time Tx is:

y(k*Tx) = x(k*Tx) + (Ts/Tx)*y((k-1)*Tx)

filters and the like get even trickier - quantisation restricts the possible
locations of poles/zeroes, which can make theoretically stable filters
unstable. Bucketloads of work has been done on trying to figure out what
resolution is required for any given job....Peter Brackett can probably
inform us further.....

Note that the advise was for a (presumed) high-volume application. For
a low-volume application you should just spend tons of money on the
processor, sample fast, and pay for it all with the reduced engineering
time.

Tim Wescott

hell yes. Some of these "whiteware" DSPs have amazing features, for <
US$10 - if you look carefully. Alas, most "designers" simply use the chip
they are most familiar with (plenty of merit in this approach, if the chip
is suitable)

 

[N. Thornton]

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c7b3fk0kp9@news2.newsguy.com>...

Ken Smith wrote:

Now how to get the computer programmer and mechanical engineer to
understand all this?

Perhaps you can't.

It strikes me that your app needs control that will meet certain
specs. And if it gets one designed by peeing in the wind, there is no
way to know if it will meet those specs. And if it seems to work there
will still be no way to know how it may misbehave under certain
conditions, nor to draw up its real performance specs, nor to assess
how it will behave with another machine of near but not identical
performance. Thus a pee in the wind approach is not going to meet the
requirements of the task.

That looks to me like a simple concept that any engineer will follow
with ease.

Regards, NT

 

[Rich Grise]

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c7bgb40sf0@news3.newsguy.com...

There, in plain public view, I have admitted my wrongness.

This is what grownups do.

Cheers!
Rich

 

[Chris Carlen]

N. Thornton wrote:

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message news:<c7b3fk0kp9@news2.newsguy.com>...

Ken Smith wrote:



Now how to get the computer programmer and mechanical engineer to
understand all this?


Perhaps you can't.



It strikes me that your app needs control that will meet certain
specs. And if it gets one designed by peeing in the wind, there is no
way to know if it will meet those specs. And if it seems to work there
will still be no way to know how it may misbehave under certain
conditions, nor to draw up its real performance specs, nor to assess
how it will behave with another machine of near but not identical
performance. Thus a pee in the wind approach is not going to meet the
requirements of the task.

That looks to me like a simple concept that any engineer will follow
with ease.

Regards, NT

Exactly. This is why I like to learn the background theory behind a
subject and be able to model and understand it, instead of "cookbook"
engineering a solution that may work but I don't know why.

Good day!


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Chris Carlen]

Rich Grise wrote:

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c7bgb40sf0@news3.newsguy.com...


There, in plain public view, I have admitted my wrongness.



This is what grownups do.

Uh-oh. Now I'm *really* assiciated with bad company ;-)


--
____________________________________
Christopher R. Carlen
Principal Laser/Optical Technologist
Sandia National Laboratories CA USA
crcarle@sandia.gov

 

[Paul Hovnanian P.E.]

Terry Given wrote:

[snip]

lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning controllers, a
jolly good trick). I have watched plenty of guys tune motor controller PID
loops in industry, and they ALL do it "empirically" ie by making it up as
they go along, often for no apparent reason (usually based on what has
worked before).

If the symptoms of an unstable control system aren't serious, that
approach will work. But see how many fly-by-wire flight control systems
they'll let you tweak until the damn thing stays airborne.

Sadly, the software people are winning the battles in many companies.
One day, they are Cobol programmers working for the finance department,
the next they are implementing autopilots.

--
Paul Hovnanian mailtoaul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
>> Insert witty message here <<

 

[Terry Given]

"Paul Hovnanian P.E." <Paul@Hovnanian.com> wrote in message
news:409A889D.C3CB8BA6@Hovnanian.com...

Terry Given wrote:

[snip]

lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning
controllers, a
jolly good trick). I have watched plenty of guys tune motor controller
PID
loops in industry, and they ALL do it "empirically" ie by making it up
as
they go along, often for no apparent reason (usually based on what has
worked before).

If the symptoms of an unstable control system aren't serious, that
approach will work. But see how many fly-by-wire flight control systems
they'll let you tweak until the damn thing stays airborne.

Sadly, the software people are winning the battles in many companies.
One day, they are Cobol programmers working for the finance department,
the next they are implementing autopilots.

--
Paul Hovnanian mailtoaul@Hovnanian.com

yeah, it only tends to happen where there arent hugely adverse consequences.
classical SISO control is a mature field, you shouldnt have to guess. I once
worked with a system whereby the programmer had, independantly, invented the
proportional controller (not that he would believe it) and had the lowest
gain possible (every loop he would add 1 to output if input > setpoint etc).
Funnily enough the performance was crap. but do you think I could get the
guy to open a control systems text, or implement a different gain, or even ,
PI controller - now way! In the end I gave up, and left the programmer
suffer the consequences (project slippage, eventually cancellation) of his
stupidity. Warning management didnt help either.

Cheers
Terry

 

[Tim Wescott]

Terry Given wrote:

"Chris Carlen" <crobc@BOGUS_FIELD.earthlink.net> wrote in message
news:c79o7h01aio@news3.newsguy.com...

Greetings:

You might want to first look at my posting "Estimating servo loop
bandwidth and sampling rate" to understand where I am coming from with
this post.

I have been slowly piecing together bits of understanding about the
subject of feedback control systems not having yet engaged in a formall
study of the subject. Most of what I know was gleaned from the "Art of
Electronics", and I am now attempting to apply it to the planning of a
new project. Trouble is, a computer programmer that I work with sees
things differently, and also has somewhat more experience than I. But I
think he has little theoretical understanding. I keep talking about
closed-loop bandwidth, and sampling rates needed (for DSP based servo
control) to avoid incurring undesirable added phase margins to both him
and a mechanical engineer who needs the final product. The programmer's
response is: "you can study control theory all day, but in the field
nobody ever uses that stuff. They just use heuristic algorithms to set
parameters, and that's it..." They seem to think I am speaking greek
when I talk in classical control theory language.

Trouble is, I think this guy has most of his experience with process
control in industrial environments with several Hz maximum system BW.


lots of studies have been done on the effect of automated control in
industry. They all end up saying about the same thing - 1/3 of all
controllers improve processes, 1/3 have no net effect, and 1/3 make the
process substantially worse. And the reasons are always the same - badly
tuned controllers (this has fueled the demand for self-tuning controllers, a
jolly good trick). I have watched plenty of guys tune motor controller PID
loops in industry, and they ALL do it "empirically" ie by making it up as
they go along, often for no apparent reason (usually based on what has
worked before).


-- snip --

I was in a local panel discussion a few years ago about control systems
where the panel consisted of me (custom embedded motion control
designer), a software engineer who specialized in GUI's for embedded
controllers, and a process control engineer for one of the local forest
products company.

It turns out that at most mills those controllers must be tuned by union
millwrights -- the engineer who specifies them _may not_ touch the
knobs, lest they be taking bread out of an honest workingman's mouth
(you can tell I'm highly pro-union, eh?). Furthermore, it's the
_millwright_ who decides when and how the controller should be tuned, so
if the 3rd-shift guy gets drunk and @#$%s it up it may not be discovered
for days.

That having been said there is a fairly good empirical method for tuning
a PID loop that generally works if you can stop yourself from trying for
too much performance. It's detailed in my paper "PID Without a PhD"
which you can get to from
http://www.wescottdesign.com/articles/pidwophd.html. Using this method
_will not_ give you an optimal tune, and it doesn't guarantee the
world's best phase and gain margins, but if done carefully and
responsibly it's a heck of a lot better than nothing.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Joel Kolstad]

Terry Given <the_domes@xtra.co.nz> wrote:

I once worked with a system whereby the programmer had,
independantly, invented the proportional controller (not that he would
believe it) and had the lowest gain possible (every loop he would add 1
to output if input > setpoint etc).

Actually, this is an integral-only system. I've used them myself... for
stuff like heaters/lightbulbs where I _wanted_ the aesthetic effect of being
able to see something heat up. I imagine my loop bandwidth was down around
0.1Hz?

Funnily enough the performance was
crap. but do you think I could get the guy to open a control systems
text, or implement a different gain, or even , PI controller - now way!

I don't believe people with comp. sci. degree necessarily ever take anything
resembling a control course these days? Even if you did get him to open a
book, at the first sign of a Laplace or Fourier transform of the use of
phasors he would have run screaming from the room.

 

[Tim Wescott]

Joel Kolstad wrote:

Terry Given <the_domes@xtra.co.nz> wrote:

I once worked with a system whereby the programmer had,
independantly, invented the proportional controller (not that he would
believe it) and had the lowest gain possible (every loop he would add 1
to output if input > setpoint etc).


Actually, this is an integral-only system. I've used them myself... for
stuff like heaters/lightbulbs where I _wanted_ the aesthetic effect of being
able to see something heat up. I imagine my loop bandwidth was down around
0.1Hz?


Funnily enough the performance was
crap. but do you think I could get the guy to open a control systems
text, or implement a different gain, or even , PI controller - now way!


I don't believe people with comp. sci. degree necessarily ever take anything
resembling a control course these days? Even if you did get him to open a
book, at the first sign of a Laplace or Fourier transform of the use of
phasors he would have run screaming from the room.

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

--

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

 

[Paul Hovnanian P.E.]

Tim Wescott wrote:

[snip]

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

At the behest of most corporations, computer science is
compartmentalized and kept apart from any other discipline. Not only
engineering, but finance, manufacturing, etc. are kept separate from
software development. Its back to the old days, with computers in back
rooms, tended to by armies of technicians with white coats, because
nobody else could possible understand how a computer works. ;-)

In reality, this seems to be a reaction to the (perceived) high cost of
software skills. Attempts are made to separate hardware and software so
that the software development could be put out for bid and (hopefully) a
few bucks shaved off the project.

--
Paul Hovnanian mailtoaul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
Sacred cows make the best hamburger. -- Mark Twain

 

[Rich Grise]

"N. Thornton" <bigcat@meeow.co.uk> wrote in message
news:a7076635.0405060332.bce4716@posting.google.com...

Chris Carlen <crcarle@BOGUS.sandia.gov> wrote in message
news:<c7b3fk0kp9@news2.newsguy.com>...
Ken Smith wrote:


Now how to get the computer programmer and mechanical engineer to
understand all this?

Perhaps you can't.


It strikes me that your app needs control that will meet certain
specs. And if it gets one designed by peeing in the wind, there is no
way to know if it will meet those specs. And if it seems to work there
will still be no way to know how it may misbehave under certain
conditions, nor to draw up its real performance specs, nor to assess
how it will behave with another machine of near but not identical
performance. Thus a pee in the wind approach is not going to meet the
requirements of the task.

That looks to me like a simple concept that any engineer will follow
with ease.

I designed an SCR phase-controlled battery charger using the timer
in a 68HC11 once. It hunted. So, I was all set to start screwing
around with various transfer functions and stuff in firmware, and
while I was mulling, my client went over and clipped a .47 cap from
the sense line to ground. It stopped hunting, so changed that part
of the design. I don't think he sold any - it was too expensive, and
apparently people who have to recharge fleets of forklifts don't
really care about 3 programmable levels of charge profile. )-;

Cheers!
Rich

 

[Terry Given]

"Paul Hovnanian P.E." <Paul@Hovnanian.com> wrote in message
news:409BD25A.B7E75F72@Hovnanian.com...

Tim Wescott wrote:

[snip]

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

At the behest of most corporations, computer science is
compartmentalized and kept apart from any other discipline. Not only
engineering, but finance, manufacturing, etc. are kept separate from
software development. Its back to the old days, with computers in back
rooms, tended to by armies of technicians with white coats, because
nobody else could possible understand how a computer works. ;-)

In reality, this seems to be a reaction to the (perceived) high cost of
software skills. Attempts are made to separate hardware and software so
that the software development could be put out for bid and (hopefully) a
few bucks shaved off the project.

Paul Hovnanian mailtoaul@Hovnanian.com
----------------
Sacred cows make the best hamburger. -- Mark Twain

Interesting. multi-disciplinary education is pretty much mandatory for an
engineer, we have to talk to all sorts of people - electrical, mechanical,
civil, thermal, control, chemical, computing, finance, quality......

I am constantly amazed (and disgusted) at the piss-poor performance of
virtually all software. Some software (matlab springs to mind) is absolutely
brilliant - robust, reliable and they fix problems. Most sw however is just
shit. I have lost count of the number of times I read sw documentation that
says "pull down the Blah menu" only to discover it doesnt even
exist.....Mathcad or protel users will no doubt have plenty to say about
this.....

as part of my EE education I studied sw engineering for 3 years. We learned
that abotu 80-90% of all software projects NEVER work/are completed/are
delivered. clearly programmers dont learn project management.

I actually think the problem is very subtle - sw is LICENSED, not sold. Most
countries have consumer protection laws that require stuff to actually do
the job it is sold for. Because sw isnt sold, these laws do not apply, and
the first bit in any sw EULA says, in effect, that the software may or may
not work properly, and too bad if it doesnt. People dont put up with this
shit from any other branch of engineering.

I would actually argue that sw performance is SO BAD it doesnt deserve to be
called engineering. This is despite the fact that the techniques for writing
good code have been well known for decades (just like the tricks for good OS
design .

My experience working with comp. sci. grads is that they know lots about
APIs etc. but fuck all about design. how to write sw functions is not too
much of an issue - the real important question is what to do (witness
Outlook and its stupid database structure for emails. I mean Duh, what the
hell is the disk OS doing.....)

I'd better stop ranting now, before I get carried away and turn out a
Kazinski-esque diatribe.....

(my favourite quote from the clinton/lewinski affair, other than "close but
no cigar" is a little limerick that won a contest rhyming lewinski and
kazinski:

Clinton and Lewinski have shown,
what Ted Kazinski has long since known,
that an intern is better,
than a bomb in a letter,
given the chance to be blown.

cheers
Terry

 

[Rich Grise]

"Paul Hovnanian P.E." <Paul@Hovnanian.com> wrote in message
news:409A889D.C3CB8BA6@Hovnanian.com...

Sadly, the software people are winning the battles in many companies.
One day, they are Cobol programmers working for the finance department,
the next they are implementing autopilots.

Speaking of COBOL, I've only had a couple of encounters with it. One
was when a contract programmer came in to do the company's bookkeeping
software - I spotted some COBOL on her screen one day, and I mused,
to the office in general, "Why do I get the feeling that I'm watching
her try to create a mnemonic memory device using stone axes and
animal skins?"

The other time there was a gal who asked if I could tutor her, but it
turned out to be a ruse - she just wanted to get in my knickers. ;-)

Cheers!
Rich

 

[Rich Grise]

"Tim Wescott" <tim@wescottnospamdesign.com> wrote in message
news:109m2sd3e77evba@corp.supernews.com...

Computer science still avoids control. Most universities no longer have
EE departments, however, they're "Electrical and Computer Engineering"
departments. This doesn't mean that people learning 'C' are learning
filters, but it's something.

Oh, I don't use 'C' for filters any more, since I got Linux. Now
I just use grep.

;->
Rich

 

[Paul Hovnanian P.E.]

Terry Given wrote:

[snip]

My experience working with comp. sci. grads is that they know lots about
APIs etc. but fuck all about design. how to write sw functions is not too
much of an issue - the real important question is what to do (witness
Outlook and its stupid database structure for emails. I mean Duh, what the
hell is the disk OS doing.....)

There seems to be a philosophy aimed at keeping software development
apart from all other disciplines. In the companies I have worked at,
software engineers were supposed to be interchangeable, between the
accounting department and flight controls engineering. In order to
encourage this level of portability, it was necessary to make sure that
the software people never obtained significant levels of domain
knowledge.

Engineers (electrical, mechanical, etc.) were taught software skills to
use as tools. In order to use a tool, you have to understand the
application to which you are applying it. Pure software engineering is
like learning how to use a socket wrench without bothering to learn how
an auto engine works.


--
Paul Hovnanian mailtoaul@Hovnanian.com
note to spammers: a Washington State resident
------------------------------------------------------------------
There was a man who entered a local paper's pun contest. He sent in ten
different puns, in the hope that at least one of them would win.
Unfortunately, no pun in ten did.

 

[onestone]

Terry Given wrote:

I am constantly amazed (and disgusted) at the piss-poor performance of
virtually all software. Some software (matlab springs to mind) is absolutely
brilliant - robust, reliable and they fix problems. Most sw however is just
shit. I have lost count of the number of times I read sw documentation that
says "pull down the Blah menu" only to discover it doesnt even
exist.....Mathcad or protel users will no doubt have plenty to say about
this.....

as part of my EE education I studied sw engineering for 3 years. We learned
that abotu 80-90% of all software projects NEVER work/are completed/are
delivered. clearly programmers dont learn project management.

I actually think the problem is very subtle - sw is LICENSED, not sold. Most
countries have consumer protection laws that require stuff to actually do
the job it is sold for. Because sw isnt sold, these laws do not apply, and
the first bit in any sw EULA says, in effect, that the software may or may
not work properly, and too bad if it doesnt. People dont put up with this
shit from any other branch of engineering.

How screwed up this situation really is came to light about a year ago.
Here in Australia we have some fairly solid consmer laws. We also have a
software retail industry that refuses to refund or accept returns of
software for any reason. The fear being that you've illegally copied the
code and now want your money back. This backfired, and revealed a hole
in the entire licensing process. Since the License is invariably
contained on the installation disk, and since it cannot be read until
installation, the law deems it unreasonable to expect a purchaser to
agree to something they haven't yet been able to see or evaluate when
their is no recourse should you not acceopt the license. ie if they
won't refund my money because I don't accept the license then the law
deems me to have bought the software, since the license terms were not
made known to me until after purchase, I am the owner of that software,
and therefore free to do as I please with it. Including making and
selling copies. Of course you'd better have deep pockets , or be a
lawyer to push this, unless, as in my case I had the Australian consumer
council fighting for me. Under Australian law the retailer, not the
manufacturer of the product is my poj tof legal redress. Therefore if a
legally appointed retailer will not refund your purchase price when the
license proves to be unacceptable the manufacturer can do nothing about
it. Even were the license made available to read prior to purchase, it
is not a reasonable license unless opportunity is given to first
evaluate the product.

I would actually argue that sw performance is SO BAD it doesnt deserve to be
called engineering.

Absolutely agree 100%. Software engineer on a job application normally
merits file 13.

Al

This is despite the fact that the techniques for writing
good code have been well known for decades (just like the tricks for good OS
design .

My experience working with comp. sci. grads is that they know lots about
APIs etc. but fuck all about design. how to write sw functions is not too
much of an issue - the real important question is what to do (witness
Outlook and its stupid database structure for emails. I mean Duh, what the
hell is the disk OS doing.....)

I'd better stop ranting now, before I get carried away and turn out a
Kazinski-esque diatribe.....

(my favourite quote from the clinton/lewinski affair, other than "close but
no cigar" is a little limerick that won a contest rhyming lewinski and
kazinski:

Clinton and Lewinski have shown,
what Ted Kazinski has long since known,
that an intern is better,
than a bomb in a letter,
given the chance to be blown.

cheers
Terry

--
Please remove capitalised letters to reply
My apologies for the inconvenience
Blame it on the morons that spam the net

 

[Guy Macon]

onestone <onestoneXYZ@ABCbigpond.net.au> says...

Since the License is invariably
contained on the installation disk, and since it cannot be read until
installation, the law deems it unreasonable to expect a purchaser to
agree to something they haven't yet been able to see or evaluate when
their is no recourse should you not acceopt the license. ie if they
won't refund my money because I don't accept the license then the law
deems me to have bought the software, since the license terms were not
made known to me until after purchase, I am the owner of that software,
and therefore free to do as I please with it. Including making and
selling copies.

That last bit would be in violation of the Universal Copyright Convention
(UCC) and the Berne Convention for the Protection of Literary and Artistic
Works (AKA the WIPO Copyright Treaty). Austalia signed both treaties.

--
Guy Macon, Electronics Engineer & Project Manager for hire.
Remember Doc Brown from the _Back to the Future_ movies? Do you
have an "impossible" engineering project that only someone like
Doc Brown can solve? My resume is at http://www.guymacon.com/

 

[Terry Given]

"Guy Macon" <http://www.guymacon.com> wrote in message
news:O4qdnYR-C53e-TLdRVn-tA@speakeasy.net...

onestone <onestoneXYZ@ABCbigpond.net.au> says...

Since the License is invariably
contained on the installation disk, and since it cannot be read until
installation, the law deems it unreasonable to expect a purchaser to
agree to something they haven't yet been able to see or evaluate when
their is no recourse should you not acceopt the license. ie if they
won't refund my money because I don't accept the license then the law
deems me to have bought the software, since the license terms were not
made known to me until after purchase, I am the owner of that software,
and therefore free to do as I please with it. Including making and
selling copies.

That last bit would be in violation of the Universal Copyright Convention
(UCC) and the Berne Convention for the Protection of Literary and Artistic
Works (AKA the WIPO Copyright Treaty). Austalia signed both treaties.

--
Guy Macon, Electronics Engineer & Project Manager for hire.

Guy is right. But, the license (usually) prevents you from on-selling the
sw, which you would be free to do now that you own it.

Terry