Recommendations to others considering Centro:
Be aware of cascading updates on very large assemblies with multiple sub-assemblies. If designers are using check-out/check-in functionality and checking-in multiple bottom layer components, every sub-assembly up the tree will initiate a cascading update for thumbnails, SpinfireWeb and Spinfire Ultimate files. Depending on complexity of assembly, the Spinfire Ultimate files can become very large the higher up the navigation tree you go. You can consume a large amount of disk space without even knowing it. Furthermore, cascading updates utilize the System Pipeline which is currently hard-coded to only run one concurrent job at a time. Large assemblies can bog down System Pipelines. We decided to turn off all Spinfire Ultimate (ACT3D) conversions and only create thumbnails and Spinfire Web conversions.
Also note: the "Generate..." option in the resource menu will automatically set the conversions to cascade whenever there is a change. For instance, if you want to create a STEP conversion, you need to select "Generate..." and select the STEP conversion box. From that point forward, that conversion will always be updated with a new version any time the native file changes. These versions can add up and consume disk space. If creating a one-time STEP conversion and don't need that STEP conversion to update every single time there is a change to the assembly, make sure to go back into the "Generate..." menu, and uncheck the STEP conversion.
Also make sure that any assemblies you decide to pipeline are linked 100% to the top level assembly. There are many ways to do this. In Catia you can put everything in design mode and use save management to link all the components properly. You also have the option to use the "Send to..." command that will save the top level product and components to a different directory such as a Centro Watch Directory. In NX, you can use the clone tool to do the same thing. If you have components saved on different directories that Centro cannot access, you may end up with a top level assembly with broken links to its components.
Biggest thing we learned: sharing components with the exact same name between two different OEMs can be disastrous. For instance, JLR and Ford often use the same Teamcenter part names since JLR was once owned by Ford. The original beauty of Centro was the ability to use the "where used" function to see all of the assemblies that used a specific component. This is perfect for VA/VE, cost reduction opportunities and many other benefits. The underlying problem with this is the idiosyncrasies with native CAD software and versions that OEMs use. If two different OEMs use the same part but different versions of CAD, there is a chance that a designer using a higher level of native CAD will overwrite the lower level of CAD. The other OEM designer will not be able to open that file to make any changes to it. We had to solve this issue by adding OEM-specific prefixes in our pipelines. We lose "where used" functionality but we keep our native CAD consistent with the OEM native CAD software version. Some functionality is there for us though: the Duplicates tab. This then will show us duplicate parts and the CatalogID prefix shows us the OEM.
Lastly, beware global implementations that use the distributed architecture model where there is one Arango database linked to multiple Pipeline Host/Pipeline Managers. There is a show-stopping latency issue when logging into a European Pipeline Host that access a North American Arango database. This setup is unbearable to use in Europe to the point that end users will not use it due to the lag. We are considering splitting up our Arango databases so there is one for all of Europe installations and one for North American installations. This option breaks up any aspect of global searching and sharing between continents, but it will improve user adoption.
Additional note update: System RAM seems to be the largest bottleneck and most critical aspect of the Pipeline Host server. There is a balancing act between the amount of cores and available RAM. We ran some tests that saturated the CPU cores by running multiple pipelines with six concurrent jobs per pipeline. What we found is that once available RAM is saturated, the system will start writing data to swapfile. Once this happens, when Pipeline Host is accessing very large assemblies in order to process SpinfireWeb, ACT3D and thumbnail conversions, they will probably timeout. Due to the volume of pipelines that we have always running, we are considering standalone server with 500GB of RAM and 32 cores. Our workaround now is to limit the concurrent jobs per pipeline to three, as well as limit how many pipelines we run. We continue to monitor system resources and make sure that our RAM usage never exceeds 75% utilization. Lessons learned: avoid oversaturating system RAM to the point where Pipeline Host is moving enormous amounts of data to swapfile. Review collected by and hosted on G2.com.
What problems is Centro solving and how is that benefiting you?
Global CAD sharing, feature model template library, fastener library, design work flow Review collected by and hosted on G2.com.
