584,866 active members*
4,881 visitors online*
Register for free
Login
IndustryArena Forum > MetalWorking Machines > Okuma > code translations available
Results 1 to 7 of 7
  1. #1
    Join Date
    Jun 2015
    Posts
    4131

    code translations available

    hello there are these common scenarions :
    ... few persons try and succeede in editing a cam post, and cnc parameters, at least those that target cycles, but such a road can take years
    ... some shops will stick to their actual cam, and cnc brand, in order to avoid going again through previous issues, but this nothing, but a limitation
    ... small shops may have a hard time achieving compatibility, many really strugling, under costs pressure

    how to start quick, from any whatever random cam, regardless of postprocessor condition ? an old solution, that rarely comes up front, is code translate, easy as cake; if you need something, i will gladly help you / kindly

  2. #2
    Join Date
    Mar 2009
    Posts
    1982

    Re: code translations available

    G-code is universal ... ha, ha

  3. #3
    Join Date
    Jun 2015
    Posts
    4131

    Re: code translations available

    yes, to some extent, but not full if it would be 100% universal, then it would mean that is possible to create a generic code, compatible across all different cnc brands, and, at this moment, this is not hapening, even if there is a tendency towards it

    problems do not come from the fact that some codes are universal, but from those that aren't; let's call them particular cases such cases will decrease in the future, and the ones that will still not be universal, i guess that will have a complexity that i can not comprehend, nor imagine at this moment ...

    back to those universal g-codes, there are still many low memory machines, that still need cycles to shorten their file size just saying

  4. #4
    Join Date
    Mar 2009
    Posts
    1982

    Re: code translations available

    Dear friend deadlykitten don't You see it is opposite?
    G-code of different brands was the same long time ago when first systems with automatic tool change were introduced. That's early 1980's. Developers did many modifications of MAP and LAP, then the differences begun. Macroses and pallet changers introduced after - more variants follows. Some new tooling ( active lathe tools ) introduced - plus variants of G-Code again. Some European companies don't care about following G-Code standards and introduced their own encapsulated cycles ( it is a branch of LAP and MAP actually ) using wierd definitions.
    In my understanding there will be even more variants of G-Code in the future, no one cares about getting closer.

  5. #5
    Join Date
    Jun 2015
    Posts
    4131

    Re: code translations available

    hy please, can you develop a bit those MAP/LAP ?

    i agree that g code list increased as configurations & options expanded over time, and also there are different codes for different machines, that, in the end. perform similar functions; this shows obviously, a tendency for more&more variations

    but, just like you noticed, i was talking about an opposite situation, and i will explain a bit :
    ... let's consider that :
    ...... 'a' is the number of common codes ( same function on different machines has same g-code )
    ...... 'b' is the number of the not common codes ( same function on different machines has different g-code )
    ...... 'c' is the number of special codes ( rare functions that are available only on some machines )
    ... when the 1st few cnc's arrived : 'a' was little, 'b' even smaller or 0, and 'c' perhaps it was 0 ( a>b>c )
    ... today, 'a' has increased a bit, 'b' has sky rocket, and 'c' has increased but not as much as b (a<c<b)
    ... in the future, i really think that a b c will all increase , but overall, a will be the smallest, c will grow as more specials will appear, while b will go high ( just like you said, some companies don't care about g-code standards )

    so far, i think is all ok, but what will happen, is that until a point more and more small cnc brands will pop-up, each own with his own approach; as they will compete, more and more similar, common modules will appear, just like how today, all cars are pretty identical ( kind of recycled design ); i think that, even if there will be different brands, in the end they will have pretty similar products ( just like how also classical lathes manufactured today are pretty similar, or maybe made in the same factory, but with different labels ); in the worst case, is possible that there will be a single cnc manufacturer having monopol, while arround it will be many other small brands strugling to survive ( this means that, even if there are many a-b-c variations, statistically speacking, only one set will matter, thus the one from the company that has the largest maket share ); this moment is delayed for cnc's, as they are pretty complex, but, for many common and simple stuff from today, this is allready happening

    another thing, is that somewhen, i think that substractive technology will simply vanish, there is too much waste; additive is still in research, then something better should come up

    okey, so this is what i was thinking; hope it makes sense / kindly

  6. #6
    Join Date
    Dec 2008
    Posts
    3110
    Quote Originally Posted by deadlykitten View Post
    hello there are these common scenarions :
    ... few persons try and succeede in editing a cam post, and cnc parameters, at least those that target cycles, but such a road can take years
    ... some shops will stick to their actual cam, and cnc brand, in order to avoid going again through previous issues, but this nothing, but a limitation
    ... small shops may have a hard time achieving compatibility, many really strugling, under costs pressure

    how to start quick, from any whatever random cam, regardless of postprocessor condition ? an old solution, that rarely comes up front, is code translate, easy as cake; if you need something, i will gladly help you / kindly
    This seems an impossible task.
    I'll throw up a scenario that your convertor would fail
    ASCII g-code written for a 4 axis machine centre with Okuma control needs to be converted to DMG 5axis with Heidenhain g-code
    One uses IJK delta start to arc centre... the other uses a two line format with absolute arc centres. This would require the use of a CADCAM system that created the original code.

    I'd hate to think of the problems if some of the canned drill cycles that have a different g-code spec between different models
    How would it convert the use of tilted planes, or TCPC, or more advanced toolpaths ?

  7. #7
    Join Date
    Jun 2015
    Posts
    4131

    Re: code translations available

    One uses IJK delta start to arc centre... the other uses a two line format with absolute arc centres. This would require the use of a CADCAM system that created the original code.
    hy super a simple translator that eats 10 lines and spits also 10 lines, can not handle that; this requires an approch that can translate paragraphs, not only lines

    a cad cam will recreate the original code, or however you name it, in the end is reverse g-code enginering, and it's not a big deal for arches, considering that all information is allready inside the code that will be translated ( also, "reverse enginering" is a bit too much for this task, there should be a simpler term, but no clue at this moment )

    I'd hate to think of the problems if some of the canned drill cycles that have a different g-code spec between different models
    canned cycles are there to allow less file size for a cnc that has low memory, while an actual machine has more than enough, and some codes no longer use cycles, but linear

    if a few years ago all the logic was inside the cnc, trying to manage his low memory, today there is enough space to do whatever you like, and create a cycle, or more precise, a custom strategy ( easy - macro, complex - software ), how you like

    How would it convert the use of tilted planes, or TCPC, or more advanced toolpaths ?
    is not about how complex a toolpath is, but to what point one can handle it ? it's easy to handle simple operations, while complex ones requires time&trials to find the working combo; for example, if a complex 3d toolpath, is executed on a 5 axis machine, considering that the code is allready there, all you need to translate is conditions and other stuff, that is not directly related to the coordinates, but to the machine

    i can't generate full complexity from nothing, but is possible to change something that allready exists / kindly

Similar Threads

  1. Replies: 51
    Last Post: 09-16-2020, 01:28 AM
  2. Need help with translations
    By LTS in forum German
    Replies: 1
    Last Post: 10-01-2016, 06:42 PM
  3. mach3 crashing with run of code/drilling holes through table with other code
    By normalform in forum Mach Software (ArtSoft software)
    Replies: 1
    Last Post: 07-28-2014, 03:38 AM
  4. corel.hpgl > sheetcam.tap > pronterface.g-code > slic3r.g.code> ramps 1.4 > H-BOT
    By thesignworks in forum Uncategorised CAM Discussion
    Replies: 0
    Last Post: 05-25-2014, 02:11 PM
  5. LaserCut53.exe english translations
    By charliex in forum LaserCut
    Replies: 2
    Last Post: 06-15-2012, 09:35 PM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •