ok, so I modified it a little bit and it seems to work - hope I made no thinking error toolnumber_now : 0 toolnumber_next : 0 p_get__s_next_20002(!is_valid_arg) lookahead_index = 1 next_tool_change_gcode = opinfo(92, lookahead_index) next_forcetool_change_code = opinfo(91, lookahead_index) toolnumber_now = opinfo(47, 0) toolnumber_next = opinfo(47, lookahead_index) while next_tool_change_gcode <> invalid, [ if next_tool_change_gcode = 1002, [ if toolnumber_now = toolnumber_next & next_forcetool_change_code=1 , lookahead_index = lookahead_index + 1 next_tool_change_gcode = opinfo(92, lookahead_index) next_forcetool_change_code = opinfo(91, lookahead_index) else, next_tool_change_gcode = invalid ] else, [ lookahead_index = lookahead_index + 1 next_tool_change_gcode = opinfo(92, lookahead_index) next_forcetool_change_code = opinfo(91, lookahead_index) ] ] s_next_20002 = opinfo(20002, lookahead_index) is_valid_arg = (s_next_20002 <> s_invalid)

@Zaffin_D Well done This is really a much cleaner solution. But in my case it doesn't work properly because some operations that follow each other use the same tool with a "force toolchange" flag. We use this for example for remeasuring the tool during roughing operations. However, this messes up the algorithm. If the same tool is used twice in succession, the tool (which is the same in both operations) which is marked with the next "force toolchange"-flag is preselected in the first operation. This is not the desired behavior (in my case). As you only loop over the g-code-change, I don´t know how to enhance your code to integrate a check for force toolchange flag and look if the next tool is the actual tool. If this is the case then operation must be skipped. I really appreciate your smart code, but I don't know how to improve it quickly.

Thanks @Zaffin_D I tried what you suggested but unfortunately I don't know how to get the next op_id$, what I need to query the 20002 parameter. The problem of op_id$ is that this is not an ordered number. Would be happy if you can give me more hints

@Zaffin_D I searched in the depths of this forum and found a post by you I used your code snippet and changed it a bit and it worked really well I don't know if this is bug free or causes performance issues, but I will implement it first and see how it works. op_identity : 0 tool_number : 0 tool_manufacturer : 0 op_ident : 0 stack_tool_number : 0 stack_tool_manufacturer : 0 stack_op_ident : 0 stack_size : 0 stack_result : 0 fstack 1 3 is_tool_in_stack : no$ stream_idx : 1 stream_op_id : 0 s_quotation_mark : "" output_tool_number : 0 output_tool_manufacturer : 0 output_op_ident : 0 fs2 4 1 0 1 0 fmt "" 4 output_tool_manufacturer p_goto_strt_tl #Make the tool start up at toolchange pfd_shft_inc psign_ang_out ##### Custom changes allowed below ##### s_next_tool = no2asc(34) + "T"+ no2str(next_tool$) + no2asc(34) next_tool_number = scan("T",s_next_tool) if stagetool = one, [ if s_last_used_tool <> s_next_tool, [ pwrite_tdef_info s_last_used_tool = s_next_tool ] ] pwrite_tdef_info stream_idx = 1 stream_op_id = streaminfo(1, stream_idx) while stream_op_id <> -99999, [ pget_tool_parameters(stream_op_id) padd_tool_to_stack stream_idx = stream_idx + 1 stream_op_id = streaminfo(1, stream_idx) ] stack_size = pop(1, stack_result, 0) while stack_size > 0, [ output_tool_number = pop(1, stack_size, 5) if output_tool_number = next_tool_number, [ !spaces$, spaces$ = 0 s_quotation_mark = no2asc(34) pbld, n$, " TOOL DEF ", s_quotation_mark, *output_tool_manufacturer, s_quotation_mark, e$ spaces$ = prv_spaces$ ] stack_size = stack_size - 1 ] padd_tool_to_stack is_tool_in_stack = no$ stack_size = pop(1, stack_result, 0) while stack_size > 0, [ stack_tool_number = pop(1, stack_size, 5) if stack_tool_number = tool_number, [ is_tool_in_stack = yes$ stack_size = -1 ] stack_size = stack_size - 1 ] if not(is_tool_in_stack), [ if tool_number <> -99999, tool_number = push(1, stack_result, 0) ] pget_tool_parameters(op_identity) tool_number = opinfo(47, op_identity, 1) sparameter$ = opinfo(20002, op_identity, 1) tool_manufacturer = rpar(sparameter$, 2)

Oh, I forgot to mention: the post must also run in version 2017

Thanks JParis - But idk what does this picture want to tell me I want to change my post. This seems to be a report.

Hi guys, I have a small problem that is giving me a headache. Maybe someone here can help me On a new machine with automatic tool changer, I need to pre-stage the next tool. Normally the next tool is called with the variable next_tool$. However, in my case, the tool number is stored under the tool manufacturer's code due to our internal rules. In a first step, I changed my post to get the output with the "normal next tool number": stagetool : 1 #0 = Do not pre-stage tools, 1 = Stage tools one : 1 #Define constant s_last_used_tool : "" #last used tool s_next_tool : "" #tool to be pre-staged in ATC s_tdef : "TOOL DEF" p_goto_strt_tl #Make the tool start up at toolchange pfd_shft_inc psign_ang_out ##### Custom changes allowed below ##### s_next_tool = no2asc(34) + no2str(next_tool$) + no2asc(34) if stagetool = one, [ if s_last_used_tool <> s_next_tool, [ pbld, n$, s_tdef, s_next_tool, e$ s_last_used_tool = s_next_tool ] ] If I just want the next tool number, that would work fine. But now: How can I get the tool manufactures code of the next tool ? I tried to use something like this: s_next_tool = opinfo(20002,1) However, this doesn´t work at all - because the returned value points to the next toolpath ( passed parmeter 1) and not to the next tool (change). If the next toolpath uses the same tool, the return value is "-99999".If the next toolpath uses a different tool, the return value is correct. I thought it could be solved with a while loop, but that get´s me to the problem, that I have to know how to determine the end of all posted toolpaths to prevent a endless recursion. Does anyone can give me a hint how I can solve this ? I've searched this forum up and down and found some posts, but everything I've tried doesn't end up with the desired output. It would be great if someone could give me some advice to get me back on track. Thanks, Erich