EEVblog Electronics Community Forum

EEVblog => EEVblog Specific => Topic started by: EEVblog on September 02, 2017, 02:37:02 am

Title: EEVacademy #6 - PID Controllers Explained
Post by: EEVblog on September 02, 2017, 02:37:02 am
David explains PID controllers.
First part of a mini-series on control theory.

https://www.youtube.com/watch?v=VVOi2dbtxC0 (https://www.youtube.com/watch?v=VVOi2dbtxC0)
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Vgkid on September 02, 2017, 02:50:44 pm
I'm really looking forward to watching this one. In my PLC class my group ran to the school library to read about this stuff, while working on a project in class.
Neat stuff.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: b_force on September 02, 2017, 03:38:44 pm
You were asking for suggestions

If I may give one.
You really need to explain thinks like phase margin, feedback loops (amplifier/regulator circuits), stability and very important is to use some practical examples.
This is still a difficult subject to tackle, even most graduated students (or people in the field) don't get that right.

Btw, the talking speed is much better compared to the previous ones!  :-+
I only would explain it even more simple.
(also find it a bit odd to start with a PID right away)
But it's improving! :)
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: kg4arn on September 02, 2017, 07:44:28 pm
 :-+ and I enjoyed the explanation. 

I am looking forward to further development.  PID looks at the feedback system in the time domain.  I hope that you will be correlating to the frequency domain, e.g. the poles and zeroes inherent in the system being controlled and the poles and zeroes introduced by  the integral and derivative controller elements as well.

Very good.  Thanks
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: madires on September 02, 2017, 08:28:06 pm
Btw, the talking speed is much better compared to the previous ones!  :-+

Yep, much better!
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: IanB on September 02, 2017, 08:37:45 pm
Btw, the talking speed is much better compared to the previous ones!  :-+

I haven't watched the previous ones, so I don't know whether fast or slow? However, on most vlogs these days I set the playback speed to 1.25 or 1.5 to make them have a reasonable pace  ;D
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: b_force on September 02, 2017, 09:26:46 pm
Btw, the talking speed is much better compared to the previous ones!  :-+

I haven't watched the previous ones, so I don't know whether fast or slow? However, on most vlogs these days I set the playback speed to 1.25 or 1.5 to make them have a reasonable pace  ;D
I am aware of that, but talking speed means more than just how fast.
It also means like breaks, pauses etc.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: IanB on September 02, 2017, 09:51:58 pm
When people are making expositions or technical presentations on YouTube I would like them to keep the pace as fast as possible. No gaps, no pauses, no slow speaking. I can easily replay or pause any bits I want to stop and think about. This is different from a live presentation in a room and the approach needs to be adapted accordingly. Video presentation is more like a textbook, where needless fluff and filler needs to be edited out.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: BobC on September 02, 2017, 10:51:46 pm
I haven't yet taken the time to watch this, because I like to allocate extra time for Fundamentals Friday and EEVAcademy videos.

However, my own experience is littered with frustrating examples of how to misuse PID controllers.

One particularly bad case was a communications dish controller that was intended to be a minor (5%) part of the software for a larger communications system.  It was similar to other pointing systems we had previously made, only larger, heavier and faster.  The "quick & dirty" prototype unit worked "well enough" with our existing PID-based controller, needing only an upgrade to the motor drive MOSFETs.  The decision was made to evolve the design and build a pair of alpha units.

The alpha units, with a simpler and lighter mechanical design, started to have problems with both backlash and flexing when we started aggressive "full-spec" testing.  A mechanical quick-fix would have scaled the unit to unacceptable weight, materials, power and performance costs (stronger mount needed larger motors, more power and so on).  So the software team was told to "make it work", and we went down the rat-hole of trying to find the "magical" PID settings to get past our issues.

Based on our "success" with the prototype unit, we thought we were "so close" to a solution that "only a little more effort" would be needed.  Based on our assurances, management scheduled an all-up full field demo for our launch customer (and development partner) who was literally on the other side of the world from us.  We were so wrong.  As the visit neared, we put in more and more time trying to get the dish to track to spec, with next to nothing to show for the effort.

