hexagon logo

PC-DMIS Measurement Routine Migrations

Starting with PC-DMIS 2021.2, PC-DMIS doesn’t allow loading of measurement routines created in PC-DMIS 2015 and earlier and will generate an error. See: I am getting the error message "Serialization error This version of PC-DMIS can only read measurement routines created in version...."
In PC-DMIS 2022.1, only PRG files from 2016 or newer will be allowed. This “rolling” restriction will continue with each new release of PC-DMIS.

For instance:
Installed Version Can read back to (or pull forward from)

2021.2 2015.1
2022.1 2016
Future projection:
2022.2 2017 R1
2023.1 2017 R2
2023.2 2018 R1
Etc.

To use older routines with a current PC-DMIS release, you need to save all the older measurement routines to any version at least as recent as that defined by the current restrictions. This can be done one file at a time but if you have a significant number of files it can be very time-consuming. To help facilitate this process, we’ve created and shared two utilities.


Conversion Utilities for PC-DMIS (hexagonmi.com)

Utility Home : SaveMRtoRequiredVersion

This will automatically open the measurement routines and save them to the desired version. (simply opens, saves and closes routines)

Utility #2: Migration_Utility

This is a little more intelligent and performs the same task as utility 1 but also handles migration from Xactmeasure to the new, geometric tolerance command. It requires you to install the most recent service pack of 2020 R1 as well as your desired version (2020 R2 or higher). It asks you to navigate to three folders – the source folder containing your routines, a destination for routines that generate migration reports and a destination for routines that do not generate migration reports. The utility will then sort routines into the relevant destination folders making it easier for you to identify those that migrated successfully and those that require editing. Please see here for a more detailed description: Documentation. It also saves probe files associated with each routine in the current probe format.

While these utilities are being provided free of charge, there is no implied support. Please be sure to back-up all of your files before starting this process.

*** Please be sure to read the help documentation on these tools. It is brief and will often answer the very questions which we are seeing posted here.

  • PC-DMIS CAD++ 2022. 1 (release) - Maskin1
    PC-DMIS CAD++ 2020R 2 (release) - Maskin1
    PC-DMIS CAD 2020R2 (release) - Maskin1
    PC-DMIS PRO 2020R2 (release) - Maskin1

    String position 19 is red and bold in the examples above. Depending on which variant you have (PRO/CAD/CAD++) the hardcoded string index the migrationutility looks for might fail.
  • I just stumbled upon that issue myself after some basic debugging in Visual Studio. See the attached image.

    Neil, perhaps you can modify the utility to get the version number by working from the index PRO.MainWindowTitle.IndexOf("20", 0) + 4?

  • I asked the person who wrote the utility to look into it. When I originally discussed how to determine which PC-DMIS version was running with him, I shared a VB.net example in which I used InStr. I'm not familiar with C# so I don't know if what he's doing is equivalent or not. Most likely, he has his logic wrong - although I'm curious as to why it runs fine on my system if that's the case - I installed the same versions as you? He's based in India so I won't get a response until tomorrow (at the time of writing this it's 9:15pm for him).
  • neil.challinor I would assume you are running PC-DMIS CAD++ whereas I'm just running PC-DMIS CAD. The location of the version number will be different in each of our cases and the code is not dynamic enough to account for different levels of PC-DMIS. Thank you for escalating this, I'm looking forward to using the utility.
  • @jacobCheverie

    Just a quick update. We're working on a new version of the migration utility that uses a different method to identify the PC-DMIS version. We hope to make it available within the next few days.


  • I believe one of my team contacted you and supplied an updated version of the migration utility that resolves the issues you were having?

    I just wanted to make everybody who reads this page aware that the new version is now available to download using the links supplied at the top of this thread: https://www.pcdmisforum.com/forum/pc-dmis-enterprise-metrology-software/pc-dmis-for-cmms/511579-pc-dmis-measurement-routine-migrations#post511579

    Please feel free to contact me should you have any feedback on the use of the migration tool or encounter any more problems with it.
  • neil.challinor I'm hoping you can help me out with this.

    I’m working with a customer who is hitting a brick wall when trying to use the conversion utility.

    He has v2022.1 installed and attempting to convert v2014 programs. Here’s the problem described in his words:

    “We copied one of our Routines into a separate folder on the desktop called “Convert_this” (just to keep things separate and make sure that if there was any file corruption that we did not lose our original files. Open the Conversion Utility, MRPath set to the “Convert_this” folder on the desktop, set the LogPath as the same location, checked the box for Sub-Folders, clicked Convert. Less than 2 minutes later it kicks out with the error message previously attached.

    Due to the .NET Framework message, I proceeded to update and install .NET 3.5 to 4.8 components with no change.

    I also read the page where you may need to run the Migration Utility after the Conversion, so we tried that on the files as well with no luck. We have tried multiple different routines with the same result. We have also tried placing the files in C:\temp just to give it a different location.”


    I’ve requested copies of his old programs so I can test on my end but haven’t heard back. Any thoughts?

    Attached Files
  • This seems like a problem unrelated to the utility itself. The error message implies there is an access or permissions issue with the folder they've created. I would suggest they consult with their own IT department on where they can place these files that would not have such permissions issues. I am thinking that the Users folders area would be a good place to start -

    C:\Users\Public\Documents
  • ...or the root of C:\

    You could also try setting the LogPath to something else than the migration path, just in case of file/folder locks.