That is a major jump.  One tip - pay attention to your config.pro settings... if you see anything odd occuring there may be a conflict with old config.pro settings.  This has bit us a couple of times. ... View more

I was hoping there would be a system parameter in creo for a drawing report field.. but I could not find one   One way would be to use CREOSON to list the features by type, count them up - and then create parameter(s) with the number of bends that could be displayed on your dawing using a parametric name reference.   That is not automatic / parametric - would have to be ran every time manually - but would work.   Dave ... View more

Wow - BUT I can see the benefit if the license floats and can be easily used by multiple people.   It completely appears to be worth the investment -- IF YOU KNOW WHAT YOU ARE DOING. :) ... View more

I can't tell from your email if you are just trying to run some sample code to get the basic interface working for a previous synchronous application, or writing something new.   Just as a suggestion... IF you are working on a "new" application and you want to be asynchronous...   Check out CREOSON - it is FREE and uses JSON transactions for a LOT of common things.  Maybe easier and faster to get up and running with for whatever you are trying to do in the end.   Hope this helps! Dave ... View more

Ok - Shameless plug here... (because it is nearly 100% what you are looking for using Coordinate Systems)   Here are a few examples of how Nitro-CELL does it (from excel):   Assemble Model Assemble Model Wildcard Assemble All Root Model Wildcard AssembleAll Model Wildcard AssembleAllRoot Model Multi-Wildcard   THAT being said - I *think* you are on the right general path... However, I don't know why you would want to just add models in space...  Typically, assembly operations have purpose (e.g. assemble components to skeleton / sub-skeleton, etc.)   Hope this inspires a bit... or encourages a different approach.     Dave ... View more

Notebooks are a special case relative to relationships... they are BOTH parents and children of related parts/assemblies at the same time.     We try to avoid using them as they overly complicate understanding of relationships when dealing with models that need to be driven by other input sources (e.g. declare/undeclare has always been a pain to deal with and manage).   This is also part of why we created Nitro-CELL back in the day - to avoid these Independencies and more easily manage the logic and flow of data without the odd dependent relationships.   Specifically - allow individual master models to be reused and manipulated by other Excel Worksheets (like Layouts) - without the whole declare/undeclare cycle - or just use a completely different Excel Worksheet to drive the same core design (e.g. USA version vs Europe logic).   Just my $0.02 on this. ... View more

Yea - CREOSON uses JLINK for the Windchill interface - so it is quite limited in this respect. Good luck! Dave ... View more

Sweet!  Congrats on getting that to work! Dave ... View more

@James62   I think you need a CREOSON to do the following:   "windchill" "set_server" "windchill" "authorize" "windchill" "set_workspace"   THEN   "file" "open"   I think you are missing a few commands before trying to perform the operation.   Dave   ... View more

@jfojtik  mmm -- this should be a really simple thing.   You should just have to do a windchill set_workspace  - then a normal file open...   Can you post the CREOSON code transactions you are trying to execute?   Dave ... View more

@James62  I think you posted this code in the wrong thread.     CREOSON does it completely differently.   Dave ... View more

