Okay, your opinion. And you're entitled to it.
Originally posted by dmaffei
I have to laugh. Reading the posts about AAM is like seeing a resume for a guy you fired last year and now, after a little spit and polish, his resume reads like the perfect employee. NOT!!!
LOL ... the SR 71, a very impressive aircraft by even today's standards was based upon 1960's technology. The Space Shuttle, Space Lab, those stealth attack craft used against Iraq so effectively, most likely all or most of the aircraft you've ever ridden in ... and felt safe and comfortable in, and most of the equipment in the factories producing everything from medicines, to parts for your automobile, bricks for your home, the fuel you use, the electricity you use, etc ... are all 80's (or before) technology.
AAM is backward compatible because it is backward. Still using technology from the 80's and it's still horrible.
However, they all seem to work pretty durned well, perform their functions reliably, and meet even today's demands at least adequately. Considered good value for the dollar.
As to the "horrible" part, there is more than just a passing chance you may not have understood the AAM system as well as you thought. Nor the reason why customers who prefer that make of DDC, prefer it.
Hmmm. My customers seem satisfied. Perhaps I am accomplishing their requirements differently than you did?
[B}Trending is a joke. [/B]
As the old saying goes, there is more than one way to skin a cat. Some are better than others.
And if yah read enough posts on this web site, the thing yah learn is that there isn't a friggin DDC controller made by anyone which doesn't have it's quirks and shortfalls, and which you won't find somebody bad mouthing and faulting all day long.
As I mentioned, I'm not going to engage in that sort of dialog. It's useless, meaningless, and non-productive. IMHO.
I read a lot of posts on this group to learn. That's why I don't actually post that often. Not near as often as I read. And read about both equipment I use, and equipment I don't. Pretty much ignore the personal "opinions", but do pay attention to any facts and hard data provided.
The thing is, I'm well aware that there is no PERFECT equipment. So what I'm interested in is to learn about the various quirks, shortfalls, and so forth of each. And the workarounds which resolve this. Even on equipment I don't use since yah never know. I may have to work with it tomorrow.
Hmmm. In my day to day business, this really isn't an issue. Or VERY rarely so. And in a year, I and my guys install millions of dollars and from hundreds to thousands of AAM controllers of various types.
Token passing, who needs it.
And the customers are satisfied and happy as can be with their systems. And continue to buy more.
Most of em, wouldn't have a clue what yah meant by that statement. And wouldn't care. All they know and care about is the system works for em, and works extactly as advertised and they expected.
Your point is? Besides the fact you, personally, don't like AAM. Which is fine. I'm hardly offended. To each his own. We all more or less find our own market niches which work for each of us individually.
[QUOTE]You can't talk across different networks of a Sage. [QUOTE]
As with the previous statement you made. Both true, and yet a non issue. To my customers.
An individual controller can not talk directly with another which is on a different port or network segment. However, the Sage can talk with anything and everything connected to any of it's varied ports. Utter simplicity to have the Sage pass on the info. If you know how.
But, for the record. As a matter of policy and design philosophy. We make every attempt, regardless of whether talking about AAM or any other controller line, to avoid one controller being dependent upon another in order to perform it's basic and necessary functions. We purposely design systems for as much "standalone" ability as we can achieve. That is, cut all network wiring to controller X, and that controller will keep right on doing it's job as much as possible. It having used the network only for getting incidental, non mandatory to it's doing it's job, info.
Many of our more knowledgeable and demanding customers make this a requirement. They want as little of the overall system and services affected by a single controller failure as it's possible to achieve.
And where it's necessary for us to use the Sage to "route" data from this controller to that. All that is tranparent to our customer anyway. They don't know how we do it, don't care.
Hmmm. We don't seem to have any problems with this.
It's compiler is very weak.
For the record, guy. I do a lot of programming, not just DDC programming. Using C, VB, and other languages. I know of no programming language or compiler that doesn't have it's issues, quirks, shortfalls, or need for the programmer to figure out "workarounds" in order to make whichever programming language do something he wants it to do which it doesn't have the "native" ability to do.
I and others at the company I work for who do AAM, typically use whatever text editor each person favors. Then calls up SoloPro to compile. In it's "list" file which it produces, it points out where the error is and the nature of it, if any. One makes one's corrections, recompiles and you're done.
The problem is?
The limited nature of the Sage programming language itself?
Well, that's an issue. On the other hand I've yet to see the requirement by a customer which I can't do with it. And easily. It's a matter of knowing and understanding the system and the programming language, and being proficient in programming in the first place.
On the plus side. A lot of folks like it just exactly due to it's simplicity. And it costs nothing extra.
No problem. Don't use their stuff. Simple.
OK, I'm sorry, I was getting ready to go on a roll.
My best to you and yours.