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.

We replaced the ones in the 3 RTU's about a month ago. Now I am having problems with one unit where the writable points fault out whenever you try to write to them. The fault says device operation problem. The interesting thing is that these were supposed to be the latest version boards, but they look like they are older version than the ones you posted DcVoltz.

I am having the same issue with points faulting out with the operational problem message, all writable points. They all come across as A.O.'s. Firmware-V2.01b App software version--V5.22e(b). Appears that mine are older than yours. These are in Your RTU's, have calls in to both York distributor and tried Johnson but sat on hold for 20 minutes. Did you find any satisfactory solution or any type of work around?

Not yet. I have a JCI technical support manager working with the factory to try and resolve this. I have already reported to them that you are having the same issue as well if you are the one that also posted on the Tridium Forum. I will keep you posted.

After my last post I tried to maintain a positive attitude towards the JCI / York but I have to say that even after having job visits from a local Rep from York/JCI and Fieldserver the gateways still seems to fail after a few weeks of operation. We just replaced another Slinc and the system comes back fine all points working properly but we are not encouraged at all because we have done this over 6 times now but every time eventually the points start to lose integrity.

This will be my last post on this topic my conclusions are as follows.

Just like my first RAGE that started it all my belief of the gateway idealism that most if not all manufactures have maintained has not changed. The idea of being in a open protocol is stifled and blocked when the systems produced are not native. When a product is talking modbus and the system is using a third party gateway the integrity of the system is compromised. There is no other way to look at it. Until manufactures start producing native machines the system will be broken. Just like the days of old proprietary protocols they will get their way and only give us an illusion of conformance rather than a system that can maintained without the costful help of the unit manufacture. To buy their unit is to buy into their system. It has been that way from the beginning and it dos not look like there will be any change any time soon

Everything you do
Will come back to you So...
Do What You Love and Love What You Do

After my last post I tried to maintain a positive attitude towards the JCI / York but I have to say that even after having job visits from a local Rep from York/JCI and Fieldserver the gateways still seems to fail after a few weeks of operation. We just replaced another Slinc and the system comes back fine all points working properly but we are not encouraged at all because we have done this over 6 times now but every time eventually the points start to lose integrity.

This will be my last post on this topic my conclusions are as follows.

Just like my first RAGE that started it all my belief of the gateway idealism that most if not all manufactures have maintained has not changed. The idea of being in a open protocol is stifled and blocked when the systems produced are not native. When a product is talking modbus and the system is using a third party gateway the integrity of the system is compromised. There is no other way to look at it. Until manufactures start producing native machines the system will be broken. Just like the days of old proprietary protocols they will get their way and only give us an illusion of conformance rather than a system that can maintained without the costful help of the unit manufacture. To buy their unit is to buy into their system. It has been that way from the beginning and it dos not look like there will be any change any time soon

Good day DC,

I appreciate and understand your frustration, but I hope you do not group all gateway manufacturers the same. Indeed, gateways in most cases are a lot harder to design and support as the gateway manufacturer has to support protocols that were not designed by them. Adding to the complexity is that even the protocol authors violate their own protocol at times (or even have bugs) and in a number of cases have undocumented "features". That being said, I am certainly not defending the players in your case and am at a loss to understand why they cannot sort it out. It is possible that there may be more fundamental issues at play here (i.e. maybe a faulty hardware design, etc) that the players are not disclosing to you. It could also be that the on-site people (that the vendors dispatched) are not intimately aware of the gateway's hardware/firmware or the protocol itself... which compromises their ability to troubleshoot the issue big time. Again these are not excuses, but could explain things...

Going forward... there are no guarantees that using all products (whether open or proprietary) from a single vendor will minimize experiences like what you are having. Larger vendors have multiple divisions, departments, third party acquisitions, etc so that even interoperability within the corporate product line is problematic at times. Granted that if a problem should arise one would think that the resolution should be easier/faster because you are dealing with only one vendor..Sadly, this is not always the case and in fact it is just as difficult as if you were dealing with different companies.

Anyway, I say the above not aggravate you, but just to add some outside comments from one who has designed a number gateways over the years.

I appreciate and understand your frustration, but I hope you do not group all gateway manufacturers the same. Indeed, gateways in most cases are a lot harder to design and support as the gateway manufacturer has to support protocols that were not designed by them. Adding to the complexity is that even the protocol authors violate their own protocol at times (or even have bugs) and in a number of cases have undocumented "features". That being said, I am certainly not defending the players in your case and am at a loss to understand why they cannot sort it out. It is possible that there may be more fundamental issues at play here (i.e. maybe a faulty hardware design, etc) that the players are not disclosing to you. It could also be that the on-site people (that the vendors dispatched) are not intimately aware of the gateway's hardware/firmware or the protocol itself... which compromises their ability to troubleshoot the issue big time. Again these are not excuses, but could explain things...

Going forward... there are no guarantees that using all products (whether open or proprietary) from a single vendor will minimize experiences like what you are having. Larger vendors have multiple divisions, departments, third party acquisitions, etc so that even interoperability within the corporate product line is problematic at times. Granted that if a problem should arise one would think that the resolution should be easier/faster because you are dealing with only one vendor..Sadly, this is not always the case and in fact it is just as difficult as if you were dealing with different companies.

Anyway, I say the above not aggravate you, but just to add some outside comments from one who has designed a number gateways over the years.

Sam Thank you for your comments and I am not aggravated not at all. But I think you miss my point... my point is this "why the gateway at all!!!" In this case we are talking BACnet - A Data Communication Protocol for Building Automation and Control Networks. Developed under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), BACnet is an American national standard, a European standard, a national standard in more than 30 countries, and an ISO global standard. So why then do we need to gateway to modbus rtu. When are we going to see native BACnet machines? The manufactures want to look open to the public and the end user but do not want to invest in a Global standard protocol one that is not buggy or have issues? Like my mom told me long ago too many cooks spoil the broth... why the 3rd party why not make it native? It is just a communication chip difference? MS/TP and Modbus are both EIA-485 why make it separate at all? Believe me my RAGE against the (Gateway) Machine has a purpose and a reason. I understand creating N2 gateways or CCN, IBEX, DMS or any other proprietary communication gateway but!!! a brand new RTU not being native? My point is..."if you are going to do a modern day open protocol system it should be done Nativity not hide and seek through gateways...that's all and that in essence is MY RAGE AGAINST THE (GATEWAY) MACHINE!

Everything you do
Will come back to you So...
Do What You Love and Love What You Do

Sam Thank you for your comments and I am not aggravated not at all. But I think you miss my point... my point is this "why the gateway at all!!!" In this case we are talking BACnet - A Data Communication Protocol for Building Automation and Control Networks. Developed under the auspices of the American Society of Heating, Refrigerating and Air-Conditioning Engineers (ASHRAE), BACnet is an American national standard, a European standard, a national standard in more than 30 countries, and an ISO global standard. So why then do we need to gateway to modbus rtu. When are we going to see native BACnet machines? The manufactures want to look open to the public and the end user but do not want to invest in a Global standard protocol one that is not buggy or have issues? Like my mom told me long ago too many cooks spoil the broth... why the 3rd party why not make it native? It is just a communication chip difference? MS/TP and Modbus are both EIA-485 why make it separate at all? Believe me my RAGE against the (Gateway) Machine has a purpose and a reason. I understand creating N2 gateways or CCN, IBEX, DMS or any other proprietary communication gateway but!!! a brand new RTU not being native? My point is..."if you are going to do a modern day open protocol system it should be done Nativity not hide and seek through gateways...that's all and that in essence is MY RAGE AGAINST THE (GATEWAY) MACHINE!

Good day DC,

Indeed I missed your point... I was looking at it from a lower level, whereas, you were presenting it at a higher level... My apologies! I am in total agreement with you here. Why some vendors choose to do this is anyone's guess. My thoughts as to why could be any one or combination of:

1. Already have a working "x protocol" and need to support "y protocol" in a minimum of time, so one looks to a gateway.
2. Because of (1) maybe and if the vendor assumes that the gateway will work as presented, then perhaps this is less costly to the manufacturer (i.e. faster time to market)?
3. Manufacturer does not have the internal resources, skills, etc to port their current protocol to the desired one and so looks to the gateway to solve the issue?
4. If the Manufacturer does it all internally now they have to support the whole assembly (assembly, test, software/firmware, hardware, etc)...so greater cost/risk to the manufacturer.

