Got a quick question for Les. I am working with a guy that is using version 5.0.1 of sheetcam. Is there a post processor for the Heidenhain 150 conversational?

I am afraid I don’t. Does it have to be conversational?

I’m more familiar with the conversational so that is what I am comfortable working with.

I compared a Sheetcam TNG conversational.scpost to a Sheetcam Heidenhain.post and there were some differences of course. I read in another thread that the .scpost files will not work with the Sheetcam version I am working with.

I had some mild success with rewriting the .scpost conversational to work with the version I am using. I managed to get some output that came close to being correct. I don’t know the logic of the code that processes the .post file so I couldn’t get it right.

Will it be possible for me to rewrite the .post to work or has the code changed so that it isn’t possible?

Thanks for everything.

Well I nearly have it figured out. Its a matter of renaming the functions and knowing what has been added. For instance the naming convention has evolved from move() to OnMove. rapid() to OnRapid.

To test it I created a 4x4 rectangle and ran it with Sheetcam TNG and Sheetcam standard and compared the output. The output is nearly identical with some exceptions which are as follows:

Sheetcam Standard

0 BEGIN PGM 0001 INCH

1 TOOL DEF 1 L+0.000 R+0.000

2 TOOL CALL 1 Z S2500

3 L Z+1.5000 F394 M ← M03 is missing

4 L X-0.0469 Y-0.0000 F M

5 L Z+0.0197 F M

6 L Z+0.0000 F15 M <—this is extra. TNG does not have it

7 L Z-0.1250 F M

8 CC X-0.0000 Y-0.0000 <—getting negative numbers

9 C X-0.0000 Y-0.0469 DR+ R0 F75 M

10 L X+4.0000 F M

11 CC X+4.0000 Y-0.0000

12 C X+4.0469 Y-0.0000 DR+ R0 F M

13 L Y+4.0000 F M

14 CC X+4.0000 Y+4.0000

15 C X+4.0000 Y+4.0469 DR+ R0 F M

16 L X-0.0000 F M

17 CC X-0.0000 Y+4.0000

18 C X-0.0469 Y+4.0000 DR+ R0 F M

19 L Y-0.0000 F M

20 L Z+1.5000 F394 M

21 STOP M02

22 END PGM 0001 INCH

Sheetcam TNG

0 BEGIN PGM 0001 INCH

1 TOOL DEF 2 L+0.000 R+0.000

2 TOOL CALL 2 Z S1000

3 L Z+1.5000 F394 M

4 L X-0.0469 Y+0.0000 F M03 ← 03 is present. Missing in Standard

5 L Z+0.0197 F M

6 L Z-0.1250 F15 M

7 CC X+0.0000 Y+0.0000 <—these numbers are positive. Neg in Standard

8 C X+0.0000 Y-0.0469 DR+ R0 F75 M

9 L X+4.0000 F M

10 CC X+4.0000 Y+0.0000

11 C X+4.0469 Y+0.0000 DR+ R0 F M

12 L Y+4.0000 F M

13 CC X+4.0000 Y+4.0000

14 C X+4.0000 Y+4.0469 DR+ R0 F M

15 L X+0.0000 F M

16 CC X+0.0000 Y+4.0000

17 C X-0.0469 Y+4.0000 DR+ R0 F M

18 L Y+0.0000 F M

19 L Z+1.5000 F394 M

20 STOP M02

21 END PGM 0001 INCH

The reason I’m trying to rewrite it is because I only have the full version of Sheetcam Standard to work with. Standard doesn’t come with conversational .post for my bridgeport and for some reason my machine will not process the g-code properly. When I try to transfer the g-code files to my bridgeport they wont transfer. The conversational posts transfer just fine. I don’t think its an error on my part. I change the machine language over to ISO before I try to transfer and I rename the file extension .I

Sorry I didn’t reply earlier. It looks like you are pretty close.

```
3 L Z+1.5000 F394 M <-- M03 is missing
```

Are **function spindlecw()** and **function spindleccw()** spelled correctly? You must not use upper case.

```
6 L Z+0.0000 F15 M <---this is extra. TNG does not have it
```

Yes you will get this. It is possible to get rid of it but not easy. Will it cause any problems?

```
8 CC X-0.0000 Y-0.0000 <---getting negative numbers
```

This can happen in both versions. It shouldn’t make any real difference. Does it upset the control?

function spindlecw() and function spindleccw() were not correct in my version. I renamed the functions and now I get the M03. At first I only renamed what I thought I would be using when rewriting the .post. I didn’t rename the tapping functions. I went ahead and renamed everything.

I haven’t checked if the control will mess up with the negative numbers. I am going to my shop later today to try to upload the code and see if it works. I’ll let you know.

Thanks for the help!

Everything worked out great. My machine didn’t complain at all about the X-0.000 and Y-0.000.

Feeding to Z+0.000 worked out okay too.

I exceeded the memory capacity of my machine by trying to upload a program with over 1000 lines but its all good. That’s what drip feed is for I guess.

Excellent product! I’ll be upgrading to Sheetcam TNG when I make some money with this machine.

New problem. The new post works great for plasma but I can’t drill anything. I get an error when running the post processor.

Post processing started…

Drill 0, 3/8 Drill Bit, 0.125 inch Deep

…SheetCam\Posts.…

6: attempt to compare nil with number

Post processing completed

Process completed with 1 errors and 0 warnings.

What I get in the output file.

0 BEGIN PGM 0001 INCH

1 TOOL DEF 12 L+0.000 R+0.000

2 TOOL CALL 12 Z S1000

3 L Z+0.3575 F10 M03

4 X+1.2500 Y+1.4093 F M

Edit: I messed with the drill function and copied over a function from the G-Code .post called function newprocess().

Now the output I get is this:

0 BEGIN PGM 0001 INCH

1 (Process: Drill 0, 3/8 End Mill, 0.125 inch Deep)

2 TOOL DEF 13 L+0.000 R+0.000

3 TOOL CALL 13 Z S1000

4 L Z+0.1575 F10 M03

5 X+1.2500 Y+1.4093 F M

6 Z+0.0100 F M

7 Z-0.0200 F M

8 Z-0.0100 F M

9 F M

10 Z-0.0400 F M

11 Z-0.0300 F M

12 F M

13 Z-0.0600 F M

14 Z-0.0500 F M

15 F M

16 Z-0.0800 F M

17 Z-0.0700 F M

18 F M

19 Z-0.1000 F M

20 Z-0.0900 F M

21 F M

22 Z-0.1200 F M

23 Z-0.1100 F M

24 F M

25 Z-0.1250 F M

26 Z+0.1575 F M

27 X+0.5000 Y+0.5974 F M

28 Z+0.0100 F M

29 Z-0.0200 F M

30 Z-0.0100 F M

31 F M

32 Z-0.0400 F M

33 Z-0.0300 F M

34 F M

35 Z-0.0600 F M

36 Z-0.0500 F M

37 F M

38 Z-0.0800 F M

39 Z-0.0700 F M

40 F M

41 Z-0.1000 F M

42 Z-0.0900 F M

43 F M

44 Z-0.1200 F M

45 Z-0.1100 F M

46 F M

47 Z-0.1250 F M

48 Z+0.1575 F M

49 X+1.6250 F M

50 Z+0.0100 F M

51 Z-0.0200 F M

52 Z-0.0100 F M

53 F M

54 Z-0.0400 F M

55 Z-0.0300 F M

56 F M

57 Z-0.0600 F M

58 Z-0.0500 F M

59 F M

60 Z-0.0800 F M

61 Z-0.0700 F M

62 F M

63 Z-0.1000 F M

64 Z-0.0900 F M

65 F M

66 Z-0.1200 F M

67 Z-0.1100 F M

68 F M

69 Z-0.1250 F M

70 Z+0.1575 F M

71 X+2.5000 Y+1.4093 F M

72 Z+0.0100 F M

73 Z-0.0200 F M

74 Z-0.0100 F M

75 F M

76 Z-0.0400 F M

77 Z-0.0300 F M

78 F M

79 Z-0.0600 F M

80 Z-0.0500 F M

81 F M

82 Z-0.0800 F M

83 Z-0.0700 F M

84 F M

85 Z-0.1000 F M

86 Z-0.0900 F M

87 F M

88 Z-0.1200 F M

89 Z-0.1100 F M

90 F M

91 Z-0.1250 F M

92 Z+0.1575 F M

93 F M

94 STOP M02

95 END PGM 0001 INCH

If you send me a copy of the post I’ll take a look at it and see what is going on.

Thanks for looking at it.

I changed the .post to .txt because the forum would not let me attach a file with the extension of .post

Here is a tweaked version of your post. It should not output as many ‘F M’ lines. Does the Heidenhain control complain when it reaches them?

I also spotted an error in function rapid() that was making rapids run at feed rate.

I haven’t got a chance to test whether or not my machine will not like the extra F M lines. My shop is about 10 miles away and I only get there in the evenings and only a couple of days a week. I’m going out tonight to test this new post.

I really appreciate your help with this.

In the meantime there are some unexpected results with the .post file.

Here is (some of) the output:

0 BEGIN PGM 0001 INCH

1 (Process: Drill LAYER1, 3/8 End Mill, 0.125 inch Deep)

2 TOOL DEF 13 L+0.000 R+0.000

3 TOOL CALL 13 Z S1000

43.4028235259904e+38,214.62995959808,3.4028235259904e+38,50.800000761856,3.9999999311872,3.9999999311872

5 L Z+0.1575 F394 M03

6198.43747151872,3.4028235259904e+38,103.18750154752,3.4028235259904e+38,3.9999999311872,3.9999999311872

7 X+7.8125 Y+4.0625 F M

8198.43747151872,198.43747151872,103.18750154752,103.18750154752,0.25400000380928,3.9999999311872

9 Z+0.0100 F M

10 Z-0.0200 F10 M

11198.43747151872,198.43747151872,103.18750154752,103.18750154752,-0.25400000380928,-0.50800000761856

12 Z-0.0100 F394 M

13 Z-0.0400 F10 M

Oops, sorry about that, I left some testing stuff in there. This one should work correctly

Hi Les, I’m wondering if you could help me with a modification to the Heidenhain conversational post processor. I’m trying to use the post on a TNC145CS which is similar to the TNC150 except some of the syntax changes slightly.

I’m trying to get the post to use some sort of “IF - THEN” type logic so that if the output is only an “X” or only a “Y” then these can appear on one line:

X100.000 R0 F M

or

Y100.000 R0 F M

But if “X” and “Y” appear on the same line then they must be processed with an “L” before the statement, like this:

L X100.000 Y100.000 R0 F M

Now to add more pain, if a “Z” movement appears on the same statement then this must use a fixed cycle - so it would be better if any “Z”'s appeared on a line of their own ie:

L X100.000 Y100.000 R0 F M

Z-1.000 F M

On our controller all movement statements need to have the full layout with a radius amount “R” or “R0” , Feed “F” and “M” function - even if they are left blank (with the exception of “R” which must be “0”)

The other raduis commands “CC” and “CP” work great except that I need to add the “R” command in with the “F” and “M”

Hope this makes some sence!

I’ve managed to get the post to output every “X” and / or “Y” to with the “L” infront but cant get the post to decide that if the output is only one or the other to leave the “L” out - also cant get it put any “Z” onto a fresh line.

Your help would be most appreciated

Thanks