Cooling options

[Konstantin]

I want an option in every tool (milling, drilling, etc.) to specify Cooling. When start milling/drilling to automatically turn on cooling, and at the end of operation turn it orr.

In my Fanuc (15M) I have this options:
M07 - Through coolant
M08 - Flood coolant
M09 - turn off cooling
Forgot other commnads, will look later, There's Jet cooling, and Air Myst, some machines has an air blast option. Theese are not used by me, but may be usefull to others.

I know, that some machines have only M08 cooling, and M07 (and other commands) are used for different things in different controllers/machines, so, it would be good to have this options in postprocessor and in every tool operation have an option to turn cooling on and off, and read available cooling options from post and exclude from list what is not used by this controller/machine. (Do I clearly express myself?)

[sliptonic]

I can think of three different ways to address this, all with pros and cons.

1) All the operations can be modified to support cooling. This means editing all the TaskPanels to add controls, Adding logic to set and get those properties and then adding logic to insert the correct commands into the output. It's pretty much the same code over and over but a lot of duplication. In the future, if we want to add Mist or Blast or something else, they all have to be adjusted again.

2) We could add another 'partial command' for cooling on/off. Partials are like mini-operations. They exist side by side with the regular operations and are post-processed just like them. In this case, the user would have to add a partial to turn the cooling on and another to turn it off again.
This might be a good solution because the user could turn it on at the beginning of a job, execute several operations, then turn it off. I still think it would be a bit cumbersome and the user will have to fiddle with the job order if adding the partials at the end.

3) We could create a Cooling Dressup. User would select the operation and apply the dressup. The dressup would have properties to select cooling type and any other options. The dressup would basically insert a 'cooling on' command at the beginning op and 'cooling off' at the end.

If the logic is more sophisticated, or changes in the future, it only has to be fixed in one place. I can imagine a situation where we want coolant applied on every vertical move or after X distance of travel. I think that's all possible with a dressup.

The downside of a dressup is that it is done at the operation level not the job level. So the user will have to apply it and configure it for every operation.

[chrisb]

(Do I clearly express myself?)

Yes. (As far as what I understand is what you want to say )
Since the cooling depends on the tool, we either need different tool changes, or we need an extended tool description, which is my favorite. This would imply adding an arbitrary sequence of GCodes to the tool description. If for one special operation we need a different startup sequence (e.g. without any cooling), would that be a different tool or should it be possible to change the sequence at any occurrence in the Job?
We recently had discussion about tooltable extensions. I repeat the core here, so we have a common place for further discussions:

So what we would like to have now is:

• ramping angle, preferably in 4 tastes: 0°, 90°, 20° and custom. (20° originating from the herbk-rule of a 1/3 plunging ratio)
• Flywheel Fly-Cutter type
• All Lengths and diameters > 100
• Keep line selected after move
• Arbitrary starting gcode sequence

[Konstantin]

1) All the operations can be modified to support cooling. This means editing all the TaskPanels to add controls, Adding logic to set and get those properties and then adding logic to insert the correct commands into the output. It's pretty much the same code over and over but a lot of duplication. In the future, if we want to add Mist or Blast or something else, they all have to be adjusted again.

On my opinion - adding it to the structure of Path module as a "class" (or how you programmers call it) and import it to every tool (class?), it would let to do changes in one place, so potentially it would cause less pain in the future, you can easily extend this class (on my opinion ). Adding it as a "partial command" is easier, but will make me do that every time by hand. I can live with that to, but... it's not cool

[GeneFC]

The cooling function sounds like it is better suited to a post processor rather than the Path module itself. There are endless varieties of tool changers and control functions in milling tools. Some are purely manual as well.

Trying to keep up with all of the variations within the Task Panels or other path generating components would be a nightmare.

The Path output already indicates tool changes. The post processor should use those indicators to control cooling or any other auxiliary functions.

Gene

[mlampert]

Sounds like the best option would be to add a generic interface (off/mist/flow ?) to the tool controller as Chris suggests and Gene alludes to. Then the post processor either ignores the information or generates the codes the machine expects.

[roivai]

Slightly related:
I once quickly implemented cooling so that I modified the post processor (linuxcnc in this case) to append M7 when any non-rapid move command is found if coolant is not on and M9 when a rapid move (G0) is found if coolant is on. With non-circulating coolant like mist it saves some coolant when it is not on during rapids.. I don't say it is a good way to do it, but worked pretty well in my case. I did not have any tool/operation dependency on it, so the coolant is on with every tool. But as I change tools manually, I usually have a separate Job for each tool so I can choose the non-cooling post processor to the tools I don't want coolant.

[Konstantin]

Slightly related:
I once quickly implemented cooling so that I modified the post processor (linuxcnc in this case) to append M7 when any non-rapid move command is found if coolant is not on and M9 when a rapid move (G0) is found if coolant is on. With non-circulating coolant like mist it saves some coolant when it is not on during rapids.. I don't say it is a good way to do it, but worked pretty well in my case. I did not have any tool/operation dependency on it, so the coolant is on with every tool. But as I change tools manually, I usually have a separate Job for each tool so I can choose the non-cooling post processor to the tools I don't want coolant.

This shows how inflexible this method is. This thing definitely should be somewhere in tools, postprocessor only should to choose which comand to choose.

[sliptonic]

Slightly related:
I once quickly implemented cooling so that I modified the post processor (linuxcnc in this case) to append M7 when any non-rapid move command is found if coolant is not on and M9 when a rapid move (G0) is found if coolant is on. With non-circulating coolant like mist it saves some coolant when it is not on during rapids.. I don't say it is a good way to do it, but worked pretty well in my case. I did not have any tool/operation dependency on it, so the coolant is on with every tool. But as I change tools manually, I usually have a separate Job for each tool so I can choose the non-cooling post processor to the tools I don't want coolant.

This shows how inflexible this method is. This thing definitely should be somewhere in tools, postprocessor only should to choose which comand to choose.

You wouldn't want to have two tools in your tool library: '5mm cutter with coolant' and '5mm cutter without coolant'. That would get worse with every variation of cooling. So I don't think this belongs in the tool itself. However, It certainly might belong in the tool controller as mlampert indicated. The simplest implementation whould just be a combobox in the TC to select cooling strategy. When the TC is post-processed, the post would add the specific gcodes to turn coolant on at the beginning and off at the end.

Roivai's example shows how the operation itself has a lot to say about when coolant should be turned on or off. It's this kind of idea I had in mind when I suggested a dressup. Dressups exist to adjust paths for real-world limitations of tools, machines, and materials. That's exactly what this is. The only downside I see to a dressup is that it has to be applied to each operation. We could make that a lot less painful by allowing the user to multi-select operations in the tree and then click the dressup menu item to apply it to all in one go.

[chrisb]

I like the idea of controlling coolant in the Tool Controller (the name never fitted better), although it should find it's possible options in the ToolTable, e.g. it is not sensible to use internal cooling, if the tool doesn't support it.