The Rage (because) of the (Gateway) Machine

Quote:

---

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.

Anyone get anywhere with this problem?

I just had the S-links replaced for the third time in two months. Waiting to see how long these last.

Quote:

---

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.

Quote:

---

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?

If these fail for the fourth time I will be going the modbus route as well.

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.