anafranil online
IPB

Welcome Guest ( Log In | Register )

 
Reply to this topicStart new topic
> Drilling cycle issue with Tormach post
mayhugh1
post Jan 19 2007, 08:59 AM
Post #1


Advanced Member
***

Group: Members
Posts: 116
Joined: 12-December 07
Member No.: 49



Dave,
I've been asked to consolidate the fixes for the Tormach post processor that you've graciously provided on this forum. This includes the fixes that Yuri sent me for compatibility with NCTuner as well as the fixes for the helical path and multiple hole drilling issues that you provided others on this forum. I've done quite a bit of testing and these fixes do seem solid. However, I have uncovered another issue with the original post in my testing. If a toolpath for, say, a simple drilling operation is created for a workpiece whose top surface is above Z=0, then the G81 line that is created in the g-code does not contain the required Z depth. If the workpiece is transformed so that the top surface is at Z=0 then the line is properly generated. Do you see an easy edit to our post to correct this?

Terry

Terry
Go to the top of the page
 
+Quote Post
Sprut_UK
post Jan 19 2007, 05:28 PM
Post #2


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



Terry, I'm very busy this weekend with DIY work that HAS to be done (so I've been told ;o).
So that I'm modding the correct post, e-mail me the one that you are using now and I'll take a look when I have a bit of time. It may be a simple fix, or it could be quite involved, it all depends on how the drilling routines have been handled in this post......

Dave
Go to the top of the page
 
+Quote Post
Sprut_UK
post Jan 21 2007, 05:02 AM
Post #3


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



Hi Terry, I've just had a quick look at the postprocessor and I cannot spot any obvious problems at this stage.
Can you check to make sure that in the project you are using to test the drilling you have the 'Safe plane' higher than the 'Safe level / Distance' height as if it is lower this will give incorrect values.

If this is ok, can you please post up an example of what is going wrong.

Dave
Go to the top of the page
 
+Quote Post
mayhugh1
post Jan 21 2007, 07:59 AM
Post #4


Advanced Member
***

Group: Members
Posts: 116
Joined: 12-December 07
Member No.: 49



Dave,
I've emailed a project which isolates the problem. I believe the safe plane is properly located above the safe distance/level.

Terry

Terry
Go to the top of the page
 
+Quote Post
Sprut_UK
post Jan 21 2007, 09:55 AM
Post #5


Advanced Member
***

Group: Administrators
Posts: 1,091
Joined: 12-December 07
From: United Kingdom
Member No.: 4



Terry, it was your description of the fault which was confusing. The problem only actually occurs when the 'zmin' for a hole is set to 0, for all other instances it works fine.

The fault is caused because the initial value of the register that outputs the Z depth of a hole (zcycle) is 0, and because the value of the register does not change when the cycle is read, the register does not respond.
To solve this problem we need to give the register an initial value which is not 0, and in fact we need to give it a value that it is never likely to get passed by SprutCAM.
All I did to achieve this was to add this line to the PartNo program:
Zcycle = MaxReal; Zcycle@ = ZCycle
This gives the zcycle variable an initial value of 99999.999.

Dave
Go to the top of the page
 
+Quote Post
mayhugh1
post Jan 21 2007, 04:16 PM
Post #6


Advanced Member
***

Group: Members
Posts: 116
Joined: 12-December 07
Member No.: 49



Dave,
Thanks much. That change to the post seems to have fixed it!!

best regards
Terry

Terry
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



Lo-Fi Version Time is now: 16th July 2019 - 12:50 PM