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!!! AAM is backward compatible because it is backward. Still using technology from the 80's and it's still horrible. Trending is a joke. Token passing, who needs it. You can't talk across different networks of a Sage. It's compiler is very weak. OK, I'm sorry, I was getting ready to go on a roll. While you can make almost any control system work in most situations, AAM is like buying a Yugo when you've never had a car (or been riding mules and donkeys). Wow, it's great! Then you ride in a real car, yikes, what have I been doing in the Yugo all this time. You mean, I can get an automatic transmission? Power windows? Cruise control? It doesn't leak oil? While I really enjoy reading posts from Osiyo, who appears to be a voice of reason and stability, having worked with this system for years, I felt I had to say something.
Well, dmaffei is right in uncovering some of AAM's weaknesses - trending is nowhere close to functional on their graphical front-end, and it takes some customer training to be able to work with the Sage's internal trends. (Horrors!! A customer savvy enough to get into the workings of our controls!!)
And an OSA on one local network can't be seen by another. So write a tiny little SPL program to take care of that...Oh, the compiler is weak? You bring up a good point about writing custom programs: the compiler is only as strong as the guy writing the programs. Need all the features? Learn all the features of the language! After all, we're only compiling control-BASIC here - if the compiler can tell you where your error is, can be told what platform it's running on, and can be issued some simple commands to limit the generation and format of the compiled code, what more does it have to do?
And backward compatibility is quite an asset when dealing with long-term customers. I've got a 19-story high-rise with 4 generations of Auto-Matrix, from RCUs through 3 different iterations of unitary controllers spanning 15 years, and they all talk to one machine. Why rip it out if it's still working, and I can still talk to it? (After all, that poor guy just getting off the donkey is going to use a BMW the same way he uses his Yugo - get from point A to point B. If he truly needed more than that, he wouldn't be living where you ride donkeys.)
And token passing: What's wrong with that? Ask 99% of the people who use controls (that's USE, not SELL), and they won't care (if they know at all) if a system uses token passing or not (LON guys excepted...) Does N2 use token passing? Who cares?. I just know when a controller is talking or not. Does PUP use token passing? Sure, if you need it to. I just know when a controller is talking or not. And while I risk sparking off more criticism of BACnet, the token passing architecture has been a perfectly acceptable way of implementing BACnet at the device level for most manufacturers of "Native" BACnet devices. Oh yeah, I know when a controller is talking or not with that protocol too...
Perhaps speed is the issue? Yes, token passing schemes work best chugging along at 9600, and fairly well up to 38.4K, but I haven't seen a customer yet that could actually tell you that your unitary networks are running at a given speed, whether that be 9600, or 115K.
I admit that passing controlled-variable information along a token-passing network is next to impossible to do reliably (or quickly enough for good control), and for that reason, engineers for years have been specifying that an input controlling an output must be on the same controller. Of course, LON removes that limitation, but understanding that limitation just makes for a little more design work for the controls engineer - certainly not a knock against Auto-Matrix or anybody else who uses a token-passig arrangement.
Whew, time to climb off the soapbox...
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.
While I haven't worked with AAM in some years once I understood it I thought it did what ever I needed. One large problem was if a a vav control was idle for a peroid of time it forgot where it was and required rebooting. Those BC vav controls did the same thing. It's probably fixed by now. Can't quite remember the control designation. Also there were a bunch of prewritten programs on their site like lead/lag, osa setback etc. Most of the problems I remember were programmers not understanding systems. Like a prison here that ran on 100% osa and kept freezing the heating coils in the rooftop units. The programmers kept writing programs that cut back osa the colder it got outside. At a point there was hardly any air to the prison. Of course the real answer was antifreeze not programming.
Tracers work both ways.
Well, Osiyo can certainly defend himself - but the jist of his post (IMO) is that the best system is the system that the customer wants and that satisfies his needs. Not everyone wants or needs (or can afford) a Rolls Royce, or even a Cadillac.
Many customers may "think" they need a big $ system, but most don't need a Mercedes to drive to the corner store. A lot of control types unfortunately buy into that logic - usually from a lack of understanding and perception/bias. To each his own. KISS philosophy is almost always the correct one to implement.
Now, if you are selling ...
[Edited by ps on 03-25-2005 at 03:00 PM]
Interesting to note the comments pro and con on AAM. I've used AAM for about 6 years and found their hardware to be extremely reliable. I've found their graphical front end software good except for trending.
All control systems I've dealt with in the past 15 - 20 years have had their own good points and bad points. No different with AAM. For the smaller installations I've been involved with, AAM has been very good for me.