Hi there,
I’m coming from a 3D printing background and developed some modifications like crossflow fan cooling, lightweight NEMA8 extruder and a magnetic tool changer (youtube search for: Ultimaker fast tool change). Especially the latter one is currently being adapted to several Ultimaker varieties (low-karma workaround: ultimaker.com en community view 10657-a-different-multi-extrusion-approach-um-tool-printhead-changer).
However, I’ll build a machine especially designed for my tool changer concept in the near future, based on a corexy with a magazine of three toolheads and smoothieware. So, is there any information about the development status of a tool changer module? It has been mentioned in the Smoothie Contest.
This means the machine must be aware of where the tools are ( that can be set in the configuration file ), and has a procedure of movement and actions to change to each tool.
Thanks
Markus
Imported from wikidot
Hey !
I’ve seen your work and I absolutely love it !
To answer your question about the tool changer module : it is a winning contest entry in the Smoothie contest, but I haven’t gotten around to processing all of the contest entries yet ( soon, soon … ), so I don’t think any work has started on this.
If you know C++, there is most probably a trivial modification ( a few added lines ) you can do to the Switch module, which would allow you to use it as a toolchanger module, tell me if that’s something you’d feel like doing.
Cheers !
Thanks!
I have no real CNC background so I started thinking about the tool changer mechanism from a 3D printing point of view.
My conclusions for a proper tool changing procedure so far:
Trivial part:
if (newTool == currentTool) -> do nothing
if (currentTool != empty) -> place currentTool into magazine
pick up newTool from magazine
Pick and place routines:
- move to a „neutral area“
- if (place) -> switch to „neutral positioning“ mode
- perform a magazine-slot-specific movement pattern to pick or place the tool
- move back to neutral area
- if (pick) ->apply toolhead offsets
Picking and placing has to be done in a neutral positioning mode without any offsets to take care that the tool arm (tool holder) can be properly positioned within the magazine.
Switching between neutral positioning mode and toolhead-specific positioning mode (with x/y/z offsets for the tooltip) must happen in a neutral zone between the magazine and the printing area. E.g. usual cartesian setups have to adjust z height there to prevent a longer tool from entering the printing area from below and damaging the workpiece.
The magazine-slot-specific pattern should be attached to the respective toolhead/extruder configuration.
EDIT:
So, given the gcode sequence
[ gcode for toolhead T1 ]
T2 // or should it read M06 T2 ?
[ gcode for toolhead T2 ]
the T2 should basically translate to:
G1 Xneutral Yneutral Zneutral
[ TN ] // neutral positioning mode
[ gcode to place T1 in corresponding slot ]
G1 Xneutral Yneutral Zneutral
[ gcode to pick T2 from corresponding slot ]
G1 Xneutral Yneutral Zneutral
apply toolhead offsets
As far as I understand smoothieware so far, this could be triggered by the on_gcode_received event. However I’m not clear about how to insert an arbitrary gcode sequence for picking an placing at this stage.
Actually, I used to work as a OO-software developer in my earlier life. But hey, that’s ages ago. I’ll try to figure out if I can remember anything.
Hey !
Actually, we already support a good part of this, see : https://github.com/Smoothieware/Smoothieware/blob/edge/src/modules/tools/toolmanager/ToolManager.cpp#L50
The only thing that is really missing, is the “movement” part of it. I think it should be easy to add.
Cheers.
I already had a look at this module. One might think about placing the movement part within the tool->enable/disable methods. However, with an automated tool changer smoothieware has to differentiate between two uses of the T command I think: setting something related to T? vs. actually calling for a tool change to T?.
If I understand correctly “T” is modal right now. Therefore for e.g. pre-setting the temperature of the extruder soon to be used (T2) while printing with T1 you’d need a gcode like
… T2 M104 S220 T1 …
because you can’t use T2 as a parameter for M104.
In cases like this you don’t want an automated tool change to happen at all.
So perhaps “M06 T?” is the cleaner way to call for a tool change ?
So, to CNC users, T1 definitely means “move to actually change the tool to tool1”. We can’t really break that.
Most CAM packages I’ve seen generate T1, not M6 T1.
Which is why I’m so upset at the dumb way marlin and others have implemented the temperature settings thing. They essentially broke G-code … 
In short : they shouldn’t be using T as the parameter here. T is like M and G, it’s never to be used as a parameter.
So we have to find a way out of this, that doesn’t break things for CNC users.
My proposed solution is ugly, but would work :
M872 = T commands do not produce movement from now on
M873 = T commands do produce movement from now on
With a default to producing movement ( so CNC users are happy )
Meaning that a slicing program would have to do :
M872
T2
M104 S220
T1
M104 S200
M873
T1
This is ugly, but it’s the guys who completely ignored how gcode works’ fault.