A couple of General CMM Queries.

Hi,

I have a couple of questions regarding the running of our CMM's. It would be great to get some feedback on them.

1. We have now moved to 24/7 shift.Will having the CMM's running 24/7 affect their capability?

2. We run our programmes off a shared drive. For example, we have 6 CMM's running from the same programme at any one time off a shared drive. Could this cause issues?

3. We are running PC DMIS 2014. At the moment we are seeing issues with profile scans, we run a part and it could have 21 dimensions OOT, run it again it might pass. Run on another CMM it also might Pass

4. Could any of the above be causing inconsistent results?

Thnaks for the help,

Cian

Hi,

I have a couple of questions regarding the running of our CMM's. It would be great to get some feedback on them.

1. We have now moved to 24/7 shift.Will having the CMM's running 24/7 affect their capability?

2. We run our programmes off a shared drive. For example, we have 6 CMM's running from the same programme at any one time off a shared drive. Could this cause issues?

3. We are running PC DMIS 2014. At the moment we are seeing issues with profile scans, we run a part and it could have 21 dimensions OOT, run it again it might pass. Run on another CMM it also might Pass

Thanks for the help,

Cian

*ding-ding-ding-ding-ding*


(That's an alarm bell ringing there)

We have five CMMs at our shop. Each one has a number(1-5). At the end of our program name is a number corresponding the CMM number. That way we can keep all the programs for a given part in the same directory, but no which CMM they are acceptable to run on.

This serves several purposes.
1. Anybody can look to see what CMM is OK to run a given part for a given operation(the part number, part rev, op number and op rev are in the name).
2. It keeps the same program from being run at the same time on two different CMMs.
3. If you regularly are have a problem with a program not running consistently on a certain CMM you can remove the program for that specific CMM, but still keep it for the others.

I don't know if this helps much, but it's food for thought.

Hi Guys,

I appreciate all the feedback and I suppose I have only one more question really and hopefully I will be able to satisfy the powers that be.

Josh
The big question for me is that. Ok it's great to here that running a shared programme on multiple CMM's is not good. But I suppose I need to be able to tell them WHY it isnt good. If I cant give them a couple of reasons why running off a shared programme is bad then I wont have much clout for getting them to bring in an automated system!

So, any info on that would be great.

Thanks,

Cian

Like others here, I would not recommend trying to run multiple machines from the exact same program file. PC-DMIS frequently writes back to the program files, and you could run into a situation where multiple machines are trying to do so at once, and one flips out because the file is record-locked. I could also see he potential for data saved back to the program file by one machine causing a conflict on another.

We have a dozen or so Globals in our facility. All of their programs, probe files, etc. are stored on the network, but in individual shares for each machine - e.g. CMM #500 has all of its data in G:\PC-DMIS\MACHINES\500\... on our network, CMM #505 in G:\PC-DMIS\MACHINES\505\..., and so forth. Our CMM programmers can easily copy a program from one machine's share to another if they need to run it somewhere else.

Also, the stability and reliability of your network connection is paramount when running from a network share. We used to have a 3COM core switch for our company network that did double duty propagating our IP phone system, but it did neither well - intermittent network latencies would sometimes crash PC-DMIS and cause serialization issues with programs. When we switched to dedicated HP core switches and a CudaTel IP phone system, these problems went away.

Just make sure a maintenance schedule is followed to keep them clean.


This is highly recommended against.
You really need to invest in an automated system that copies the desired program from the network central repository to the hard drive of the machine that needs to run it. Then the CMM runs it, and once it's done the program should have the Save As VB script in it to Save As it to an archive folder. Finally, the automated system should delete the copy of the original program.


This could be a dozen things, ranging from probing to programming to glitches in the matrix. Try and pin it down if it's a specific part program or a specific dimensions such as profile.




You're welcome!