Alternative to alignment recalls

  • Filter
  • Time
  • Show
Clear All
new posts

  • Alternative to alignment recalls

    Well, I've pretty much had it with these loop programs. I've written many of them, but I need a new method of programming that is less prone to corruption. We have two cmm's, one with a 13-station fixture and the other with a 20-station. The fixtures are practically the same, except one has 7 more stations than the other (bigger cmm). I have many loop programs written for the 13-station that recall fixture alignments: within each station, a plane and line are taken from the fixture surfaces, and a midpoint from the part. A DO-loop is used. I would sometimes encounter a problem when I would save one of these with a new name and then make modifications to run a different, tho similar part. I would also get corruption with various copying/pasting. I could live with all that, because it didn't happen very often.
    However, since i've been copying the programs over to a new directory and modifying them for the 20-station, most of the programs are ending up currupted. They will run station 1 but nothing else, or they won't run at all because theoreticals have changed. Somehow, the program must not like having all it's fixture alignments replaced with new ones.
    We're a fast-paced job shop, and my bosses don't want me re-writing programs for a new cmm. They want me to copy and paste everything to save time. I don't blame them. Copying parts of programs to write others was always touted as a great feature of PCDMIS, but I'm beginning to realize it is the cause of un-fixable problems.
    So, to make a long story longer, I think if I had a way of running parts on these fixtures without recalling fixture alignments I would have fewer corruption problems when cloning. That's my theory. What other programming methods could be used to get an alignment on each part, and check either ALL parts or check ANY ONE part on the fixture? In the distant past when I used the built-in LOOP function, there were too many problems with move points not looping, true-position values I don't want anything to do with that. Any ideas?
    Whew! Aren't ya glad ya clicked on this one?

  • #2
    Don't blame alignments. I must believe it is just plain PCDMIS no matter what you are doing. I get the same thing. Our engineers here are notorious for changing a part 20 times per week and the more I edit programs the more prone they are to becoming corrupt. There are some I have edited so many times I don't dare keep it up I just start over. Same thing with copy and paste of programs. I have copied programs then edit them heavily to make a new but similar part number and they end up being prone to corruption. as goes for copy and paste inside a program. If you can limit your copy and paste in a program to strings only (not references) then you should be OK. As soon as you copy and paste in order to get a reference you'll start having problems. I don't believe it has anything to do with your alignments I just think that part programs are not as stable as they should be.

    <internet bumper sticker goes here>


    • #3
      Well, you COULD try this:

      1) Write a program that does all the fixture alignments, and saves each alignment to an external file.
      2) Write a program that checks one of the parts, recalling the external alignment for a station, then copy the program and change the alignment recall and do this for each station. This would give you 13 or 20 programs. No copying, no loops, but lots of open and close to check the entire group or parts.


      1) Write a single program that aligns ALL the stations, saves each one to an external file (same as above)
      2) Write a single program to check the part BUT use a variable to recall the external alignment.

      This would require that each station's alignment file would be a sequential number, ie AL1, AL2, AL3, AL4, etc. Then, with an input statment, ask the operator which station he wants to check. (S)He enters the number, the Pcdmis recalls THAT external alignment file and checks the part. This SHOULD work as long as it is for all identical parts. THe operator input could also be used as the tracefield for the stats to tell you what station it came from.
      Originally posted by AndersI
      I've got one from September 2006 (bug ticket) which has finally been fixed in 2013.


      • #4
        Looping sucks. Period. I know you guys use it, but it just sucks in PCDMIS. It lacks alot of what a programmers expect in a program that is supposed to loop.

        To loop through a series of part stations would be better served by an external program controlling the program and telling it where to run than trying to do it inside of a single part program....

        (craig- did you think that I could leave this one alone?)
        Links to my utilities for PCDMIS


        • #5
          Actually the loop is great for itterating through stations. I will share your gripes though on the accesibility (or apparent accesibility) of the features generated by it. I think that could be a little smarter. It certainly would be nice for an intuitive way to access the features that have been looped both graphically and in dialogs. Loops work well but copy and paste on the other hand leaves much to desire and can make debug a very painful process when the syntax is proper but things are not behaving as they should.
          <internet bumper sticker goes here>


          • #6
            Thanks for the gracious replies, gentlemen. Instability of programs? Strange - the B&S folks never mentioned that....hmmmmm....
            Actually, we need programs to run all the parts WITHOUT anyone monitoring. My bosses said that the QC folks are supposed to start the program running, and then go do something else. Believe it or not, we can usually get away with it. I've just been hitting a brick wall when trying to copy over to the other machine. My bosses want to know when all the programs from the small cmm will be on the big cmm. I tell them it's a struggle, and that I'm looking for a new way of looping other than fixture alignments. They seem to think it should be like G-code/M-code, going from one mill to another.
            I didn't really expect any revelations, I just thought I'd touch base with you wizards. It looks like I'm going to have to keep the fixture alignment method, but do more re-writing of programs for the bigger cmm. It takes more time, so we may be looking for another programmer. Anyone want to work in Chelsea, Michigan for an orthopedic supplier?


            Related Topics