100% support for your point!
As anyone who supports the Expedition/DxD/DC-DV products and needs to recover from dumb actions and crashes, installs the software at new sites, builds libraries and sets-up long term archival and RETRIEVAL will tell you, the loss of the HKP/ASCII is a major pain. How important is it: The last ECAD installation that I did, the company didn't go with Altium, spent twice the money for Expedition/DxD and one of the prime reasons was ASCII manipulations to build the libraries that saved enough time and money to offset a lot of the higher costs. Mentor is being a penny wise and a pound foolish.
100% support for your point!
We would like to weigh-in on this discussion. We appreciate the feedback that we have received and the passion demonstrated around our recent message concerning HKP availability. Thank you.
We are committed to provide our customers a better, safer and more secure way to do what you are doing today with HKP automation. Over the years we have found that HKP manipulation is error prone, not secure and at times has created unsupportable situations. As we work through these changes it would be very beneficial for us all to look at this from a slightly different perspective. It would be really beneficial for us to understand what is needed from us to allow you to move away from your current HKP automation?
We understand that there are many different use cases currently deployed; some customers have written their own interfaces into corporate PLM systems to exchange and modify library data. To address this use case we are actively working on a very light weight and robust interface into PLM systems that provide this exact capability that is much safer and secure than what you have today. It will be releasing soon and but there still is time to provide feedback to ensure that we fully understand how you want to exchange and modify library data.
Some customers are using HKP based automation to perform automated librarian functions. We now provide automation API support for all library editors within Library Manager and next year will have automation support for Library Services. What else is needed?
Someone said they use HKP automation to create BGAs. Is would certainly be possible to do this through the automation interface. But there might be even a better alternative: PCB Matrix came to Mentor through the Valor acquisition. PCB Matrix has an excellent generator for land patterns: LP Wizard. Isn’t this a good opportunity to evaluate this product, not only for the generation of BGAs, but also to evaluate, which of your automation around footprint / cell generation could be resolved with this parametric generator?
We developed and released a great Automation Tutorial describing how to write scripts using our Automation API and it is on SupportNet accessible to all at this location:
The expanded documentation of our automation interface provided within our online documentation describes its robust capabilities. The API is now so rich and robust that we actually use this very interface to produce a number of the features and functions we provide within Expedition today.
We are committed to work with you to help transitioning your existing HKP automation to an automation API based solution. We understand that this might require some extra effort for you, creating scripts to replace the old HKP functionality. But ultimately it will ensure your processes to remain stable by using API calls and not depending on data structures that can change as we see need in the evolution of Expedition Enterprise.
We will continue to enhance our tools as needed to give you the capabilities you need to replace your HKP automation. In addition we have enabled you to exchange with other customers in the PCB Community, exchanging scripts you may have developed and want to share, or searching for scripts you may be looking for. You can find the Automation and Scripting community here: http://communities.mentor.com/community/pcb/automation_scripting
Mentor will not leave our customers behind, and we will be working with you through this transition process. We will continue to provide ASCII Decryptor and Encryptor licenses to those need. But we need to understand the use cases, so we can account for these use cases going forward. We will continue to respond quickly to your questions, comments and feedback related to this topic and have set up the mail address firstname.lastname@example.org. We look forward to hear from you there.
Hello Big Brother,
If Mentor thinks that their solutions are better, more secure, cost effective, whatever, why not let the customers/users to decide how and when to switch to an alternate solution?
Today as EE7.9 is released we can not switch to it because it breaks our flow because of the HKP issue......
Is there a chance to get a license to free dataconvert in EE7.9?
We could prepare for the automation solution for the next release.
I was thinking of writing an automation program to export/import the part data in hkp format.
Ofcause we will provide our customers with a free licenses to the ASCII Decryptor and the Encryptor. But we want to understand the use cases and requirements much better to prepare for the future changes.
It is important for us to make sure that our customers will be able to get their job done without problems. At the same time we want to make sure we are understanding the situations that cause you to require HKP.
We have defined a process for users, which you can find here: http://supportnet.mentor.com/news/Change-Import-Export-EE.cfm
BTW, the first time when the upcoming changes were announced more specifically was with EE2007.3, over a year ago. Meanwhile we have gathered a number of use cases via email@example.com. This was helpful to understand, where customers are using HKP and how. But we know there are still a number of use cases that we do not understand yet. And we know that customers are using HKP in different ways for similar use cases.
While the first series of responses have led to significant enhancements in automation and tutorials, we know that there is much more work to be done on our side before we can consider the transition away from HKP as being successful.
Please help us with your use cases and submit your request to firstname.lastname@example.org.
Well, maybe Mentor could keep HKP import/export at least for Library items only (parts, cells, padstacks)?
Well the sun is now up in the new world and I have been looking at this nonsense for a couple of hours. So here we go.
I HAVE been making comments to Mentor and the community since the first whispers of the death of the ASCII interface. So far, NONE of the uses for and techniques done with ASCII file data have been addressed by Mentor in the product user interfaces. I have done presentations at user group conferences on the need for ASCII in long term archival and retrieval and library management. In the forums (and in off-line) I have walked users through database recovery, moving cells from Drawing type into other types when people have built their libraries wrong and creating, building decade sequences parts, etc. So anything that may not have said directly to Mentor is still public and in places that Mentor should have been reading. They have been stated on the Mentor/users group conference calls.
Everybody in this discussion writes scripts and programs. We all know that we can kill our databases with bad code. But there is an added layer of filtering out bad data when using the ASCII importation that we don't have when we do direct data manipulation. So I don't understand the import bad data reason for dropping hkp interface.
Everyone in this discussion not only supports the company that they work for but also other users outside of their companies. When one is walking a novice through a library build or problem, letting them work in ASCII and tools (editors) that they understand gives them a sense of confidence. Remember, they are trying to save time and money building their libraries or fixing problems. Their fear is real and not based on getting a boat load of parts done in a hurry but that their jobs are hanging in the balance if the new ECAD system does not start producing and paying for itself. Those 20,000 to 50,000 part libraries that Mentor delivers, like Mentor's competitors, just don't seem to be enough. They are at the same time trying to learn a large complicated CAD system and the philosophy behind setting up that CAD system. So it is better to stay in a tool that they understand. Maybe I see this a little differently than some of the others because I install ECAD systems besides designing aerospace boards. And now another question. Why is it that after working with the Expedition family of software for twenty years one still can't open a library partition, copy or create one resistor, then have Library Manager automatically generate a (standard) E24-E96 decade sequence of parts and naming them based on a set of rules? It is not like nobody has asked for this.
The company that I work for owns a copy of PCBMatrix LP Wizard and I copied down and loaded their Expedition cell libraries a month ago. I remember using the hkp importation to get those cells into the partition. Do you have another magical way?
The projects on which I work have life spans of 25-35 years. One of the best archival formats for long term archival and retrieval is to store the data in a man-readable ASCII format. As you may have write a translator some time in the future if the CAD company decides to change CAD data format in the mean time. Maybe more than once.
You see, I noticed that you did not address my comments.
Also, I must admit that I missed that announcement that the BS Neutral File was being dropped.
I run the Great Lakes regional Mentor users group. Joe, I invite you to come to our next conference and describe to us in detail the benefits we receive of dropping the hkp import/export since so many of us have been unable to grasp them.
If We can wait a long time, I agree your opinion. But I hope you can reconganize the fact Mentor can't provide any solution in time and no user is willing to waiting the solution until Mentor are ready. In today world, things get changed.
this is a good discussion, and largely without emotions.
We all must admit that technology evolved over the last decade significantly.
Here are a few examples:
Functional and pin density more than quadrupled
High speed constraints became a must have in almost every design
Almost every other design has at least one FPGA
A library is not just a schematic, a footprint and a mapping. It is has dependencies into other teams.
Customers are focusing on productivity increase and are seeking for solutions to tighten up their communication and collaboration between PCB design, FPGA design, analysis teams, the MCAD groups, production engineering and shop floor.
In the center of this we have the PCB development process. the PCB design cannot be seen stand-alone anymore. If you twist and tune here in isolation, you might possibly interfere with the work of others.
HKP is doing this in isolation. It does not consider dependencies, it only focuses on the PCB database.
What worked 10-15 years ago may still work today, but will hold us back to evolve to address the needs of tomorrow.
We are committed to continue to provide the best board design flow. That requires innovation. Innovation often comes with change.
Change is all around us, whether its the extinction of the analog cell phone or evolution from analog satellite TV to digital. Change can be inconvenient, until we see the benefits.
When change is being announced, well in advance, we can prepare for the change. Thats what what we do here and now.
Old havits die hard. If we do not keep the heat on us as human beings, we will not be able to change. In our case this applies to us as the provider and all of us as the PCB community. If we do not embrace change, we will have difficulties to evolve our methods.
We are re-announcing this evolutionary step now, well in advance.
We know where what the goal will be, but we cannot reach this without you.
We have about one year to get this done - together.
We are asking for your constructive input, making sure we do cover the needs you are addressing with HKP today.
Your input is essential.
To help you to provide this input in a structured format we will deliver a mechanism to you within the next couple of days.
Please stay tuned for this announcement shortly.
The new v2010.1 LP Wizard with encrypted HKP export will be released on June 30 (in two weeks).
It will be a fully Mentorized version with a new FLEXlm license, Mentor Installer, new Mentor Splash Screen and Desktop Icon, all known bugs fixed and several new features.
There will also be a new LP Wizard website, new "unlimited" 30-Day evaluation license and LP Wizard on SupportNet available on June 30.
Note: the new v2010.1 LP Wizard will no longer support the ASCII HKP file.
EDA Library Product Manager
Mentor Graphics Corporation
Mentor says : Automation is the best solution. Maybe. But which librarian is a SW-Developer and speaks VBScript od VisualBasic very well?
Many things in manipulation Symbols or Cells I do very quickly in ASCII.
I´m not a SW-Developer.
Here is are a example, that automation is not the best way:
Change the font and font-height of a property in all DC-symbols in my library:
1. HKP out
2. Replace DEFAULT with Arial and the new height (by Textedit or Wordpad)
3. HKP in
4. Well done in 10 min per partition
My best way in Automation (Automation increase my productivity (Mentor says so)):
1. I have to run around to find someone, who speaks VisualBasic or VBScript.
2. Explain him the task
3. Then he write a script after he understand the DataModell
4. I have to pay himal lot of € or $
5. It takes a very long time
6. My boss say to me: Change your CAD-System
By this way there in no increase in my productivity!!!!! It takes a longer time -> so the costs decreases.
One important thing is: Mentor overlooks and forget, that a librarian is NOT a SW-Developer. Maybe all can be done with automation, but who will this done?????????
I can only accept the End of ASCII, if Mentor writes the script we needed in a short time and without costs for us.
In the past i havehad a lot of trouble with Jobs, (BoardOutline disappears -> Solution Job to hkp and insert a BoardOutline, Traces fixed and locked and so on. Wrong entries in Library done by LibraryManager, ) and i could repair these jobs in a very short time by using ASCII. Will Mentor solve my problems in a very short time and off-time?
The Tools from "PCB Matrix" may a good way, but it means additional costs for us!
I think, the view of Mentor-Management is: Customers are only a self-service shop.
Like a rocket the idea to keep dataencryption for HKP jumped to number 3 in just three days.
Thanks to all for supporting and discussing. (What a pitty, this are not the billboard charts )
Now its ours, as Joe requests, to tell Mentor why we still need HKP. It's not that we just want it back, we need it back.
We have to tell them why we still need this functionallity (for us it is one, not a workaround).
So please feel invited to go on with the open discussion here, so everybody can share his needs.
I'am sure we will find many commons.
Just a thought, is it possible to manage the library with 2007.8 while working with Design Capture+Expedition 7.9 ?
Another thought, Is it legal to limit the functionality of the program while we are paying maintenance for improvements in new releases?