Excessive crashes with PCDmis

everything mentioned above is good stuff. In addition, each user ID that logs into Windows on that PC will need to have these registry keys and folders (at bottom) set to administrative and read/write permissions.

I do not think your problems are resource related.  Unless you are opening large (>100mb) *.CAD routines I highly doubt additional RAM (or upgrading graphics card) will net any gain whatsoever.

I also advise if you are using a network folder to store any PCDMIS files (PRG's, PRB's, etc) don't.  Copy them locally to that machine's hard drive and set them as read only if you need configuration management sustained.

Per the Hexagon support page, the following is what they say is required:
“If I do not have local admin access can I still run PC-DMIS?
May 25, 2018•Knowledge
Details
Yes- if the end user is denied local admin access on their PC to run PC-DMIS, then ask IT to make the following changes to the application's install folders and registry branches below.

Grant the user's account full permissions on all of our Hexagon application folders here:

• C:\Program Files\Hexagon (64-bit installs)
• C:\ProgramData\Hexagon

In the registry you should also explicitly give the same user full permissions to the following branches:

• HCU\Software\Hexagon
• HKLM\Software\Hexagon
• HKLM\Software\Wow6432Node\Hexagon
• HU\.DEFAULT\Software\Hexagon

louisd said:

In the registry you should also explicitly give the same user full permissions to the following branches:

• HCU\Software\Hexagon
• HKLM\Software\Hexagon
• HKLM\Software\Wow6432Node\Hexagon
• HU\.DEFAULT\Software\Hexagon

This only applies to older versions (before 2022 I think).  Settings are now stored in .json format in the following folder locations...

C:\ProgramData\Hexagon\PC-DMIS\version

C:\Users\username\AppData\Local\Hexagon\PC-DMIS\version

.

Where username is the Windows user account name and version is the PC-DMIS version (e.g. 2024.2)

Maybe this is very hard to believe, but the state of the software has become much better compared to the older releases. More stable, the PRG-cannibalism has pretty much stopped (PC-DMIS eating it's own programs), the moody bugs are very far in between... With that said, there are still some things that is the polar opposite to other softwares user interfaces and some other quirks. I for one, would not go back if I got to choose.

Matthew D. Hoedeman Version 3.7 was definitely one of the better versions and for almost all users this would be true.  In my case I noticed issues when using VB in this particular version of PC-DMIS.  It was so bad I knew that after running a specific number of measurements that I had to close the software otherwise it would be closed for me.  I have only seen this problem with version 3.7 (nothing newer or older had the same issues).  Most users are not using VB for regular part programs so they would never run into this.  I just wanted to clarify what I was talking about earlier.

Y'all need to imply good intent. Hexagon has no motivation to intentionally mess stuff up.  Improvement and advancement is just like any other engineering profession: iterative.  The software is leaps and bounds more advanced and stable than v3.7.

I agree that their product releases should be renamed beta versions, and until bug reports are extinguished, the version should not be named a "release".  tomato/potato.  They are still working their butts off to stay market dominant and the most adaptable user-friendly software to program with. 

Collapse-o has way more functional bugs, deficiencies and hoops to go through for many things PCDMIS just inherently tackles with less than 3 mouse clicks.  I loathe all their measurement strategy popup menu's you have to go 3 pop-ups deep, before actually being able to modify hit locations. 

MCOSMOS?  yeah its terrible to program on the fly. One exe software for programming, another exe software to open to execute. you can't execute and make any program changes without having to exit the routine and open the other sw package!

give them a break, it's hard for any organization to both simultaneously innovate and sustain a 30 year old user interface and programming methodology.

Thank you louisd , I’ve so far been resisting the urge to respond to the many negative comments as I don’t have the time to get drawn into a heated discussion but I think you summed things up quite well. One thing I would like to add is how unhelpful it is when people who, by their own admission, “never use” a particular feature or are not even running a current version offer comment on things they have no experience of using.  I have no objection to people trying to be helpful but, if you don’t know how something works, don’t try to guess.  It just adds to the confusion and misinformation that's already far to prevalent.

 louisd You are correct that nobody intentionally tries to mess stuff up.  That is completely true regardless of the industry you work in.  Do you believe PC-DMIS has a good track record on stability?  (no response required).

You mentioned Calypso and MCosmos.  From a user interface point of view they are both 'old school' for sure.  Do they work though?  Are they crash happy?

If your thinking is along the lines of leading-edge, innovative, or something like that I just don't buy it.  Just look at the change log for a history of new features in PC-DMIS.  For example, what new, innovative features did PC-DMIS 2024 have that 2023 didn't (or 2022, 2021, 2020, ...).  Minor stuff really.

If you think it is not possible to create inspection software that is relatively bug free (no software is 100% bug free) and not crash happy then have a look at Polyworks.  Their tech support is the best.  If you find a bug, which is insanely rare, they don't ignore it.  That software, that company, gets top marks from everyone I know of who has ever dealt with them.  I have yet to find someone who has a complaint about Polyworks.  I don't know of anyone who ever told me it crashed.

Polyworks is dependent upon an I++ interface.  Have you ever dealt with I++?

--It's quite klunky and is giving one of my sister sites so much grief they are planning to replace both of their Zeiss CMM's running PCDMIS.  The machine's probes and calibration for probes is managed in calypso. everything else is managed and dcc is run with pcdmis.  I presume similar wonky handshakes and relationships will remain if you put polyworks on a non-polyworks device.

I know I++ quite well.  Although I believe Polyworks supports I++ they are not dependent on it.  A lot of software is capable of being an I++ server (including Zeiss, PC-DMIS, Renishaw, and likely a few others) and quite a few more can be an I++ client.

I did a lot of work for one of the 'big three' automotive companies in the past.  They bought a bunch of Zeiss CMM's but wanted to run PC-DMIS on all of them.  The solution was I++ and this sounds exactly like the setup you have at your referenced 'sister site'.

I completely agree that this setup is 'klunky' and I was never was a big fan but it works.  The part I really hated was creating all the probe nick-names in PC-DMIS.  The rest was fine but that always was annoying and should not have been necessary.  If you have two CMM's with this setup and are tired of the hassles then replacing the machines is an option but it might be a hard sell to those who actually pay the bills (there is nothing wrong; you just don't like it).