Desperate and frustrated, two days before the demo I decided to throw out and replace all of our work.  Well, OK, technically I removed nothing: I added a layer beneath the PID controller, so the PID controller would activate only when the lower-level controller failed.  As you may have already guessed, the new controller was a bang-bang controller.  And given my many hours with the system, I had by this time developed an internal (definitely non-numeric) model of the system dynamics that permitted me to dial it in very quickly.

I finished testing the code and the system just an hour before it all had to be loaded onto a truck for the demo.  No, "finished" is too strong a word: I ran out of tests I could perform in the time remaining.

Remarkably, Murphy was absent that day, and the demo went off impressively well.  Far, far better than I had personally expected.  The customer was extremely pleased, and asked us to repeat the demo several times under changing conditions.  The system just kept on working, all the way up to nearly DOUBLE our baseline performance spec, literally setting a new standard for our industry niche.  It was a struggle for us not to show our own amazement.

So many lessons were learned from that fiasco:

First and foremost, we failed to stop at the beginning to re-assess the actual problem, by measuring the system's dynamics and developing a suitable model (starting with attaching lab-grade sensors and subjecting the system to step impulses and linear accelerations at various speeds).  The MEs who designed it weren't able to do a full dynamic FEA (Finite Element Analysis), and were able to only assess the system under static loads.

Second, when things go wrong that are visible at the system level, the first thing to do is to hold a full team meeting, maybe even a full design review, before committing to any specific path.  For this specific problem, everyone thought the hardware work was done, so the software team was in charge, rather than the electro-mechanical team.  By "owning" the problem, we software folks basically prevented the MEs and EEs them from finishing their work.

Third, our "success" with the initial prototype was a total farce.  That unit had lower-resolution position encoders and weaker motors than the final system, and it's data (and our processing of it) was simply inadequate to even compare to the actual system needs.  But we convinced ourselves it was a huge step in the right direction, and made several important decisions based on that data.  We again failed to provide useful feedback to the electro-mechanical team.

Fourth, we simply got lucky, massively and miraculously lucky.  Yes, a bang-bang controller was absolutely appropriate, but it was BAD ENGINEERING.  My work bypassed all of our engineering processes.  Most importantly, my solution had no high-level analysis, it received no design review, and it had no formal test plan.  In reality, it was only a tiny step above what you'd wipe off your butt.

Fortunately, I did gain vital understanding of the limits of PID controllers.  So, there's that, at least.

If appropriate, after viewing the video I'll provide additional examples here and in the video comments.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Brumby on September 03, 2017, 12:51:02 am
When people are making expositions or technical presentations on YouTube I would like them to keep the pace as fast as possible. No gaps, no pauses, no slow speaking. I can easily replay or pause any bits I want to stop and think about. This is different from a live presentation in a room and the approach needs to be adapted accordingly. Video presentation is more like a textbook, where needless fluff and filler needs to be edited out.

That might work for you - but it doesn't for me.

I would rather watch a video once - and understand the content as it is presented ... and if that means 10 minutes worth of content takes 12 minutes to present, then that's how I would want it to run.  If I missed picking up on something, I can step back there and then.

Going back and picking out different bits to go over again is, IMHO, inefficient.  You can spend more time trying to locate the point you want in a video than actually watching the clip of interest, not to mention the whole discontinuity of doing so.  The total time to absorb the subject matter is going to be longer - and I might question the quality of the understanding because of that and the disjointed nature of the learning experience.

I also challenge the differentiation between a lecture hall and a video.  In both situations the student is being given a presentation.  In both situations, the student will need to take in the material at the pace it is presented, so it is important, IMHO, that this pace is appropriate for comprehension, not just delivery.  For this, pauses are critical.  They not only give time for a concept to be absorbed but, more importantly, they more often than not define a particular segment of that concept ... and since the presenter is the one who has the knowledge, it seems to me that they are the one best placed to inject appropriate pauses.  A student doing so on their own would have to assess/guess where to insert their own mental (or real) pauses - which makes it more laborious for them and risks making the subject more difficult to understand if they get this wrong.

If you can follow a fast-running presentation without pauses, then you probably know more about the subject in the first place than most of the rest of the audience.

At least, this is my take on the subject.


As for Dave's presentation - I felt the pace was excellent.  I did, however, feel that there were a number of occasions where little bits of information were skipped over and I found myself wondering what they could be - which distracted me from following what came next.  For example, if you are going to present a formula, then address each term in it.  Even if you don't give a full explanation, at least give some idea as to what it's about.  If it is going to become clearer later in the presentation, then say so, but don't ignore it at the first appearance.

