Couldn't agree more with you. I'm more annoyed that there wasn't more warning given out that dataconvert.exe was going to be broken in this release as I was told it was going to be a long time before this utility would go away. Usually when mentor says "long time" it means years not months...
So how do you get hooks into the library so you can extract the information needed?
There are not any examples of Library creation using Automation in AATK in case your looking. The Library editors are new to the tool and I took care of all that stuff using HKP write and read because that is all we had at the time I wrote them.
I managed to figure it out, I asked the question before I really got a chance to take a good look at it. I got my hooks into it, now I just need to figure out how to extract the information I'm looking for.
There is a vicious rumor that you are getting out of the AATK business. Is John Dube or someone else going to lead us users to the promised land of none ASCII manipulation of library data?
I do scripting to solve my customers problems that they are facing today. Trying to do the impossible, make products faster, better and cheaper with the current release of software and not waiting 3-9 months for a patch. I have always had the philosophy that if your going to do something once do it any way you can but, if you are going to do it again, automate it.
I took over the AutoActive Tookit (AATK) from Otaki-San. We (Thanks for all those who helped!) expanded it to include the Expedition Enterprise flow giving you the whole customer base examples on how to make menu items, icons, pulldowns and script for Dx, CES, Expedtion, XE, Drawing Editor.... I see from the statistics on Source Forge AATK has been downloaded 3030 times. It had the first support for dogbones (early teardrops), testpoint control and insertion, FlipChip design, Advanced placement routines, full IDF support, voice control of the router, Fabrication flows... I guess from the lack of emails I get the vast majority of the users grasp the concept that it is a non-supported toolbox that they can use as a template for their own scripting efforts and that they have the source code to make it do whatever they want. You can see the value in AATK if you look at this way, I would probably charge $5000 for AATK and it has been downloaded 3030 times. That is $15,150,000 yes 15 million dollars.
I have done the majority of AATK on my own time. It is not in my job description, I do not get paid for it, I am an Applications Engineer. I do it because I love to help people and I want to see Mentor Graphics succeed! My boss Mike Walsh has also been very supportive. For those of you who used BoardStation, You know Mike has the same philosophy.
As far as getting out of the AATK business, I have been very depressed lately becasue I am an open-source type guy and my main problem is how do I fix the customers problems without re-writing what was just taken away? If I do, will I get shunned by Management that I need support from for my customers? I'm torn. What the heck am I supposed to do?
For those of you that are use to Kendall responding in these forums. Kendall has also personally attended users' group conferences to offer incites, support and training on automation programming.
Thanks and here's to your continued success.
Kendall has always been a big help anytime I hit a roadblock with any of my scripts!!
As you may have recognized already, we have moved this discussion into a dedicated sub-community, which will be focused around the migration of HKP use cases.
You also have seen that we have posted a couple of documents.
The first document is addressing frequently asked questions.
The second one is a form, which we ask you to complete for your HKP use cases. This will help us to validate each scenario and a possible (current or future) solution.
We will shortly open an exchange here as well, where you can upload scripts and macros or download examples from Mentor or other customers.
Thank you for actively working with us and making this migration successful.
Let us please add some clarifcation.
It is correct that we announced changes to the HKP Import and Export licenses with the release of EE7.9. We announced these changes now, with 7.9. We raised the visibility of the future change with the introduction of these new licenses.
We believe it is important to highlight, that the ASCII Import and Export have not been disabled in EE7.9. This might be misleading. No work is gone, no workarounds have been removed.
We have introduced new licenses for Decryptor and Encryptor, which we will ofcause provide to customers, who require any of these licenses in their process.
Our engineering team is very responsive. We have reviewed an approved a number of requests for licenses already as they have been submitted to ASCII_Answers@mentor.com.
We do not take away functionality our customers need in their current process. We will give these licenses to our 7.9 customers, who really need to edit HKP data.
But we want those same customers to work with us on a better solution, whether it is our effort tp create open format for the export and import of library data, improvements in Automation, better integration with 3rd parties, especially Open Door partners, or better solutions for our customers in the tools directly, to handle the use cases that you, our users, identify as critical.
We need the constructive feedback or our customers, we need you to work with us to identify the holes and opportunities for improving our solutions.
Our customers are critically important to us. Our management has dedicated a great deal of personal time and energy to insure that we don't walk away from any of our customers.
Please work with us to explain what you need to be successful.
We are committed to your success and when we finally stop supporting HKP files, you will have a superior solution.
thank you for clarifying MGCs point of view. It's good to hear that HKP will be alive for some further time, and hopefully we will get an automation-based solution sometime in the future - but I'm convinced that this will take a long time.
In http://communities.mentor.com/docs/DOC-2043 I read that you want to provide HKP for only one more year. This is by far to short to allow a transition to any other solution to your customers. Up to now we couldn't even judge if automation enables us to do what we actually are doing with HKP - up to 7.9 automation was only partially available in LibraryManager. We have set up workflows based on HKP that have been in use for years and that are proven to work efficiently. And now you expect us to transfer them to automation within a year? Don't forget that our main job is not to develop software around your tools, but to create high performance pcb designs in an efficient way.
I'm convinced that one can create very efficient solutions with automation - I even can admit that I'm a fan of it. But programming takes time and it is not my primary job and neither the one of my system administrator. If everything else in the EE workflow would be fine and no automation would be required to come to an acceptable level of productivity with the workflow, one year would probably be sufficient. But there are so many open issues where we have to put our programming ressources in, that a transition period of at least two years seems to be the absolute minimum to me.
Now, let's talk about communication:
You claim that mentor announced the changes of HKP im-/export licenses. If this is the case, then why don't we find any hint of it neither in the release notes nor in the highlights?
To me, this looks like you originally wanted to remove HKP silently, and only after massive critics you decided to publish the new DataDecryptor license (originally probably only intended for MGCs internal use). Why didn't communicate it upfront? This would have saved a lot of time for us, your valued customers.
I'm slightly confused about your wording in "we ... approved a number of requests..." In my opinion, you don't have to approve anything - if a customer needs the HKP license, he has to get it immediately without having to fill in any forms. You may ask him to explain his requirements, but this shall not be a prerequisite for getting the license. I'm convinced that most customers would willingly describe their usecases for HKP, but this shall be decoupled from the time-critical request for the licenses. If you want a serious description of usecases, this takes more than a few minutes...
OK, I took the time to fill in those forms and placed a request last friday morning on ASCII_Answers@mentor.com. Up to now I didn't even get an acknowledgment of receipt...
We're using SymbolWizard, a tool that MGC bought a few months back (Formerly Valor / formerly PCB Matrix), and it requires HKP for part impot into LibraryManager. That means we have a software that we payed you money for, and we're not able to use it acually, just because someone decided to switch off ascii import without any clear upfront information to the customers.
You may think "Don't worry, in a few days we'll get you back on track" - but my company pays my team to be productive, and not to play around, wait, and look for workarounds (Which we luckily found, you may just use the converter of a previous version to encode the HKPs.)
If you're seriously interested in providing a superior design solution to your customers, then get in close personal contact with your customers to exactly understand their requirements. Bring your product managers and software engineers in direct contact with the end customers - the electronics engineers and pcb designers - and give them the time to study and understand the usage of your software in productive environments.
I'm still conviced that Expedition is the best pcb layout engine, but the entire workflow around it is still very clumsy and brings the overall performance down.
Let's start to really work together to make an improvement on it.
I'd happily welcome you here in my company and have my staff members demonstrating you what our criticisms are based on.
you are 100% right.
There is a little more history behind the announcement. The first time that Mentor said that they were thinking about dropping the hkp/ASCII interface was a couple of years ago. The user community reacted the same way it is reacting now. Many people said no way and this is what we are doing with that interface. Most of the user cases of use have not been addressed in the mean time. The users had heard so little about the idea until now that some of us had thought that Mentor had gotten the point and dropped the idea. Such was not the case.
It is my understanding that PCBMatix/Mentor is releasing a new update in a few days that will not need the hkp interface to move cells into Library Manager. OK if you are under a maintenance agreement. Interesting thought about Symbol Wizard; I have not asked about Symbol Wizard since I believed that the DxDesigner symbol import was not an hkp interface but another ASCII format that DxDesigner had been using.
Other than that. Have fun
I'm aware that dropping of HKP was around for a long time (We've had a discussion on that during the German U2U in 2008), and in principle I'd say this is OK for me. I'm absolutely sure, that on a long term view we may get better and more comfortable results with automation.
My concerns are about the way it was communicated and about the short transition time. I would expect to get the information that HKP will be dropped or the like from the support pro newsletter -that's one of the reasons I have a subscription on it. I don't have the time to scan all SupportNet pages for all products we use just to find out if there is any relevant information. And if you enter the EE7.9 download through the DxD page, you'll never find Dan Boncellas letter to the customers.
Until now we didn't have write access on library objects through automation, and now they expect us to migrate to automation within 12 months - and still nobody has proven that you really can do everything you could easiely do with HKP by automation.
That's why we need more time for the transition....
Regarding Symbol Wizard and DxD:
You're right, originally SymWiz only created the DxD Symbol. But about two years ago I got in contact with PCB Matrix and requested that they also create the part information (mapping) as required by the expedition workflow. And Michael Bitzko implemented this function within a few weeks for me (and hopefully many other users later on). And now the part creation workflow really rocks - in many cases you have the cell already available and you only need the symbols(s) and the pinmapping (part.hkp). With SymbolWizard you can extract these informations from datasheets (PDfs etc.) within a few minutes and import it into LibraryManager. A high pincount part can effectively be created within a quarter of an hour or so.
4 years later...
One of the things that is missing with automation is the "library services".
We implenet the functionality with the HKP files.
Is there a road map for implementing "library services" and other library functionality by automation?
Otherwise why do you ask every 6 months if we still need the dataconvert license?