Jump to content

Presumptuousness


Recommended Posts

<rant>

So, as some regular readers may know from my previous posts, I spent a few days last week struggling to figure out whether my PCI-6601 Counter/Timer board was capable of performing the pulse generation that I was trying to do. After striking out in my attempts to find applicable examples or knowledge base articles, I tried posting here and at the NI forums. At the suggestion of Ben and our local field engineer, I called NI's application engineers. The application engineer just refered me to the same knowledge base articles that I'd already found. When I pointed out that none of these really did what I was looking for, he concluded that what I wanted to do might be possible, but it would be up to me to decide whether figuring out would be a good use of my time.

Now, fast forward a week. I gave up on trying to make the 6601 do what I need. Instead, I'm using an external NAND gate to operate on the 6601 output and everything is working fine. This morning, I got an email from NI that starts as follows:

QUOTE

One week ago, our Application Engineer suggested a resolution to your service request number XXXXXXX. At this time, we presume that the suggestion indeed solved your issue.

Does anyone else find that second sentence somewhat off-putting? Just because an AE spent 15 minutes talking to me, saying "Read this. Read that." doesn't mean that he solved my problem.

What rubs me the wrong way is that implication in that email was that a) NI's documentation is so clear and b) the customer is so naive that all it takes to solve a problem is to politely tell someone to RTFM (or in this case "RTF Knowledge Base"). At least that's how I read it.

I think "we hope we helped", rather than "we presume we helped" would be a much less arrogant way of dealing with customers.

As far as I recall, this is my first question to an AE - maybe others have had better results.

</rant>

Link to comment

QUOTE (Gary Rubin @ May 22 2009, 08:13 AM)

<rant>

So, as some regular readers may know from my previous posts, I spent a few days last week struggling to figure out whether my PCI-6601 Counter/Timer board was capable of performing the pulse generation that I was trying to do. After striking out in my attempts to find applicable examples or knowledge base articles, I tried posting here and at the NI forums. At the suggestion of Ben and our local field engineer, I called NI's application engineers. The application engineer just refered me to the same knowledge base articles that I'd already found. When I pointed out that none of these really did what I was looking for, he concluded that what I wanted to do might be possible, but it would be up to me to decide whether figuring out would be a good use of my time.

Now, fast forward a week. I gave up on trying to make the 6601 do what I need. Instead, I'm using an external NAND gate to operate on the 6601 output and everything is working fine. This morning, I got an email from NI that starts as follows:

Does anyone else find that second sentence somewhat off-putting? Just because an AE spent 15 minutes talking to me, saying "Read this. Read that." doesn't mean that he solved my problem.

What rubs me the wrong way is that implication in that email was that a) NI's documentation is so clear and b) the customer is so naive that all it takes to solve a problem is to politely tell someone to RTFM (or in this case "RTF Knowledge Base"). At least that's how I read it.

I think "we hope we helped", rather than "we presume we helped" would be a much less arrogant way of dealing with customers.

As far as I recall, this is my first question to an AE - maybe others have had better results.

</rant>

Hi Gary,

Your experience is one of the main reasons I have been such a nut-case about answering questions on the NI forum. I was ashamed of the type of support novice LV user where recieving and had it within my power to help, so... well the rest is history.

I have been working with "support" from one company or another for about 30 years. Over that time I have learned that the quality of support I get is really up to me (no I am not blaming you!). So here are smoe suggestsions.

1) If not geting help from AE, call the local rep. THey can get your call escalted.

2) Do your research ahead of time and make it clear that none of the published info holds the answer.

3) Don't trust them to "get back to you". Let them put you on hold and listen to elevator music.

4) When you do need to let them off of the phone make sure you know their name (this is psycological, if you know their name you have power) and the SR#.

5) Get them to commit to when they will get back to you and ask for it in writting. Tell them "THen if I do not hear from you by X I will be calling".

6) Get them to read back to you the exact specs of your request before you let them go.

7) If they can't get an answer then ask "Can we please escalate this issue?". They don't like escalating but it gets the request in front of the appropriate product support for that product.

8) If they do not escalte ask the local Ni rep to get it escalated. They make money from you buying their stuff so it in their interest to get the stuff working.

9) If the AE you talk to does not know what they are talking about, just call back and log another service request (I call this Support roulette).

And to grease the skids going forward...

If you get good support from an AE, ask for their supervisors name and e-mail and send an "atta-boy" or "atta-girl" letter. THank you letters are rare these days so your name will spread internally and eventually they will know not to feed you bovine-scat.

For there are a couple of questions my fellow developers hear me saying every time I call NI for support;

A) Are you premiere support?

B) Have you been warned about me?

Again I am sorry you had that experience.

Your brother in wire,

Ben

Link to comment

Thanks for the advice, Ben (as always).

I understand that, as you indicated in #2, it's important to let the AE know that they're talking to someone with LV programming experience. Given the marketing thrust embodied by the Express approach, I'm sure a large portion of calls to the AE line are from novice users and can be solved by simply pointing the caller toward available resources.

I am sympathetic to the AE's. How do they know the technical level of the caller? Talking to a novice user as if they were a LV expert isn't helpful, and talking to an experienced wireworker as if they were novices leads to grumpy people like me. Just asking the caller about their level of expertise isn't particularly helpful either, as the response isn't very well calibrated. I guess that's where the field engineers come in - they supposedly know their customers better.

