While I like the views associated with viewsheets, there is no way I could organize them like Levelsets.

Unless someone could show me how I could organize viewsheets like my levels, I can't see going to them any time soon.

6 hours ago, C^Millman said:

I got away from the process using Mill_inch tool library. I have copied all of those tools into each holder library. I then will use that holder library for that machine. Drives me crazy we have every holder under the sun in one tool library, but we on't have the tools in each holder library. Once you see how many clicks and time it saves programming this way will be hard to go back to using the default library IMHO. I have also updated the Big-Inch into every Version since it was stripped out and have given it to many customers so they can have many of the tools they need defined from the start.

Agreed, Ron.

Our Horizontals used dedicated tools (134 per machine), so our libraries for each machine reflect only those resident tools.

We also use libraries for kitted jobs, and special cribs. Then, we attach those to our machine defs that reside in our templates. Our templates contain all fixturing used on that machine.

Makes things soo much easier.

I just showed the Mill_inch, because I just opened MCX to a default vertical that we don't use libraries for (only 16 tools).

Yes. In your machine def, select the following:

1) General Machine Parameters
2) Inside the General Machine Parameters Dialog 2), select tab 3) Tool Material Libraries.
Then, Select your library 4).

Save your machine def, and the library is assigned.

Always make a backup before changing a machine def.

The post is outputting the correct value for a Fanuc style control.

R is treated as an incremental value from the INITIAL plane, So, an Absolute Z.1 IS -.9 from an initial plane of Z1.0 as in your program.

The absolute/incremental in the cycle only determines where the R plane should be in reference to the geometry. It has no bearing of whether or not an R value is absolute or incremental in the control. Those are two different things.

From a Fanuc manual:

Now, if you want this to do something else, it will probably be in the prdrlout or lchpbrk$ postblock.

But since I'm not too well versed in the LATHE POST BY LEO postprocessor, I can't tell for sure.

On 9/1/2017 at 6:57 AM, So not a Guru said:

Thanks Günther, it is fantastic of you to keep this add-on updated & improved. It is one of the best tools available for communicating between the programmers & operators/setup men.

If it ever came to the point of losing X+ or upgrading Mastercam, I would stay at the X+ capable version until I found a new software.

In the past, I've created a safety sphere on it's own level. Then I project points onto, and all around the sphere, in a grid pattern I think will suffice.

Then , I can select any of the appropriate points in any 3+2 plane to use as an escape point for any operation I may wish. It's easy and visual.

2 hours ago, Mark K Smith said:

Learned the whole "why won't cylindrical interpolation work" thing on this machine as well.  It's a Y axis one also.  Seems it will drive G2/G3 just fine if you accidentally leave g18 vs using g17 but Cutter comp won't actually make any adjustments from zero.  I have enough headaches.  Sounds like you have your hands even more full.  haha    Thanks again for the confirmation of what I thought was the likely reason.

 

The sad part of all of this, is we had to create test coupons to verify planes, comp, and motion for a given combination.

Star (the Swiss machines we have) does not even know what the combinations are.

