Send graphical data to Python

[GoogleCodeExporter]

I had not appreciated what the 'ScriptOp' would do until Dan Falck gave an 
example on his blog.  Dan's example includes his base coordinate data as part 
of his manually added script.

I was wondering if we should allow the ScriptOp to contain child sketches 
(actually it probably already does).  If these are found, the python code 
generated for it could include a set of nested class definitions that described 
the sketches in terms of lines and arcs.  (BSplines and other such graphics are 
converted to either lines or biarcs anyway)

In the Contour operation, I have code that traverses the sketch elements.  It 
uses the CMachineState to know whether the next 'edge' in sketch is connected 
to 'this one' and, therefore, whether to raise up to clearance height and rapid 
across.  i.e. it knows what sections of the sketch are contiguous and which are 
disconnected.  The idea would be to define lists of lines/arcs with each list 
including only contiguous (connected) graphics.  It would then have lists of 
these connected lists.  All this would be done before whatever Python script 
was found within the object itself.  i.e. the manually produced one.

This way, the manually produced script could assume that the nested classes 
(lists of lists of graphics) were already defined and it could use these as 
graphical references for its own purposes.

I have added this issue by way of asking whether this would be useful or not.  
I have not done the work and I don't wish to if no-one is likely to use it.

Any opinions?

Original issue reported on code.google.com by David.Ni...@gmail.com on 5 Jul 2010 at 11:09

[GoogleCodeExporter]

This would be excellent. Being able to paste in arcs,lines,and points would be 
very useful for this operation. A lot of times, I copy objects out of the tree 
and paste them into an external text editor to look at the xml data. I was 
actually looking into parsing the sketch xml code in python, but that's a hard 
way to go.

Thanks,
Dan 

Original comment by ddfalck2...@yahoo.com on 6 Jul 2010 at 4:00

[GoogleCodeExporter]

Dan,
  I started this work but I'm not very far in yet.  I'm not very good at Python so I'm trying to figure out what is good syntax as I go.  Have a look at the script I'm generating so far.  This version has lists of '_lines', '_arcs' and '_points' but this is not what we need.  I wanted to gather lists of connected lines/arcs and have lists of these 'connected lists'.  This way, you could use a single 'connected list' of lines/arcs in some toolpath.  When you needed to start another 'connected list', you could raise the tool to clearance height and rapid over to the next 'connected list' starting point.

 The only reason I'm showing you this file now is that, if I've really missed the point, I would rather you tell me now.  If you want the Graphics class structured differently, can you give me an example to follow?

 I should also mention that I'm doing all this in the ScriptOp class.  Dan (Heeks), would you rather I left this class alone for now or is this OK?

  Thanks
  David

Original comment by David.Ni...@gmail.com on 8 Jul 2010 at 11:58

Attachments:

• post.py

[GoogleCodeExporter]

David,
I might be answering a question for Dan Falck here, but I don't think you will 
mind.
Looks like correct Python code to me.
But, I don't see the point in all the functions, like X().
Why not just have member variables X,Y,Z and access them?
Also, you don't need to declare variables in Python.
So, the Point class would simply be

    class Point:
        def __init__(self, x=0.0, y=0.0, z=0.0):
            X, Y, Z = x, y, z

        def Type():
            return Type.PointType

The line class would be:
    class Line:
        def __init__(self, start = Point(), end = Point()):
            Start = start
            End = end

Also, Python lists can contain different kinds of objects, so you could append 
lines and arcs to the same list, if you wanted to make a path.
I would suggest you don't insert the class definitions into post.py, but put 
them in a separate file, written manually; "graphics.py", which can be 
installed in the HeeksCNC folder ( like kurve_funcs.py is ). Insert "import 
graphics" at the top of the post.py file.

David, I don't mind you messing around with the ScriptOp class, so long as I 
can still simply put some text in there and have it appear in the post.py file, 
when I post-process.
Dan.

Original comment by danhe...@gmail.com on 8 Jul 2010 at 2:02

[GoogleCodeExporter]

I know I haven't done this yet but I think the way forward is to use the Path, 
Line, Arc and Point class definitions available in the OpenCamLib project.  Dan 
Heeks has done this within the ocl_funcs.py file and it's quite neat.  If we 
generate a python program that defines a path for each child sketch.  We could 
define these path objects in lists of path objects to represent 'all the 
children'.  It makes more sense to use the Path, Line, Arc and Point classes in 
OpenCamLib than to define yet another one ourselves.  If we did this, we may be 
able to leverage functions implemented within the OpenCamLib based on the 
geometry that came from HeeksCAD/HeeksCNC.

Just thinking out loud at the moment.  If you think I'm on the wrong path 
(pardon the pun), please let me know.

Original comment by David.Ni...@gmail.com on 16 Jul 2010 at 3:01

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Dan,

 I have something that works (just).  Is this in the right direction?  We can change it yet if need be.

 Thanks
 David Nicholls

Original comment by David.Ni...@gmail.com on 16 Jul 2010 at 8:41

Attachments:

• a.heeks

[GoogleCodeExporter]

David, if I simply make a Script operation with no text and post-process. I get
NameError: name 'script_op_id_1' is not defined. 

