Page 2 of 5 FirstFirst 12345 LastLast
Results 14 to 26 of 59
  1. #14
    Join Date
    Jun 2008
    Location
    NE PA
    Posts
    36
    Quote Originally Posted by BACnet View Post
    The existence of such a document, (not to mention multiple revisions of said document) doesn't exactly portray the ProtoCessor in a good light...

    Not trying to judge. but it does not look good
    At this point I am leaving the situation back in the hands of York/JCI

    I have talked to many different people and I guess Fieldserver will build on any spec and communication protocol it all depends on what you want to spend on it and how well you want it to operate... (you get what you pay for)
    Everything you do
    Will come back to you So...
    Do What You Love and Love What You Do

  2. #15
    Join Date
    Feb 2005
    Location
    Edmonton, AB Canada
    Posts
    584
    Quote Originally Posted by DCVoltZ View Post
    <snip>

    I have talked to many different people and I guess Fieldserver will build on any spec and communication protocol it all depends on what you want to spend on it and how well you want it to operate... (you get what you pay for)
    Good day DCVoltZ,

    If the people you spoke to and/or FieldServer says that they (FieldServer) only build what they are told to, then I call bull crap on this. It is true that a suppliers/manufacturers will cater to a customer's wants, but I have a hard time believing that if these wants have inherent issues/problems that the suppliers/manufacturer would knowingly implement these issues/problems given that it is their (supplier/manufacturer) name on the end device. In other words would not the manufacturer have a vested interest to ensure that their good name/reputation is maintained in the products they develop?

    Even if the customer had a spec that was flawed and the flaw known to the contractor/supplier/manufacturer, would it not be the responsibility of the contractor/supplier/manufacturer to correct/inform the Customer?

    To me it seems that there is finger pointing going on instead of the various parties banding together and investigating and addressing an issue.

    Cheers,

    Sam

  3. #16
    Join Date
    Jun 2008
    Location
    NE PA
    Posts
    36
    Quote Originally Posted by s2sam View Post
    Even if the customer had a spec that was flawed and the flaw known to the contractor/supplier/manufacturer, would it not be the responsibility of the contractor/supplier/manufacturer to correct/inform the Customer?
    IMOHO They may or may not have even known of the issues at hand. I been in this trade for over 20years and been working in and on computers for even longer. The Idea of Alpha, Beta, Gama testing has gone by the wayside. The supplier/manufacturer of any electronic device or technology does not do what we did back in the 80's to prove said devices. The steps now seem to be alpha straight to gamma.. meaning from the idea test bench to final product working in field. So we in essence of being the ones that first buy the product get to be beta testers. Beta Testers used to get something extra, like extended warranty discount pricing or some kind of retribution. but why do that when there are people doing it for free....why because they do not even know they are doing it.
    Everything you do
    Will come back to you So...
    Do What You Love and Love What You Do

  4. #17
    Join Date
    Feb 2005
    Location
    Edmonton, AB Canada
    Posts
    584
    Quote Originally Posted by DCVoltZ View Post
    IMOHO They may or may not have even known of the issues at hand. I been in this trade for over 20years and been working in and on computers for even longer. The Idea of Alpha, Beta, Gama testing has gone by the wayside. The supplier/manufacturer of any electronic device or technology does not do what we did back in the 80's to prove said devices. The steps now seem to be alpha straight to gamma.. meaning from the idea test bench to final product working in field. So we in essence of being the ones that first buy the product get to be beta testers. Beta Testers used to get something extra, like extended warranty discount pricing or some kind of retribution. but why do that when there are people doing it for free....why because they do not even know they are doing it.
    Good day DCVoltZ,

    Indeed, the issues may or may not have been known... but if the problem lies within the FieldServer I would expect FieldServer to sort it out...it is their device and only they can fix their own product...Placing blame on what they were told to do is a sidestep. Bugs do happen, so deal with them (the manufacturers that is). I say this not to be caviler, but Bugs are a part of any device. I have equipment in the field that appeared to be bug free for years only to have an event occur which caused the bug to arise.. I have been designing equipment for over 20 years and what I do know is bugs will occur no matter how much testing is done... thus design your product to allow for bug fixes... If we can do it and we are not even a rounding error, to a rounding error, to a rounding error in the earnings of the big companies, then I find it unacceptable when I hear the big companies (100's of million, Billion, etc) say they cannot do it.

    As for testing, you are quite right that product roll-outs have much less testing than they once did. Time to market, upper management, bean counters, etc seemingly place pressures on Engineering departments to roll out products much sooner than some would like. On the other side Engineers like to always test, test, test and there is a point where you do no need to release a product... As an Engineer myself I am always uncomfortable with a new product release no matter how much testing I have done. It is the nature within the breed. That being said ideally how much testing versus product release should be decision made by both Upper Management and Engineers (Product Manager) so that each party's and the customers' concerns/interests can be addressed...

    Anyway my apologies for the thread diversion...

    Cheers,

    Sam

  5. #18
    Quote Originally Posted by s2sam View Post
    Good day DCVoltZ,

    If the people you spoke to and/or FieldServer says that they (FieldServer) only build what they are told to, then I call bull crap on this. It is true that
    To me it seems that there is finger pointing going on instead of the various parties banding together and investigating and addressing an issue.

    Sam
    Well finger pointing between whom knows, humm, all I know is two of my well seasoned techs have spent over 100 hours (out of my pocket) trying to get integration into 11 York RTUS complete with no faults.

    How the hell are we suppose to price a job when we run into crap like this and the manufacturer, and rep takes their sweet ass time on responding? We care about the customer more than the manufacturer does, AND during this whole time we are trying to complete a LEED GOLD commissioning, getting heat from the commissioning agent, GC, MC, and whoever else that likes to scream!

    The manufacturer needs to set this crap to ULTRA HIGH PRIORITY and get this straightened out, they need to have one of their GEEKS, sitting next to my GEEK, and get this FIXED, and if Filedserver is in the mix, get their GEEK out there too, instead of sending a box, my two guys driving out, installing the fix, find out there are still issues, then loop the process again. In my case over 5 times now! THIS IS BULL****!
    Intelli-Building = Less Stress, commissioned with diligence!

  6. #19
    Join Date
    Mar 2005
    Location
    Pacific Time Zone
    Posts
    4,151
    I was looking at a FieldServer solution but if this is how the system works or should I say doesn't work I'll be looking at another solution.

  7. #20
    Quote Originally Posted by crab master View Post
    I was looking at a FieldServer solution but if this is how the system works or should I say doesn't work I'll be looking at another solution.
    Well you can tell that I am really pi**ed off, but I think that I have the right to blast their butts, when this saga has been going on for three months! How long a time before the manufacturer JCI/York, and Fieldserver take a SERIOUS OWNERSHIP, this is financially killing the job, and they hem/haw around like they have all the time in the world. We did round 5 a week ago Friday with no response!!

    I am afraid this is going to end up in litigation, which is a waste of everyone's time and money!
    Last edited by paulir; 05-29-2012 at 03:21 PM.
    Intelli-Building = Less Stress, commissioned with diligence!

  8. #21
    Join Date
    Aug 2009
    Posts
    2,459
    Paulir-

    If these chillers speak modbus natively and you're having a hard time getting the modbus gateways to work, would it be possible to pull them into the front end as modbus devices?

    I realize you might have to pull some wire but stopping the hemorrhaging and successfully getting off the site is probably your number one priority right about now.

    Please take this suggestion with a grain of salt, I'm just tossing out options...

  9. #22
    Join Date
    Jun 2008
    Location
    NE PA
    Posts
    36
    Quote Originally Posted by BACnet View Post
    Paulir-

    If these chillers speak modbus natively and you're having a hard time getting the modbus gateways to work, would it be possible to pull them into the front end as modbus devices?

    I realize you might have to pull some wire but stopping the hemorrhaging and successfully getting off the site is probably your number one priority right about now.
    As for me like I stated in the beginning If it was not for my customer I would have already done the modbus but my customer is wanting what he spec'ed so here we go! I do not know how it got to be about chillers because my issue is RTU's. If you could see how they wired the modbus side you would want to scream out... modbus run inside a RTU Mech panel ran in thhn wire no shield and wires run right past primary power. standard wiring practices ??? nothing standard here. As a Control contractor you can plan for the worst as I did totally separate MSTP Comm port, isolated wires kept away from all power sources, shield is properly landed, EOL's in place and I even placed a oscilloscope on it just to make sure of my square wave. Just to have all of this Trump by the manufacture cutting corners on equipment labor and practices. Its just not right!
    Everything you do
    Will come back to you So...
    Do What You Love and Love What You Do

  10. #23
    Join Date
    Apr 2007
    Location
    Amarillo by mornin'
    Posts
    850
    Quote Originally Posted by paulir View Post
    Well you can tell that I am really pi**ed off, but I think that I have the right to blast their butts, when this saga has been going on for three months! How long a time before the manufacturer JCI/York, and Fieldserver take a SERIOUS OWNERSHIP, this is financially killing the job, and they hem/haw around like they have all the time in the world. We did round 5 a week ago Friday with no response!!

    I am afraid this is going to end up in litigation, which is a waste of everyone's time and money!
    Went through the same thing with a 20 ton'ish JCI VAV/RTU. The new tenant had moved in before it was fixed so in the interim, I put in a N/C relay
    on the 24 volt side of the unit and wired it to another near by controller so the Maint. crew didn't have to keep going to the roof to cycle power on it to get it going again.

    Finally after 5 return trips, I met the JCI controls tech out there and I connected three different types of devices and proved to him that it was their POS not me!

    I heard he spent a combined time of just over two weeks getting it going.
    "It's not that I'm smart, it's that I stay with the problem longer”
    Albert Einstein

  11. #24
    It was stated that most control firms are small and do not have resources. Does this mean that control firms should not invest in tools and processes to identify issues with products or communication? What specific information is provided to manufacturers pointing to communication problems?

    Individuals state something like "I tried many other manufacturer devices on the network and they all work" or "the entire network worked fine until I installed this product". This provides mostly nothing in regard to proper diagnosis for a manufacturer. Any manufacturer rightly can dismiss this commentary as ineffectual. The only thing it does is call into question the roustabouts providing this type of non-information.

    Many manufacturers concentrate their efforts in areas other than the equipment control communication. Their limited staff is largely unacquainted with communication technology. Their controller works to run the equipment, and communication is an implementation of Modbus which does not have many rules placed for implementation. Such companies then typically will buy a communication interface product and make the non-thoughtful decision that this device needs to be inexpensive. The result is Heath Robinsonish. You get an unnecessarily patched contraption that does not work well.

    The better route would be to investigate and employ a more comprehensive controller design. Few choose this route.

    Any firm that makes the effort to identify communication failures can do well to notify the managers of the deficiencies and bill accordingly for lost job time not the fault of the installing firm.

  12. #25
    Join Date
    Jun 2008
    Location
    NE PA
    Posts
    36
    Quote Originally Posted by AtticusFinch View Post
    It was stated that most control firms are small and do not have resources. Does this mean that control firms should not invest in tools and processes to identify issues with products or communication? What specific information is provided to manufacturers pointing to communication problems?
    In my case I listed all issues tested and prepared a detailed itemized list of problems. We did our part from testing with an oscilloscope to trying everything I could think of doing. My correct statement was Most control Firms do not have the resources or time to fight to get what they paid for. As for the control contractor that does not do his homework in this day and age well the botttom is pretty deep better get your waders on!.. BTW we did get paid for labor but only barely and only after raising a big stink!
    Everything you do
    Will come back to you So...
    Do What You Love and Love What You Do

  13. #26
    Join Date
    Aug 2009
    Posts
    2,459
    Quote Originally Posted by AtticusFinch View Post
    It was stated that most control firms are small and do not have resources. Does this mean that control firms should not invest in tools and processes to identify issues with products or communication? What specific information is provided to manufacturers pointing to communication problems?
    In context, DCVoltz's comments weren't meant to indicate anything more than exasperation at the fact that this issue is still ongoing. He clearly has the tools and has been providing the manufacturer with exactly what is needed to understand this particular problem.

    Individuals state something like "I tried many other manufacturer devices on the network and they all work" or "the entire network worked fine until I installed this product". This provides mostly nothing in regard to proper diagnosis for a manufacturer. Any manufacturer rightly can dismiss this commentary as ineffectual.
    Indeed, I agree with you there 100%. That's why providing the Mfg's with network transaction logs eliminates the possibility that the provided information is circumstantial. Speaking [I hope] for all manufacturers, we really do appreciate getting that sort of feedback when there is a perceived problem. It wastes less of your time and less of our time.

    Many manufacturers concentrate their efforts in areas other than the equipment control communication. Their limited staff is largely unacquainted with communication technology. Their controller works to run the equipment, and communication is an implementation of Modbus which does not have many rules placed for implementation.

    Such companies then typically will buy a communication interface product and make the non-thoughtful decision that this device needs to be inexpensive. The result is Heath Robinsonish. You get an unnecessarily patched contraption that does not work well.

    The better route would be to investigate and employ a more comprehensive controller design. Few choose this route.
    Well in this case it appears that the modbus part is not the problem, (it seems to have been the gateway in this case), but your point does stand. Modbus is a very simple protocol to implement so it will continue to be a favorite choice among manufacturers who don't consider controls to be important.

Page 2 of 5 FirstFirst 12345 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
Comfortech Show Promo Image

Related Forums

Plumbing Talks | Contractor Magazine
Forums | Electrical Construction & Maintenance (EC&M) Magazine
Comfortech365 Virtual Event