code structures ...

[deadlykitten]

I have no experiece with CAMs, so i just program as i can

i use parametric structures for simple operations as : rough turning, face milling, drilling, etc ...

however, during testing i compared a simple program, with another filled with formulas ... every formula / calculation means a small delay, thus program will perform slower

calculations are not complex, but easy ... what makes the machine to delay is the number of calculation

so, even if there are "math functions", each one will slow down the machine

is good to have a "read ahead" buffer, because things were worst without it, but even so, i did not expect such delays from the machine

that "read ahead buffer" can not handle "math functions" in "real time" : in other words, the buffer is great for machining, not for formulas

a simple program runs always almost the same, while another filled with formulas may run with ± some seconds

i don't know yet how the machine behaves on G41/G42, or cycles, versus simple code .... kindly !

Similar Threads:

• Need help with g code for fire control pocket on AR15 lower reciver, have G code.
• BAE Systems offers a great opportunity for a Design Engineer (Structures) in UK
• Newbie- corel.hpgl > sheetcam.tap > pronterface.g-code > slic3r.g.code> ramps 1.4 > H-BOT
• Reinforced concrete damping for steel machine structures.
• Newbie- Takeout Unused G Code commands in Mastercams Generated G Code

[deadlykitten]

question : G41 & cycles, or just code ?

some structures are built in, so i guess they perform faster .... i did not test this yet

[deadlykitten]

If in 2016 we still have to buffer towards a machine this is pure waste on time.

hy, this is not about buffering data from outside the machine, but about internal buffer ...

What ever the G feature is, controllers are now supposed to read at speed they can access the data they can replicate within the axis

this is general ... is the way the machine works

[deadlykitten]

hy teahole

Not entirely certain there was a question in there

question : G41 & cycles, or just code ?

If you don't believe me ...

how could i ? )

... go to a Fanuc machine. Run a program without an M30 or M2 at the end of the program.Then go to an Okuma and try to load a program that doesn't have an M2/30. Or where you don't turn off G41/2 after you turn it on. The machine alarms before you can even load the program. "No end of code" alarm I believe.

this behaviour on Okuma is a simple 'program check', that goes superficial ; "ahead buffer reading" goes deeper : for example, you may "program select" without any errors, but, during runing, something may show up

The machine is absolutely capable, most are really, the question becomes am I ready for the machine to read the code and do the math yet.

if code is only coordinates, than machine goes fast

if code is filled with formulas, machine goes slower

for example, don't use G00 X = radius * sinus [ 30 * V1 ], but G00 X=56.895

is better to do simple calculations outside the machine, and after, send the results to the cnc

i think this delay is because the cnc does not behave like a computer, but is waiting for confirmation signals from the electronics

For example, I often do things based on other ... on what VATOL is 20 lines from now because there may be a tool change in there somewhere.

so far i have encountered a single case when "ahead buffer reading" made things harder for me : during driling, sometimes there were chips on the tool, but not always ... there was code with "/", so, if operator would push the "/" button, the drill/spindle would stop and raise 150...200mm, so easier to clean the tool

because of the "buffer", pushing "/" would not act instantaneously, and this was not good

i delayed the buffer using G00 Z = VWKBZ i know this variable from you, so thx again

an alternative would have been to use peeking, so to cut just a bit each time > i did not like it, because machine would move more, thus unnecessary movements would appear ...

[deadlykitten]

I would argue that in 2016 if we are still generalizing something as a "pure waste of time", we sure ...

30% of 2 minutes is nice especially if without messing with the cutting specs

thinking economical is tricky, and even if something can perform better, this does not mean that it can not be left as it is ...

there is a fashion to go improving at a low-level which has almost no impact on general mechanism

generally is "time vs money" : faster means more expensive

is important to determine quantificable parameters, and measure them corectly

i asume that i have done something if at least 5% is gain ; some people consider 2.5% as a "change"

this 2.5...5% tagets a phenomen / is important to know "how important is the phenomenon", because otherwise, it may be a "waste of time"

[deadlykitten]

hello again tea hole

That was the most drastic example i've got, it was not the rule of course, but it sure felt good

yeah, i know that it was you who wrote that program, and also you corrected it

I have never seen an instance where the math in any way affected the speed

[ mill ] i have a code that does cilinder roughing, as shown into attached image

v1 ... only coordinates > 1:26
v2 ... parametric structure, thus formulas everywhere > 1:30 ( "math overload" = 4 seconds )
v3 ... v2 + extracting coordinates at every position > 2:00

[ lathe ] i adapt same program :

v1 ... 1.22
v2 ... 1.23 ( "math overload" = 1 second )
v3 ... 1.51 ( newer lathe ) / 1.57 ( older lathe )

conclusions :
... lathes are faster, when it comes to math, at least mine
... simple coordinates are recomended, especially on mill
... "math overload" depends on formulas complexity :
...... simple formulas will trigger a smaller overload
...... "parametric structures" will trigger a greater overload

... coments and NOEX trigger delays as well : i heard that a lathe had a small delay when indexing, and it was because i had some comments before an operation; since then, i write all comments in another file, or i write them after M02 without brackets

... coordinates extraction comes with greater delay, because of each "file open - file write - file close" , but this is less important, because such techniques are used to generate the main code, and should not be left active

[deadlykitten]

... coordinates extraction comes with greater delay, because of each "file open - file write - file close" , but this is less important, because such techniques are used to generate the main code, and should not be left active

coordinates/data extraction delay duration may be reduced by using a single CLOSE , at program's end, and not for each position; this is for my program :
.... CLOSE @ each position : total time = base duration + delay
.... CLOSE @ program end : total time = base duration + delay * 0.33

on the other side, a single CLOSE does not allow multiple file writing

[deadlykitten]

