Post a reply to the thread: The Rage (because) of the (Gateway) Machine
You may choose an icon for your message from this list
Please enter the name by which you would like to log-in and be known on this site.
Please enter a password for your user account. Note that passwords are case-sensitive.
Please enter a valid email address for yourself.
Will turn www.example.com into [URL]http://www.example.com[/URL].
With products such as these the problems have a tendency to be multiple. To start a manufacturer that cannot properly produce a communicating controller, but they desire they should manufacture and design everything from their product internally. Naturally, they feel their product is ace, blinkered from reality. These manufacturers next realise they must conform to specification agents who request varied protocols. Realising this technical expertise is not internal they shop for what is typically the bottom cost outside vendor as the manufacturer is not invested in the outcome, as they feel their controller works on some rudimentary level for communication. The manufacturer wants to minimise costs and only utilise a gateway when absolutely necessary. The gateway manufacturer comes into the scenario and likely deals with a substandard manufacturer control device. If the gateway manufacturer is not good, problems are simply compounded. An observation: there are control manufacturers able to handle multiple protocols admirably. I do not see these installed much as original equipment. In my opinion the gateway devices you do see these manufacturers use is substandard. The manufacturers are not investing the proper amount to provide adequate product. It would be advisable that contractors take measures to understand the product and properly make a comprehensive report to the owner and responsible specification agent. The contractor should also send this to the manufacturer stating they are unfit for use in projects. Most often this does not occur due to many factors and contractors try to resort back on some solution that partially may function. To be fair it would seem many contractors do not have the knowledge or time to report comprehensively on product defects to get compensated for their time wasted on a project, so they are snookered. What does get attention from manufacturers is constantly dealing with failure as failure costs money. These manufactures want costs to end after shipment. It is imperative contractors gain the skills necessary to force extra investment from the manufacturer on matters. For problems stated here I would request the manufacturer continually send out representatives daily until the problem is resolved and force a position whereby they are unwilling to arrive, they get penalised or have product removed.
If these fail for the fourth time I will be going the modbus route as well.
Originally Posted by paulir We just abandoned the S-LINK ran a new network wire and we are talking just fine thru Modbus. How the hell they get away with bull crap like this amazes me. Wait till they get MY BILL, yes that's right, I don't BETA test for FREE York/JCI. I might add I told the MC to hold back money from them on another project. They will be getting back charged for the 80 plus wasted hrs. Wasted hours we could have been productive elsewhere. I am really pissed that these clowns can't straighten there crap out and make it work. Just sell us your stuff with anti cycle protection timers and pressure switches and let control with stuff we trust. And JCI owns YORK they should be fricken ashamed of all the bull **** they are putting us integrators thru! Shame, shame, shame!!!!! Enough FIX YOUR CRAP! Do I sound pissed?
Originally Posted by lwarren I just had the S-links replaced for the third time in two months. Waiting to see how long these last. We just abandoned the S-LINK ran a new network wire and we are talking just fine thru Modbus. How the hell they get away with bull crap like this amazes me. Wait till they get MY BILL, yes that's right, I don't BETA test for FREE York/JCI.
I just had the S-links replaced for the third time in two months. Waiting to see how long these last.
Anyone get anywhere with this problem?
Originally Posted by orion242 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.... It doesn't look like it's even isolated to their S-Link (Protocessor) either. Was trying to get 3 YORK water cooled chillers to talk BACnet. It showed in the IOM to be "Auto-Baud" selecting (WTF?) The York start up tech came out and I told him my troubles and was told "Good luck with that, our controls tech's have a heck of a time with that also..." Holy $h1T! JCI/York can't even intergrate BACnet with their own stuff?!? That was after screwing with them on and off for three days. I gave up and set them all to Modbus and they haven't missed a beat since. Maybe York/JCI just can't get BACnet figured out. I dunno, but I know they are the worst at interfacing with.
Originally Posted by DCVoltZ 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....
The new Carrier Open system is native bacnet, Doing a job now with 45 CV RTU's and 3 VAV RTU's going with Bacnet Spyders for the VAVs. I prefer lon myself but what are ya gonna do.
Patience = how many years worth? DCVoltz - you should talk to/look up Sysint.
Originally Posted by DCVoltZ 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? Patience is a virtue young grasshopper.
Originally Posted by DCVoltZ 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). Cheers, Sam
Originally Posted by s2sam 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. 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!
Originally Posted by DCVoltZ 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. Cheers, Sam
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
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.
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?
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. Mine are App software version V2.01j Firmware revision 6.05c(B)
I only have a screenshot of the BACnet Device Manager to go by, here's what's in our gateways: Vendor: FieldServer Technologies Model: ProtoCessor Firmware Rev: V5.17c (E) App SW Version: V2.00d (K)
Forum Rules
