Issues with Heidenhain/MANUALplus post processor and Gildemeister lathe

[yoshimitsuspeed]

I am having all kinds of issues getting this post processor to work with our Heidenhain/Gildemister lathe. I had this working a couple years ago but haven't needed CAM for a while. 
I am running a 2020 post with some custom code I needed to do to get our machine working correctly. I have also downloaded the most current post and all issues I am having in both. 
I'll post back when I remember other issues but right now I can't get it to do a drilling cycle. 
First it gave the error Parameter Q cannot be assigned to any function. I found this is tied to the pecking cycle. It's a deep hole I want to peck but I decided to try a drill rapid out just to see if I could get it to run but now it gives the error R cannot be assigned to any function. 
I could have sworn there used to be an option to output things like a chip breaking cycle as gcode instead but I can't find it now. 

[yoshimitsuspeed]

Issue 2

It seems to be calling tool numbers backwards. 
The machine has an 8 tool turret. Then there is the tool list which has setup and offset info for all tools. 
So if I want to call tool 1 on the turret and tool/offset 8 from the tool list I want T601.
In the tool editor under post processor if I set number to 1, and offset to 6 it will call up T106

In typical tools I got the right T call by switching number and offset numbers. This isn't properly calling up my drill though. 
In the master tool list it is number 33 and it is installed on T6 on the turret. 
If I enter 33 for number it calls T3300 no matter what I try. I have tried entering 6 for length offset and for diameter offset but no matter what it just calls 3300 when I need it to call 3306. 

Not the end of the world but annoying when I have spent hours now messing with similar issues, plus those mentioned above. 

[yoshimitsuspeed]

Issue 3
G94 and G95 aren't giving F values so I have been entering them manually. 

[yoshimitsuspeed]

Didn't there used to be a way in the Post process interface where you could tell it to convert something like drilling, chip breaking, ops into basic Gcode movements instead of a Gcode command? This would at least get me up and running. At least I hope, assuming there aren't other issues. 

I spent some time looking through the post processor for such an option or something that might help me work around this bud didn't find anything. 

I did find the G7X drilling commands section but I don't know what would need to change. In a quick search it almost looks like some machines see these as completely different operations. Other discussions show completely different letter usage for different machines. Some use Q and R, other's don't. I feel like I would need to know a ton more to have a chance of going in and messing with that though. 

[seth.madore]

Yes, it's called "expanded cycles". Could you share your post processor here?

[yoshimitsuspeed]

Post name is in title of thread

https://cam.autodesk.com/hsmposts?p=heidenhain_turning

[yoshimitsuspeed]

There is nothing in my 2020 post or in the most recent post called expanded cycles. 

There is this little part mentioning cycleexpanded but this is the only thing even including the word expanded in the whole post

if (cycleExpanded) {
expandCyclePoint(x, y, z);
} else {
writeBlock(yOutput.format(y));
}
}
}

