No Responsibility: Factory Engineer Refuses to Confirm in Writing

[Ivan Seeking]

This sort of thing just kills me - sometimes literally, in a financial sense!

I have an application requireing that a large number of analog I/O be read very quickly. The manuals for the processor of chioce weren't crystal clear regarding my max tolerance of 5ms for data updates, given the data load. The local rep couldn't be sure either so we had a conference call with the factory for clarication. After about an hour the factory engineer finally agreed that this processor and card configuration can handle the load at speed. It will do it.

So I asked for that in writing. "I have a lot riding on this. If we're wrong, I will get sued. I have to be sure about this and would like confirmation from the factory." Well it says it in the manual, he replied. Yes, said I, but it took three of us - two product specialists - two days to figure out what the manual was saying. Surely you can understand why I want a confirmation specific to this application. All I need is an email stating that I can read each channel in 5ms given some configuration - what you just confirmed here verbally.

He wouldn't do it. He thought it was perfectly reasonable that I should be willing to put my reputation and career, and not to mention a lot of money, on the line, and risk getting sued, based on the language in the manual, but he wasn't willing to back up his words in writing - the words he had spoken a minute earlier.

 

[Ivan Seeking]

Oh yes, this company constantly innundates me with literature and brochures telling me how they are my "partner in business". Quite a partner, eh?

Flex, if your are reading this [I just saw you post elsewhere], I know you know what I mean. Flex lives in the same world as I in many respects.

 

[timthereaper]

I love corporate CYA. You don't mind throwing anyone under the bus just as long as your cash flow stays as undisturbed as possible.

 

[turbo]

When I was consulting for a pulp mill, updating and documenting the process control equipment related to their power boilers, Kraft chemical recovery boiler, T-G set, etc, I was required to carry $1M in liability insurance in case my documentation and operating instructions were in error and caused an accident. The problem with that is that I Fed-Exed in a fresh installment every month, and their engineers and supervisors were tasked with reviewing the information for accuracy. Obviously, they were not going to be training operators with information that had not been vetted, so why was I required to carry so much liability insurance? CYA.

 

[Proton Soup]

what if the hardware is capable of meeting the specs, but the implementation is flawed.

 

[Ivan Seeking]

what if the hardware is capable of meeting the specs, but the implementation is flawed.

Then it's my problem but that won't happen. The hardware is the issue. No matter how good you are, you can't process data that you don't have.

I see people make this mistake all the time when tuning PID loops. They are often looping at frequencies way beyond the data update limits and can't figure out why they can't stop the system from porpoising [or in some cases, self destructing!]. I hate to even guess at how much money I have made correcting that mistake over the years. I've seen people who are real pros at tuning caught by this; esp in systems where you have a very slow step response. In large systems, the step response to output changes can take as long as minutes. But the stuff that seems to fool people is on the order of one second. In systems where you can see a step response on the order of the scan time, a lot of applications people are oblivious to the significance of loop update times.

In fact, solving that very problem is what started my career as a contractor.

 

[Proton Soup]

Then it's my problem but that won't happen. The hardware is the issue. No matter how good you are, you can't process data that you don't have.

I see people make this mistake all the time when tuning PID loops. They are often looping at frequencies way beyond the data update limits and can't figure out why they can't stop the system from porpoising [or in some cases, self destructing!]. I hate to even guess at how much money I have made correcting that mistake over the years. I've seen people who are real pros at tuning caught by this; esp in systems where you have a very slow step response. In large systems, the step response to output changes can take as long as minutes. But the stuff that seems to fool people is on the order of one second. In systems where you can see a step response on the order of the scan time, a lot of applications people are oblivious to the significance of loop update times.

In fact, solving that very problem is what started my career as a contractor.

hmmm, sounds complicated. control stuff was a long time ago, but it sounds a bit like people end up mixing discrete and analog control elements? (or, perhaps discrete control elements that operate fast enough to look like analog wrt the data sample times) yeah, i just have no idea, i don't think i was ever taught any theory that mixed the two, or mixed different delta-t's.

 

[Ivan Seeking]

hmmm, sounds complicated. control stuff was a long time ago, but it sounds a bit like people end up mixing discrete and analog control elements? (or, perhaps discrete control elements that operate fast enough to look like analog wrt the data sample times) yeah, i just have no idea, i don't think i was ever taught any theory that mixed the two, or mixed different delta-t's.

Sorry, if you don't know the industrial processor world then that may not have all made sense. There is still a lot of analog sensing done. But you are still limited to sample rates for that data in the processor, but most esp for the application, and that limitation can tend to get buried in the background. For many applications it isn't significant so people from those environments often overlook the sample rate [which may or may not be independent of processor speed].

Either way the programming on this isn't too bad as long as the data arrives in time. I don't see programming being an issue on this application. But if we proceed with a processor that's too slow, I'm hosed.

 

[enigma]

Could you hook it up to some sort of supply giving some sort of random pulses going as fast as your sample rate and then filter it through a FFT to see if you're getting a result?

Would let you know for sure that the hardware can handle the response without having to burn your experiment which I'm assuming is exorbitantly expensive to run.

 

[Ivan Seeking]

Could you hook it up to some sort of supply giving some sort of random pulses going as fast as your sample rate and then filter it through a FFT to see if you're getting a result?

Would let you know for sure that the hardware can handle the response without having to burn your experiment which I'm assuming is exorbitantly expensive to run.

I could but I would have to buy it first. At $11K or so just for the processor and I/O cards, I would rather know it works first. Hopefully the local rep will be able to manage a test station with a factory loaner.

But I did put the ball in their court. If they aren't willing to give me a written confirmation that we're interpreting their manual correctly, why should I recommend using their product?

Btw, Enigma, it has been a very long time. Nice to see you poking around again.

 

[Borg]

I see this behaviour with government organizations also. For example, whenever I email a local or federal agency with a question, the response very often has the original question stripped from the email. That way, there is no proof that their answer was wrong with respect to the question that you asked. Those responses also tend to be more vague on details or copied and pasted directly from their website.

 

[Ivan Seeking]

Would let you know for sure that the hardware can handle the response without having to burn your experiment which I'm assuming is exorbitantly expensive to run.

I should mention this is for a new machine design. Trying to retrofit a different controller after the fact would be very expensive [easily in excess of $30K] and cause long delays. Also, I shouldn't have to do my own testing in order to confirm the factory specs. It just isn't practical. I can make plenty of my own mistakes without any help from the factory!

I see this behaviour with government organizations also. For example, whenever I email a local or federal agency with a question, the response very often has the original question stripped from the email. That way, there is no proof that their answer was wrong with respect to the question that you asked. Those responses also tend to be more vague on details or copied and pasted directly from their website.

I run into three different types of unreliable sources of information; usually from factory support people and product reps. The first is the person who will give a definite answer when he or she doesn't really know. The second is the person who tries to spin the answers so that you hear what he or she thinks you want to hear. Most common perhaps is the oversell. I have a specific question about product X, but instead of giving me a straight answer, they try to sell me a more expensive product. This is often done when they can't answer the question.

But, to be fair, I deal with many people who provide excellent support, as well. In fact, in this case the local rep has really done a great job. The factory was the disappointment. Usually it is the other way around.

The best support I ever received was from a soon-to-retire engineer with Baldor Motors. I needed to know everything there was to know about their 180VDC, 1/2HP, PM Motor. He was the guy who designed that motor. IIRC, he spent something like five hours on the phone going over the entire design while working from his personal notes... in fact, I seem to recall that he would have spent all day talking about it had I wanted.