How many service requests this year?

[infinitenothing]

I've been a little more active in filing service requests this year. I have:

• 3 open
• 1 RMA
• 3 CARs
• 12 created in the last 12 months

Thanks NI for giving me a resource to help me through the tough spots. I'm never leaving SSP if I can avoid it.

Thanks everyone else for all the CARs you generate before I have to generate my own reproduce case.

Edited September 19, 2017 by infinitenothing

[smithd]

I pretty much only make service requests when there is a problem that an AE can't solve, so I think I have a different experience than you

For example, did you know that labview RT for pharlap can deadlock at the OS level? Neither did I (well I mean in theory sure, but I'd never seen such a thing). There was no CAR for it, and there is still no CAR, because the AE wouldn't escalate unless they could reproduce it. Through trial and error I'm fairly certain its related to some combination of hyperthreading and IEEE 1588, but its impossible to know for sure because it isn't reliably reproducible, and theres nothing clear in logs or memory dumps or anything like that.

Either way, my answer is 6 in the last year, of which:

• 1 was resolved quickly and painlessly
• 1 ended up being another vendor's issue
• 4 didn't particularly resolve my issue

Edited September 19, 2017 by smithd

[Jordan Kuehn]

7 hours ago, smithd said:

There was no CAR for it, and there is still no CAR, because the AE wouldn't escalate unless they could reproduce it.

Having worked as an AE intern 8 years ago (wow, 8 years??), I'll point out that it's not the AE who won't escalate. It's the PSE or whatever they are called these days. No replication means it's an issue on your end. That was fun to explain to a customer. 

[Rolf Kalbermatter]

1 hour ago, Jordan Kuehn said:

Having worked as an AE intern 8 years ago (wow, 8 years??), I'll point out that it's not the AE who won't escalate. It's the PSE or whatever they are called these days. No replication means it's an issue on your end. That was fun to explain to a customer. 

But it's logical. Without a reproducing case there is nothing you can fix realistically. Sure you could send someone to check all umptien million lines of source code in LabVIEW, DAQmx, NI-488.2 and low level drivers like NI-KAL etc, but that is a task no person could fill in in an entire life time and still missing hundreds of potential gotchas. Unless it's reproducible it is not a bug, at most it could be your imagination or a cosmic ray causing it. 

And from my own experience as AE more than 20 years ago, and from application development for customers, if I can't reproduce it, there is a serious chance that the problem is indeed at the other end of the line, and not in the software I am supposed to support, no matter how angry a customer is about the piece of sh*t software he presumably bought. 

And if you have spent hours supporting such a customer and finally after many hours realize what error on his side caused it, it can be still a challenge to break those news to him in a sensible way. The people who tend to get most angry are often not very good in admitting their own faults.

Edited September 19, 2017 by rolfk

[hooovahh]

You got me wondering so I went and looked at the service requests I've opened and...it only lists 8 in 5 years.  I think it is missing some maybe due to account weirdness, but on top of that I realize I gravitate to the forums a whole lot more for support, which does make it harder to track.  Many times I'll have some issue like a crash in LabVIEW when I run a project.  Then I'll start minimizing the project to isolate the problem, then I'll post the test VI on the forums so others can try it out and convince me that it isn't just my setup causing the crash. Then eventually someone from NI will chime in and say yes this is a bug I've assigned CAR XXX.  If it is a major issue with no work around then yes I'll contact NI directly but if the issue can be isolated it can usually be worked around.  

Anyway of the 3 service request I've opened in the last year, one couldn't be reproduced, and is still a point of concern but hasn't been an issue in months, one I opened yesterday but is looking good, and one I opened a month ago because of a licensing issue that NI hasn't been able to resolve.  That being said I've always been impressed with NI's ability to help out.  I also thought Microsoft did a pretty good job with support too.

One major downside of the forums for CARs is while it might get more attention at first, it is easy to just lose track or ignore requests.

[smithd]

4 hours ago, rolfk said:

But it's logical. Without a reproducing case there is nothing you can fix realistically. 

And from my own experience as AE more than 20 years ago, and from application development for customers, if I can't reproduce it, there is a serious chance that the problem is indeed at the other end of the line, and not in the software I am supposed to support, no matter how angry a customer is about the piece of sh*t software he presumably bought. 

Not really, an issue is still an issue, even if it isn't actionable. If there is one thing I learned, there is absolutely zero way for me to predict what CARs get fixed and what CARs get shoved on the backburner and ignored for a decade.

In this case we're talking about an OS level deadlock, outside of any application code on a software and hardware platform sold directly by national instruments.Regardless of if its reproducible or not, its still an issue to be reported, and there is no reasonable way for it to be my problem just because I'm the only person who hit on the specific combination of magical conditions to cause it. NI literally sells us this stuff on the basis that things like this just dont happen.

6 hours ago, Jordan Kuehn said:

Having worked as an AE intern 8 years ago (wow, 8 years??), I'll point out that it's not the AE who won't escalate. It's the PSE or whatever they are called these days. 

PSEs are part of R&D, so I consider talking to them an escalation. AEs have to be willing to accept that they don't know something and actually ask the PSEs for help.

Edited September 19, 2017 by smithd

[Rolf Kalbermatter]

31 minutes ago, smithd said:

Not really, an issue is still an issue, even if it isn't actionable. If there is one thing I learned, there is absolutely zero way for me to predict what CARs get fixed and what CARs get shoved on the backburner and ignored for a decade.

In this case we're talking about an OS level deadlock, outside of any application code on a software and hardware platform sold directly by national instruments.Regardless of if its reproducible or not, its still an issue to be reported, and there is no reasonable way for it to be my problem just because I'm the only person who hit on the specific combination of magical conditions to cause it. NI literally sells us this stuff on the basis that things like this just dont happen.

Was that on an NI RIO hardware or a standard PC used as a RT system? If latter then there is still a very realistic chance that it is due to some specific hardware version of chips in your system. They tend to have all sorts of bugs that can negatively affect software. Systems like Windows contain a lot of pretty involved software hoops in the hardware drivers to work around such bugs. Even Pharlap has that but to a much lesser degree since they are not used as much and not on as many more or less mainstream hardware systems build with all kinds of components from sometimes rather obscure sources. PCI bridge implementations are very well known to not always follow the official standard to the letter and even those standards are regularly revised and improved to better support certain advanced modi.

Even if it is NI hardware this is still true, but then NI should be with some effort able to reproduce it.

From the sound of your error description it looks like a race condition somewhere in the kernel that can under very specific circumstances cause a mutual exclusion lock somehow.

Edited September 19, 2017 by rolfk

[infinitenothing]

See, whenever I have a bug in my code where "it works on my machine" I just build a debug version of the executable, transfer it to the computer in question, set some breakpoints and discover that there's some unexpected combination of things that I never accounted for. It's then usually just a matter of putting in a retry or upstream validation and the bug is solved. I really wish the AEs could do something like that. I feel like it would solve 70% of my problems in 20% of the time. I feel like the other method of making random modifications to my code so the bug magically goes away really does us both a disservice because the bug is going to come back for no reason for both me and a few other customers.

[infinitenothing]

4 hours ago, hooovahh said:

One major downside of the forums for CARs is while it might get more attention at first, it is easy to just lose track or ignore requests.

We all have those. This is one reason why people are afraid of xcontrols. I think there's some code base that everyone's afraid to touch:

https://forums.ni.com/t5/LabVIEW/XControl-quot-Data-Change-quot-Event-only-fires-when-different/td-p/418552/page/2

Edited September 19, 2017 by infinitenothing

[hooovahh]

Oh only a known bug for 11 years on value change not working properly?  Kinda seems like something someone might run into all the time.

6 hours ago, smithd said:

If there is one thing I learned, there is absolutely zero way for me to predict what CARs get fixed and what CARs get shoved on the backburner and ignored for a decade.

Oh so true, new quote for a signature?  Possibly.

[smithd]

7 hours ago, hooovahh said:

Oh so true, new quote for a signature?  Possibly.

Yay!

Edited September 20, 2017 by smithd

[Rolf Kalbermatter]

Your sentiments you posted in your first unedited post are fully valid. NI has gone from a small technically driven company to a middle sized bean counter controlled company. It can feel rubbish at times. But I'm not sure you or I will change that in any way. Their customer support is still above average in many cases but if the problem gets difficult you can run into a brick wall sometimes and the people in support are not allowed to leave the predefined channels even if they don't work.

But without a proper reproducing case that also shows the symptom on a system that NI can test on, there is nothing anyone could do about this. The PSE in question will shoot down any CAR without at least a clear description how to reliably reproduce the problem. Unless you can show NI in a convincing way that you will buy for a few millions of extra hardware if it works .

Edited September 20, 2017 by rolfk

[smithd]

(for context, I just said that my real issue in this case is ni's relationship management. I dont necessarily expect my issue to be fixed but I do want to feel like someone gives a damn. But I decided this wasn't a worthwhile rabbit hole to go down so I removed it.)

4 hours ago, rolfk said:

but if the problem gets difficult you can run into a brick wall sometimes and the people in support are not allowed to leave the predefined channels even if they don't work.

I guess my view on this is that the AE role is should be to push against the PSEs as the customer advocate even as the PSEs push back and help prioritize quality issues for their R&D groups. I think you're right that AEs are taught to stay in as you put it this vaguely defined set of channels, but whats the point of hiring engineers to do a support job but then not empowering them to really do the job? To be harsh about it...anybody can google some terms and throw KBs at people until they go away :/

Edited September 20, 2017 by smithd