Saw this come through today: https://www.ptc.com/appserver/cs/view/solution.jsp?n=CS174472
Who writes these things? Why would anyone write a product spec to randomly name files when batch printing?
I could understand if they said, "oops, we didn't think about that", but instead, "we designed the product to name your files is such a way so that you have absolutely no idea what they are." Really?
The specification didn't exist before you complained... but now that you complained, miraculously, it does exist, -and- what do you know, it meets it -perfectly- !
Thank you for bringing this to our attention. I've pulled this article from the public domain and submitted it for rework by an engineer in that product area.
In the future, the "Did this document help you?" feedback widget is available in the lower right to let us know how such documents can be improved.
Here is another one that came out today. Seems like a similar issue.
I find it hard to believe that the product specification actually spells out this behavior. It seems more likely that this is undefined in the spec., and therefore automatically considered in compliance (since no other behavior is specified). Absence of pre-defined behavior in the spec. shouldn't equal compliance, especially when the resulting behavior is completely illogical (unless it really isn't).
I guess the root issue is this, if tech support is going to tell me something "works to product specification", then I expect them to be able to produce that portion of the specification both proving it and explaining the "why" behind it. Doing so would help us understand the software better and maybe even show us new/better ways of using it.
How long would it take for the database Admin to make a search of that database for "Works to product specification" and flag each one that doesn't link to the applicable product specification? Years, probably.
There aren't as many as I would have thought.
Total number of visible support documents - 140,391
"works to product specification" - 1,581 (731 are for Windchill and 41 of those are for 10.2)
"intended functionality" - 336
Combined this is only 1.3% of all documents.
Given the effectiveness of the KB search engine, the total could be 2X or 3X or more of that.
In addition to the 'effectiveness' of the KB search engine and even more ways to say the same thing, keep in mind that customers cannot see other customer's cases and resolutions, UNLESS the PTC rep specifically writes up a separate document.
It seems that it is not a large percent of cases where this happens as I have searched the database for an answer, not found it, opened a case, and TS refered to a document I did not have permission to view...until he wrote something up and 'published' it. This has happened more than once. The more of these documents PTC publishes, the easier it will find info on our end without having to open a call.
Several years ago I was sitting at the PTC User conference over lunch with the head of tech support. I expressed my frustration with the canned "intended Functionality" response, which is what they used to say instead of "works to product specification". He told me that if the support rep tells you that he ought to be able to produce documentation to support it. Ask to see it if you think he's simply trying to close the case without action.
I have asked on several cases to produce documentation, but even on the cases where I think it was legitimately accounted for they have never produced any kind of documentation. When pressed they just tell me what R&D said, and their reasons. Have you ever had success asking for this? And if so how do you word it?
Frankly, no, I've never actually gotten anything back. The closest I've come is receiving custom written documentation from R&D explaining certain aspects of Pro/e that were (and still are) undocumented. Making the request for proof does help me move cases to higher level personnel who often have a deeper understanding of the software. The vast majority of the cases I open end with the tech saying, "please create an idea on the PTC community". I don't think I've ever been told "why" something is a certain way. I'm slowly learning that "why" really doesn't matter. Instead I make sure I really understand how it is supposed to work, then either submit suggestions to change it, or find a way to work around it.
I have decided that tech support is a resource. "no question to dumb" kind of thing.
However, I have received some really bad replies. If I am not satisfied with the response, I tell the tech that I will escalate the case to get a better understanding. This often spurs additional action on the part of the tech.
What really gets me is the circular arguments...
My problem is X
Your problem is Y
My problem is obviously not Y, it is X.
Your problem is not X or Y.
My problem is still X.
Your problem is &
My problem is not & because it is not even in the same context.
Your problem has been resolved
My problem is not resolved. I shall escalate.
No, please! I will ask why & is not related...
My problem is tech support.
Your problem has been resolved. & works to specifications.
And then they raise the cost of maintenance for the high quality support services I am receiving.
To be honest, I call tech support so infrequently I have not had the opportunity to use this. Tech support is almost always too slow for our needs.
Tech support always responds in a reasonable timeframe but often had not even opened the attachments or reviewed the problem. I try not to submit cases because it is a whole lot of work for me! Even the simple ones result in 3 or 4 phone calls.
I have found TS to be either hit or miss. Sometimes it is awesome and very fast, and other times it is slow and useless results. Then there is everything in between. Quite frankly though, if no one reported bugs, there would hardly be any fixes and the software would be a whole lot more frustrating and time consuming.
Like it or not TS is necessary. Personally, I like aspects of it while acknowledging there is room for improvement. On most of my recent failed calls, the problem has not been with TS, but what R&D/Management and the decisions they are/have been making. When something doesn't work TS is really just the messenger, and recently I have found them to be more helpful and communicate better than in past experiences...Well that's providing you don't get those reps who just want to close/"resolve" your case in 'record time'.
Let's see which is more productive... Support or this forum.
I have a high business impact issue. It is in relation to basic dimensions and leaders.
Creo adds a gap on prefixed dimensions when the text is to the right of the leader.
This is not in accordance with ASME or ISO.
And there is no way to fix this in Creo 2.0 M040 that I can find.
Anyone else experience this?
I will report back on how tech support handles this.
Not bad, a return call within 1/2 hour and a confirmation this is not just my imagination.
Now we have to wait to see how this gets spun.
In the meantime... shall we lay odds:
1: Works to Specification
2: An SPR has been filed
3: A Pro|WorkAround^TM
I am going to go out on a limb and vote on #2, with the evenetial fix being implemented on existing drawings using the Update_Drawing to a value of either yes or your specific SPR #.
Speaking of which, did you try the setting this hidden drawing option to yes?
I am leaning toward #2 also.
Since the feature is being created in the current version, the update_drawing will not change anything. This is only if the drawing was created in an earlier version. That option is simply a small subroutine that goes in and tweaks some data in the file. I doubt that it is a good idea to leave the option active at all times.
I checked and problem also exists in Creo M110.
We use a mapkey to do this whenever there is a problem. It is amazing the number of problems it fixes on old dwgs (we typically reuse dwgs via save as instead of starting new ones). I have been using it more and more routinely and have not yet noticed it creating any problems. For us it has been very good and fixed a lot of problems that would otherwise take much longer to fix or work around.
I suspect it is like a registry-cleaner routine for scrubbing files and making them compatible again.
I fully concur with Antonius' post about tech support not reviewing the case notes. The last three cases I created had the information added before I even completed the case for the questions the person asked.
This drives me absolutely batty.
I recently had a case where after two weeks the tech says he found a solution and sends me an article. Problem is I already mentioned that article and how it doesn't solve my probem in the very the very first comment I created the same day I opened the case.
I actually posted to the case, "Please don't take this wrong, but did you actually read all the comments I've created?" Never did get a answer to that question...
Here's another one. It's like the people writing the spec's don't actually use the software. I just don't get it.
You know you're dealing with tech support when you see "Works to Product Specification"
You know you're dealing with Marketing when you see "You know, this is a valuable feature and we're going to charge extra for it"
I'm less frustrated with tech support and more frustrated with the person who wrote the spec. Why in the world would someone go to the trouble of making it possible to display an image on a part but then not have it display on all the copies of that part in an assembly? Maybe there is some good reason. I just can't figure out what it would be.
The image uses resources to regenerate, so by only having it show once, PTC can claim that performance is improved.
Yes it is Friday!!