Again the above are not meant as excuses, but may generate some thoughts as to why... As I said I am complete agreement with you that new equipment should support whatever protocol natively. This would certainly minimize finger pointing as now you have two vendors in the loop that can point fingers at one another. Regardless of who is the blame I still find it difficult to understand why either one of the players cannot isolate where the problem resides. If it was my gear I would install equipment for data capturing on your site and instruct you to "start" it when the problem occurs. This way I could determine on which side the issue is occurring... then install debug features (within the offending device) to assist with narrowing down where the issue is. Anyway, I digress and have dropped down again into the lower levels... my apologies again, as this is usually where I am at (the nuts and bolts of these type of controllers).

When are we going to see native BACnet machines? The manufactures want to look open to the public and the end user but do not want to invest in a Global standard protocol one that is not buggy or have issues?

"How it can be considered "Open" is beyond me. Calling it "voyeur-ed" would be more accurate." pka LeroyMac, SkyIsBlue, fka Freddy-B, Mongo, IndyBlue
BIG Government = More Dependents
"Any 'standard' would be great if it didn't get bastardised by corporate self interest." MatrixTransform
My 5 yr old son "Dad, Siri is not very smart when there's no internet."

After all of the negative reports that I have made on here concerning my problems with the S-Linc Modbus to MSTP Gateway I want to also report the Positive! We had a FieldServer and a JCI Rep come to our site on Tuesday and after they updated the firmware and the point list of the S-Linc we are pleased to announce that all systems seem to be working properly. I want to give a High-Five to FieldServer and JCI for getting to the core of the issue and making my Job 100%. I also want to let everyone know this is just an example of how perseverance and holding on to a principal can get you what you need to accomplish your goal. All-tho it should be said and repeated that it does not pay in monetary concerns to stick up for ones beliefs.

Sorry this issue has me really steaming, going through the same crap…..

Your original post had me thinking York/JCI garbage. I have several of these RTUs that have always been a total PITA. Several calls to tech support, none of which fruitful in resolving any of the problems. This was after 20-40 minutes of holding of course.

I gave up, we simply do not figure a week of time on a project to try and get them out to fix their trash, nor should we have to. I absolutely HATE integrating their stuff, it almost always turns into gigantic cluster fack.

I'm going round and round with an owner currently on one of their large RTUs that does not have the slink. All I'm doing is passing setpoints, and reading values.

Customer wants OA damper position. Pull it in, it’s labeled OA damper position in their interface & IOM. Customer "Why the (*@#$ is the damper position 0% when its at min position (not closed)?". Because that's what your pile of @*&# unit is telling me!!!

And this goes on, and on, and on, down the points list. Should have been a good project, now with all the meetings, letters, calls defending myself the project is totally tanked.

I FEEL YOUR PAIN AND JUST MAYBE IF WE ALL WISH IT TOGETHER THE PLANET WILL BE PURGED OF THIS GARBAGE....

After all of the negative reports that I have made on here concerning my problems with the S-Linc Modbus to MSTP Gateway I want to also report the Positive! We had a FieldServer and a JCI Rep come to our site on Tuesday and after they updated the firmware and the point list of the S-Linc we are pleased to announce that all systems seem to be working properly. I want to give a High-Five to FieldServer and JCI for getting to the core of the issue and making my Job 100%. I also want to let everyone know this is just an example of how perseverance and holding on to a principal can get you what you need to accomplish your goal. All-tho it should be said and repeated that it does not pay in monetary concerns to stick up for ones beliefs.

Sorry this issue has me really steaming, going through the same crap…..

Your original post had me thinking York/JCI garbage. I have several of these RTUs that have always been a total PITA. Several calls to tech support, none of which fruitful in resolving any of the problems. This was after 20-40 minutes of holding of course.

I gave up, we simply do not figure a week of time on a project to try and get them out to fix their trash, nor should we have to. I absolutely HATE integrating their stuff, it almost always turns into gigantic cluster fack.

I'm going round and round with an owner currently on one of their large RTUs that does not have the slink. All I'm doing is passing setpoints, and reading values.

Customer wants OA damper position. Pull it in, it’s labeled OA damper position in their interface & IOM. Customer "Why the (*@#$ is the damper position 0% when its at min position (not closed)?". Because that's what your pile of @*&# unit is telling me!!!

And this goes on, and on, and on, down the points list. Should have been a good project, now with all the meetings, letters, calls defending myself the project is totally tanked.

I FEEL YOUR PAIN AND JUST MAYBE IF WE ALL WISH IT TOGETHER THE PLANET WILL BE PURGED OF THIS GARBAGE....