Link to comment

Gary,

I have had a wide variety of experience with NI technical support and IMHO it sometimes really boils down to the person you interact with. Sometimes I've had better luck starting with the local reps I know then calling and asking for "random" support.

I'm finally coming back to this forum after a long and exhausting project, I've had some experiences playing with the PCI-6602 cards in my applications, is it too late for me to bother looking at what you had posted?

-Pete Liiva

Link to comment

QUOTE (cbolin @ May 22 2009, 10:15 AM)

Yes, I did fill out the survey. You can't complain if you don't provide feedback, right?

QUOTE (peteski @ May 22 2009, 10:21 AM)

I'm finally coming back to this forum after a long and exhausting project, I've had some experiences playing with the PCI-6602 cards in my applications, is it too late for me to bother looking at what you had posted?

Pete,

I would certainly appreciate any wisdom you could provide.

The original post here describes what I was trying to do.

Thanks,

Gary

Link to comment

QUOTE (Gary Rubin @ May 22 2009, 08:13 AM)

One week ago, our Application Engineer suggested a resolution to your service request number XXXXXXX. At this time, we presume that the suggestion indeed solved your issue.

I think that it's sent out automatically if nothing is updated in the support database, which means that the AE didn't make any notes like "got a call from customer and we talked about stuff". If NI doesn't hear from you for a while then all they can do is assume that you don't need their help anymore, so they assume that your issue was solved (I think when it's said like that then it's not too much of a stretch).

Maybe "At this time, we presume that the suggestion indeed solved your issue" should be replaced with something like "Has your issue been solved?"

Link to comment

Best advice I can give.

When you find a good AE, get his/her direct line number and put it in your contacts list.

I've been using the same guy for the last 3 years and you don't have to spend 15 mins going through all the secretarial rubbish to get to talk to someone :P

QUOTE (Gary Rubin @ May 22 2009, 03:27 PM)

I think what you are after is the Counter Gate. (CTR n GATE) It enables you to Start/Stop/Mask counters (if configured). You have to sacrifice a PFI, but if I remember correctly, the 660X series have loads of them anyway.

Link to comment

QUOTE (ShaunR @ May 22 2009, 04:13 PM)

Best advice I can give.

When you find a good AE, get his/her direct line number and put it in your contacts list.

I've been using the same guy for the last 3 years and you don't have to spend 15 mins going through all the secretarial rubbish to get to talk to someone :P

I think what you are after is the Counter Gate. (CTR n GATE) It enables you to Start/Stop/Mask counters (if configured). You have to sacrifice a PFI, but if I remember correctly, the 660X series have loads of them anyway.

Nice catch, ShaunR! That should be able to make it work. I forgot all about the Gate functionality.

Getting rusty in my old age!

-Pete Liiva

Link to comment

QUOTE (peteski @ May 22 2009, 07:21 PM)

Nice catch, ShaunR! That should be able to make it work. I forgot all about the Gate functionality.

As far as I can tell, and someone can correct me if they've gotten this to work, is that the Gate applies for input counters, the Pause is the equivalent for output counters (i.e. pulse generation).

Link to comment

QUOTE (Gary Rubin @ May 22 2009, 07:46 PM)

As far as I can tell, and someone can correct me if they've gotten this to work, is that the Gate applies for input counters, the Pause is the equivalent for output counters (i.e. pulse generation).

I've got to dig through the documentation to trigger my memory on that. When I get a chance I'll have a look.

-Pete Liiva

Link to comment

QUOTE (Gary Rubin @ May 23 2009, 12:46 AM)

As far as I can tell, and someone can correct me if they've gotten this to work, is that the Gate applies for input counters, the Pause is the equivalent for output counters (i.e. pulse generation).

Indeed. But you can use can set the output to trigger off of an input and gate that input (just wire it to the other output). I think the "Pause" just pauses the generation from the software making it difficult to synchronize continuous pulse trains. Whereas Gating is done at the hardware level.

Link to comment

QUOTE (ShaunR @ May 23 2009, 04:18 AM)

Indeed. But you can use can set the output to trigger off of an input and gate that input (just wire it to the other output). I think the "Pause" just pauses the generation from the software making it difficult to synchronize continuous pulse trains. Whereas Gating is done at the hardware level.

I've taken a quick look through the documentation and examples, and it looks like it should be doable by combining the "Gen Dig Pulse Train-Continuous-Pause Trigger.vi" with with a "Gen Dig Pulse Train-Continuous.vi". First start the first counter with "Gen Dig Pulse Train-Continuous.vi" which will be the "clock pulse" for the second counter, then start the second counter with the code from "Gen Dig Pulse Train-Continuous-Pause Trigger.vi". The code from "Gen Dig Pulse Train-Continuous-Pause Trigger.vi" would have to be modified to tell the second counter to use the output from the first counter as its sample clock. This I think should be doable using the "Sample Clock" instance of the "DAQmx Timing" function in the DAQmx palette.

BTW, the "Gen Dig Pulse Train-Continuous-Pause Trigger.vi" calls for a digital line for the Pause, that would imply to me that it is a little more hardware driven then software driven.

I don't really have the time right now to try to verify any of this, though. I'm taking a 3 day course on how to write engineering requirements. :(

Hope this helps,

-Pete Liiva

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.