Ability to re-order machine operations

[GoogleCodeExporter]

A file may have multiple machine operations.  It should be possible to
select an operation and move it up or down the object tree and regenerate
the python code and g-code.

If the user desires to have an outside profile operation happen last, that
operation must be added last or any subsequently created operations will
execute after it.

Currently, the preceding operations must be deleted and re-added to achieve
this functionality.

Original issue reported on code.google.com by shopinth...@gmail.com on 30 May 2009 at 3:06

[GoogleCodeExporter]

My suggestion would be to add an 'execution order' integer to the COp class and 
allow
its value to be editable along with each object that is based on the COp class. 
 By
default, all objects could be created with an 'execution order' that matches 
their
type.  For example, I would want the CuttingTool object's execution order to be 
a
small number (range 1-10 for example) and a DrillingCycle object's execution 
order to
be larger (range 11-10 for example).  This would ensure that tool table entries 
are
created before drilling cycles 'select tool'.  It's a similar scenario.

I would be happy to look at this if other people agree with this solution.

Original comment by David.Ni...@gmail.com on 15 Jun 2009 at 3:30

[GoogleCodeExporter]

Now that I have added a "tools" object
see http://code.google.com/p/heekscnc/issues/detail?id=103
You won't need to worry about the tools being before the operations, in the
"operations" list, because they won't be in there.

We still need this ability to re-order the operations, though. I agree you 
should be
able to move objects up and down in the tree.

Original comment by danhe...@gmail.com on 15 Jun 2009 at 9:14

[GoogleCodeExporter]

I started having a play with this today.  I fixed up an oversight in Adaptive 
and
Drilling where the GetProperties() methods were calling the 
HeeksObj::GetProperties()
method where they should have been calling COp::GetProperties() and letting it 
call
its base class.  This allowed the 'comments' attribute to show through 
correctly.

This didn't do me much good, however.  The Programm::m_operations is based on 
ObjList
which, in turn, contains a list<HeeksObj> objects.  This jumps one level of 
class
heirarchy.  i.e. it skips the COp layer.  I think the m_operations variable 
should be
a list of COp objects rather than going straight to HeeksObj.  The 'comment' and
'execution order' attributes really do belong in the COp class.  It makes sense 
to
have a COp class as there are things that only operations do.

The reason I haven't changed the rest of the code is that I'm too scared to do 
it.  I
am not sure I understand all the data structures well enough yet to be doing 
such
wholesale changes.

Dan, do you have an opinion on this?

Original comment by David.Ni...@gmail.com on 16 Jun 2009 at 3:59

[GoogleCodeExporter]

I have implemented the 'execution order' setting in the COp class.  This means 
that
all NC operations inherit it.  I have also added the tool number into the COp 
class
so that all NC operations may assign a tool number to them.  The 'select tool'
commands are issued during the GCode generation when the tool number is greater 
than
zero and when the tool number is different from the previous operation's GCode
production call.

The only other thing that would be nice is if the execution order value was 
used when
listing the Operations beneath the Program entry.  At the moment, the integer 
can be
manually set and the GCode generation supports it but it's not very visually 
obvious
which order the operations will be performed in.  I don't know how to do this 
at the
moment.

Original comment by David.Ni...@gmail.com on 16 Jun 2009 at 6:06

[GoogleCodeExporter]

You said >> I think the m_operations variable should be
a list of COp objects rather than going straight to HeeksObj

To do this correctly ( keeping the code tidy ), this would require making the 
ObjList
use templates, which I have not really learnt how to do. I want all the 
behaviour of
ObjList.

However, we know that all the HeeksObj* objects in m_operations must be derived 
from
COp, so it is OK to cast them to COp*, like this

    for(HeeksObj* object = m_operations->GetFirstChild(); object; object =
m_operations->GetNextChild())
    {
        operations.insert( std::make_pair( ((COp *) object)->m_execution_order, ((COp*)
object) ) );
    }

Anyway, I don't think there should be a m_execution_order variable.
The order of machining should simply be determined by what order the operations
appear in the tree ( in m_program->m_operations ). We need to make drag and 
drop work
in the tree.

Original comment by danhe...@gmail.com on 16 Jun 2009 at 8:20

[GoogleCodeExporter]

I agree that the drag and drop features would be the most intuitive.  Would you 
like
me to remove the m_execution_order variable from COp or will we leave it there 
until
the drag and drop feature is implemented.

I'm afraid GUI stuff is not something I'm good at.

Original comment by David.Ni...@gmail.com on 16 Jun 2009 at 9:52

[GoogleCodeExporter]

Feel free to leave m_execution_order there for a while, then, but bear in mind 
that
it will be removed eventually.

Original comment by danhe...@gmail.com on 16 Jun 2009 at 11:08

[GoogleCodeExporter]

I've started using HeeksCNC and am quite impressed. Thank you so much for 
continuing
work on it. 

To this issue, I would simply like to vote up the importance of the gui 
representing
the machine order of "operations" and the ability to edit that order with drag 
and
drop. It's amazing how often I try and drag a drill operation above a pocket
operation to re-order them even knowing it doesn't work!

Excellent progress thus far.

Original comment by edgarpan...@gmail.com on 19 Nov 2009 at 9:44

[GoogleCodeExporter]

OK. There is some other essential work needing doing to the tree, first, like 
the
fact that it keeps collapsing itself when you edit anything. I will try to look 
at
this again soon.

Original comment by danhe...@gmail.com on 20 Nov 2009 at 4:08

[GoogleCodeExporter]

Agreed, the collapsing issue is most annoying! At the very least, shortcut keys 
for
the primary tree locations would be pretty sweet. 

Actually, eventually it would be really helpful to store app-wide and plug-in
shortcuts in a table that the user can access so we can make changes to suit 
our taste. 

For example, currently, ctrl+center-mouse=screen shifting (hand tool) but I 
would
rather set that to either shift+center-mouse or center-mouse+left-mouse as it 
is in
Sketchup. I'm sure others have their own preferences.

Original comment by edgarpan...@gmail.com on 20 Nov 2009 at 6:28

[GoogleCodeExporter]

You can now drag and drop to re-order operations

Original comment by danhe...@gmail.com on 23 May 2011 at 8:19

• Changed state: Fixed