I think its VT-100, not sure, been a long time for those.

 

Open? Thats a joke! Unless you're good with Hex decimal, forget it. Their support is horrible!!!!! You can access the AAM with a 232 to 485 converter and a program called Solo Pro. If you don't have the labels for the points, or know what each I/P and O/P is, it's kind of tough.

 

You can access the system with a 232 cable and hyperterminal (vt100). You will need a user name and password. When you reach the main menu press m for monitor/modify points. Then enter and the default group will appear, you can navigate the system groups and points from this (default) menu. Only points originally programmed will be available, this should include any setpoints. The N+ and N- is the (485) pup system, you will need solopro software to navigate to each controller. You can create points in the SF-1 to edit any controller points. Automatrix still sells the SF-1 controller, but a Sage is a better option. A local Automatrix Dealer may be able to help.

 

Thank you for the information. We will try Hyperterminal tomorrow. Without a user name and password we may be sunk.

I do agree the support for this system is very poor. Seems to me even the manufacturer does not want to work on them. Just happy it is the only Auto Matrix we run into.

 

There is a backdoor password if they will give it to you.

 

I think the user is aam and the password is system or the other way around

 

Thank you for the information. We will try Hyperterminal tomorrow. Without a user name and password we may be sunk.

I do agree the support for this system is very poor. Seems to me even the manufacturer does not want to work on them. Just happy it is the only Auto Matrix we run into.

Hmmm. The manufacturer does support all their stuff. However, like many, they won't tell you much unless you are an authorized dealer.

<Shrug> That's as much as I'll comment on that.

AAM is one of the lines of DDC we deal in. A lot of folks have bad things to say about their stuff. Which is fine. But routinely we make their stuff stand up and perform as well as or better than competing systems. Do it all the time.

I like their stuff. Very flexible. Very easy if yah actually understand the system. As concerns the hardware, we have stuff we installed that's considerable older than 10 years which still works just fine. And have numerous customers who're loyal to the brand.

If there is a weakness, it is that it's a proprietary system. Which can be very frustrating to those who don't have access to the info and software needed to work with it.

Now, we (the company for whom I currently work) give the customer all the docs and manuals on every project, And offer in depth training, if they wish. But not all contractors do this. And sometimes even when they do, the customer loses the stuff or tosses it. And at later dates regrets that.

That last, is actually done by a lot of folks, not just customers with AAM systems. I've worked on older systems of numerous name brands where customer once had the manuals, listings, data, software and knowledge. But somewhere along the line all was forgotten or lost. I see it all the time.

Factory default user name is: SYSTEM
Factory default password is : AAM

Might be useful if someone did not disable the factory default.

That's about all I'm willing to discuss publically.

FWIW, while I do like AAM's stuff, I'm not trying to sell yah on it, or any other particular system. We do more than one. In LON, I prefer TAC. Most of our business is in one of the two. (And still do a fair amount of CSI older stuff)Tho we do a lessor business in some others. We've recently dropped Honeywell, except to provide service for what we previously installed.

 

Why did you drop Honeywell ?

 

Why did you drop Honeywell ?

If you are wondering whether or not I'm gonna bad mouth them, no ... I'm not.

I live in the land of Honeywell, Minnesota.

And to be fair they make pretty good stuff.

Let's just say it's a business decision. Jointly decided by management, the salesmen, the engineers, and the automation techs.

The capabilities of their hardware and software, hardware reliability, promptness of customer support, etc just didn't work out well when viewed from the point of value gotten per dollar spent. As compared to a number of their competitors.

That's not to say their stuff is bad.

It was just a very hard sell for our salesmen to justify to our customers. Except for those who are just plain sold on and loyal to Honeywell. And there are plenty of those. But also there are plenty of contractors who're in the business of selling Honeywell. At least there are here in Minnesota.

So for that reason, and a couple others, we decided to back off on Honeywell. Absolute cutthroat competiveness if the customer wants, specifically, Honeywell.

We looked at the situation. Got plenty of Honeywell contracts. Big dollar ones. But ... profit margins sucked. We had to sharpen pencils REAL friggin sharp, grit teeth and put in some low durned bids to get the contracts.

In short, on the Honeywell side of the business, a lot of money went thru our hands but we sure weren't getting to keep much.

OTOH, if customer not absolutely sold on Honeywell, but wanted good quality, Lon, etc ... Heck we could toss a proposal at em using TAC. More often come in low enough to get the contract, but make more of a margin.

If LON wasn't specified or particularly wanted by customer, we could go two ways, TAC or Auto Matrix. Could bid even lower if Auto Matrix was acceptable. And it is often enough. There are still a lot of folks buying propriety systems. And a lot of our past Auto Matrix customers LIKE that line. Have been using it for years and are specifying it on new projects.

The decision was more of a business decision than a decision based upon pros and cons of hardware and software.

Just as we review our past customers time to time. Do formal reports and run the numbers. Sometimes a person can have a customer you do significant business with, a lot of dollars, but ...

Some customers are so hard to please, deal with, keep happy, and penny pinching. That if you look at the numbers you find out you're spending a lot of time, an inordinate amount of time, on a customer. Such that in the end, you're not making a dime, or not much. While tying up a lot of manhours that's not out there doing work for a better customer.

<Shrug> So sometimes we "fire" customers.

