Understanding STOPRE and NEWCONF
There are many reasons why a G-code program can fail. In this post I’ll just be looking at a couple of commands you may not have heard of which can save you from a lot of otherwise inexplicable bugs.
Relatively simple one here: you’ve changed machine data in a program and are confused as to why you’re not seeing any effect. It comes down to those two little letters beside the machine data.
First, “im” is immediately active, just set and forget. Second, “cf” is only active after a NEWCONF or by pressing the “Set MD to Active” softkey (or by pressing reset – if all else fails, press reset). Note: the “Set MD to Active” softkey does nothing while a program is running, you will have to reset the program in order for it to work. The “re” and “po” are channel reset and power on reset respectively and therefore are not particularly useful if you want to set data live within a program.
Take home message: if you set machine data within a program – first make sure it’s going to work but checking how it’s activated; second, use NEWCONF.
STOp PREprocessing. Here is where a lot of software writers get tripped up when writing programs to be executed on an NC. G-Code is sequential (whereas PLC code is cyclic) – that part’s easy enough; in a normal computer program on line is executed after the other – sequential, easy.
The difference between the NC and a computer is that some lines in a program take quite a bit more time to execute than to calculate (for example movement commands), so there’s quite a bit of extra time up the NC processor’s sleeve. In a lot of cases it is important to know what the next 20-50 movement commands are so that the NC can plan axis acceleration, deceleration and block smoothing. Combine these two together and you get the pre-processor – the NC will read in several lines of code ahead so that it can optimise what it has to do now. This is great for standard G-code and CAM output, but when you start writing parametric code which performs calculations on the fly, it can get messy.
What’s the problem? Well, the NC can have a movement command sitting in the pre-processed blocks which contains a calculated value (e.g. an R-Parameter). At some point later in the program this value gets re-calculated. Unfortunately, this has the effect of changing already pre-processed block so that by the time it is actually executed, it does something other than what was planned.
Solution – use STOPRE to perform a preprocessing stop before new values are calculated, this forces the buffer to be completely executed before processing any further lines. Be warned, though, excessive use of STOPRE (particularly in long FOR or WHILE loops) will blow out the execution time of your program.