Thanks Chris--I fixed the links where I placed inline, and they appear correct to me now. Sorry for confusion.
There's two different things; First, detecting if the operation violates the model. Clearly this belongs to the operation itself.JoshM wrote: ↑Thu Sep 27, 2018 3:59 pmHey Brad,
I don't think we're really at large cross purpose here. By adding smarts, I meant the ability to do just what you describe--to be able to use the amount removed by a prior Op be the input for subsequent operations. I also do not mean to limit ability to do an atomic action, but rather it is clear to me that you can add a level of Warning in that the OP configuration will violate the model, then let the user allow/disallow, or modify the OP...
If the roughing op uses a dropcutter algo to determine intersection points, that collection of points may not be useful for a finishing op that uses the same tool and model but a waterline algo. Or maybe it is. I don't know. I'm just suggesting that it's a level of optimization that can wait.On redundancy, what I meant is that if the 3d Job model is picked apart to determine how a Tool geometry interfaces with it, then for example, a Roughing OP is performed, leaving only 0.5mm from the finish, it makes no sense to me to have to pick apart the geometry again to generate the Finish OP.
okI do think there is merit in parsing the whole job, sectioning the stock, according to how the Job looks from a Tool-Centric viewpoint, and then using that information to generate atomic operations. As I mention, the Heights approach is challenging, and I've ruined more than a couple jobs because I lost sight of a Rapid that moved directly through my stock. There really should be little ambiguity about where Rapids are intended in a 3d system. As a default, I would start above the Stock Top, then allow it to be modified as needed by the user. Once Stock is removed, if computing bandwidth were no issue, one could increase the allowable bounds, but I'd kick the can on that until many other issues are resolved. That said, by using the 3d Model of the job, there is a lot of context to be gained, even now.
The project document can contain any number of jobs. Each job is a separate thing with no linkage between them.You mention that PathWB is actually relatively agnostic--just a container. I've been confused because when I've poked at it, it seems in an Active Document containing more than one Job, all Jobs and Tools are objects on the same hierarchical level. From the Outlist, I can get the Default Tool, but I'm not clear how I could iterate through all Tools added into a Job?
I completely agree with you here.There's two different things; First, detecting if the operation violates the model. Clearly this belongs to the operation itself.
Yes, that's the stuff.sliptonic wrote: ↑Thu Sep 27, 2018 8:08 pm
Actually, It's even easier:
>>> j= App.ActiveDocument.Job001
[<Path::FeaturePython object>, <Path::FeaturePython object>]
Code: Select all
j= App.ActiveDocument.Job002 for t in j.ToolController: t.Name t.Tool.Diameter print("\n")
True, true, but, one does not always need or want or require a roughing op depending on the work part.