Hello, these questions are a bit weird in this post is the 1st one :

simple code is performed faster

some things will slow it down, like conditional code ( if, jumps ) and a lot of arithmetics ( especially in parametric structures, for example like this structure for splines that is mrore versatile than a cycle : http://www.cnczone.com/forums/okuma/309768-cnc.html )

what i don't have tested yet is " simple code " vs " default cycles "

well, that being said, i have procedures that are filled with conditional code ( if, jumps ), and they make things easier, so is ok to have them, and i don't like that the cnc loses time when is computing them, because it does a lot of background checkings; so : is it possible to reduce the ammount of background checkings performed by the cnc, at least ( only for ) some codes ?

M/G... ( disable / lower background checkings level )
some code
M/G... ( default background checkings level )

how to implement those M/G codes ? kindly !

[deadlykitten]

now the 2nd one : let's consider a program that is in the MD1.

each time when the program is restarted at a specific position, the machine goes in background over it until it reaches that specific position.

if the program is long, than this procedure will take some time; and if the restart is repetead, than it will take some amount of time as before ...

is like the machine compiles that code each time, even if the code has not been modified

is there a posibility, or did someone think of eliminating this behaviour ? so to compute a code as new only one time, and after that to load it faster if nothing changed ? well, off course, as long as the program is <2mb, or it's size is under the buffer required for one time shot, so program size is small enough to be loaded entirely ...

code for a new program should be compiled once into an aplication that remains in the volatile memory; next time the cnc should not run the program, but that aplication

in my opinion, this is not impossible, but i think that the cnc developers don't take it into consideration, because it's result does not affect the speed for computing a program, since loading stuff each time in the virtual memory is pretty fast, and if the code is long, even it is simple, is not their problem. If read ahead buffer is there, than they consider this more than enough

if this would be done, than the gain will be seen on reduced ( almost instant ) duration when restarting, even in long programs ; during compiling, maybe it will buff a bit the read ahed buffer also, this will reduce / optimize data flows through those eletronics

[deadlykitten]

There are many reasons ... will suffer greatly as a result.

hy ghyman, yup, there are lot of variables, but i think those variables may be classified, and each class should be taken a propper approach.

is not impossible, but it requires some work that i don't think that Okuma guys find it relevant

it would be easier if the osp was an operating system based software, but is not; it is a bit on his own, and all comunications with the operating system are made to some whatever interfaces that is opened partially to a programer through the API; it's core is not on the hdd, there is just the build from Okuma which is a bit hard to get into by normal guys

if it was based on an operating system, than it's language would be common, and a lot of remote programmers could works on that, but since it is encapsulated, only "some" guys can do the work, so their resources are limited on this.

I do not understand that statement. Cutter comp is, and has been for decades, a simple code. What, exactly, is your concern with using it?

about comp, i don't know if is faster to :
... 1) use the part dimensions as the toolpath + G41/2 + radius declaration + P declaration , or
... 2) use a virtual toolpath, thus no G41/2, no radius declaration, no P

what i know is that the comp (1) comes with unnecesary movements, at toolpath "start" and at "end"; so far i managed to solve this easy for the "start" position, by using imaginary vectors, while for end is a bit different

so i guess / hope that (2) is faster than (1), so i won't mess my head with this unnecesary movements any more

Please do not give out advice like this. Once again, just because something is better for you, in this particular instance, does not mean you should post that it is better for everyone.

i will reload let's compare how a lathe igf generates code for a roughing operation, vs how a mill igf generates code for a helix

lathe igf will output the shape between some master codes, that will tell the cnc to do some background calculations for the toolpath; thus code is simple, while toolpath is complex, for each pass, being computed "inside"

mill igf will do some math, and will output the code for the toolpath, so there will be less background calculations

in this case, the mill igf does some calculations in advance, so to spare the control

so outside calculations, or if you wish, calculations done before generating the code should reduce "background" calculations done by the cnc when code is executed

One of my machines ... saves literally hours a day

this is parametric code; parametric code is another story

well, not another story, like there is no connection between them; when i said that "is better to do simple calculations outside the machine, and after, send the results to the cnc", i was not refering to parametric code

also, parametric code optimizations is an issue, because if you fill it with conditions and stuff, than it will work slow

parametric code is much close to programing than a simple cnc program, but yet, if you optimize a parametric code to shorten it, than the cnc will perform it slower, because is not build for conditional programing this is why in a previous post i asked if is it possible to reduce the ammount of background checkings performed by the cnc, at least ( only for ) some codes ?

[deadlykitten]

Cutting conditions are calculated based on the tool and the material

by the way, how do you compute feeds ?

what do you think about a constant specific for each material type ? it may boost that code of yours

[deadlykitten]

pls check attached image

feed for soft metal : f = 0.017*dia + 0.075, or 0.05 * dia ^ 0.7

1st one is easier to implement in a *.ssb

fine adjustment by corection factors : 80%f .. 120%f

multiplicators for plastics, for example : f x 1.5 ... 4

ps : rpm = V * 1000 / VPAI / diameter > V*320/dia or V*318.30988618/dia ( depends how tolerant you are )

well, i guess you know al these things; all the best

[deadlykitten]

hy all there is the posibility to reduce code's length by :
... removing comments + useless blanks/spaces
... concatenate lines

attached image shows an example

idea behind this thread is to reduce resources required to run a program : in this case a tiny bit of time gain + less file size

[deadlykitten]

Please do not give out advice like this. Once again, just because something is better for you, in this particular instance, does not mean you should post that it is better for everyone

hy ghyman yup, i know, it has been almost an year

i am afraid that it was not about a particular case : osp300 looses precious time when performing simple calculations; using NOEX will fix that

this behaviour should be present also on some elder control generations / kindly