At user conference 2008, I asked the SDD managment team these same questions. I will not try to report all of their responce for fear that I misstate them. The bottom line is that ASCII is going away, but Mentor did not give a time frame. The licensing/encryption had many reasons in their view. One of them is to help identify the communities dependence. They did mention some sort of substitute, but couldnt speak to details. It would be wise to develop away from ASCII all together, and use the COM objects
Manipulating ASCII data can be error-prone. And importing bad ASCII data into the Expedition toolset can be problematic and result in corrupted designs. Because we are now supplying Automation capabilities that allow you to directly manipulate design data in a controlled manner, you can manipulate your data through Automation without fear of corrupting your design data. Therefore, using Automation is the preferred method for manipulating design data.
In some cases, ASCII data can also reveal intellectual property that would be better left unexposed. This is another reason to encrypt the data as we have done in 2007.3 and beyond.
We will not charge our customers for the encryption and decryption software in the future. However, at some point, encrypted HKP ASCII data support will be removed.
We realize that we still have some work to do in order to supply Automation functionality for every piece of PCB design data and library data. And we will not remove the HKP ASCII Support until we are confident that our Automation capabilities allow customers to manipulate all of the same data that can be manipulated through HKP ASCII. Therefore, we don't yet have a date for the removal of encrypted ASCII support.
We strongly encourage our customers to start the transition from using ASCII HKP data to Automation interfaces now. This will allow us to work with our customers to ensure that we provide the solution they need to continue to develop complimentary tools for their specific design needs.
Our goal is to continue to provide tools that help improve your productivity. Although the removal of HKP ASCII support is an inconvenience for some customers at this time, we feel the adoption of Automation-based customer applications provides the best long-term solution for all customers. The Automation approach provides a sustainable, fully supported solution for years to come.
I hope this information is helpful.
At the moment, I have a rock solid ASCII out from boardstation for geometries. Which I can easily maniplulate (and reliably) to put it into the correct format for Expedtion. This allows me to maintain an accurate library for both Boarstation and Expedition (It is utterly unfeasible to trasnfer all designs across from BS to expedition, so I need to have an accurate sustaining engineering CAD system).
In the absence of ASCII in/ out, what is the no cost option for translating geometries from Boardstation to Expedition?
Thanks for the additional information. You have a very good point regarding the use of ASCII as a way to move BoardStation geometries into an Expedition library.
I am currently looking into the available "off-the-shelf" options that we may have available for your use. As soon as I have some additional information on this subject, I will send a follow-up response.
There is a set of free translators out on SupportNet. The link is:
There are several translators available. I think the one you will be most interested in is the LMS translator.
Please take a look at what is available there and let me know if it meets your needs or not. Based on your investigation, we can determine what needs to be done next.
Thanks and best regards,
Thanks for the reply. Unfortunatley we do not use LMS, so the LMS translator won't work for us.
Interestingly, the translator that would probably work, the Boardstation to Expedition translator, http://supportnet.mentor.com/downloads/related/upload/bs2exp.pdf tells you to create ASCII geoms as part of the translation process, and then import in to Expedition to create ASCII Cells (Which is effectively what we do at the moment, without the need to create a dummy job)
With the removal of ASCII in/out, this presents a problem for "official" Mentor translators, presumably.
I need a translator, that allows me to translate a single geometry and manipulate the data, which I can then use to create a cell. Or I need ASCII in/out.
Thanks for the additional information that you provided. I will work with the folks on our translator team to provide a more up-to-date solution.
Your information has been helpful and I appreciate the time that you spent to communicate your issues.
ASCII in-out is needed for some competition product to interface, mainly to generate the board and the geometries.
Two examples of them are:
The interface between BS and Specctra (now Allegro PCB router). As I know the (Mentor and Cadence) interface asks for a ASCII geoms file to correctly generate the needed files.
So I guess that since the two companies are still defacto competitors this is a way to discourage the users to easily interface between the two tools.
(Please correct me if I see this wrong, but I still like the fact that I can choose the point tool that I like the most). For more rambling you can freely look at the unfinished similar discussion that took place on the MUG international forum: "Poll: EE2007.3 ascii encryption"
- A tool that we use for calculate the reliability of the boards (a company named BQR- an official open door partner of Mentor) uses the ascii output to collect the board. They use the different net file, comp file, ascii geoms file to achieve import.
My guess is there are more companies that rely on ASCII for import-export operations.
The positives side is that now that Mentor has stared this discussion a lot of thought is put on way ascii on the long term was and still is a very good way to store and manipulate data.