I saw this recently - I must say - it looks VERY COOL - and VERY USEFUL.   So many people *think* they know GD&T (ahem - they don't!) -- this looks like a great tool.   I don't know if they have an eval of this - but I would reach out to them to see if you can evaluate it.   Please write up a post of what you think if you do.   Dave ... View more

 @JoaoGoncalves ... Well...we use the Windchill interface all the time for automated back end processes ... specifically to take a Bill Of Materials (BOM) as an input, connect to Windchill, create a local workspace, then retrieve components and assemblies ... building the final assembly on the fly. OR, again Windchill specifically, just retrieving components from windchill for batch modification/updates.         The CORE of CREOSON is used in commercial products like Nitro-CELL, Nitro-BOM and Nitro-PROGRAM which are used by our customers to automate a variety of things using Excel.     CREOSON specifically can be as a local application service to integrate CREO Parametric with your existing application(s) (e.g. CREO Parametric becomes another thing to talk to much like a database, excel, text file, or web service vs embedding everything inside CREO Parametric and reaching out to those other data targets).   CREOSON an also be used for local task-specific applications (e.g. I can't put logic in a mapkey to run the right commands, but with CREOSON I could evaluate model state/condition/information quickly and then make the right calls to get to a desired result faster).  <-- we see this frustration a lot!   As a bonus, CREOSON enables remote manipulation of CREO Parametric (over your network or over the Internet).  No one has really talked about this capability yet and it is not perfect today; however, there was someone early on in the discussions that caught on to the potentials through.  This is a bit of a mind-bender for most users who see CREO Parametric as "in front of them" always.  We all know cloud services are coming like a Freight Train... I personally see CREOSON easily enabling customer-internal, cloud-based, micro-services using CREO Parametric at some point very soon.   The services could easily expensive replace commercial configurators, quoting systems, etc... and reduce the need for outsourcing.  This could be easily done by choosing a more modular and direct approach to delivering highly accurate results very quickly via CREO Parametric - and do it remotely, and headless...  (ex. web page to collect requirements, submit, requirements validated, new part/assembly generated with documentation, results available for download within 30-seconds....)  <--- Note: We have done this in the past for a few customers.   There are MANY use cases for CREOSON... the beauty of it - generic, simple, very powerful and can be easily integrated/leveraged by ANY scripting/programming language that can execute JSON requests over HTTP (locally or over the internet)   CREOSON is a bit of clay... it is up to you to figure out what you want to build with it.   I hope you dig in and give it a try -- I am already blown away by what people have done so far.   Dave ... View more

James,   WOW - you are the MAN!   Oh regarding Windchill... I think we are not going to be adding many more functions specific to Windchill for a while... we are using JLINK ya know... (limited functionality) :)   Dave ... View more

Hi Mauro,   Glad to hear CREOSON was working perfectly! :)       We created the JSON interface as a "generic" solution for any language to use.  We are not experts in every language, VB is a good example of something we have used - but only when necessary.   The best advice I can give is to look up how to execute a HTTP request to send/receive JSON data using Visual Basic and start experimenting.  The toughest part is going to be figuring out the request/response communications, once you have that figured out... you can focus on CREOSON and automating CREO Parametric with it.   The examples are included in the documentation for how to use CREOSON - look at the Functions section in the Help Documentation, you will find the specification and often more than a few examples of how the requests/responses look.   Once you figure out how to execute JSON requests with VB, I am sure many others would appreciate any solution you come up with.  So please share what works.   The YouTube was meant to be a "taste" of what could be done with the interface... not actual instruction - more motivation. :)     Thanks again for your positive feedback. Dave       ... View more

CREOSON Update... Documentation is one of those critical things that we have always struggled with delivering cleanly and efficiently.  The biggest problem has always been delivering documentation that is easy to find and use - and accurate to what you want to do. After a bit of thought, and since CREOSON uses a HTTP (Web) Server locally for the JSON Interface to CREO Parametric, we are doing to deliver the documentation via the same HTTP Server.  The documentation will include pretty much everything required to get going and use the JSON API - for the specific version you would download and use. We thought about hosting the documentation somewhere on the web, but that just seemed like a pain for users in the long run.  Specifically, as new functionality gets added, older distributions may be confused when things don't work properly -- because the user found the latest doc via Google and the current version on their machine is NOT that.  I know, that sounds like "duh" -- but it happens more than you can think.  This is an even bigger problem when inputs/outputs change within an API over time -- something we are striving to avoid. Here is the current plan:     Application Services : http://localhost:8000/creoson     Documentation: http://localhost:8000/doc This is not final yet, but we are working on it over the next two weeks.  We hope to have an initial beta out soon.  If anyone is interested in being on that short list -- please reach out. Dave ... View more