function onCycleEnd() {
if (!cycleExpanded) {
writeBlock(gCycleModal.format(80));
zOutput.reset();
}

[yoshimitsuspeed]

@seth.madore 
I still haven't found how to do expanded cycles or to find any solutions that would allow me to get this machine running, let alone all the little bugs that I will have to deal with if I did. 

[seth.madore]

Before I dig up the info on how to convert this exact post to Expanded cycles, do you know exactly what you need for existing canned cycles to work? Do you have a programming manual for your machine/control?

Regarding the tool offsets and things being backwards: you state that you have an 8 position turret. Does your controller understand that "station 7" (as an example) is not T33?

Do you reassign your turret numbers with each job? Would it not be better to just number the tools when they hit the document level? So, T606 is in turret #6, T101 is in turret #1 etc etc

[yoshimitsuspeed]

@seth.madore 

 

The shop is a bit of a drive but my friend snapped this pic today. If you need more I can get it to you. 

[yoshimitsuspeed]

As for tool numbers. 
To give a little more info, this is at my friends shop. I was working with him more when he got the machine and helped get it set up and running and programmed some projects in Fusion 360 and HSMworks. 
I did have it running programs generated by F360 and this post processor and even drill ops which has me a little confused. With that said I feel like I remember there being a check box or easy way to switch to expanded cycles. Maybe I'm wrong but whatever the case I just did a new post of one of those old programs I ran and it includes Q and R so either the machine used to accept these and doesn't now, or I had it running expanded cycles. 

Anyway I haven't been involved for a while and he found the internal programming got him by well enough to not want to deal with CAM for the jobs he was doing. 

Now I'm trying to get everything set up properly to try to get F360 CAM operational again. 

Adding that context because when I was first working with the recently acquired machine we didn't have much more than 8 tools and just moved them around in the tool list so they were always 101, 202, etc. 

Now however the tool list is getting at least into the 40s. He has his own system of numbering set up and has that working with his operations programmed directly in the machine. So now it would be a lot more inconvenient to need to move tool 33 in the tool list to position 3 for turret 3, and then keep track of what is where, what needs to be moved back, etc. 

I will admit this is outside my area of expertise and maybe we are doing it wrong or could be doing it better I also don't have all the nomenclature. 
I am assuming by station 7 you mean the physical tool spot 7 on the turret itself? 
Then assuming that is correct, and in the tool list we have tool #33, if I call up 3307 the machine loads offsets, tool angle, etc, assigned to 33 in the tool list and it rotates to tool position 7. 
If I call tool 107 it loads offsets and info from tool list tool #1 and rotates to physical tool position 7. 

As far as I know this means that to get tool offsets and info in tool list #33 to work with 707 I would need to move the existing tool 7 in the tool list, copy, and paste tool 33 into 7. This seems less convenient generally but would also require him completely changing his existing workflow, organization, tool numbering system, etc. 

[yoshimitsuspeed]

Since we are getting close to a related issue I will mention it here just in case it is actually related, or in case anyone has any ideas. 
We have always had to call a tool number twice to get it to load. So for example if it has tool 3 in position and in the UI if I type in 101 it does not rotate to 1 but the UI shows it has gone to 101. Then if I type in 102 it will rotate to tool 2 and show 102. 
In Gcode we have to call the tool twice to get it to move to position. I was doing this manually but learned how to modify the post processor so that it just doubles the toolchange gcode. IE

N25 T101
N30 T101

We have always expected this is an issue somewhere between software, firmware, and hardware. 
I figured I'd mention it though in case it is something else, or if we actually aren't calling up tool numbers properly or something like that related to why things seem to be calling from F360 backwards to what is working on the machine. 

[seth.madore]

I should state (just for the record) my turning experience is only in Fanuc based systems. So, how "I" do things and expect them to be could very well be quite different than how other flavors of NC Controls decide to do things.

From what you're saying, you have a tool table in the control that allows you to easily assign tool numbers to turret pockets/stations, is that correct? (My Lynx has no such easy method; T101 is always station #1, offset 01)

As for having to call it up twice, this sounds very much like a machine/control issue.

[yoshimitsuspeed]

@seth.madore 
Yes exactly, it can store a huge or maybe indefinite number of tools in this tool list in the control. So any tool I add I can add a new line designating it to the next number in the list, input offsets, tool angles, or drill bit diameters and data, etc. If I remove or move a drill bit in the toolholder I can just go in to that tool and readjust the Z, or if I change the stickout of a cutter just readjust the x offset. I don't think it applies to CAM Gcode but it also has things like spindle rotation direction for the internally programmed operations and other data. So that is very handy in that we don't need to do a full offset and setup on a tool, and if we pull the whole tool and toolholder off, then put it back on don't have to change anything. Just call up that number from the tool list. 
It also allows you to copy and paste. So to give another example of how this all works, or how I have been taught to use it at least lol. 
If I have an 11mm drill bit in tool list #19 and physical turret position 1 so calling 1901 and now I want to switch to a 12mm drill I can copy tool 19, paste into #20, change the diameter in the setup to 12mm, and set the z offset and now I'm ready to go. I can take the 11mm out of turret spot 1 and put the 12 there and use 2001, or I could leave the 11 in turret position 1, load up the 12mm in say turret position 5, and call it up and put it in position with 2005.  

[seth.madore]

And how do you define the tool number and offsets in Fusion?

[yoshimitsuspeed]

@seth.madore 
So let's say I have put tool 33 from the console tool list into turret physical position 7. 
In the console I call this by punching in 3307
Looking in the F360 tool library I would expect this to mean "number" should be 7, and "compensation offset" should be 33. However this gives the Gcode output of T733. 
If I enter "number" 33 and "compensation offset" 7, it does output T3307 for turning tools. 
I haven't gotten to running this yet but I expect it would work fine, it just seems backwards and I'm not sure if there are any issues it could cause. 
The biggest issue is with drill ops though. 
If I set "number" to 33 it will always call up 3300. If I set length offset, and or diameter offset to 7 it still calls up 3300. 
I cannot figure out a way to get it to call up 3307, aside from of course editing the gcode after generation. Which isn't the biggest deal in the world but it sure would be nice if this all just output properly and intuitively. 

Also even going to the more traditional T101 this doesn't seem to work properly for the drill op. Entering 1 for "number", "length offset", and "diameter offset", it still generates T100. 

Probably redundant but to clarify with the drill op this means it will call up the stored offset, angle, cutter, etc data for that tool number in the too list with the first number/s, but will not give the command to rotate the turret to the proper position which it expects from the last two numbers. 

[yoshimitsuspeed]

@seth.madore 
Any thoughts or updates? At least maybe being able to run expanded cycles to see if that gets us up and running? 

[seth.madore]

Sorry man, I've been swamped. For the Expand cycle: just add the following code to the top of onCyclePoint (or you could remove the entire onCyclePoint function).

if (true) {
expandCyclePoint(x, y, z);
return;
}

[yoshimitsuspeed]

@seth.madore 
Thanks for the help. Other stuff came up but I hope to test this out later this week. 

I am always a little confused on what counts as within the realm of what AD is responsible for updating regarding bugs or issues with these post processors but it seems to me these issues would qualify. Do you think the issues I have listed here would get pushed to devs and fixed for the next version? 

[yoshimitsuspeed]

@seth.madore 

Thanks for your help. I was able to get it running with the correct edits and disabling canned cycles. 
While I can run programs now it is very time consuming making the edits and becomes quickly infuriating if trying to dial in a post needing to make all these changes every time I make one little change in Fusion and output a new post. 

I would really hope Autodesk would be willing to fix these issues. 
I don't know if the current post is working for other machines. In which case maybe it needs to be branched for different machines, or different Heidenhain versions, software versions or something. 

Thanks for your help so far. I would love it if we could get this to be more functional out of the box instead of needing to make so many modifications to the post processor, and then to every post it generates. 
https://forums.autodesk.com/t5/fusion-support/bd-p/962