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 :)
Re: code translations available
G-code is universal ... ha, ha
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 :)
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.
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 :)
Re: code translations available
Quote:
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 )
Quote:
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 :)
Quote:
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 :)
