RL G3 BACnet

[dts_inc]

Killer,

Thanks again. One other thing...you mentioned configuring the G3 to read data actively. Is that accomplished by setting the direction of the data or it done through block control request/acknowledge?

 

[killer]

Just set the block direction to either read or write data. The G3 will poll the reads periodically, but the writes will occur with a change of data.

No need to use the data request and acknowledge in this situation. Just leave them blank.

 

[dts_inc]

Thanks again.

 

[dts_inc]

I'm still unsure of what the "device id" should be in Crimson under the device config in the BACnet master driver. I spent a little time on it yesterday and still was unable to communicate. Also starting to wonder if the pinout is right. RL tech support instructed me to use pin 1 -, pin 2 +, and pin 6 common.

 

[JeffKiper]

Look at the manual that came the redlion.

I haven't used BacNet. I would use the slave's id. This tells the master what slave to talk to.

 

[dts_inc]

Part of the problem may be the fact that the chiller in not a slave....I'm just treating it as one. According to Johnson Controls there is no way to set this particular unit up as a true slave.

 

[JeffKiper]

No disrespect intended. Do You understand how these communication systems work. I HAVE NOT DONE BACNET. I am going off past experience with other networks. The master (chiller in your case) sends data to the slaves or request data from them. The slaves can only answer the direct question when spoken to. They don't talk to any other unit on the network. They only listen for commands from the master. You may be able to setup some type of messaging between the 2 devices master to master but I bet the RedLion doesn't allow that.

 

[dts_inc]

No disrespect taken. I've never done BACnet either. Honestly, I hope to never use it again! While I'm most at home using DF-1 and ethernet with AB products, I have used some MODBUS and a couple other comms protocols. I usually plow through and figure them out.....this one has been particularly sticky.

 

[Clay B.]

I'm still unsure of what the "device id" should be in Crimson under the device config in the BACnet master driver. I spent a little time on it yesterday and still was unable to communicate. Also starting to wonder if the pinout is right. RL tech support instructed me to use pin 1 -, pin 2 +, and pin 6 common.

This is RS232 basic. Pin 1 and Pin 2 are read and transmit not Plus/minus Pin 6 is common. Depending on the wiring on the field unit you may need to switch Pin1 and Pin 2. On your field device you should see Tx and RX or something of that nature Tx is the transmit line and Rx is the receive line. The receive line on your device (chiller, whatever) connects to the Tx on your G3. Since you use AB you do this without noticing by using a null modem (well actually the null modeme does a bit more but that part is not needed for this discussion).

Anyway the point is when trying your diffent comm settings try switching just the RX and TX and leave the Common alone.

Part of the problem may be the fact that the chiller in not a slave....I'm just treating it as one. According to Johnson Controls there is no way to set this particular unit up as a true slave.

Sorry to say I have no direct experience with BACNET but on most other Comm systems if it can be a master it can be a slave. The only thing that would prevent it from being a slave would that you could not address it. Not real sure what a "true" slave would be. Either it can be addressed or it can't.

Anyway this is a side issue.

From the manual posted I see you have read only and write only and read/writes.

Start with the Reads. Do not mess with the Writes yet. Set your reads up on your screen along with your Comm error word you can create in the G3 (refer to the Crimson Manual for more details).

Now you can play with the comms settings and wiring and find out when you actually have it working. Your Comm Erros should go to zero and you should see new data in your words. This will also let you know if byte swapping is taking place.

Remember a Write only works when the data changes, otherwise it just sits there so get the reads first. Once you have the reads working then your comms work. Now comes the fun part of getting the writes to work without clogging the system. That is where you get into timing.

Also that Comm Error I talked about earlier. It comes in real handy during this phase. Well it does in Modbus I can say for sure.

 

[dts_inc]

Sorry......the "+/-" comes from the chiller BACnet terminal block and the JCI people instructed me on how to wire to it. Pin 2 to +, pin 1 to -, etc. I can certainly try to change it.

As for the master/slave issue, JCI said that the unit can only be addressed from 0-127 and according to them, any address below 127 is a master. I've also read that in some of the Johnson documentation. I say "true slave" because even though it's a master, I was trying to treat it as a slave...using the master driver in Crimson. As Jeff mentioned earlier, Crimson probably doesn't allow this.

I agree with trying the reads first. That's what I've been doing. I simply try to read one temp from the analog read points based on the chiller mapping. There shouldn't be a whole lot of writing to the device beyond the initial shakedown of the system. There are only two temp setpoints to be adjusted for this application.

 

[JeffKiper]

The +/- makes me think it is a multi drop system (422/485) . I have NOT read the manual on this system so I am going off previous experience with similar systems.

Making 2 masters talk to one another is usually less than fun. A lot of the time I make a bridge out of slaves and have them pass info.

 

[Clay B.]

The +/- makes me think it is a multi drop system (422/485) . I have NOT read the manual on this system so I am going off previous experience with similar systems.

Same here. You may need to visit this again. It maybe you need to use the RS485 port on the G3 instead of the RS232. You maybe already doing this I assumed you were using the RS232.

 

[Jmartinez]

2 o 3 weeks ago i was able to read data from a york chiller using bacnet and a redlion DSP.
config on the DSP there is no-tricky: just selected the 485 port as bacnet ms/tp master, selected the baudrate matching that on the chiller and selected "mac addres:102" and "highest master:103" i set the york chiller's id=103.
after that i mapped the tags.. to such as "PLC.AV1.present-value" and so and it worked.
to configure the york chiller press "cfg" or "prg" (i dont remember well), the password is four key downs, and just follow the menu to set the port to protocol bacnet, slave, and id (tricky: id is set with 2 parameters, one of them "modifier" is ultiplied by some factor and added to the other one.).
i could connect this 2 guys but it was only a test, for the final project we ended up setting the york to modbus in order to daisy.chain other non-bacnet devices to it.