Welcome to HVAC-Talk.com, a non-DIY site and the ultimate Source for HVAC Information & Knowledge Sharing for the industry professional! Here you can join over 150,000 HVAC Professionals & enthusiasts from around the world discussing all things related to HVAC/R. You are currently viewing as a NON-REGISTERED guest which gives you limited access to view discussions

To gain full access to our forums you must register; for a free account. As a registered Guest you will be able to:

Participate in over 40 different forums and search/browse from nearly 3 million posts.

Hybrid View

Not a DIY post but...

I work for a company that repairs electronics. We work on things like laptops, GPS, cellphones etc. which we repair to the component level -- I spend much of my day soldering under a microscope.

One of our larger customers has, apparently, "a warehouse full" of HVAC control hardware that is known bad or used/untested. Our boss has been working up a Plan to repair these controls and my role in this project is to come up with test fixtures and so on to make it all happen. I have the general electronic chops to put this together, but I'm looking for a source of low-level information on Alerton control modules to save the trouble of having to reverse-engineer everything from scratch.

I'm hoping you folks can get me pointed in the right direction.

So far all the stuff I've been shown is Alerton; Ibex and BACtalk. I had early success with a TX-653P. On one of the forums here I found a piece of software called "TDS" which allowed me to connect to the RS232 header on the 653 and control it. I could read all the inputs and set all the outputs. The only info I had on the module was a tag that said, "analog?" and sure enough, the analog outputs were all dead. I quickly narrowed it down to an opamp that cost a quarter, changed that out and all was well. The customer put that module into one of his HVAC systems and verified that it worked.

So of course the boss now thinks I'm a genius, and the next thing I get is a bunch of BACtalk modules that don't have RS232 ports and wouldn't work with TDS (I think?) even if they did. And a box of Microset wall modules.

I did get a BCM-PWS and BCM-ETH, and I hooked them up to a router and can talk to the ETH but it doesn't see any of the BACtalk modules I've hooked up to it. This could be because all the modules I've tried are dead, or it could be because I'm not doing something important.

Now all of these things (except the Microsets) have RS485 and I've done a lot of work with RS485 in previous lives. But I need to know what to say to the 485 port to make each module do its thing.

Ultimately, here's what I'd like to be able to do: For any arbitrary Alerton Ibex or BACtalk module, communicate with the module. Read the value of all inputs, set arbitrary values to all outputs. Clear any stored program in the onboard memory ("DDC"?). Talk to a Microset without any other Alerton hardware involved to read all the buttons and sensors. The Microsets I've seen so far all seem to be input-only widgets, but if there are Microsets with display elements, LEDs, etc. I want to be able to write arbitrary stuff to those outputs.

I work with microcontrollers extensively, and have no qualms about building and programming a microcontroller-based gizmo that lies through its little digital teeth to the module being tested. I just need to know what language to lie in :-)

What I'm NOT looking to do is to build an HVAC system, whether live or as a test bed. I don't even really care that these modules are used in HVAC -- they could be for automotive engines, oil refineries, or Mars landers; outputs are outputs and inputs are inputs regardless.

All I'm looking for are pointers to sources of information on things like comm protocols and device enumeration so that I can get access to those tasty IO ports. The googling I've done seems to basically point me either to people selling modules, or right here to the hvac-talk.com forums. Can someone here help me out with a couple of URLs?

In BACnet there are two types of devices, masters and slaves. You can easily tell which is which because a master will boot up and immediately start sending packets out on the network whereas a slave will sit patientlyand do nothing.

There are open source BACnet stacks and tools available, and you can also buy software that will make things a lot simpler for you. You wouldn't want to make a program all on your own to communicate with these devices since inserting yourself into the token ring is something that uses very tight timing characteristics.

In fact, I'd suggest that you go an entirely different way. I'd use a BACnet controller to read and write the I/O on your BACnet devices. There are touchscreen-based BACnet devices on the open market that can be used to interrogate I/O on other BACnet controllers. It's not exactly what they were designed for, but it's well within their capabilities.

With Alerton you have two types of controllers. IBEX which is a proprietary protocol and BACtalk which is a BACnet protocol. If you want to communicate with the IBEX controllers using the BCM's, you will need to add a BCM-TUX to your array. You will be able to communicate to the BACtalk devices using the BCM-ETH.

Tip...with BACtalk the devices instance from the factory is 9999, so when you do a device scan and have more than one device on your network it is possible to have them conflicting.

I've got an RS-232/TTL converter connected to COM1 of a Windows7 PC. I open DOSbox and map the physical COM1 to the DOSbox COM1. In DOSbox, I run the TDS software that I found in this post from 2008. (I have to use DOSbox because TDS won't run under 64-bit Win7.) I connect the TTL serial data to the port labelled "RS-232" on a TX-653P and I can use the TDS software to read the points on the 653, and change the outputs. This all works.

Now, I want to be able to talk to devices that don't have the "RS-232" port (which isn't really RS-232, but I digress). So, now that I have a working system I make a change: I switch over to this RS-485 adapter connected to the "Comm trunk" pins on the 653. The 485 adapter shows up in Windows as COM4, and I map it through to COM3 in DOSbox. I change the configuration in TDS to use COM3 (the 485 adapter). I can verify with an oscilloscope that there is data coming through the 485 adapter, but it doesn't look like the same data (it's much shorter) and the TDS program doesn't see the 653. I've tried hooking up +/+ and -/-, or +/- and -/+ but neither polarity works.

Is this something that should work? Or is the "comm trunk" port different from the RS-232 port in some way other than voltage levels?