Feed- and Speedrate

[herbk]

Hi,
let me show an other suggstion...:

In this time feed- and speedrate are boundet at the tooltable (means: each tool uses the same feed and speed).
From a technical perspective is this wrong. Iff you drill a hole you need an other spindle speed as with an end mill. If you use a 15mm drill you can not use the same speed like on the 3mm drill, - same for endmills...

So, in my mind, speed- and feedrate should be boundet at least to the tool itself, better to the path (15mm drillling/milling steel needs am other speed as n aloy)
The speed/feedrate on the tooltable can be used as default, but should be rewritable in the path settings (like cw ccw).

[mlampert]

The feed and speed rates are bound to the ToolController (TC), basically what it does is to establish a correlation between the tool itself, the used feed rates and spindle speeds.
You can create as mane TCs in a given Job as you want, each one can reference the same (or a different tool) and still have different feed and speed rates. Note that the use of TC does not introduce a tool change g-code command by the post processor script, unless the new TC command actually references a different tool from the tool table.

I can see that it might be a bit confusing - in the beginning this tripped me off all the time because I thought TC means ToolChange, but it doesn't.

[sliptonic]

A TC is like any other operation. When a TC is post processed, it makes its outputs its commands. The post processor is then responsible for acting on those commands appropriately. That can mean writing them to gcode, caching them, or suppressing them entirely.

In Linuxcnc, a tool change gcode with the same tool number will be ignored. But since the tool change commands also include the new spindle speed, the post should probably output that always.

[herbk]

Hi,
ah, - that i have to ad a additional tooltable if i want to use a different tool for a path i didn't figure out....
For me not very logical, I think i suggestet in an other thread before: The way "a machine has one tooltable from which i can select the tool to use for each path" will be more easy and logical.

[herbk]

Hi Sliptonic, hi mlampert,
one post before i said "or me not very logical" to the way to set feed and speedrate.

The logical way would be for me, if the steps i have to go in path WB are nearly the same like the steps i have to go if i work on a mill without CNC support.

In my mind the best (and only logical) place for the feed- and speedrates are on each individual path.

Workflow.jpg (222.42 KiB) Viewed 3677 times

That's like i would like it, - but maybe there are some other minds to...

From "Test suite for Path Workbench"

If people (even non-programmers) want to help with GUI design, I encourage them to install QT-Designer and mock up panels.

I have tried to install, but i can't find a QT-Designer for OpenSuse and QT5. Only a few libs but not a frontend for it.

[mlampert]

I think this is a logical workflow if you're milling by hand and is probably how most people go about it, thanks for drawing that up.

The difference to a CNC workflow is that you don't have immediate feedback - but have to set all feeds and speeds upfront. What can happen, and happens to me more often than I care to admit, is that I get the feed rate wrong. If that happens I want a quick and reliable way of changing the feed rate for all related paths.

So if I'm milling a piece and use 2 tool bits for it, and I got a parameter for one bit wrong, I want to change the feed/speed rate for all paths that use that bit. If I have to manually edit each path then that is quite onerous and error prone.

Having said all that we are thinking about making the ToolController a bit more of an attribute of an operation, rather than an operation itself. Which should be very close to your workflow from an editing standpoint - yet still allows for all related operations to share the same controller settings and thereby provide an easy and safe way of changing the settings for all those operations.

[sliptonic]

In my mind the best (and only logical) place for the feed- and speedrates are on each individual path.
Workflow.jpg

Ultimately we have to have the feed and speed rates for each path. But, as they say, "the devil is in the details".

I have a couple questions about your chart:

In your workflow, "the first thing a user does is select a machine" Would he be creating a job at all? Your job has no attributes of its own. Does it have a purpose? I would guess that you're using the job like we discussed earlier -- as an aggregation of paths for cutting many parts from one sheet. If it isn't this, what purpose does it serve?

You show three paths below the machine; Path 'a', 'b', and 'a' Are you doing this on purpose where the third operation is another pass at path 'a' with a different tool or should that be path 'c'? I don't understand how we would re-use the path 'a' data but with a different tool.

Your three paths use three different tools. What would happen if path 'a' and path 'b' both used tool #2 but with different feed and speed settings? In that case, is tool#2 in each path a copy of the real tool or is it the same tool but with different details?

I *think* I understand the workflow you desire and I think we can get there and make the GUI fast and intuitive. But Markus is right that without something like a tool controller, the user will have to change feed and speed properties on every single operation and this will cause all kinds of trouble. This is the way that HeeksCNC currently works and I have broken many tools because of it. The concept works fine as long as the number of operations is very small (ie < 3) but as jobs get more complex it becomes an unmanageable mess.

[nahshon]

IMHO having the feedrate in the tool controller is a good idea.
Comparing with HeeksCad where I had to change some parameter, I had to go to each path and change ths same parameter agai and again.
Off course there may be other ways to achieve the same purpose.

In the more general case, Would it be possible that many properties of a path will use common data sources (eg, the TC operation) or be able to have own value.

Example, make it possible to select the feed rate of a milling operation can be:
TC1.FeedRate (take it from the tool controller)
or
600 mm/min (use private value)
....

IIRC there was once a spreadsheet module option to overwrite any property with the value of a spreadsheet cell.
The implementation was too difficult to use. As far as I know that was gone when the spreadsheet was rewritten from Python to C++.
Anyway, extending the spreadsheet idea, the tool, the spindle speed and the feedrate could come from a spreadsheet. The spreadsheet could even use formulas to calculate optimal speeds based on given tool and materials.
....

What is happening when changing the order of operations in job? If I drag a TC operation before a profile operation would the profile get recalculated with the parameters of this TC?


-- Itai

[sliptonic]

What is happening when changing the order of operations in job? If I drag a TC operation before a profile operation would the profile get recalculated with the parameters of this TC?

-- Itai

Yes.
That's the current behavior. The operations find the parent job, then iterate upwards from their own position to find the previous tool controller and use it. This is a terrible workflow and really needs to change. The first thing we should do is make the linkage between an operation and a TC an explicit selection from a combobox of all ToolControllers in the job. This alone would make the workflow easier.

This has been proposed before but no one has had the time to implement it yet.

[herbk]

Good Morning,

or should that be path 'c'

it should be path "c"... sorry, (i changed the pic)

I would guess that you're using the job like we discussed earlier -- as an aggregation of paths for cutting many parts from one sheet

'Hm.. I see the Job on top with the attribute "machine". I like the idea of ​​first selecting a machine, because i can set the limitations of an machine (workspace) there. And if each machine has it's own tooltable, i can not make the mistake to schedule a job with a tool which is not possible on this machine.

In that case, is tool#2 in each path a copy of the real tool or is it the same tool but with different details?

It's the same tool with different details.

the user will have to change feed and speed properties on every single operation

Here i think its necessary to do so, - BUT: a single operation on a machine (must) can have more than one path .
If i have a sheet of wood where are to cut out 20 peaces, its one operation one the machine if ican selct all 20 and than say: "cut it with tool2 and speed xy". If i see i speed is wrong, i change the speed one time, because i have only one path for all 20 peaces.
Thats like "path by faces" works in that time and it's great... but for that we are together i think .