Engraving cannot find BaseObject

[chrisb]

The Engraving operation used to have a ShapeString as a base object.
This has vanished and I currently I cannot assign the ShapeString to the engraver. Instead I get a message:
No Tool found or diameter is zero. We need a tool to build a Path.No Tool found or diameter is zero. We need a tool to build a Path.
I had selected an engraver which - of course - has a diameter of zero.

If I take an endmill as tool I get the message
The Job Base Object has no engraveable element. Engraving operation will produce no output.

I am afraid I missed something in the handling.

[roivai]

Yep, PathEngrave seems to check if tooldiameter > 0, which is totally unnecessary as the diameter information is used nowhere.

But I was able to create a path from ShapeString just fine when I had a tool with a diameter>0:

2017-05-06-105857_3840x1200_scrot.png (107.04 KiB) Viewed 1912 times

Do you have the problematic file, I can try?

Pekka

[chrisb]

Thanks for the offer, your post was already a help because I could see your simple tree to the left.

I managed to get an engraving path but I had to create another job with the shape string as it's base object. That leads to the problem, that the start depth is always zero - probably because the engraving job doesn't know anything about the solid where the shapestring is attached to.

It would be great to have the old function back, where the shapestring could be attached to the engraving operation directly, not via the job's base object. (Perhaps I can give it a try myself, if there are no objections - oh boy, there is so much on my todo list ... and probably no chance to start before mid of june.)

[sliptonic]

I changed the base object behavior to support arch panels. Panels have 'tags' for the individual parts and also the whole sheet so being able to do a single engraving operation for the whole job is important.

The standard that seems to be evolving is for the operations to automatically find and select all elements that they can work on and add them to a list that the user can select/deselect from. Roivai's work on drilling is a good example.

I also ran into some limitations of the current implementation yesterday - engraving won't work on an array of shapestrings - so I'll be looking at it soon if you don't get to it. By all means please try

[chrisb]

I changed the base object behavior to support arch panels. Panels have 'tags' for the individual parts and also the whole sheet so being able to do a single engraving operation for the whole job is important.

The standard that seems to be evolving is for the operations to automatically find and select all elements that they can work on and add them to a list that the user can select/deselect from. Roivai's work on drilling is a good example.

I also ran into some limitations of the current implementation yesterday - engraving won't work on an array of shapestrings - so I'll be looking at it soon if you don't get to it. By all means please try

Sure I will try and thanks for looking at it. Offering a list seems to be a good idea, another possibility would have been to select the elements to be engraved in the tree. Although I don't know the internal structure I guess that finding all shapestrings is much easier than finding all drillable holes.

[sliptonic]

Sure I will try and thanks for looking at it. Offering a list seems to be a good idea, another possibility would have been to select the elements to be engraved in the tree. Although I don't know the internal structure I guess that finding all shapestrings is much easier than finding all drillable holes.

I've been playing with Engraving a little today because of a project I'm working on. I've made a couple minor changes which I can push in a separate branch if desired (I removed the check for tool diameter and corrected the handling of safeheight and clearanceheight).

But it got me wondering about engraving in general:

Should engraving have startdepth and stepdown values like other operations or is it generally a single pass operation at the final depth? Right now, we DON'T have stepdown or start depth (there's a startdepth input field in the task panel but it doesn't do anything )

I generally use engraving for a laser job so it's a single pass operation.

As for base object:
In the past, you could select one or more shapestring objects and create the engraving operation for them. Now, as noted above, all operations share the same base object identified by the Job. This makes a lot of sense to me since all operations in the job will be working on the same part, they'll share common properties like stock object, tools, post processor, etc (and in the future, maybe things like material)

But shapestrings aren't attributes of a base object, They ARE a base object. They have their own placement data unless copied into a Part object or other group.

Arch panels are different. The engrave-able element of the panel is the 'Tag' which is an attribute of the panel/Sheet. If the panelcut or sheet moves, so does the tag.

For shapestrings, I see three possibilities:

1) Make engraving work like it did before. It would work on any arbitrary shapestrings that you pick. This is very easy and convenient but I think it's a mistake. It won't give the user a cohesive view of the job. If the base object is moved, the string will have to be moved as well and the operation properties will have to be adjusted manually. If we change the UI to hide everything but the base object and the path visualization, the shapestrings won't be visible.

2) Make Jobs accept PDN Part objects as base object. To engrave a part, the user would have to create a Part object in Part Design and add the shapestring(s) to it. We would make engraving search through the Part tree and add the child shapestrings to a selection list automatically then let the user enable/disable as desired.

3) Leave it as it is now. If the user wants to engrave a shapestring, a job is created for the shapestring along with a new tool etc. Downside is that each shapestring will require its own job.

[chrisb]

Perhaps there is fourth possibility, but I am no longer sure if I understand the concept of shape strings very well . So let me share my experiences and views of the matter.

If I create a model using shape strings for engraving I do the following 3 (sometimes 4) steps
- create a shape string on a surface
- extrude it
- cut the extrude from the object.
- Sometimes I don't cut it directly but I fusion all the extruded shape strings first and cut them as a whole.

The fourth possibility is nothing really different from your possibility 1), it is only a different view. I like this possibility because I don't have the feeeling that engraving really justifies a new job.
For me a shape string is not engraved directly. It is used like the other elements to define an object. So the shape string is not what really is interesting but rather its impact on the object. It is similar to cutting a cube out of an object where I don't want to mill that cube but rather th pocket defined by it. The difference between cutting a pocket and engraving a shape string is that we probably still need the shape string itself to create a path.
I have to confess that I am really not sure where this fits smoothly in the Path's programming model, and I am not sure if the impact of a shape string on the object can be reliably determined.

As a side point: since you mentioned placement I tried to move the object and realized, that the engraving follows the move, so the object is moved correctly. But the path does not follow, it stays at the place where it was. So your third possibility (leave it as it is) needs manual correction as well.

[sliptonic]

Your workflow makes sense but won't be universal. It's a valid 4th option I hadn't considered and there are probably others. I don't have a good answer at the moment so I guess I'll ponder it for a while. Perhaps wisdom will come with time.

As for the Path placement, does it update when you mark the operation for recompute and then refresh the document? Sounds like the engraving operation hasn't detected the change to the base.

[bill]

Over the path year or so, PATH has evolved/developed a relatively high degree of structure. Part of this is inevitably due to the environment/domain being modelled; e.g. Job organization, tool-selection, operation-selection, Path generation, Path:Dress-Ups, etc..

Programmatically, Option N0.2 supports this evolution and the new norm.

2) Make Jobs accept PDN Part objects as base object. To engrave a part, the user would have to create a Part object in Part Design and add the shapestring(s) to it. We would make engraving search through the Part tree and add the child shapestrings to a selection list automatically then let the user enable/disable as desired.

Stepping to final depth is essential!

?Will a user be able to engrave a STEP-defined object; Is this simply an import into a PDN model?