Well - being that this is OpenSource .... and the core is written in JAVA.... you *could* add your own functions via a JNI Interface.  There is no reason you could not add an interface to support your own functions - assuming you have the licenses to build the Pro/TOOLKIT / ObjectToolkit libraries and distribute them internally. Our primary reason for using JLINK started years ago... everyone had it - typically installed by default with Pro/E / Wildfire / CREO. asynchronous communication enabled us to "not require Corporate IT department involvement to install/configure software" <--- HUGE! Java was less code to get down the road than Pro/TOOLKIT (back when we started writing our core interfaces) Java was pretty much already installed everywhere also.  (but today -- our commercial apps like Nitro-CELL include JAVA with the distribution to remove machine localization and version problems that we came across over the years) We could do pretty much everything we needed to do, and our customers needed to do, with JLINK for ProE / Wildfire / CREO Automation Purposes...  Our approach and philosophy was waaaay different than the typical Pro/TOOLIT developer's approach to automation that we have seen over the years.  Most of our automation processes have focused on the "flow" of data and regeneration ... not creating everything from scratch like a user does..  So JLINK satisfied our goals in this regard 10+ years ago -- just as it does today. I think the biggest thing we have learned, and tried to teach our customers over the years... Pro/E / Wildfire / CREO have ALL gotten better and better and better as a modeling and documentation tool.  IF you are planning for change, it will respond and execute properly -- IF you have planned ahead ... specifically the workflow of what data goes in, how and when to produce the desired results.  So we encourage our customers to think about the flow of data and execution -- INSTEAD of what a "user does" to get to the same result.  Specifically - TRUST CREO will do what you tell it to...  When you step back and really look at it that way - things get easier, and are more repeatable and useful.  There are going to be barriers you hit, but that is when you fallback to "how does a user fix that issue?" --- START EXAMPLE --- Years ago I was talking to some corp Pro/TOOLKIT developers about our interfaces and how we do things.  One example that came up was to "update all the parameters in every part of a large assembly".... I asked them "how would you do this?' -- the answers mostly came back -- "open the assembly, walk the tree, look for a part, process each part you find during the walk, keep track of each part processed and skip them if they come up again." My response confounded them... "NO!  Open the assembly, get all the parts from memory, process each part... regenerate the assembly.  DONE!" They sat there dumbfounded for a sec.  Until the lightbulb went off and they realized that they were looking too close at the problem!  They got caught up in the complexity of the Assembly structure on the screen and forgot that all the unique parts were just sitting in memory no need to walk an assembly structure to get to any of them...  just get "what is in memory" and process those! --- END EXAMPLE --- The above example highlights the approach we fundamentally use for Automation of CREO.  Sometimes the simplest, fastest and most efficient way to do something is NOT to look at the screen. Hope this is all clear.  Thanks for inspiring a detailed response. ... View more

Stay tuned...  We will be pushing forward on this soon... I hope we can get something out there initially within the next few weeks if possible. We have a LOT of functionality that we have built up over the years... So we may start with the obvious things and then dig deeper into more functions later. ... View more

We are currently working through the details of "how" to properly OpenSource this... if you have any suggestions please throw them out.  We "may" release a Node.js module also to play with at the same time (depends on our workload).  But Javascript and Node.js are VERY popular these days - very flexible.  But that stack has its own issues and learning curve.  Other languages (e.g. php, Ruby, Python, etc...) may be easier for people to use and learn.  <--- THIS is what I am specifically excited about, I think people are going to come up with some amazing things using other languages and integrations that we have not thought about. We think that GitHub would be the primary way to go - but it does not have the best "control mechanisms" as far as we can tell to manage things to the resolutions we would like to see.  It is important that no other code get into the distribution that is not tested and/or also OpenSource. Specifically - we are NOT permitted to distribute any PTC Code... so we have to protect/manage that.  Still talking about this internally.  ANY SUGGESTIONS? The generic JSON microserver and application framework for CREOSON is already developed and we are testing that currently.  The stuff that is missing is purely on our side - churning all the high-level interfaces to take the last 10+ years and make it available via this new JSON interface. We are trying to schedule the work around a commercial release we are behind on (the latest release of Nitro-CELL). More to come.... Stay tuned.  Thanks for your interest! ... View more