Load / Save Alignment with loops?

[[No...]]

Has anyone ever used Load/Save Alignment (utility menu) in a loop together with XYZ transformations of the alignments?
I'm trying to load a number of coordinate systems in a loop, shift them by a certain offset (in the machine system) and resave. But for some mysterious reason it only works for the very first one in the list. In all subsequent iterations of the loop the values don't change anymore and all saved alignments come out wrong.

I think it has to do with the way Calypso recalculates features in a loop. It looks like my features, coordinate systems etc. only calculate once and then stay the same for the rest of the loop. But the weird part is that they ARE recalculated on each iteration, but still show the same result every time (I checked this with PCM test messages and the PCM test mode).

I've already tried all tricks I could think of to force a correct recalculation (like using LOOP1 in getActual() recalls), but to no avail. Am I missing something essential here or is this just some kind of weird software bug nobody noticed yet? What is the correct method of forcing a complete recalculation of 'everything' in a loop? I wish I had a deleteActuals() PCM command.... 🙄

[[Ra...]]

Please sign in to view this quote.

So much this.

[[Da...]]

Not sure if you're looking for the same thing . But, I made a base alignment for a group of parts that I put on a square mag chuck . Each part has a different size ,so it locates at a different point. I made a secondary alignment and looped it. So, you run the base alignment on the first pc. For the next different part you recall the base alignment but run under current alignment. The machine runs the secondary alignment with a loop for each different part. If the chuck has to be moved, you rerun the base alignment and all the different parts are aligned with only that one base alignment run. You then run all features to the secondary alignment.

[[Er...]]

If you haven't figured out how to do this yet, and you refuse to use odd stuff, my tip is to install Calypso 2018.

There you can recall values by itteration from alignments, if I remember it correctly 🙂 And some other really neat stuff. Available on a sdp near you 😉

[[To...]]

It is my understanding that licenses for 2018 will not be available in the US until August or September.

[[se...]]

Tom, that's exactly the timeframe I recieved from Zeiss today.
In the meantime, the release info makes for interesting reading....................

[[No...]]

I was rather disappointed by the 2018 release notes - maybe because I don't need 95% of the stuff mentioned. But I miss a lot of items from the wishlist in the old portal.

Dave, what I'm trying to do is to shift all our base alignments by a given offset in X/Y/Z (because Calypso still has no built-in function to do this - see above 🙄 ). We use magnetic chucks too and all our parts are run by untrained people with autorun. Recently one chuck broke and we realized that if we need to buy a new (different) one, we will have to reestablish all our alignments by hand. To avoid that, I want to measure the difference and make Calypso shift all alignments by that offset. For this I go through a previously created list of all alignments in a loop, load each one, shift and resave to a new location.
I know that my method works in principle, it's only that Calypso seemingly refuses to recalculate everything from scratch from the second alignment onwards.

[[Da...]]

Please sign in to view this quote.

Norbert, We had a large (200) program set running from our chucks current location. Zeiss came in to calibrate and removed the chuck. I understand your pain. Every program had to be manually (re) aligned. The process I described would require a rewrite of every program, but it does solve the problem in the future. One alignment to the chuck and then recall that alignment into every other program.... run the "secondary alignment with a loop and it runs the same as before the change. All of them. Recall the primary alignment into all the programs written for that chuck.

Run the next part number ( recalling the saved alignment ) as "current alignment" . So it won't RUN the primary alignment, just the secondary , and it has the loop. The only remaining problem is I am having trouble zeroing the secondary alignment so, my nominal locations are all offset. It doesn't matter for my final results , but would make the programs easier to read.

We are trying to do the same thing.

[[Er...]]

To avoid missunderstanding again, you have updated all your base systems, but from there your problem starts with difference systems and features?

[[Da...]]

Eric, Are you responding to me or Norbert ?

[[Er...]]

I was refering my question to Norbert.
But from now on I better shut up. I clearly cant write so anyone understand and I always miss the point in what ppls issues are...

Over and out..