Original comment by danhe...@gmail.com on 16 Jul 2010 at 8:57

[GoogleCodeExporter]

That old problem.  That's the third time this week....

Try it now.

Original comment by David.Ni...@gmail.com on 16 Jul 2010 at 9:06

[GoogleCodeExporter]

That's fine now. Thanks.

Original comment by danhe...@gmail.com on 16 Jul 2010 at 9:16

[GoogleCodeExporter]

I have exposed some of the members of the Arc and Line classes in OpenCamLib so 
that they can be accessed from Python.  I have also added a getTypeSpanPairs() 
method to the Path class.  All this has allowed me to make the attached example 
work.  i.e. it can access the sketch data that was generated into the Python 
program by the ScriptOp object.  It's not a particularly good example as it 
doesn't take into account the cutting tool's location but it demonstrates how 
the data can be accessed.

Original comment by David.Ni...@gmail.com on 17 Jul 2010 at 1:06

Attachments:

• a.heeks

[GoogleCodeExporter]

Very nice. I hadn't thought of making it act upon the points and sketch 
entities automatically. very cool. 
Can it be refined further by having it act upon sketches with unique names?

Great work. Thanks so much for doing this.

Original comment by ddfalck2...@yahoo.com on 17 Jul 2010 at 2:34

[GoogleCodeExporter]

Ok, I see that the sketches do get unique names already, in the python program 
panel.

Original comment by ddfalck2...@yahoo.com on 17 Jul 2010 at 3:48

[GoogleCodeExporter]

Hi David,

I noticed that you are using tabs instead of 4 spaces for indentation of python 
code. Could you switch over to 4 spaces instead? Spaces seem to be the python 
norm and if I edit any of your code, I end up with mixed spaces and tabs and 
things get out of sync. I think Dan Heeks is using spaces instead of tabs too.
Thanks,
Dan 

Original comment by ddfalck2...@yahoo.com on 17 Jul 2010 at 4:58

[GoogleCodeExporter]

I have run into a problem that shows my ignorance in programming.

For a set of points in Heeks like this:

<?xml version="1.0" encoding="UTF-8" ?>

<Point col="0" x="6.3337" y="7.55869" z="3.333" id="1" />

<Point col="0" x="10" y="0" z="0" id="2" />

<Point col="0" x="10" y="10" z="0" id="3" />

<Point col="0" x="0" y="10" z="0" id="4" />

I am getting this out of ScriptOp to the Python Program panel:

class script_op_id_1:
    sketches = []
    points = []
    points.append(ocl.Point(2.485321144e-257,8.832635857e-316,6.3337))
    points.append(ocl.Point(2.426735249e-257,8.830812952e-316,10))
    points.append(ocl.Point(2.426938496e-257,8.830819276e-316,10))
    points.append(ocl.Point(2.48577845e-257,8.832650086e-316,0))

I notice that the third value in each entity appears to be X. 

I see that the output in ScriptOp.cpp is from this section of code:

        case PointType:
            double p[3];
            memset( p, 0, sizeof(p) );
            heeksCAD->VertexGetPoint( *itObject, p );
            python << _T("    points.append(ocl.Point(") << p[0] << _T(",") << p[1] << _T(",") << p[2] << _T("))\n");
            break;

What's happening with this?
Thanks

Original comment by ddfalck2...@yahoo.com on 18 Jul 2010 at 4:16

[GoogleCodeExporter]

Dan,
  as part of this work, I changed the implementation of the VertexGetPoint() routine within the HeeksCAD interface.  It used to assume that the HeeksObj pointer passed in pointed to a Vertex object.  It now checks the type of object and allows a pointer to a HPoint object as well.  I suspect you need to fetch the latest HeeksCAD source and recompile it.  It sounds like you're running the old HeeksCAD with the new HeeksCNC.

  I have attached a file with your points in it and the ScriptOp code looks to correctly reflect the point locations.
  Ta
  David

Original comment by David.Ni...@gmail.com on 18 Jul 2010 at 10:23

Attachments:

• b.heeks

[GoogleCodeExporter]

Dan,

  I also noticed that I was always sending the data to the ScriptOp in mm.  I have changed this to send the data in the chosen units instead.

  I also had a bug in the code that converted any BSpline-based sketches into lines before sending the lines to the ScriptOp data description.

  The moral to the story is that you'd better grab the HeeksCNC code as well as the HeeksCAD code again before re-testing.

  Ta
  David

Original comment by David.Ni...@gmail.com on 18 Jul 2010 at 10:54

[GoogleCodeExporter]

Ah,that was it. I always forget to check the other half of the project.
Thanks. 

Original comment by ddfalck2...@yahoo.com on 18 Jul 2010 at 11:28

[GoogleCodeExporter]

Are the changes that have been made enough to satisfy this issue?  Can we close 
it off?

Original comment by David.Ni...@gmail.com on 9 Aug 2010 at 3:11

[GoogleCodeExporter]

no feature requests here, just bug reports for HeeksCNC 1.0

Original comment by danhe...@gmail.com on 24 Mar 2014 at 5:07

• Changed state: WontFix