Honeywell Spyder BACnet VAV no talkie

[MCP]

There were 8 of these installed with a com line run between them but no head end controller. We are trying to add that but can not communicate with them.

We have tried from Jace and a few other MSTP methods at every known baud rate to all of them and to individual controllers.

They seem to be functioning; just not communicating. Is there something that may have been skipped in programming them that would cause this since originally they were not talking back to a head end?

Any help would be appreciated.

-Ken

[BACnet]

According to this (http://customer.honeywell.com/TechLit/pdf/63-0000s/63-1328.pdf), you should check the BAEnte status LED after a clean boot and see how fast it is blinking. Check out page 4 (of 8).

-B

[RACLman]

I believe the BACnet Spyders auto adjust thier baud rate to the JACE when they power up. Cycle the power to the Spyders with the JACE up and online and they should syncronize themselves with the JACE and begin communicating. This assumes the spyders are addressed properly.

[BACnet]

RACLman-

If that's true, then on sites like this (where there is no front end) is communication simply impossible?

AutoBaud is a wonderful thing if it's done properly. Sadly, I've seen people implement a broken style of autobaud far more often than I've seen them implement a legitimate one.

For those wondering- In BACnet you are allowed some amazingly long period of time to get on the network once you first power up. I think it's something like a full minute, although I don't know many controllers that take more than a few seconds tops. This is plenty of time to play around with baud rates if you so choose.

In order to properly autobaud, one would listen at the last known baud rate, then when it hears good data, it joins the network. If no good data is heard, the UART is cycled through the various baud rates until it hears good data on one of them. If that doesn't work, the last known good baud rate is used, a token is generated and the beat goes on. This is hardly rocket-surgery.

But if they simply stay silent until they hear someone else talking (as suggested above) then they won't ever communicate unless a non autobauding controller is added to the network. That's a pretty big failure IMO.

[dracula]

I have found on "automatically selected baud rate" systems, that it is a good practice to shut down all of the devices, then bring one on line at a time, map the points, then bring on another, etc.

Helps the others devices that you bring on line kick into the correct baud rate without all ot then trying to sync at the same time.

[BACnet]

It's just a shame that some people have screwed up what is otherwise a great idea.

It's no harder to design it right the first time, but doing it half-assed makes one's products seem cheap/crappy.

[dracula]

BACnet,

Unfortunately I have found that many manufacturers of so call BACnet devices, and for that matter, control devices in general, are making a full court effort to build their products so that they can eliminate the need for ANY skilled startup control technicians, and have the hope that the devices can be installed by the least trained staff a contractor can get their hands on.

"Plug and Play" is their matra, and it is driven by the owners of the controls contracting companies complaining to the manufactures that "your controls are so compicated to install, "can't you make it easier so I don't have to train these techs, or hire those expensive computer geeks?"

Anyway, have a wondeful day

Drac

[BACnet]

Well that's a double edged sword there. If your controllers are harder to set up than they need to be, you can potentially alienate your customers.

But if they are too simple to set up, DIYers will start to use them and then everyone gets sued when they burn down their building or freeze their chiller coils.

It's always best to make things as simple as possible within reason. But asking people to read a manual or watch some online training videos is not too much to ask if it's a complex product.

But trying to make a "plug and play" controller and accidentally ending up with one that can't communicate because it's waiting for baud rate advice is... well let's just say I'd rather have the "hassle" of setting a dip switch or writing to a baud rate point instead of having a network that doesn't allow itself to communicate.

[MCP]

It does say the baud rate is configured at the "global controller" so i'll buy into auto sensing. I'll talk to my guy that was out there and see what order he did things in and see if he got a look at the LED status at all.

Thanks for the tips and info.