I'm not trying to give anyone the run around or make excuses.... I'm just trying to help some guys out on the forum using past connections if I can. I'm just a dude, playing the dude, disguised as some other dude My synopsis was just for everyone playing along at home to understand the environment. There's a lot of peeps here on the forum that I know are always curious what the actual problem is. I was trying to help everyone understand. If I didn't do a good job of that, I apologize. Collision control is all $P_WORKAREA_CS_ variables, cycle shapes just need a few special characters to open in the graphics menu. I believe this is all working fine. Syncs aren't magic either, they just aren't the same as an M-code. INIT,START,WAITM,SETM and CLEARM - took an m$, buffer and a pretty short post block to sort out. The syncs come out perfectly fine. The whole system works okay. It's just tedious because you have to manually set the syncs on each toolpath. Just like your MI$ solution (only syncs happen in the Code Expert window on an MT environment, but basically the same thing). On a "normal" machine, you don't have to to do that. After you sync, the machine will chill there until given an additional command. It appears on these machines that each operation requires a sync whether it's objectively "required" or not. That's means there's a lot of alignment PITA to manually sync everything. If you've figured out a set of rules that allows auto-syncing without manual intervention and a set of labels that can be auto applied, that's what appears to be missing from the puzzle.

Thank you for the information, and I might reach out to you depending on the outcome of our help from Mastercam. They are currently working behind the scenes to get this problem resolved, and I am very optimistic that they will get it figured out. May not happen in a short while, but Rhome wasn't built in a day either!

Ball Lock® (jergensinc.com)

Hey Rusty, Siemens 840d user here, although all the machines I currently work on are single channel. I did a little searching and found this video, which fully describes program structure, how the code should look, and a little bit about how the CAM system should output. TL:DR you need a couple of different programs. First is a .JOB which will contain a CYCLE208 and the master program names for each channel. Next will be the master program with the synch codes (which should look like this, WAITM(1,1,2)) and other relevant data. Last will be the .spf programs, which should contain all the cutting data. This is fairly similar to my preferred output method of programs, even on single channel machines. However, CAM software wasn't quiet able to get me all the way there with posting out. I ended up making a python script to handle building of the master program, which works pretty well. Feel free to DM me if you want to see how that works. A couple of notes, it looks like there is a pass option in the WAIT for individual channels. This should allow single channel operation, but without a machine to test it on I can't confirm. This YouTube channel has a lot of really good information on the 840d control, I would highly recommend watching to figure out some of the more powerful options on the Siemens control. Also, there is a machine simulator for the 840d called Sinutrain, this allows some basic simulation on your computer. Really helps when trying to diagnose problems like this with complex cycles, or macro programming.

Every new machine we purchase gets it's own steel grid plate made to suit. max overlap of table is a plus. 5/8-11 and Ø.6255 x 2" grid, All our Fixtures fit every machine. The only ones we wont do is our Kuraki's although we did do the 6 axis KTR 1200.

We've had really good experience with Lang. You can put the studs on almost anything and haven't run into any problems with repeatability between set-up swaps. https://lang-technovation.com/en

I was being generic with the run around bit, I'm sorry if it came across as directed at you. You've invested some time on this topic and dug up a lot of info for sure. Bit of a contradiction here, the whole manual PITA doesn't sound very perfect. All I have to go on here is wild speculation (not seeing anything workflow and am assuming gildemeister struktur for the .mpfs) , so grain of salt and all, but I used the mi$ as a dummy flag and the required syncs increment/output automatically (I'm sure there's other ways to accomplish it as well). If nothing is in gildemeister struktur, then none of what I've said applies.

So, funny story. I basically copied/adapted Saunders plates for my own purposes. And then I clamp a vise on top of it as needed. A previous shop I was at, we bored the flanges of the vise to accept the ball lock and just mounted the vise directly to the table that way. I think Orange Vise uses something similar, but they ball lock in the center of the bed? Per Jergens catalog, a single 20mm shank ball lock has 3000 lbs of hold down force and you always run 2 or more. So, I would say they are plenty good for 99% of applications. If you're exceeding 6000 pounds of tool pressure, you're on a much more substantial machine than I am and I pray for your holders lol

Ball locks is how I like to do it. Either make a sub plate that has a pattern or even machine them straight into your table. I have seen it done both ways. Saunders I think still does custom plates as well, so if you have something specific he might be able to accommodate. He's also coming out with his own zero point quick change system that integrates with his subplates. Might be interesting for you if you use alot of fixtures

we use the 5th axis rocklock system. they even have a kurt vise plate to mount on to the rocklock system. the kurt vise with the plate is heavy though, so we ended getting the HAAS SHOP ARM, to load/unload anything from the rocklock system.

