Tool Management – Useful System Variables

$TC_MPP6[magno, locno]

Magazine Place Parameter 6: I like to think of this as the magazine mapping. It gives the internal tool identifier or tool number (a number between 0 and 32000, inclusive) of the tool occupying this location (locno) in this magazine (magno). Zero (0) means no tool in that location. To find out which tool is in the spindle, you would use $TC_MPP6[9998,1] – incredibly handy!

$TC_TP2[toolNumber]

Tool parameter 2: Tool ID (a string) – this is what you use to call a tool, as in T=”CUTTER”, or T90. Note, in the latter case, $TC_TP2[x]=90, but x is not necessarily equal to 90, and is more likely to be some completely different number. It is important to remember that when reading the Siemens documentation, any parameter that uses the tool number to address it will use the internal identifier, not the tool ID.

$TC_DP3[toolNumber, edgeNumber]

Cutting Edge Parameter 3: Length 3 which is generally applied in the Z direction for milling applications (G17) in both 3 and 5 axis milling. In standard 5 axis milling with the system in G17, Length 3 will be applied along the tool vector in TRAORI.

$TC_DP6[toolNumber, edgeNumber]

Cutting Edge Parameter 3: Tool radius (by default – can be changed to diameter via machine data). Very important when using cutter radius compensation (e.g. G41, G42, CUT3DC).

Drive-CLiQ Topology General Tips

Drive Group and Drive System

In Sinamics, each individual control unit has it’s own drive group. Multiple drive groups can be combined into a drive system which¬†might be controlled by a higher level motion controller to co-ordinate movements but each control unit will only know about the components located in its drive group.

Standard Topology of a Drive Group

In the standard configuration, you would connect X100 of your Control unit to X200 of your first drive. Then you would daisy chain from X201 of that drive to X200 of the next drive. Motor encoders (be they attached via SMC, SME or just drive-CLiQ) would be attached to X202 (or X203 for the second drive on a motor module). The infeed (if it has drive-CLiQ) can be inserted in the daisy chain or connected separately to the CU (i.e. through X101).

You are not required to place all drives in the group on the one daisy chain. However, any daisy chain that exists must follow the X201 -> X200 pattern.

The standard topology doesn’t handle direct encoders. These can be attached to any free drive-CLiQ port in the group, but must be configured correctly using Starter.

Use of Hubs

Drive-CLiQ hubs can be used to minimise cabling and also to provide additional Drive-CLiQ ports for the connection of additional encoders and Drive-CLiQ devices. The device numbering convention works a little bit differently on hubs than you might expect so it is important to note the port number your device is connected to and cross-check this with your project.

Be sure to remember that you can only use hubs to connect devices which belong to the same drive group. Example: you have three drive-CLiQ motors: Motor 1, Motor 2 and Motor 3. Motor 1 and Motor 2 are in Drive Group 1 and Motor 3 is controlled by another CU in Drive Group 2. All three motors are located in the same spot on the machine and you would like to reduce the cabling back to the drive cabinet. If you put a Drive-CLiQ hub in, you could only connect Motor 1 and Motor 2 to it and it would belong to Drive Group 1. Motor 3 would still have to be cabled back to the cabinet. If the cabling is long enough that saving one run is worth the cost of the hub this might be worth it. However, it makes more sense to try to re-arrange your drive groupings so that Motor 3 is also in Drive Group 1 and can be connected to the Hub.

Device Numbering

The Drive-CLiQ topology is traversed as a depth first tree, with the control unit as the root. In the standard topology (ignoring infeeds), the CU would be numbered 1; the first drive 2; second drive 3 … (n-1)th drive would be numbered n and its encoder would be device n+1. As encoders are the last node on any branch, the traversal would return to the (n-2)th drive and its encoder would be device n+2 and so on.

Why Doesn’t My G-Code Program Work? Have you tried STOPRE?

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.

NEWCONF

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.

STOPRE

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.