Having said that, I am looking forward to the next instalment.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: IanB on September 03, 2017, 01:10:30 am
Going back and picking out different bits to go over again is, IMHO, inefficient.  You can spend more time trying to locate the point you want in a video than actually watching the clip of interest, not to mention the whole discontinuity of doing so.  The total time to absorb the subject matter is going to be longer - and I might question the quality of the understanding because of that and the disjointed nature of the learning experience.

I think you miss the point of what I'm saying. I don't go back and pick out different bits to watch again, I watch the video in a linear fashion from beginning to end, just like most people. See below.

Quote
I also challenge the differentiation between a lecture hall and a video.  In both situations the student is being given a presentation.  In both situations, the student will need to take in the material at the pace it is presented, so it is important, IMHO, that this pace is appropriate for comprehension, not just delivery.  For this, pauses are critical.  They not only give time for a concept to be absorbed but, more importantly, they more often than not define a particular segment of that concept ... and since the presenter is the one who has the knowledge, it seems to me that they are the one best placed to inject appropriate pauses.

This is precisely the reason why the presenter should not insert pauses. How likely is it that the presenter will know to insert a pause at the place where I need it?

Quote
A student doing so on their own would have to assess/guess where to insert their own mental (or real) pauses - which makes it more laborious for them and risks making the subject more difficult to understand if they get this wrong.

Exactly! This is not hard nor laborious, it is trivial! I am watching along, and I don't quite get what was said. So I immediately hit the stop button while I think about it. That's my pause, where I need it. If I need to hear it again, I just hit the "five seconds back" button and re-listen. What happens is that I pace the video at my comprehension speed, pausing and re-listening exactly where I need to.

Watching a video lecture needs to be an active process, not a passive process. You need to engage as the listener and actively absorb the content. You may even pause the video for 10 minutes while you sketch something out on paper to clarify your understanding before continuing.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Brumby on September 03, 2017, 05:57:45 am
From your other points, I will not argue - since it is clear that I have misread some of what you posted.

However:
How likely is it that the presenter will know to insert a pause at the place where I need it?
This is a rather bizarre question, IMO.

The presenter will know the subject matter - and those with the experience will naturally pause between elements of that subject matter.  A longer pause indicates a more significant portion of a concept has just been covered.  I equate varying pause length with sentences, paragraphs and chapters of a book.  Those "breaks" allow for better comprehension and were included by the writer for just that purpose.

You, however, do not know the subject matter - or at least as much as you want to - hence your interest in the presentation, so I would lean towards the presenter having a better "feel" about when to pause.  I will even hazard a guess that you do respond to pauses, for example, by clicking on the "pause" button or skipping back at the point where the presenter takes a pause.

But aside from that, I see your opinion as a selfish one.  As I said before, your preferred approach may work for you, but it doesn't work for me - and, I would suggest, it would not be the choice of the majority.


However, I'm not saying that I'm right and you're wrong - I'm just saying that, in my opinion, appropriate pausing is a necessary part of a presentation for optimal comprehension for the wider audience.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: b_force on September 03, 2017, 01:18:17 pm
I'm just saying that, in my opinion, appropriate pausing is a necessary part of a presentation for optimal comprehension for the wider audience.
I know people who are teaching or have been teaching for over 30 years about these subjects.
They all totally agree with this.

Second to that is to make it as simple and easy to understand as possible.

Teaching is almost a form of art that way.

The speed was fine this time, but like others said, there were to many jumps or things that first timers never would understand.
I use control theory almost on a daily basis and I find it even difficult to join all the ends together at certain points.

Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: IanB on September 03, 2017, 04:45:10 pm
The speed was fine this time, but like others said, there were to many jumps or things that first timers never would understand.

It's a false expectation that someone can understand new and complex material on the first encounter. If you suggest to students that they should be able to do this, then they will get demoralized when they can't and think they are failing.

So of course teachers should use the best presentation skills, but even so, expect that there will be students who don't get it first time, or the second time, or the third...
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: floobydust on September 04, 2017, 12:56:34 am
PID control is based on math with calculus, so it is hard to present and give an intuitive understanding to the masses.