Their response to my inquiries ( the books don't go into that info for a given combo) was "we just program the way we think it should be, and if it is wrong, change it".

I explained that we are Post and Play, no at machine edits allowed, and his response was "nobody can do that on these machines". He is Star's best applications guy. That was also Partmaker's response.

We post directly to the machines. No matter how complex the operations. Including pinch milling and turning with 2 turrets, while pulling in Z sync and spindle/C sync with the sub spindle.

Needless to say, Autodesk (Partmaker) does not see our posts. It is our competitive advantage.

2 hours ago, David Colin said:

It s the same here on our Integrex. I wondered why and understood that X,Y an Z axis direction are the same for main/sub spindle but you are milling from opposite Z axis. You should also notice same behaviour with G2/G3.  

That is why. As long as the Z motion is not mirrored.

Some machines, a Z- move is deeper into the chuck, Regardless of main or sub spindle.

This configuration swaps G2/G3 and G41/G42 from spindle to spindle:

Main                                                              Sub

Z- >>>>>>>Z+                                           Z- >>>>>>>Z+

This does not:

Main                                                              Sub

Z- >>>>>>>Z+                                           Z+ >>>>>>>Z-

Now, you can imagine my day. Creating and proving posts for 3 turret, twin spindle, 13 axis, 3 channel machines. Some Siemens, some Fanuc.

Throw in G18/G19 plane swapping for cylindrical and polar interpolation, depending on spindle/turret combination.

Generally, CRC is opposite on the Sub. So G42 climb would be correct.

But definitely test.

23 hours ago, lowcountrycamo said:

Well I did not ignore anything.  Was only told of the warning and scrap after it happened.  We are both somewhat new to 5axis programming.  This is a table table machine with c axis unwinding.  Our reseller sent us back a toolpath to try and it was even worse but moved in different ways.  Both had Caxis spinning in the cut.  What troubles me is we have been making parts for months with little trouble.   We tried the same path on our haas trunnion and it looked just fine.  I am not passing blame.  Just trying to understand something I obviously don't.

One thing to look at, is that while it is the C axis unwinding, it may be due to an A (or B?) axis limit, wherein the post is unwinding C to move to the other (always 2 combinations for any given 5 axis move), more achievable axis combination. This is where knowing your machine's kinematics as Ron said above is key in understanding how axis combinations are arrived at.

This could be as simple as seeding an MI$ secondary axis position. Or not. Knowing your kinematics is the answer.

Just a heads up....

When creating a buffer for 8 digits tool numbers, be sure not to index on the tool. Use a different value, even if it is a dummy.

Otherwise, your buffer might end up with 86,125,050 or so records.

I would have to see how the tool list is being created. Normally, it is with buffers.

In our toolchange block, we use a lookup table and increment it each time the tool is used.

Here is a part of the lookup table:

# --------------------------------------------------------------------------
# Define Tool Number Usage
flktbl  3       64      #Lookup table definition - table no. - no. entries
    0   1
    0   2
    0   3
    0   4
    0   5
    0   6
    0   7
    0   8
    0   9
    0   10
    0   11
    0   12
    0   13
    0   14

.................................

And here is how we increment it in our ptlchg_com postblock:

tused       : 0     #Nth time a tool is used - for N9 numbering


ptlchg_com      #Tool change common blocks
     .........	
	code and stuff here
........

      tused = flook(3,t$)
      #"This tool has been used ", *tused, "times", e$  ### Debug for counting number of tool changes for N9 numbers. 0 is first time run.
      result = finc(3,t$)
      if tused = 0, n$ = (t$*10)+ tused
      if tused > 0, n$ = (t$*100)+ tused
      if plane$ < 0, plane$ = 0
      if sof & scomm_sav <> snull,
        [
        spaces$ = 0
       *n$, pspc, scomm_str, *scomm_sav, scomm_end, e$
        spaces$ = sav_spc
        ]
....... more code and stuf here
.......

We use the tused variable to store the tool number and number of times used.

The finc(3,t$) line increments the lookup table value of times used by one.

For T1, it outputs N10 the first time used, then it outputs N101 second, N102 third, N103 fourth, etc....

For T2, it outputs N20 the first time used, then it outputs N201 second, N202 third, N203 fourth, etc....

11 hours ago, C^Millman said:

What if you wanted the N block number to be in the tool list and at each tool call? Will you need a buffer? I did a simple process, but if the tool gets used more than once the process is broken and it doesn't match. I am thinking the dreaded buffers will be needed since buffers are used for making the tool list. How do you make the tool list use a number and then have the program use it for a tool even if the tool is used more than once in the program? Any way without buffers?

Couldn't you use the normal lookup table method used for N$ increments inside the buffer and ptlchg to keep track?

Of course you would prolly want to use different  variables  (say tused and btused ) inside the buffer and in ptlchg postblock

I think they would maintain the same increments whether pre-processed (buffer) or processed.

      tused = flook(3,t$)
      #"This tool has been used ", *tused, "times", e$  ### Debug for counting number of tool changes for N numbers. 0 is first time run.
      result = finc(3,t$)

Just thinking out loud...

On 2/7/2017 at 8:31 AM, Colin Gilchrist said:

 

All of those reasons are good things. You aren't crazy. Those are some of the exact same reasons I started learning how to edit post processors many moons ago.

 

The Generic Fanuc 5X Mill Post is certainly capable of supporting this machine, unfortunately there are some functions like TCPC that do not work OOTB (Out-of-the-box). You have to add your own logic to support these functions, or pay someone else to do it.

Agreed. Fortunately, Mastercam has a number of options in terms of posts. there are a number of good post writers out there in IHS, Postability, etc

You can also go the route of external posts, ie Camplete, ICAM, etc...

Or, you can learn to edit posts yourself.

I only wish that CNC would get there act together for Millturn and Swiss...

We use Partmaker to program our Swiss machines. Lesser of all evils. Especially now that Autodesk bought Delcam, and are pushing towards the subscription model licensing.

We have a number of 12 axis Star ECAS machines. 3 channel, 3 turret Swiss machines. These machines have Siemens 840 controls.
Partmaker posts are terrible. You pay for a post, and lots of stuff doesn't work. G@/G3 and comp backwards on a turret, wait codes mis-aligned, you name it. A stock post will not make a simple program without machine alarms. Partmaker support can help a bit, but they are no Dave Thomson. and a simple edit takes weeks to get back.

There is nobody like Camplete or ICAM or Postability for Partmaker. Only Partmaker.

So I learned how to edit their posts, and have a 100% post and play, send to the machine, no hand edits required system in place.  We now do stuff Partmaker says cant be done in Partmaker. We now have a competitive advantage over everybody that programs Swiss with Partmaker.

Now, we buy some new Star machines. These are ST-20 machines. Same as ECAS, but because Star and Siemens have a falling out, Star no longer uses Siemens, but Fanuc.
We now need a new post. For a 12 axis, 3 turret, 3 channel machine that we already have a post for, but in the wrong language.

Easy-peasy. I convert our existing post from Siemens commands into Fanuc commands, retaining all of our existing logic, user conditions, and custom cycles. Since I already knew the logic by heart, this was pretty painless. A Partmaker post would have needed more time to fix than ours took to convert, and about 6 grand to boot.

So I guess the moral of this story is to use the tools at your disposal, but the best tool may be in your own shop.

Then I guess I'm not seeing what you are truly after. Because I see you say "all axis arrive at the same time", I think inverse time. That is what it is designed to do. 

Inverse time feeds.

Are those tooling balls in known locations?

If so, just add in some modifiers to recalculate offsets by those modifiers after the TOX TOY and TOZ calculations are done.

You can access the tool plane matrix info in M1$ ~M9$

Just thinking out loud, as I'm kind of confused as to what you are actually looking for...

Thanks for the explanation.

I did essentially that between Cribmaster and Mastercam and Jobboss (or Vista) using scheduled queries and custom reports in Crystal.

Contrary to popular belief, custom reports can be used to build and write back to tables in basically any format required, and scheduled to import or export the data based on changes or time.

We live updated back and forth between Oracle, MS-sql and access with no issues. But the key is having access to the back end. SAP should be able to connect no problem I would think.

Frank,

 

I manipulate WinTool and Zoller databases on a weekly basis. I've written half dozen applications to query WinTool and CIMCO databases. Don't bother to waste time building MC databases if you are going to have WinTool2Mastercam interface.

 

Not a technical constrain, but anyway WinTool is MS-SQL or MS-Access and Mastercam is SQLite. It's like saying your are going from TCP/IP data transfer to save stuff in a file.

 

 

Besides, their tables don't have much interoperability with each other in terms of how data is structured. They're designed with different purposes in mind.

Question Daniel... Do you use Chrystal Reports?

Reason I ask, is the interoperability between datasets is unbelievable.communicating between MS-SQL and any other flavor of SQL (or ODBC compliant data - Oracle, Sybase, ) is as easy as drag and dropping arrows to map fields. They only have to meet the same data type and size constraints.

I always see people build these applications to extract data and then re-format and import into the other dataset.

Is there something I'm missing?

Ron, what then is singularity in the driving situation with the wife?

 

LOL!

That's when you both agree on the destination, but argue about how to get there.

The way I see that Zimmerman, is the math is not more complex, they are just dividing the dual solution rotation combinations by splitting the AC by adding a B divisor.

That could actually be done with the existing post by simulating the seed start position and limits MI's with math.

Instead of forcing a re-position when you hit a limit, it engages the B axis to modify the vector so that AC can now achieve it.

But that area of the post is prolly binned, so this is just speculation.

This setup doesn't actually add degrees of freedom, it just divides them up into shorter move solutions.

I tried reinstalling it. On both systems. Nothing changed. Not sure why, but the only place I could see the X+ items were in categories. Till I changed Lang.dll

Ben, that wasn't VBA, but a decompiled/edited/recompiled dll resource file.

I'm sure Gunther can say if I'm all washed up or it was just coincidence on our systems that fixed it. But that's how I got them back in the list.

Heck, it could boil down to permissions or any range of things. This tech stuff confuses me.

I've looked in all the pull down areas.

Have you looked on your customize ribbon area since installing? My system wasn't updated, and it showed properly. Another system was, and they were not in the commands. I updated my system, and they were gone like the other (updated) system.

I actually got it working correctly by hacking the Lang.dll and getting rid of the /n"chookname" in the string selector. (Hope you don't mind, Gunther, I will never share a hacked resource file)It was already like that for TPSketcher, which led me to try that. The entries magically appeared in the commands column.

All is right with the new Lang.dll

As of the last 2017 update (19.0.11004.0) X+ items no longer (well, only TPSketcher) shows in the commands area of the customize ribbon. All of the items show in Categories, but that only allows you to put them on a context menu.

See pics below:

 Only TPSketcher in list for commands:

All items in list for Category: