Understanding opLoft with Path Guides (and opSweep)

EFish

I am currently working on a feature that will generate a belt profile following a path that will contain sketch edges as well as 3d splines. Using the loft feature, you are able to generate a object by selecting the profile and then the guide path that forms a closed loop. I am having trouble understanding how to replicate this behavior using the opLoft function, instead when I give the value for the guide path it returns the error "LOFT_SELECT_GUIDES". I have also tried using the sweep function instead as well but the sweep doesn't handle the spline transitions very well and is very touchy on whether it returns an error. 

Document Link "PolyCord Belts" : https://cad.onshape.com/documents/028ca8fb10baf53e1f6fce96/w/b1250a450d0ba88f0a8b1811/e/ef2bfd25e938251a6c1a9dbb?renderMode=0&uiState=6328c1ee89ceb03aa422ae19

Thanks in advance

S1mon

I would think Sweep (OpSweep) would make more sense. Loft is overly complicated.

Your Fitsplines are likely more the source of your pain. The ends are not tangent to the arcs. You might be better off using 2 bridging curves per fit spline or a sketched spline which is in a plane described by the end points in your sketch 1 and an end point from sketch 3. 

It also looks like your featurescript uses the diameter of the belt as the midVect offset. In your manual prototype you used .255 when the belt is .25, which is why it works. You need some amount of clearance like that for the loft or sweep to work. The Parasolid kernel can't handle a point or line intersection between two solids.

EFish

The reasoning for me initially going with using the loft function was due to how the loft function handles intersections very differently, and will move past possible intersections much better than the sweep function. 

I did some testing based on what you suggested and here's what I found.

1. I first tested having the clearance adjustment, in the manual prototype as well as through the featurescript, it did not make a difference in either case.
2. I did some testing manually with the sweep function and oddly enough the sweep feature would require a very large offset in order to work for a solid body (I tested based on the path generated by the featurescript). But it generates the way I want to as a surface manually (it does not require the offset), but I have not been able to replicate the behavior via featurescript yet.
3. I agree that a probable cause is that the input pathway may be incorrect, but that may be due to less preprocessing from not using the full sweep / loft feature (I can't find the opSweep or opLoft functions in std but that is my guess) because of the fact that while the functions are unable to use the path via featurescript, the full feature in the part studio is able to.

I'll keep looking around and testing ideas, thanks for responding so quickly!

EFish

Update-

After some time looking through the sweep.fs tab in the std document, I noticed that before the path query is given to opSweep, the query is passed through 'followWireEdgesToLaminarSource'. This made the path input valid for the sweep function, which now allows it to generate in some cases (I have to rebuild the point system to be more robust). Although it is still the case that only surface bodies generate without getting a intersection error (probably from imperfect splines that aren't truly tangent), it is very helpful to have an actual body generate. 

S1mon

I haven't really dug into this code to understand what all is being done beyond calling OpSweep, but the Circle Sweep feature script might be helpful for your endeavors.

EvanReese

@EFish
I agree that this looks like a job for opSweep since the profile should always be the same, and for a complex belt with lots of turns you're going to hit the profile limit for Loft path (50). I think with the Loft you're confusing "Guides" and the "Path" option which are different. I don't think opLoft even handles the Path option. I think (but am not 100% sure) that the loft feature actually generates new intermediate profiles along the path itself, and lofts through them. If you really need this functionality you could call the actual Loft feature inside of your custom feature instead of opLoft.

EFish

@Evan_Reese
I definitely agree with the conclusion that using the opSweep function is the way to go. Not until some later testing did I realize that the Loft function had a profile limit of 50 (which I understand is a performance limitation), but from my understanding the Loft feature uses the "Guides" in the same way that the Sweep feature uses the "Path", the notable difference is that the Loft feature generates a new profile at the intermediate points as you have already said. Which makes the end result more blocky due to a lower "Guide" resolution, since Loft is connecting from profile to profile.

The main point of confusion at this point is how opSweep operates between solid bodies and surface bodies, because it seems that the solid bodies have a very different collision check compared to surface bodies, that commonly creates intersection errors where surface bodies don't. This very well is due to the Parasolid kernel as @S1mon stated before. Currently I can make due with the surface body generation, but a solid body would be ideal (allowing parameters such as weight more easily).

EvanReese

I'd be curious to see the cases you're talking about where solids fail but surfaces work. I did a test and wasn't able to get it behaving that way. In your feature, it will be critical to leave a little tiny gap where the cord crosses itself. If it's touching (but not intersecting) it will fail. Here's an example with a small gap. It's configured so you can change between a solid and surface, and change the gap spacing. With this model, the solid is more stable than surface. If the cord intersects itself, solid works and surface fails. https://cad.onshape.com/documents/194dbea05678dcbc97413d3f/w/3f73c8ef0e7471cb4bf0d968/e/6123250c3eafc797c8781ae8