Copying tool path to a new Machine group?

[neurosis]

I am getting ready to move a job from one machine to another. This has always been a bit of a pain for me as we had machines that had different memory types.... Now that issue is gone so I figured that this should be a very SIMPLE task.

 

So I created a new machine group. I plan to copy all operations to the new machine group and post for that specific machine.

 

I copied all of the operations to the new groups, fixed the few good issues that were apparent and tried to post.

 

I kept getting warnings for same tool number being used in multiple operations error. I noticed that the operation numbers that it showed had one being from one machine group and one from the new one.

 

I then noticed that even though I was posting from the newly copied operations it was using settings that were from the original operations (misc values used for high speed). I had turned all of these off in the copied operations.

 

This made me curious so I edited one of the original operations in the original machine group. It not only dirtied the operations in the original machine group, but also dirtied the "COPIED" operations as well.

 

So when I am trying to post, even though I have all of the copied operations selected, it is using the settings from the ORIGINAL operations!

 

Anyone seen an issue like this?

 

For now, I am just going to save the file under another file name and make the necessary changes.

 

I may attempt to send this file in to QC.

[CJep]

Why not replace the original machine def in the machine group properties with the new machine def?

 

It not only dirtied the operations in the original machine group, but also dirtied the "COPIED" operations as well.

 

Did you have any remachining toolpaths in the original group?

[neurosis]

Why not replace the original machine def in the machine group properties with the new machine def?

 

 

 

Did you have any remachining toolpaths in the original group?

 

There is not a single re-machine operation in this part file. There are however LOTS of transformed operations. It is a 20 station fixture on a 4th axis.

 

I think when I get a chance I will just edit the post to ignore those misc int for the high speed functionality. That way I can just change the machine def and re-post for that machine.

 

I didnt realize that such a seemingly easy task was going to become such a hassle.

[CJep]

There are however LOTS of transformed operations.

 

That could be were the associations are coming from.

 

I will just edit the post to ignore those misc int for the high speed functionality.

 

Did you try doing an edit common parameters and change the misc values that way?

[neurosis]

That could be were the associations are coming from.

 

 

 

Did you try doing an edit common parameters and change the misc values that way?

 

Yes.. That was the way that I changed them.

 

I then went and double checked every operation to make sure that the changes were indeed made. Then regenerated the operations because of the issues.

 

That was when I decided to make a change to the original operations. I knew something was forked up when I made a change to the original Misc Values and it dirtied the operations.. Usually they do not dirty when making changes to the Misc Values. It dirtied both the original AND the copied operations. Not just the Transformed, but the driving operation as well.

[K2csq7]

When you copy a transform and it's source op, the new transform will be referencing the ORIGINAL source op, not the copied source op. You have to go into the new transform op and select your new copied source op.

[neurosis]

When you copy a transform and it's source op, the new transform will be referencing the ORIGINAL source op, not the copied source op. You have to go into the new transform op and select your new copied source op.

 

Im going to play with this again this afternoon.. I wasnt aware that a tranformed operation could reference an operation from another machine group. Seems like that should not be possible. That is probably what the issue is though.

 

That would explain some of the other errors that I was getting.

[neurosis]

I edited the post to remove all unwanted output. Problem solved.

 

Thanks K2csq7, that was definitely what the issue was. I am surprised that I didnt even think about this since I copy transformed operations all the time so I know that this happens.. Ive never copied them to a new machine group.

 

There are so many transformed operations for this particular part/fixture that it would be just as fast to re-program than to try and copy the operations and point them to the correct operations. Seems smarter to modify the post so that I can just change machine def and re-post. That should work for all future applications as well.

[K2csq7]

I didnt realize that such a seemingly easy task was going to become such a hassle.

 

Yup, and I always put it (the task that you would never expect to have problems with) off until zero hour, then get bit....

 

Gad you got it!

[neurosis]

Yup, and I always put it (the task that you would never expect to have problems with) off until zero hour, then get bit....

 

Gad you got it!

 

I think that the time factor may have played a part in lack of attention. We just found out that this had to be swapped this morning and of course the job is hot and it needs to be on the machine RIGHT NOW! Always the little things that get over looked.

 

The nice thing is, this will not be an issue in the future. It gave me the ambition to make those post changes..

[Matthew Hajicek - Singularity]