[[No...]]

Please sign in to view this quote.

Dave, I'm not sure I really understand what you are doing. 😕, but it sounds like a lot of work to implement.

Eric, my program saves the shifted alignments to a new location ("Save Alignment" saves to a standard folder in workarea\basesystems and PCM copies it away to a new folder, then "Delete Alignment" deletes what was just saved to avoid any mismatch with the next alignment).
To test the output of the program I put my part on the machine, load its program and move the probe to the origin of the alignment. Then I close the program, rename the original basesystems folder, copy in the new one and reload the program. Now I check the position of the probe again. The position window should now display the offset I used for translation. But it's only correct for the very first alignment that was processed. All subsequent ones show completely wrong values.

I assume it must have something to do with the way results are calculated in a loop. The very first alignment is calculated from scratch because I start the run with "reset existing results". But whatever comes after that seems to recycle the existing results and I can't get rid of them during the run. I mean, normally it's one of Calypso's big advantages to measure and calculate only what is really needed, but in my case it's a P.I.T.A.

[[Er...]]

Dave nerver runs The basesystem, he place everything in a difference system. Has one advantage, the one he describes. But I can think off several disadvantages. Temperatur correction is one of them...

Im not sure I understand your issue either. Why do you loop? You only wish to add a constant offset to your base system. If its not one million programs, you could create The offset in a difference system, load that, and place your features in There. But still some manual labour.

How ever, if I had to offset all my base systems by a constant offset. My initial approach would be to read the data file of The base system, calculate The new matrix, (dont care a out The vector since it Sounds like its "not" changing) updated The data file and loop that task. I threw a quick eye at the data file and its readable. Binary. But i dont think I would use pcm, more like py with the scipy lib or similar.

Or simply force some one else to manually do all The base alignments again 🙂

[[No...]]

Please sign in to view this quote.

The problem's not "who" but "when". We just have no spare time left when we could do this. It's not a million, but about 1200 is enough. As soon as we'd install a new chuck, ALL programs would stop working at once. But all of them are used for production release, so no way. That's also why I don't want to change all the programs unless there's absolutely no other way.

Using something else to manipulate the data files directly was my first thought, but I don't know the data format and the math involved.

Btw. I have now tested the Calypso program with only two alignments but without a loop. Both came out right. So it's clearly the loop that causes the problem. I can't believe there's no way to force Calypso to calculate everything from scratch in a loop.

[[No...]]

The deeper I dig into this problem, the weirder it gets and the more confused I am about Calypso's behavior.
To better analyze what's going on, I added control messages to all features and characteristics in my program, so I can see which element is executed when. And guess what: according to the order of the message output, one of the very first things that happen after loading the alignment is the calculation of the final coordinate system (the one that's to be saved afterwards). This step should be done at the very end. But it happens even before the actual translation takes place. And still the first shifted alignment is correct. This is either real magic or something is terribly wrong with the way Calypso executes PCM presettings! 😮

[[Er...]]

Yes, coordinate systems that don't relies on actual measured values are always calculated prior anything else. That's how I understand it. Even if they aren't used for anything. All objects can communicate with each other to collect information. So it retrieves your offset, calculates coordinate systems and then goes on with the rest. The beauty (read confusion) of oop. Objects can get information with out "executing" pre- or -post-settings, since that feature/characteristic isn't really necessary, unless it retrieves actual data.. (Can't find a better way to explain)

I can show you how to read object storage files saved in binary, if you wish. But it is one of those things I don't like to show the whole world how to do. Should probably not be general knowledge, even if it is pretty harmless..

[[No...]]

Please sign in to view this quote.

I had a vague suspicion of something along this line, though I don't understand how Calypso can calculate a coordinate system that depends on an offset that doesn't yet exist. Anyway this is very confusing for an everyday user and makes debugging of bitchy programs an even greater P.I.T.A.

I wouldn't mind knowing about reading those binary files. I'm not sure if and when I will have the time to actually make something of it, but knowledge never hurts.