Issue with G-Code for tool change ("next_extruder")  

RE: Issue with G-Code for tool change ("next_extruder")

I think we can close this thread. This has not been implemented for Prusa devices and Prusa Slicer, respectively. Too bad...

RE: Issue with G-Code for tool change ("next_extruder")

Is it this ??

M104 S[temperature_[next_extruder]]  

...

note: this only works in tool change gcode

temperature

M109 S[temperature_0] M109 S[temperature_[previous_extruder]]

RE: Issue with G-Code for tool change ("next_extruder")

My apologies, I missed the underscore. But the result is the same I am afraid. I add a

M104 S[temperature_[next_extruder]]  

to the "tool change" section and Prusa Slicer complains. If I add this, however:

M104 S[temperature_0] 

Prusa Slicer has no issues with it...

RE: Issue with G-Code for tool change ("next_extruder")

Posted by: @wieman01

My apologies, I missed the underscore. But the result is the same I am afraid. I add a

M104 S[temperature_[next_extruder]]  

to the "tool change" section and Prusa Slicer complains. If I add this, however:

M104 S[temperature_0] 

Prusa Slicer has no issues with it...

RE: Issue with G-Code for tool change ("next_extruder")

Posted by: @wieman01

My apologies, I missed the underscore. But the result is the same I am afraid. I add a

M104 S[temperature_[next_extruder]]  

to the "tool change" section and Prusa Slicer complains. If I add this, however:

M104 S[temperature_0] 

Prusa Slicer has no issues with it...

I ran into this issue and seem to have stumbled upon the solution after several hours of throwing everything at the wall to see what sticks.  The g-code parser doesn't seem to like nested brackets, replace the outer brackets with braces:

M104 S{temperature[next_extruder]}

RE: Issue with G-Code for tool change ("next_extruder")

I suspect this is part of the inconsistant logic around multiple extruders, sometimes you need to reference as an array index eg 104 S{first_layer_temperature[0]*0.9}, sometimes it assumes index 0 and some times curly not square brackets.

BTW not 100% sure about my example, there may be some syntax that works without the array usage but have tried a bunch of things this was suggested and is works and it makes sense, as it depend on which material forms the first layer.

RE: Issue with G-Code for tool change ("next_extruder")

Isn't there some sense of static versus dynamic syntax here? That when an evaluation needs to happen curly braces are needed?

[offset+1] doesn't work but {offset+1} does?

https://manual.slic3r.org/advanced/conditional-gcode

RE: Issue with G-Code for tool change ("next_extruder")

@tim-m30 "Isn't there some sense of static versus dynamic syntax here?" Damned if I know but I strongly suspect that you do. Could you give an example that demonstrates the difference between the two?

RE: Issue with G-Code for tool change ("next_extruder")

{if layer_z < max_print_height}G1 Z{z_offset+min(layer_z+30, max_print_height)}{endif} ; Move print head up

This statement supports both my assertion, which is an educated guess, and what michael said. 

Said another way, if you need the interpreter to evaluate something from multiple values, curly braces are required. 

Here's a slightly different example of the same thing:

total_layer_count

M117 printing layer {layer_num+1}/[total_layer_count]

.. [total_layer_count] doesn't need any evaluation: it simply points to a number in memory. {layer_num+1} needs to be evaluated - the sum of a number in memory and a number in the gcode. Think of it as {[layer_num]+1} ...

https://github.com/prusa3d/PrusaSlicer/wiki/Slic3r-placeholders-(a-copy-of-the-mauk.cc-page)

But then Prusa comes along has has a better idea... lol.

https://github.com/prusa3d/PrusaSlicer/wiki/Slic3r-Prusa-Edition-Macro-Language

I think a hidden surprise is this text: 

Multidimensional vectors can currently be only accessed as a simple vector variables resulting in a string value (e.g. if the extruder_offset placeholder holds a value of 0x0,nx0 it can only be accessed as extruder_variable[1] resulting in [n,0] string value -- can be posted in g-code but can not be used in arithmetic operations).

There are things that evaluate to strings and things that evaluate to numerics. 

RE: Issue with G-Code for tool change ("next_extruder")

ps: in those links it explains why the OP's expression fails. 

M104 S[temperature[next_extruder]]

should be written

M104 S[temperature_[next_extruder]]

What isn't well explained and must be inferred by example is that underscore as a vector indicator.  Normal languages use var[x] - yet Prusa or other gcode gods chose var_x - and the added convolution of requiring brackets for var_[x] ...

ps: then again - can't test any of this without an MMU profile ... 

But if 

M104 S[temperature_[next_extruder]]

doesn't work and 

M104 S[temperature_0]

does work, try

M104 S{temperature_[next_extruder]}