I've had some of these issues too, and I don't use transformed operations. Attempting to make a copy of a machine group can be a real headache. My best solution has been to put a question in the post processor to ask the user which machine to post for, and post for all machines with that one post and machine definition. The post then does all the logic needed to post different output for different machines.

[Brando]

 

For now, I am just going to save the file under another file name and make the necessary changes.

 

 

yep ive found this is the best thing to do, we run the same jobs on diffrent machines and saving a different file when i change machines is my std

 

and i also have had many issues with copying ops from machine def to machine def in the same file, tools, holders get messsed , mixed, scrambled and if there are any tool paths the require source ops like k2csq stated they all have to be manually updated

[Matthew Hajicek - Singularity]

The problem with copying (for me) is that later when I want to revise the program, I then need to make the same exact changes in two or more different files, verify them separately, etc. What if you have a process that you want to be able to post on a moments notice for any of a dozen different machines?

[K2csq7]

What if you have a process that you want to be able to post on a moments notice for any of a dozen different machines?

 

If your using anything after V9.... your in trouble.

Before the whole introduction of the MD & CD this was easier than the pie recipe I posted.

I know in "theory" this should be easy, just switch machine defs, right.... Somehow, it never goes smoothly.

In V9, you hit post, it asks which post, and your done.

[peon]

Well said K2! I thought the Machine/Control def was an awesome idea. But after using it the last several years starting with X2, I would love to go back to the V9 method and let the post handle many of the parameters. We have 7 different makes of machines here and switching machines can be a pain in the A$$!

[Newbeeee™]

In V9, you hit post, it asks which post, and your done.

Keith - you're just so last Wednesday. We've progressed since then...

[K2csq7]

Can anyone tell me what functionality has been gained since the introduction of the MD's & CD's?

Not toolpaths & such, just things that the post could not have handled, which required the implementation of MCD's (<< I just made that up, Machine and Control Definitions)

[Newbeeee™]

We have 3 chevalier vmc's and 2x robodrills. We started to use different defs, but stopped because I got peed off when updating one post, adding the changes into the other (we were on a bit of a post mod frenzy at the time...).

So we settled on the 'one post does all' route, and added the idiosyncacies of the robodrill into the other 'standard' post.

Our reseller ( thanks Phill) added all of our functionallity required for all of our rotaries (prompt box = 0 noA/1 A but no clamp/2 A with clamp/3 Asimultaneous), G05.1 is active always as standard, and it has been very successful.

The posted code will run on any machine - the only difference is the pretool select. We have to manually delete it from the posted code for the robodrill (yeh - we could have another prompt box asking for stagetool output y/n but it really isn't a biggie).

We tend to tune feeds on the machine so the ncprogram is master, rather than the mastercam file. Doing it this way - we only ever have the one program rather than two for the same part which I REALLY don't like the idea of.

So to me, this is a simpler solution than mcd's (quite catchy that ).

 

But, I do use them when it comes to prototype work. If it's a one off programmed for the prototrak, I'll post it and run it on the machine.

If the part repeats and goes on the vmc's, then i'll select the vmc mcd and change things accordingly and it does save time over starting from scratch.

 

I do think mcd's are a good idea in principle and would asume they would integrate/work quite well with 'fancy verify' (machine sim).

But as that DOESN'T WORK ON POSTED CODE, i haven't even bothered playing with it...

[Oscar R.]

There are however LOTS of transformed operations.

 

Like others have already stated, this is the problem. I've had this happen when copying transofrms to other machine groups. Thankfully they've been in small programs do I just go into the copied transforms and re-select my ne toolpaths.

We currently have our posts being modified with logic to avoid having to use transform for our purposes. Won't see them until next week, hopefully they turn out as well as we expect.

 

We have 7 different makes of machines here and switching machines can be a pain in the A$$!

 

We use a software here to convert all of our proven programs for other machines. This way if on machine is not available for a repeat job that has a dialed program we can convert it and run it on any of our other machines. Once you have all the perammeters set the way you want them it works realy good. I think now you can even get it with some standard control converters included.

Look up KipWare from Kentech Inc.

[Tim Johnson]

Oscar,

Do you use Kipware? If so, are you satisfied with how it works?

I'm looking at this software to convert Fanuc code to Okuma code. They have the package (including Haas for some reason) but there is no mentioning of probe data storage/retrieval as needed or Dprint conversion.

Thanks for any advise you can give.