Does anyone happen to have a post processor for a Deckel mill with Dialog controller?
/Torleif.
Does anyone happen to have a post processor for a Deckel mill with Dialog controller?
/Torleif.
Can you supply a sample of code? I can probably match it to one of the existing posts.
Thanks Les.
The mill is completely new to me, so I’ll have to see what I can find. And I’ll do some tests when time permits.
As I understand it, the file needs a certain header and footer to be accepted by the controller. I had hoped that somebody had done this already, so that I would get the file correct from the beginning.
I’ll be back.
Does anyone happen to have a post processor for a Deckel mill with Dialog controller?
/Torleif.
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8537#8537
-------------------- m2f --------------------
Can you supply a sample of code? I can probably match it to one of the existing posts.
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8538#8538
-------------------- m2f --------------------
Thanks Les.
The mill is completely new to me, so I’ll have to see what I can find. And I’ll do some tests when time permits.
As I understand it, the file needs a certain header and footer to be accepted by the controller. I had hoped that somebody had done this already, so that I would get the file correct from the beginning.
I’ll be back.
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8539#8539
-------------------- m2f --------------------
I’m now working on a post processor for the Dialog 4. I have a few questions:
/Torleif.
This can get a little complicated. The easy way is to get rid of all line numbers. To do that, simply delete function newline(). If you want line numbers, have a look at the Gerber Sabre post to get an idea how to do it.
I’m afraid you can’t insert the tool table. The tool details are only available when they are selected.
Yes, add a + to the format string. For example “+0.###”
Thanks Les.
I have split newline() in newline() and linenumber(). Works fine.
I’ll either let sheetcam do the tool length compensation then, or append the code to a fixed tool table.
Hmm. Why is this:
For simplicity, I have generated the below using the unmodified non modal post. I have based my Deckel Dialog post on the non modal, so it does the same. As can bee seen, the first move after a tool change is modal. The Deckel will not accept modal G0’s so I’m stuck.
Am I missing something?
N0000 G21
N0010 M6 T5
N0020 M03
N0030 G00 Z4.0000
N0040 G00 X48.5000 Y25.0000 Z4.0000
N0050 G00 X48.5000 Y25.0000 Z0.5000
You have hit an interesting quirk in the posts. The very first move is always Z only. In most cases this is correct as the post has no way of knowing where the machine is so it needs to get Z to a safe height first. This is done by making the first endx and endy variables unfeasibly large. The number functions know they should ignore these values.
In your case it causes a problem. Try adding this line to the beginning of function rapid():
if (endx > 100000) then return end
I think that is correct. If it doesn’t work, try using -100000 instead.
This will completely ignore the first Z safety move.
Now I have the basic functions up and running. I haven’t done any tests with tapping though.
Since the Deckel only has 256k program memory, I would like to reduce the size of the generated code. Is it possible to have Sheetcam generate subroutines/subroutine call’s, so that it won’t repeat all X and Y movements for every depth?
Since thread milling has been pending for a while, would it be possible to simply add a parameter entry entry like the drilling window and then call a post processor function with those parameters? I assume that programming the thread milling in the post processor will be fairly straight forward.
/Torleif.
This can get a little complicated. The easy way is to get rid of all line numbers. To do that, simply delete function newline(). If you want line numbers, have a look at the Gerber Sabre post to get an idea how to do it.
I’m afraid you can’t insert the tool table. The tool details are only available when they are selected.
Yes, add a + to the format string. For example “+0.###”
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8559#8559
-------------------- m2f --------------------
Thanks Les.
I have split newline() in newline() and linenumber(). Works fine.
I’ll either let sheetcam do the tool length compensation then, or append the code to a fixed tool table.
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8560#8560
-------------------- m2f --------------------
Hmm. Why is this:
For simplicity, I have generated the below using the unmodified non modal post. I have based my Deckel Dialog post on the non modal, so it does the same. As can bee seen, the first move after a tool change is modal. The Deckel will not accept modal G0’s so I’m stuck.
Am I missing something?
N0000 G21
N0010 M6 T5
N0020 M03
N0030 G00 Z4.0000
N0040 G00 X48.5000 Y25.0000 Z4.0000
N0050 G00 X48.5000 Y25.0000 Z0.5000
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8561#8561
-------------------- m2f --------------------
You have hit an interesting quirk in the posts. The very first move is always Z only. In most cases this is correct as the post has no way of knowing where the machine is so it needs to get Z to a safe height first. This is done by making the first endx and endy variables unfeasibly large. The number functions know they should ignore these values.
In your case it causes a problem. Try adding this line to the beginning of function rapid():
if (endx > 100000) then return end
I think that is correct. If it doesn’t work, try using -100000 instead.
This will completely ignore the first Z safety move.
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8562#8562
-------------------- m2f --------------------
Now I have the basic functions up and running. I haven’t done any tests with tapping though.
Since the Deckel only has 256k program memory, I would like to reduce the size of the generated code. Is it possible to have Sheetcam generate subroutines/subroutine call’s, so that it won’t repeat all X and Y movements for every depth?
Since thread milling has been pending for a while, would it be possible to simply add a parameter entry entry like the drilling window and then call a post processor function with those parameters? I assume that programming the thread milling in the post processor will be fairly straight forward.
/Torleif.
-------------------- m2f --------------------
Reply to this post simply by hitting reply in your email client or you can read this topic online here:
http://www.forum.sheetcam.com/viewtopic.php?p=8564#8564
-------------------- m2f --------------------