It was third-year university when we got into it. Then you go work in industry realizing you know nothing about optimizing PID for process control  |O
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Circlotron on September 04, 2017, 02:26:00 am
Thirty years ago, with no tertiary education and no understanding of mathematics beyond high school level I began to teach myself analog PID stuff. I have a rock solid appreciation of the principles involved but the descriptions on the whiteboard using letters that are not even in the alphabet make my head spin.  :scared:

One principle I came to appreciate was integral windup. In a car cruise control extra load makes the car slow down and integral feedback makes the throttle gradually open further and further until the correct speed is attained again. Two things are at work here - one is the wound-up integral is trying to make the car assume it's original *position* on the road as if it had never slowed down by overshooting the speed until it catches up to where it would have been. You don't really want that. Second is the extra energy needed to accelerate the *mass* of the car back to original speed in addition to the extra energy needed to supply the extra load.

Really fun stuff!  :-+ :-+ :-+
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Brumby on September 04, 2017, 03:56:05 am
The speed was fine this time, but like others said, there were to many jumps or things that first timers never would understand.

It's a false expectation that someone can understand new and complex material on the first encounter. If you suggest to students that they should be able to do this, then they will get demoralized when they can't and think they are failing.

So of course teachers should use the best presentation skills, but even so, expect that there will be students who don't get it first time, or the second time, or the third...
You missed the point entirely.

While your comments are valid in themselves, they are not relevant to the issue that was raised.

The point - and one which I wholeheartedly agree with - was that there were details - little details - in the presentation that were skipped over.  This has nothing to do with the style of presentation or the capability of the student ... it is a fundamental omission - and while it may seem minor to one familiar with the material, it is a discontinuity of the logical explanation.  This sort of thing can cause a student (especially one who is paying attention) to wonder "How did we get here from the previous statement?"  "Did I miss something?"

I would liken it to being shown a PCB trace with a hole along its length and not being told the hole was actually a via.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: ali_asadzadeh on September 04, 2017, 10:22:43 am
Thanks for the video, It was needed ages ago! :) ;)

By the way please try to use ARM Cortex M for the controller as a practical controller, not arduino, it will limit us! and the future is Cortex ;)

The good point about Cortex M is that the Controller is written in the cmsis math library and we have all versions of floating point and Fixed-point versions and hopefully you would teach the more practical version of Fixed-point one :)

A side note though, since almost all of us have access to matlab, it would be also beneficial to be able to do a step-response on the DUT and get the PID Coefficient from matlab for tuning,

Here you can see a snippet and simple code for ARM Cortex M PID in fix point integer


https://www.eevblog.com/forum/projects/dc-motor-speed-q31-pid-tuning/msg1290371/#msg1290371 (https://www.eevblog.com/forum/projects/dc-motor-speed-q31-pid-tuning/msg1290371/#msg1290371)
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: DutchGert on September 04, 2017, 05:52:46 pm
Yess David, these are the kind of video's that David SR should have done a long time ago :).

Talk speed and voice is a lot better than previous video's, good to listen to now, a bit anoying in previous videos.

Nice build up and enough detail.

If I may make a suggestion, do video's with this level of detail (not to less, not to much) about Op-Amp/DC-DC stability, phase margin, etc.

Nice work
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Howardlong on September 05, 2017, 09:48:14 pm
A side note though, since almost all of us have access to matlab

Unless things have changed dramatically in recent times, the only people to have access to Matlab are those in academia and those with extremely well funded R&D departments.

Octave is an alternative option that's open to all.

I never have figured out why Mathworks' marketing have decided to effectively competely block out almost all SMEs from their product line.

I would add one further point about Matlab. While it's a really great tool, but you must be careful not to use it as a crutch. For example, most of the code it generates is a very long way  from optimal.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: f5r5e5d on September 05, 2017, 10:20:17 pm
yes it has changed: https://www.mathworks.com/products/matlab-home.html (https://www.mathworks.com/products/matlab-home.html)

I've used SciLab http://www.scilab.org/ (http://www.scilab.org/) as a Matlab workalike, not quite as .m file compatable as Octave and domain specific packages are way behind Matlab, if slowly getting better
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: EEVblog on September 05, 2017, 10:45:37 pm
I'm just saying that, in my opinion, appropriate pausing is a necessary part of a presentation for optimal comprehension for the wider audience.
I know people who are teaching or have been teaching for over 30 years about these subjects.
They all totally agree with this.

