Help - Search - Members - Calendar
Full Version: maho 800C postprocessor
SprutCAM forum > SprutCAM Forum > SprutCAM Postprocessors
Hello all,

I'm from the Romanian reseller of SprutCAM.

These days I have to deal with a MAHO 800C machine with a Heidenhain TNC control. I have no ideea what kind of TNC it is because the owner didn't have any manuals at all.

I tried to run some tests in order to figure out how the controller works (linear, circular interpolation) but the owner didn't allow me to stop its production more than 20 mins (he has some hard production dealines to meet).

So, the conclusion is:
- it is like a TNC 151, but the circular interpolation does not work like that
- the closest post-processor from SprutCAM its the MahoHem232, but there are some differences (the main one is that MahoHem232 uses X Z instead of X Y axes, but that is easy to modify).

After this long introduction, here comes my cry for help smile.gif

Does anybody worked with this machine and developed a post-processor for it ?

Of course, I'm ready to start working to develop a new one, but hopefully someone just did that before.

Thanks in advance.

Hi Radu,

I don't have a postprocessor specifically for this machine, however I do have a good Heidenhain postprocessor that you are welcome to try.
You can download it here

The older Heidenhain controls tend to be a bit fussy about arc's and if you are getting errors I would suggest altering the 'Tolerance (digits)' value in SprutCAM to at least 1 more than the number of decimal places that the postprocessor is using.
This postprocessor is outputting to 3 decimal places, so I would suggest using at least 4 or maybe 5 as the Tolerance (digits) value.

Hi Dave,

Thanks for your help.

However, the main problem consists in the way the fixed cycles are programmed.

The fixed cycles are defined in the same way as in the post processor you sent me, but they are called in a different way. For exemple, for drilling two holes, the sequence is:

cycle definition

LBL 1 (start underprogram)
position above the first hole and calling the cycle (M99)
LBL 0 (finish subprogram

LBL 2 (start underprogram)
position above the second hole and calling the cycle (M99)
LBL 0 (finish underprogram)

Do you have ever seen a SprutCAM post-processor with that facility ?

However, if there isn't such a post-processor, I believe the cycles may also be called without using underprograms. I have to check that.

Anyway, thanks again for your help.

Hi Radu,

No I have not seen a postprocessor to use labels in Heidenhain language.
It seems to me that this is perhaps a request from the customer rather than a specific requirement of the machine?

I have had these kinds of request from a couple of my customers before, and I just explain that the use of labels in Heidenhain are very useful for making programming easier at the machine, however, when we are programming offline they have no benefit and are (in my opinion) unnecessary.

It would be possible to modify a postprocessor so that it uses M99 instead of the CYCLE CALL command, but I prefer the latter method because when test running a program in single step mode on a Heidenhain machine, when using M99 the machine will move to the X/Y position and immediately drill the hole, whereas, using the CYCLE CALL method the machine will move to the new X/Y position and the drilling will not proceed until cycle start is pressed again.

If the machine can only drill holes using the LBL method, then I think this would need some input from Sprut themselves as I'm not sure that it would actually be possible.

Hi Dave,

You were entirely right, it is a specific request from the customer.

Actually, there are some post-processors which use LBL's, but in a different way. So, I belive it would be better to discard the use of labels instead of modifiyng the posts.

Thanks for your help,

Hi Radu,

You are welcome.
I have had a quick look through my library of postprocessors and I did find one which used LBL right at the end for creating a park position.
From what I can see it didn't actually achieve anything that couldn't have been done by not using a label.

1659 LZ+20R0F MAX
1660 L Z+150 R0 F MAX
1661 LBL 999
1663 L Z+100 R0 F MAX M5 M9
1664 L X+0 Y+500 R0 F MAX M91 ;TISCH VOR
1665 LBL 0
1666 CALL LBL 999
1667 L M30

I personally would have used QDEF's instead which would have been a lot more flexible from a machine operators point of view......

Hello Dave,

Unfortunately, I run into the error you told me regarding circular interpolation.

You recommended me to alter the 'Tolerance (digits)' value in SprutCAM to at least 1 more than the number of decimal places that the postprocessor is using.

My question is, where should I do that:

- in Job list - Parameters - Preferences - Toolpath generation parameters - Tolerance (digits


- Options - Import - Curves approximation tolerance ?

I believe it is the first one, but...

As always I rely on your help.


Hi Radu,

Yes the first one you mentioned is correct. You can check in simulation mode, by looking at the CLData, you should see that when you have made the change, the calculations will work to 4 decimal places after the decimal point.

I hope this helps.

This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2019 Invision Power Services, Inc.