Fixed parking points for machines

[[Da...]]

Hello,

in our company we have 5 different CMMs, each machine has a different parking point due to a room layout (safety reasons). It causes a problem, that each machine has a different plan for the same parts, due to a specific parking point requirement. Therefore plans on the machines "live their own lives", unfortunately, and differences in the plans start to appear after some time. We cannot integrate the plans in a network location due to the parking point problem.

Is there any way to "fix" a parking point for CMM after measurement, no matter what measurement plan has been executed (without PCM option)?

[[No...]]

Without PCM you probably won't be able to make it plan-independent, but you can create several end park positions in a measurement plan, one for each CMM, then use conditions on them to execute only the one that belongs to the CMM the plan currently runs on.
Since you cannot put a condition on the whole path element, you need to put it on the strategy element(s). In the conditions you can query the CMM serial number ( getRecordHead("dmesn") ) to distinctively identify the correct CMM.

[[Ma...]]

Condition can be used on park positions too.
I just tested, and it returns string back - in mine case i did this to get true/false

getRecordHead("dmesn")=="197535"

[[Je...]]

Please sign in to view this quote.

This is a great solution if you are using a non-standard End Park.

In terms of a "standard" End Park I will add here, it is advisable to use an End Park position near "home" for reasons of machine safety (in the event of power failure etc for homing routines). No formulas are necessary, just make the end park relative to MC and XYZ values between 15-30mm (X30, Y-30, Z-30) The same End Park routine will work for all programs on all machines regardless of size if movement routine is correct. In automation setups, this position is usually also used as the safety/anchor position for interfaced devices also.

+Z clearance plane >MC Z-30 > MC X30 > MC Y-30 is typical to avoid stylus racks and fixturing.

If using an RDS, add a stylus rotation between X and Y move to A90B0 or A0B0. This will prevent unforeseen rotation into the bridge upon the machine attempting to rotate after a homing routine after startup. It also preps the sensor for stylus change.

You said you don't have PCM but if you did, this can be added to the end of a "report_end_pcm.txt" and file placed in the main inspection plan directory and it will be used for all programs. It makes for quick and easy "global changes" when adjustments are needed.

[[Ma...]]

Please sign in to view this quote.

I didn't know that - must look at it more deeply ( we don't need this - only one machine ).
How it can be setted in case of multirack - can it be applied like 30mm before rack?

[[Da...]]

I have always used Z axis only park positions. X and Y moves are too dangerous. You can hit stuff on the table with that. Especially if you move the part to a new location.

[[Je...]]

.

Please sign in to view this quote.

So how do you perform automatic stylus changes? Another option for End Park is a stylus change (I would assume you have set the paths for those to not interfere with navigation) to MasterProbe (or any stylus in rack) then move to X30, Y-30 Z-30. "Too dangerous" sounds a lot like a challenge to an engineer and programmer.

Your first move in your End Park navigation should be above your Z clearance plane. If you have an issue of not being able to get "around" a part, put a second/third move of "Move to +Y clearance plane" and/or "Move to -X clearance plane" before executing the full ZXY path. If you can still run into your parts then you have set up your clearance planes and navigation paths incorrectly.

Please sign in to view this quote.

There shouldn't be any need to worry about your MSR. Your rack should not be at a height that it would interfere with your stylus at around X30, Y-30, Z-30. If it is, you have bigger problems as the machine will not be allowed to complete a "Home" routine at start up. If it is a problem with a specific stylus, make sure you have a "Stylus Change" operation in your End Park to MasterProbe and this will prevent crashes when structured properly.

[[Ri...]]

Please sign in to view this quote.

I'm an idiot - move on.

[[Je...]]

Please sign in to view this quote.

Thats not how this works...

"Relative to MasterProbe" refers to ball center of the MasterProbe when it is in the sensor. Completely irrelevant of the probe rack or where the MasterProbe is once it is out of the sensor.

[[No...]]

Please sign in to view this quote.

In my pocket 😱
HELP!! My CMM is chasing me! 🤣 🤣
['Yakety Sax' playing in the background]

[[Da...]]

Wow, I didn't expect to receive so many replies, thank you all!

As for conditions/formulas in parking positions - we have tested "dmesn" and everything looked fine, but for some reason the formulas do not "refresh" until you open the window where the coordinates for parking positions are defined. For example: when we copied and pasted the plan from machine A to machine B, parking point from machine A was executed. Are we doing something wrong, or is this a normal behaviour?

[[Ma...]]

It seems, that this information ( "dmesn" ) is stored in inspection file - loaded from this and not from machine.

Have you used position from refference system? You can use position from actual probe in actual alignment, or position in actual alignment but with refference probe, or position in machine alignment ( not dependant on where have pallet moved ) with refference probe.

[[No...]]

Please sign in to view this quote.

I can't give you a definitive answer. All I know is I once had problems with non-updating formulas in other functions (not parking position) in past releases many years ago, so I know this has once been an issue. I can't say if this has been remedied in all sections of Calypso.

[[Ri...]]

Please sign in to view this quote.

My apologies for misspeaking. I guess I was misinterpreting what it was doing.

Either way the position point relative to the MasterProbe in the MCS is the better solution since it is relative to machine coordinates, and not part coordinates.

[[Je...]]

The variables are stored and system variables are not over-written until the program is executed. In order for the "dmesn" to be corrected for the machine, the inspection plan would need to be executed so Calypso reads the proper paths.

Using PCM (and other coding languages) it is common to "clear" your variables prior to execution of a calculation to ensure that no data is transferred from a previous instance. This previous instance is what you are seeing. The "dmesn" was stored in your start file of the inspection and wasn't overwritten until you executed the plan which created an updated start file.

[[Da...]]

Please sign in to view this quote.

The problem is that the plan was executed, but the formula was not re-calculated until i opened the window "Path CNC End Park position" - is this caused by the problem mentioned above by Martin Jansky?

[[No...]]

Please sign in to view this quote.

Unclear. Header variables are stored in the inspection file as well as in a file named protheadpara. If protheadpara is present, it overrides the data loaded from the inspection file. But with data like dmesn, which depends on the machine you're currently on, none of both should have priority, but it should be read from the controller when needed.

[[Je...]]

Please sign in to view this quote.

Correct Norbert. The variables are stored in the protheadpara. They are then written to the startfile from the protheadpara. Inspection file has lowest priority and I cannot recall from memory if/when that variable hierarchy is updated in the inspection file without testing for it specifically.

System parameters are loaded from the controller or Calypso at Calypso startup or Inspection Load depending on the classification. They are immediately written to the protheadpara. In the case of getRecordHead("dmesn") it is updated before your inspection plan is loaded regardless so there should not be an issue with it "updating" the value of the parameter in your formula. If it did not update, I would verify that your formula calculates in the condition. It should read `getRecordHead("dmesn")=="000000"` (substitute your SN there). If you leave 000000 and are in simulation mode, this should return a "true" (yes path). Anywhere else this would return "false" (no path).

Easiest way to verify it calculates properly is from within the <Condition> window to right-click on the yellow formula text box and select "Formula" to go to the formula creation window. Copy/Paste your formula to this window and click "Compute" to verify its value operating properly. If you prefer to verify further deeper during operation, you can add a "program stop" function to your End Park and add the condition to that as well. In the text for the "program stop" you can add a test phrase to verify its operation in the manner you intended.