Second to that is to make it as simple and easy to understand as possible.

Teaching is almost a form of art that way.

The speed was fine this time, but like others said, there were to many jumps or things that first timers never would understand.
I use control theory almost on a daily basis and I find it even difficult to join all the ends together at certain points.

The Great Scott channel is a good example of this issue I think.
I believe he gets a fair bit of criticism on his tutorials for being way too fast paced and skimming over things entirely rather than pause and explain details, and this is very deliberate for his channels styles and mainstream appeal. His argument is you can always pause the video and look at the schematic and try to understand it etc.
I take the opposite approach and try to explain in detail when I hit upon a detail I think needs explaining (which to me is most things). Hence I end up with long form tutorial videos.

One way appeals to a more mainstream audience that want to be quickly edutainmented (that's a word), and the other appeals to a smaller audience who want to try and more fully understand something.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: b_force on September 05, 2017, 11:02:25 pm
It's funny/interesting how people look at things.
I personally find Great Scott pretty slow in his explanations, sometimes a little bit to repetitive or so, can't really explain.
I always skip through his videos.

But maybe that's also the subjects and therefore the audience.
His subjects are a lot more simple.
On the other hand, he does sometimes skip essential information
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: IanB on September 05, 2017, 11:21:31 pm
yes it has changed: https://www.mathworks.com/products/matlab-home.html (https://www.mathworks.com/products/matlab-home.html)

Not that much: "For personal use only. Not for government, academic, research, commercial, or other organizational use."

It remains the case that Matlab is mainly in regular use in universities and for non-commercial purposes. I think the cost is far too high for businesses and commercial organizations to make general use of it.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: ali_asadzadeh on September 06, 2017, 05:26:14 am
Quote
Not that much: "For personal use only. Not for government, academic, research, commercial, or other organizational use."

It remains the case that Matlab is mainly in regular use in universities and for non-commercial purposes. I think the cost is far to high for businesses and commercial organizations to make general use of it.

Ok, Octave is free and is almost compatible with matlab, which ever one you choose is OK, and please use Cortex M and the DSP math lib for them, they are free too :)
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Howardlong on September 06, 2017, 05:38:01 am
Quote
Not that much: "For personal use only. Not for government, academic, research, commercial, or other organizational use."

It remains the case that Matlab is mainly in regular use in universities and for non-commercial purposes. I think the cost is far to high for businesses and commercial organizations to make general use of it.

Ok, Octave is free and is almost compatible with matlab, which ever one you choose is OK, and please use Cortex M and the DSP math lib for them, they are free too :)

Counter intuitively, some of the CMSIS DSP library is far from optimal either, ISTR that the M4F  floating point FIR decimator is an example, I am sure there are others. I rolled my own, which was a lot more educational, and for my application was two orders of magnitude faster. Vendors often concentrate their efforts on headline algorithms like FFT. Beware!
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: f5r5e5d on September 06, 2017, 10:48:05 am
what engineer in a real company isn't supported by something close to his yearly salary in capital - which should include software tools

Quote
It remains the case that Matlab is mainly in regular use in universities and for non-commercial purposes. I think the cost is far too high for businesses and commercial organizations to make general use of it.

if your company only needs the tool and expertise once a year or less then hire a consultant who has the tool, if you need it more than a few times a year then even US$ 10-20k is a bargan compared to the product dev team time, cost, lost profit from not hitting the market oppourtunity window
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Kleinstein on September 06, 2017, 05:12:03 pm
The PID software is pretty simple - so really basic C. So it should not really matter if it will run on an Arduino / ARM cortex M4, PC or maybe even one of the old basic stamps.

You have to implement the reading the sensor and output of the control separate anyway, as the input can be more than just an ADC value (e.g. timing, frequency) and the output can also be DAC / PWM / frequency and others.

On how much explanation one likes depends on personal preferences and also the a-priori knowledge. Some of us are at high-school other have an PhD in engineering or science. So there is no perfect way to fit all.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Red Squirrel on September 12, 2017, 03:29:41 am
I know the oven is just an example, but this theory is more for really fast stuff like a SMPS right? Since for a slower control type situation like an oven you'd just keep checking the sensor value, and then if it goes above or the same (or maybe a bit above if you want to account for thermal mass etc), you turn off the relay, then wait till it drops to a predefined temp (a dead zone) then turn the relay back on.  Right? 

