RIB Bacnet Relays

[kontrolthis]

Has anyone used them on a job before? Cost wise they seem to be a cheap alternative when you need a quick Bi/BO with MSTP address.

Let me know what you think.

Thanks

[amigo]

I used it once and it took down the whole mstp bus.
They may have fixed their issues, don't know.
did not try it after that.

So do your testing before diving in.

:.02:

[kontrolthis]

Thanks for the heads up. Anyone else use them?

[kontrolthis]

Ordered one today, willsee how it bench tests in the shop.

[legionrider]

We have used them with no problems.

[Big Unit]

I've used a few on one project and everything went pretty smoothly. Maybe Amigo just got a bad one?

[freddy-b]

Never used the Bacnet models, but the Lon models work as advertised.

[kontrolthis]

Cool deal. I hope to have ours in hand in a few days.

[bdivell]

did anyone have any luck with changing the object identifier ? you can change the last 3 with the dip switches but i need to change the 277 as well

any help would be great

thanks

[bdivell]

The Vendor_Identifier for RIB products is 277. The Device Instance on RIB products
will default to 277000, or more specifically, the Object_Identifier will default to
DE277000. The Device Instance will be changed when the WriteProperty Service
receives a request using the Wildcard Device Instance. The new Object_Identifier will be
stored in EEPROM.

could anyone lead me in the right direction with this info?

thanks

[BACnet]

I just pulled up the PDF on one of their BACnet relays. Specifically this (http://ribrelays.com/images/product/Data_Sheets/RIBTW2402B-BC.pdf) one.

It looks like the dip switches are for the MS/TP address, but by default it uses that same number + 277000 as its device instance.

It appears that changing the device instance via a network write will decouple the two addresses, although it isn't entirely clear that doing so will keep the MS/TP address from being added to the new number.

From the document: "Device Instance changed via Object Identifier Property of
Device Object"

So basically, write to the Device ID directly with a clean instance that ends in 3 zeros- like 100000 for example. If it's dip switches are set to MAC address 15, the next time it boots, the device instance will be either 100000 or 100015, depending on how they've implemented this. (Their documentation isn't all together clear to be honest). I assume if you write 100000 it'll bee 100000 but I want to be clear that I didn't design this device or write what they consider the "manual" for it so I don't know for sure.

Of course, depending on the tool you are using to do the network write, you may be asked to enter a Device ID into the GUI, or you may be asked to simply write the instance and the tool will add the object class for you. That's of course tool specific but it's something to keep in mind if the RIB rejects the write and responds with an out of range error.

[ORCA_GUY]

I used 2 of them about a year ago to control some remote pumps and they worked fine. The address wasnt a big issue for me on this project. I think they ended up being 277001 & 277002. I did have to upgrade the OWS software because it didnt recognize the Bacnet ID of functional devices. I would use again if needed to.

[bdivell]

Thanks BACnet & ORCA_GUY for the responses and the info, I will try this and let you know

[CTC]

They can be connected directly to the MS/TP network. We tested and communication was easily set up for the relays and we could easily command them on/off and read the input values they provided. I think you'll have good luck with them. We didn't attempt to change the default device instance number. I don't think it would be a big deal for you unless you decide to use a bunch of them on the same network.

[digo]

I just pulled up the PDF on one of their BACnet relays. Specifically this (http://ribrelays.com/images/product/Data_Sheets/RIBTW2402B-BC.pdf) one.

It looks like the dip switches are for the MS/TP address, but by default it uses that same number + 277000 as its device instance.

It appears that changing the device instance via a network write will decouple the two addresses, although it isn't entirely clear that doing so will keep the MS/TP address from being added to the new number.

From the document: "Device Instance changed via Object Identifier Property of
Device Object"

So basically, write to the Device ID directly with a clean instance that ends in 3 zeros- like 100000 for example. If it's dip switches are set to MAC address 15, the next time it boots, the device instance will be either 100000 or 100015, depending on how they've implemented this. (Their documentation isn't all together clear to be honest). I assume if you write 100000 it'll bee 100000 but I want to be clear that I didn't design this device or write what they consider the "manual" for it so I don't know for sure.

Of course, depending on the tool you are using to do the network write, you may be asked to enter a Device ID into the GUI, or you may be asked to simply write the instance and the tool will add the object class for you. That's of course tool specific but it's something to keep in mind if the RIB rejects the write and responds with an out of range error.

Tried this from a t-box for like an hour...
Scenario: You try to edit the device id via the edit button in the BACnet device Manager view -> click OK ->nothing happens. Then you try to invoke the DeviceID button, but it asks if you want to confirm the change from the new id to the new id??? it fails miserably with a duplicate id !@#$!@#

Instead, click the deviceID button first, confirm the first dialog (yes), and then enter the new id in the confirmation dialog. Kinda backwards if you ask me... probably got a few gray hairs from this one today.

[kirkH]

probably got a few gray hairs from this one today.

Could be the smog....or surly coworkers.