CTX Gamma 1250 CNC code parameter

[rusty.ross]

Sorry for the late reply... I was locked out due to being a newbie lol.

Here's the update so far... We have had these machines in the shop for just under 4 years. Originally was going to be setup to run g-code but we had a few DMG guys come in and tell us to run it with their structure or conversational programming. We are at a point now; we need just basic code and was told this Mill Turn software was the way to go! The salesman has since retired, and we are still on the island  waiting for help!

My co-worker aka other programmer has been working on this project since December 2023 when we purchased said software. He has made some headway but just keeps getting the runaround. I can't tell you how many people he has had conversations with, or shared screens with etc. but I know it's quite a few. 

Ok now for my input. I took the file @Aaron Eberhard uploaded and was able to see the changes that should have been made. I was able to fumble around enough to get the software to output the separate files; however, the main program still dumps both channels in one file. I then cut and pasted each channel into its own .MPF file and loaded those onto the machine including the appropriate subs. I tried running the machine this morning and although we finally got some movement we ran into a few alarms. For the time being, I have block skipped them and have the cycle in simulation working!!! 

 We are a long way away but seems promising, especially with the help of you guys. I need to get back to @scottm085 regarding the process as it sounds like he has a workaround that might help us. As of right now our Mill Turn license only works for 2024 version and I'm not sure who we are to get ahold of now since our reseller has retired. Maybe we could share screens when you have time and give us some help?

 

Thank you all for taking the time out of your day and helping us! I know my boss appreciates the progress we have made just in the last 24 hours.

[scottm085]

Something to watch out for, when you post your file, it should be a .ARC then when you read it into the controller it converts the file to a .WPD at this point the controller breaks up your program and puts each file into its appropriate folder. Also, in the sync manager make sure to rename your file to whatever you want to call it otherwise I think it reverts to the name "SAMPLE CODE" and you will have to go in and rename each program file individually on the controller.

[Aaron Eberhard]

1 hour ago, scottm085 said:

We have had meetings with our reseller, post builders from CNC Software, and the guy from DMG who wrote the code for the CTX module/post from Germany. I think everyone agreed that they had some work to do! All of us were in a meeting together, which was nice, but unfortunately not that productive. At this point we're just dealing with the work arounds which is still a headache. It wouldn't be so bad if we were a high quantity production shop, but we are a high mix low quantity job shop which forces us to constantly be changing over setups and running new code on these machines. 

Ah, okay, sounds like you're on the latest stuff, then.  As Newbeeee says, be sure to work your contacts on that side!  Keep them accountable

[Kalibre]

You can also just add .WPD to the folder name where the .MPF and .SPF are and cut/paste straight from the key without chancing something getting borked.

MCAM -> posted MPF/SPF files -> Part CH1/CH2 .WPD folders on key -> into the control

Only times I've done anything with .ARC is controller backups/parameter dumps and firmware upgrades.   

[Newbeeee™]

17 hours ago, Aaron Eberhard said:

Ah, okay, sounds like you're on the latest stuff, then.  As Newbeeee says, be sure to work your contacts on that side!  Keep them accountable

Put yourself forward Aaron for a PO from rusty! You're well into MTM and having worked at the ivory tower, I bet you still have the right numbers to phone if needed - unless they changed them all when you left 

 

 

[Aaron Eberhard]

2 hours ago, Newbeeee™ said:

Put yourself forward Aaron for a PO from rusty! You're well into MTM and having worked at the ivory tower, I bet you still have the right numbers to phone if needed - unless they changed them all when you left 

 

 

I'd be happy to help out Rusty if he needs and I can, but I don't have any real experience flying those machines..

 

For some reason, whenever I call my Mastercam friends, they all say, "New number, who dis?"

 

 

[Aaron Eberhard]

Seriously though, I have forwarded this thread on to a few people to see if I can help get those guys some support

[gcode]

On 4/3/2024 at 6:26 AM, Newbeeee™ said:

Every day goes by, is a day too long. Both DMG and your reseller need holding to account....

True dat..

If it doesn't work, they shouldn't be selling it,,,, and they sure as hell shouldn't be calling it "turnkey"

[JParis]

2 minutes ago, gcode said:

and they sure as hell shouldn't be calling it "turnkey"

Why not?  It sounds like they stole the money, got into the car turned the key and drove the getaway car..

[rusty.ross]

On 4/4/2024 at 9:53 AM, Aaron Eberhard said:

Seriously though, I have forwarded this thread on to a few people to see if I can help get those guys some support

Appreciate that my friend. We had a teams meeting today with our reseller and Mastercam so hopefully were onto bigger and better things! I will be sending you an email Aaron so be on the lookout for that. Thank you again!

[Aaron Eberhard]

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.

[Newbeeee™]

Thanks for the write-up Aaron - very informative.

So basically....ultimately, for this machine, the actual "solution" would be to program on the control - or if they offer one, an offline/PC control....:shrug:

[Kalibre]

17 hours ago, Aaron Eberhard said:

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

This is the general run around I experienced, and at the end of the day it's just a lot of words to say they don't want to expend any effort to provide an actual solution.

The 840D isn't a black box, the Siemens manuals are probably the most in depth I've dug through.

Getting clean, fully functional code that gives the majority of bells and whistles isn't even a herculean task. It's syntax and formatting.

Collision control is all $P_WORKAREA_CS_ variables, cycle shapes just need a few special characters to open in the graphics menu.

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.

DMG apps can't tell you what the CAM output should be, because they don't know outside of the control menu. The solution providers don't have enough customer demand to really want to bother, so say things like ....

18 hours ago, Aaron Eberhard said:

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.

 Sorry, I'll never understand why pretty lame excuses from both parties are accepted with CTX machines specifically, and I guess I have some residual bitterness at the memory of those interactions and no progress was made in the 6 years since apparently. 

[Manofwar]

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.

 

[Aaron Eberhard]

23 hours ago, Kalibre said:

This is the general run around I experienced, and at the end of the day it's just a lot of words to say they don't want to expend any effort to provide an actual solution.

The 840D isn't a black box, the Siemens manuals are probably the most in depth I've dug through.

Getting clean, fully functional code that gives the majority of bells and whistles isn't even a herculean task. It's syntax and formatting.

Collision control is all $P_WORKAREA_CS_ variables, cycle shapes just need a few special characters to open in the graphics menu.

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.

DMG apps can't tell you what the CAM output should be, because they don't know outside of the control menu. The solution providers don't have enough customer demand to really want to bother, so say things like ....

 Sorry, I'll never understand why pretty lame excuses from both parties are accepted with CTX machines specifically, and I guess I have some residual bitterness at the memory of those interactions and no progress was made in the 6 years since apparently. 

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.

[Aaron Eberhard]

On 4/9/2024 at 7:09 PM, Newbeeee™ said:

Thanks for the write-up Aaron - very informative.

So basically....ultimately, for this machine, the actual "solution" would be to program on the control - or if they offer one, an offline/PC control....:shrug:

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.

[rusty.ross]

18 hours ago, Manofwar said:

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.

 

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!

[Kalibre]

2 hours ago, Aaron Eberhard said:

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

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.

2 hours ago, Aaron Eberhard said:

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. 

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.