In this case, we fired a manufacturer. Not because they're bad or anything. We just don't find it beneficial, to us, to hawk their goods for em, to make half the profits we'd get if hawking somebody else's stuff, which works just as well ... in our experience. YMMV

 

I guess they didn't CARE for honeywell!

 

We too found a similar experience with Auto-Matrix. Having a proprietary line isn't all bad - having product lines like Honeywell and Johnson in the stable are nice for dealing with engineers stuck on names, but even Auto-Matrix can do a great job if the customer is interested only in results.

And the tech support available from AAM is really no different than that available from any other manufacturer. Get any guy off the street to try to reach Honeywell TAC or Johnson's tech support. Isn't going to happen. Only once you know the proper channels (whether that means being a dealer, or knowing a distributor that can place the call for you) will you get manufacturer tech support. So that really isn't a mark against AAM - that's just the way they all are.

So it boils down to the same conclusion as most threads on this particular forum - finding the right contractor, willing to work with the customer to properly support something they've properly installed.

Don't abandon hope for the AAM product you've got, hvacmanager. Properly configured, it works great. (Just make sure you're using a null modem cable to talk to that SF1...)

 

We too found a similar experience with Auto-Matrix. Having a proprietary line isn't all bad - having product lines like Honeywell and Johnson in the stable are nice for dealing with engineers stuck on names, but even Auto-Matrix can do a great job if the customer is interested only in results.

Yep, precisely.

It's all fine and well to have the discussion about open protocols, interoperability and so forth. Such ideas are great.

However, the reality is that the majority of the customers we do business with are FAR more concerned about results ... that count. ie Equipment that operates properly, good sequences of operation, energy savings and efficiency. Front end control that's clean, neat, professional and allows em to do things their way. And, of course, affordability.

Another thing some look at, is history. Of performance. ie We have customers who've used AAM for many years. It does everything they want, does it well. And once they understand how it works, THEY think it's simpler and easier than many other systems they've had experiences with.

I know, there are folks who'll take exception with this. Fine. I'm not here to sell yah on AAM. Make your own choices. What I'm repeating is what more than just a few of our customers tell us. And some of those customers we've had since the mid to early 90's. And I'm not talking small businesses only. ie We're currently working on a project, new construction. Controls end of which is a contract near $2 mil. Controls are AAM. And the customer has had AAM in other buildings owned by them since the mid 90's. They know it, understand it. We've made it sit up and dance as fancy as they've wished and it's done all they asked. One of the things they like is that if one of their inhouse folks understand a 1996 AAM controller, He will easily understand the latest. Works the same-same. Just more added features. Retraining is a minimal necessity. And there are fewer operator caused problems. THAT is very important to them. They also like the fact that they can stock a few controllers. And are then covered for every repair/replacement need. Service and repair they do inhouse. And reliability is one of their absolute top priorities.

This customer has the bucks to buy simply anything they wish. Money is not a question or issue. ie In the new building all the air handler stuff, and the new chiller stuff is top of the line Trane. Air handlers bought with no controls. We tack on AAM stuff. Chillers have Trane controls with which we interface, minimally. We import Trane controls into front end via BACNET. This is something we see a lot of in the case of chillers and boilers. Where the built in controls of the manufacturer are left intact. As it thought the manufacturer knows his equipment best. And will have the most reliable controls for that item.

<Shrug> In other cases we have someone like another large customer. Again, an account of significant money. Who likes the cost-performance ratio of AAM stuff. As they are trying to get the most per dollar spent. In their case, no interest in big, fancy front ends. Which we can put in for em, they just don't want or require it. About 30 buildings, each having AAM installations. But they just use local access via an in-house tech connecting to a system with a laptop when needed. Or, dial in using a terminal program from the main office. They haven't opted for a graphics front in, as yet. Not sold on the need, as versus cost. <Shrug> Their call. Thier buildings, their equipment. The only extras they asked of us was data recording, trend logs and so forth set up in the various Sages. Info they collect and use periodically.

Another account, also large. A major medical equipment manufacturer with multiple sites. They've had experience with Honeywell in this building, JCI in that, so on and so forth. This past year they decided to retrofit all with AAM as the system giving them, in THEIR estimate, best cost-performance ratio. Plus they're a bit displeased with Honeywell and JCI over several issues. Combination of contractors who did not do a good install, program job. And difficulty getting customer service at Honeywell and JCI to respond in what customer thought was a timely fashion. Without also giving em answers that seemed to always include the need to spend more money ... a lot more money.

I'm not friggin knocking other systems. Or dismissing the appeal and advantages of LON, or BACNET. Etc. Just pointing out that there are reasons some customers, and this incldues some corporations any one of yah would recognize the names of, big players, still see usefulness and advantages to continuing to use some older, propriety systems.

Especially if manufacturer has been consistant thru the years, ensuring compatibility between old and new products.

 

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

 

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

Okay, your opinion. And you're entitled to it.

AAM is backward compatible because it is backward. Still using technology from the 80's and it's still horrible.

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.

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.

[B}Trending is a joke. [/B]

Hmmm. My customers seem satisfied. Perhaps I am accomplishing their requirements differently than you did?

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.

Token passing, who needs it.

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.

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.

You can't talk across different networks of a Sage.

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.

It's compiler is very weak.

Hmmm. We don't seem to have any problems with this.

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.

OK, I'm sorry, I was getting ready to go on a roll.

No problem. Don't use their stuff. Simple.

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.

 

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.