Like all good answers It depends... It appears that for everything other than simple parts, there's still a lot less overall time invested in getting a CAM program to output the code, it's just that I haven't talked to anyone who figured out a way to take out the manual fiddly part of it (all the syncing and labels/comments). It's more that on the syncing part, CAM doesn't really offer much of an advantage. It still offers the normal advantages everywhere else.

It says typical hardness it 86-88 Rockwell. It says low CTE. Probably for something optical

I've been around some of 'em in a low-end job shop. The newer ones I've seen looked like normal quality imported machines, consider them a store-brand version of a lot of your better advertised flavors. The older stuff used a lot of proprietary control parts (think of them as a competitor to someone like Centroid), but they've mostly discontinued that line and focused on being a integrator/machine tool sales channel with Siemens or Fanuc controls. I wasn't terribly impressed by the old lathe control software, but those machines were quite old and it survived a while which is worth something. Those controls are no longer available but Fryer still seemed interested in servicing them, so that was nice to see. The Siemens integration version seemed well done from Fryer's side. The mills themselves were pieces of crap, but it was also ordered to be the absolute cheapest bottom-of-the-barrel vertical mills you can imagine with absolutely no maintenance done on it ever, so, ya know, I'm not really blaming fryer on that one. I'd imagine the linear rail versions are as fine as any other Taiwanese imported iron (it's hard to screw up linear rail machines), and if you get the box way machines plan on doing normal box maintenance to keep 'em in that <.003" range. I've never been around one of their 5 axis integrations, however, and as we all know with a Siemens or Fanuc, 100% of your results depends on your integrator and how well they set up the parameters.

I've been having some conversations on the side, and I think I have a fairly complete picture of the situation now, at least. I'm putting this out here so that everyone playing along at home can understand the problem as I see it. It seems like the problem lies in disconnect between workflows using a Structured Language output (not the standard ISO/G-Code) using a CAM system (Mastercam/Partmaker/etc.), vs. the onboard programming language, and how they get the end goal. From talking to a few people, it seems like all of the structured code itself coming out of Mastercam is correct. It's all the stuff around it that's a problem and it really makes it tedious to get running. DMG wants everything ran on the machine in structured format, which is apparently really good at what it does. It will wrap up all of the kinematics into it, so collision avoidance, easy edits at the control, etc. are all enveloped in this which makes it way safer for the operator and way easier for the DMG techs to help with. The downsides are a lot of the things we take for granted in the ISO/G-Code world (i.e., only needing a sync if you specifically call it out) don't apply. Being Das German, ya, there are rules and structures that exist for the sake of rules and structures existing One problem here is that there are very few DMG techs who are familiar enough with the machines and can really help diagnose issues that are related to structure/workflow. Once you leave their conversational programming world, you're in uncharted waters as far as they're concerned. ------------------- The main problem talked about in this thread seems to be related to the "weird" syncing that you have to do in Mastercam MT environment (and, it sounds like Part Maker/Esprit/(possibly?)SolidCAM as well, I have limited experience with PM & E here), where you end up in a bunch of post-processing work manually syncing things and getting your tokens & labels set up correctly. If you were to use the onboard programming environment, then you would get things synced as you went (i.e., make a toolpath, sync it up, make the next one, sync it up). That doesn't really exist that way in Mastercam, as there's nothing to force you to sync it before moving on the next, or sometimes you can't sync yet, because you haven't made whatever it's going to sync to yet, etc. ------------------- Expanding on this last point, there's also not a good way that you can programmatically describe a solution because it's very much part dependent so you can't really even wave a magic wand and get something that's even 75% of the way there by defining a set of rules, e.g., Always sync Approach of Upper Turret before Motion of Lower Turret. That makes it a really tough nut to crack from the programming side as without those rules, it's hard to express to a programmer how to fix the issue. ------------------- So, pragmatically for now, the best way to work in this environment would be to always have the Code Expert window open, and as you work through toolpaths hit the ol' G1 button and make sure that each toolpath is synced & set up as you go. It's the same amount of effort overall, but at least you're doing it in bite sized nibbles instead of having to make the whole pie at once. If there's a set of small, discreet changes that could be made after you're up and running with that, perhaps changes to MT can be made to support it Mastercam can be given a set of "rules" to follow. I.e., All operations with Upper/Left get automatically labeled SP4 and the Lower/Right get labeled SP3? Make an option for this machine only to automatically sync all unsynced Upper channel if there is a single operation on the Lower Channel, etc. Coming up with this list would be daunting. Another option, although significantly less likely, would be to run this up the chain far enough that DMG/Mori sees a problem like this and gives them an option of turning off the requirements to have syncs where they shouldn't really be required to, or accepting that no labels are okay. Does that seem like at least a good summary? Many thanks go out to @scottm085, the "prefer to remain unnamed" customer I talked about earlier, and a few anonymous CNCers and Resellers that I talked to.

Sorry been on the road for the last 6 weeks and still on the road the next 4 weeks and was killing a little bit of time on my 16 hours home between trips. Was trying to give you more feedback, but out of space to post up more screen shots than what I did. It was education file and as such only a few people could even open it. Like I said I don't have an older version of Mastercam on this computer so what good would have it done to post it up anyway? qc (at) mastercam (dot) com is where you are more than welcome to report the issue you have found. You came in blaming the software and its lacking and I wanted to help point you in the direction to know it was possible. Free time is funny when people try to be helpful to others thinking someone else owes them something. I helped on my own dime taking away from other things I could be doing and sorry I did it in a hurry taking care of 5 other things at the same time. Your attitude is what I suspected it was going to be when reading that first posting and like the last 21 years on this forum you have followed it to a script. Come in blaming Mastercam for its shortcoming. Get upset when someone shows you that yes it can do what was asked and when others point out that you are being an a$$hole then deflect it on to them verse being a person and admitting you came in with a axe to grind verses looking for real assistance. Was is possible? Yes it was. Was it shared in a way others can help with? No it was not, but you got answers anyway, Now your upset that yes the software can do what you want just not the way you feel it should do it and as such it is crap software because you don't like the way it does it when it can do exactly what you originally asked for was can it do it. That about sum it up? Is this a bug? How would any us know if it is a bug or not? We can theorize all day long and call things we find bugs. I do the same thing all the time calling things in Mastercam bugs, but when it could get the job done with some settings that needed to be changed does it make a bug or a user preference?

Just talking to another machinist in the company, he suggests putting bushings right in to the table. I didn't like the idea at first, spent so many years trying to not drill into a table, but the more I think about it I like it.

By my own admission? Like that's something I should be ashamed of and try to hide? What is it with the fragile egos here? And I thought that cliche was about the machinists not the programmers. Pro life tip: If you don't know something, it's okay to admit it. If you're wrong about something, there's no need to feel shame and lash out. That immature personality trait is how we get so many hard headed trump cultists in the U.S. I didn't post details on the bug because the case was closed and I'm not sure it effects the industrial version... However, thin shell up there apparently had to change something in their industrial version, so perhaps the bug is present. Not showing the toolpath or saying which setting was change is a total cop out. I suspect they didn't really have a solution and tried save face and run away. Lit me reiterate, there's no need to "save face" just because you don't know something. That's not a healthy mind set. The bug: Overlap enabled and set to Zero allows the tool to follow the chain back up to the previous pass. It worked on the left side as intended. On the right side, it worked on every pass except the 1st pass where you see the remaining nub of stock. The cutoff was .00004" to get the proper result. The behavior I don't want is for the toolpath to overlap more than 0; I want it to meet the previous tool position in X and not go past. I'm sure the post processor will round down so the nc output would still be what I want simply because there is less precision, but theoretically it's overlapping .00004 on every pass and it should be 0. That is a software error. You can tell me I'm wrong. I don't take offense, but you have to be able to back it up. I do take some issue to you being offended to my inoffensive matter-of-fact response. Sorry if this all comes off as a bit harsh but I'm not going to grovel and tip-toe around someone just because they're sensitive old gatekeepers that think they're hot xxxx who had to work so much harder than everyone else so they hoard industry secrets for a sense of superiority when they know how to do something that requires a workaround instead of petitioning mastercam to fix the issue because they're dug in and by using convoluted software they receive job security. I freely share everything I learn; that's probably why they try to keep me around. Sadly corporate policy to "wear gloves at all times once you step foot in the building" was a dealbreaker. They just installed touch screens everywhere. They just installed fingerprint scanners. What the hell were they thinking. And they just ripped a guy's thumb off because they told him, a lathe operator, to put on gloves. Then they fired him. (tangent rant, my bad.) Idk, maybe the crazy mill guy is touchy because I said programming was easy that one time a long time ago? I mean, I just started a programming job and the day flies. It's like playing a video game all a day. Come on. The only difficulty is in Mastercam's under-documentation and inconsistent work flow stemming from haphazard implementation of new features. It's definitely more difficult being the machinist having to correct programs at the machine because the programmer can't be bothered to get the geometry correct and has an ego that prevents them from working with the machinist and uses excuses like "that's how we've always done it" or "how did Q.C. even found out about this? Because you told them huh you little jackass."... How about you stop shipping bad parts have you thought of that? (oh tangent rant again my bad) Back on topic. If I'm wrong, prove it. And PSA: grow some skin.