At least that's how I did it with my furnace when I built my thermostat system. I also add a minimum run/stop time to prevent short cycling, ex when it's 50 below outside the temp will drop faster but it does not "feel" cold yet in every room.  I plan to redesign that whole system to make it more modular to sense/control various things via plug in cards, so I presume this is knowledge that is going to be good to have.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: IanB on September 12, 2017, 03:41:35 am
"Fast" and "slow" is all relative. For example, something which is "fast" when time is measured in minutes can become "slow" if time is measured in seconds. And then the thing which is "fast" in seconds becomes "slow" when measured in milliseconds. So you control your oven temperature with "bang-bang" on/off control, but as time constants get faster you might turn the control element on and off faster and faster, until suddenly you find yourself doing PWM control with variable mark/space ratio  ;D
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Brumby on September 12, 2017, 08:12:41 am
"Fast" and "slow" is all relative.

Very much so.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Kleinstein on September 12, 2017, 12:28:24 pm
There is no principle difference between fast and slow systems. So one can use the same PID theory and regulator type for both.

The simple on/off regulation method is usually slower than a PID regulator for the same system. It also depends on the system to regulate how good different regulator types work. The Question of using simple on/off or PID does not depend on the speed / time scale of the system to regulate, but on the type of system (e.g. direct reacting, integrating, integrating with extra delays ) and the control element (e.g. continuous or On/off).

With system that allow for an analog control, the PID regulator usually gives better control than the simple on/off scheme. Especially in systems with extra delay, the simple on/off system may not result in a stable control loop.
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: Howardlong on September 12, 2017, 12:53:31 pm
what engineer in a real company isn't supported by something close to his yearly salary in capital - which should include software tools

Quote
It remains the case that Matlab is mainly in regular use in universities and for non-commercial purposes. I think the cost is far too high for businesses and commercial organizations to make general use of it.

if your company only needs the tool and expertise once a year or less then hire a consultant who has the tool, if you need it more than a few times a year then even US$ 10-20k is a bargan compared to the product dev team time, cost, lost profit from not hitting the market oppourtunity window

Everyone has a price, and that depends on the perceived value.

It depends what you call a "real company". It might be your opinion that support cost should equate to salary, and while that might be your experience, it doesn't make it true for all. But as an example, my own "support" R&D budget is several times my salary, and I still don't consider Matlab to be valuable enough to purchase.

For example, I've had an MSDN sub that my company has funded for many years, and the use and value I get out of that far outweighs the cost of Matlab. The same applies to the numerous other bits of software, in either capital or recurring expense, particularly development toolchains, from which I get daily use. You can add to that my hardware budget which is several times my software budget.

My need for Matlab/Octave is occasional and sporadic, perhaps two or three times a year, but it tends to be a couple of days of intensive use, unlike the development tools or MSDN, I have no need to use it day to day. At one point about 15 years ago I did have a one year Matlab licence as part of TI's DSP toolchain. There were a couple of Matlab tools I used fairly frequently to do with filter design that Octave didn't have, but other than that Octave could do everything else I needed. I simply could not justify the horrendous cost of Matlab for the value it provided, and since then there are many other options that provide the functionality I was using from Matlab without an outrageous price.

At what price point would I consider Matlab worthwhile? Perhaps $300/year tops to me. I see their website gives me an individual price of $5,000 with the toolboxes I'd be interested in, double what I pay for my annual MSDN licence, so thanks, but no thanks!
Title: Re: EEVacademy #6 - PID Controllers Explained
Post by: nctnico on September 12, 2017, 02:04:18 pm
Quote
Not that much: "For personal use only. Not for government, academic, research, commercial, or other organizational use."

It remains the case that Matlab is mainly in regular use in universities and for non-commercial purposes. I think the cost is far to high for businesses and commercial organizations to make general use of it.

Ok, Octave is free and is almost compatible with matlab, which ever one you choose is OK, and please use Cortex M and the DSP math lib for them, they are free too :)
I agree. GNU Octave can do a lot which Matlab can do too. I've used GNU Octave for a project to check some control loops and it has served me well.