Polyworks is software.  They don't sell devices that I am aware of at least.  They may support I++ but they are definitely not dependent on it.  It was only recent that they started connecting to motorized CMM's (previously it was scanners and other large point data devices) so that is likely when they added the I++ option.  The point I was trying to make is that this is an example of software that, to the best of my knowledge, has never crashed or caused users to lose their programs.  It should have happened at least once statistically speaking but I have never heard of it.

 Pick me! I have crashed PolyWroks (on model import), I have experienced the software misbehaving (menus were not functioning), I have had it peace out and go to lunch in the middle of a huge scan (I was very mad that I had to climb out of the part I was inside of and force restart the computer due to it being hardlocked by the software). 

However, my company has wonky computer security which influences every facet of our digital existence, quite possibly could have influenced these occurrences. 

I am not a shrill for Polyworks.  I hear only good things about them from anyone who uses this software or deals with this company so I am just sharing that consolidated opinion.  I am citing them as an example of 'better' written and tested software because I believe it is.

Out of curiosity, if you had Polyworks crash importing a specific model did you contact their technical support?  If you did I suspect they would have been on that like white on rice.  It seems like they are known for resolving issues promptly when brought to their attention.

The original poster of this thread described 335 crashes in 140 days with no help from Tech Support.  That sounds over the top even for PC-DMIS so there is something more going on.  My first thought would be to see if the SDx / Pulse thing (or whatever it is called) is installed and running.  I seen a machine where that was installed and it was almost unusable.  The web-interface front end is a source of problems too.  There is not enough information to even suggest anything to the original poster.

So, if you are telling me Polyworks is not stable, not reliable, then I will keep that in mind.  It is just not something I hear when visiting various companies that run that stuff.  I just hope you are not talking about a one-time event...

Thats not what I said.
Those are the only crashes I have ever seen. Statistically low compared to some other things. The crash from importing the model was likely due to running out of ram on the PC by selecting the incorrect model. (let's just say it was REALLY REALLY big. I just wanted a bite of the sandwich, not the whole thing) 

The Demon is head and shoulders above its competitors in nearly every aspect, even if we are used as beta testers. There IS a reason my boss won't let us upgrade past 2020R2, just can't risk it yet. 

Thats not what I said.
Those are the only crashes I have ever seen. Statistically low compared to some other things. The crash from importing the model was likely due to running out of ram on the PC by selecting the incorrect model. (let's just say it was REALLY REALLY big. I just wanted a bite of the sandwich, not the whole thing) 

The Demon is head and shoulders above its competitors in nearly every aspect, even if we are used as beta testers. There IS a reason my boss won't let us upgrade past 2020R2, just can't risk it yet.