path array behavior

Post here for help on using FreeCAD's graphical user interface (GUI).
Forum rules
and Helpful information
IMPORTANT: Please click here and read this first, before asking for help

Also, be nice to others! Read the FreeCAD code of conduct!
User avatar
Vincent B
Veteran
Posts: 4713
Joined: Sun Apr 05, 2015 9:02 am
Location: La Rochelle, France

path array behavior

Post by Vincent B »

Why and how avoid that? Path array doesn't follow path with some objects? :roll:
I would like my revolve on the path.
...
OS: Windows 10 Version 2009
Word size of FreeCAD: 64-bit
Version: 0.20.26858 (Git)
Build type: Release
Branch: master
Hash: e209bc706d35121098f9bac779bc6b09c24ddd95
Python version: 3.8.6+
Qt version: 5.15.2
Coin version: 4.0.1
OCC version: 7.5.3
Locale: French/France (fr_FR)
Attachments
patharray.FCStd
(16.36 KiB) Downloaded 31 times
TheMarkster
Veteran
Posts: 5505
Joined: Thu Apr 05, 2018 1:53 am

Re: path array behavior

Post by TheMarkster »

If you select the transform tool the dragger gets placed at the object's origin point, which is off with the revolve:
Snip macro screenshot-70ee45.png
Snip macro screenshot-70ee45.png (60.67 KiB) Viewed 1519 times
Move the revolve such that the desired origin point is on the origin, make a compound of it there, and use the compound as the base of the path array.
montyl
Posts: 19
Joined: Tue Jan 22, 2019 5:08 am

Re: path array behavior

Post by montyl »

If the revolve came from somewhere you can't change it, Markster's answer is the solution, since you don't have the source.

If you created the revolve, re-create it so that the point you want to follow the path is 0,0,0.

The reason the array "moved away" is the offset of the revolve. Notice that both measurements, from 0,0,0 to Revolve001 and the one from the beginning of JoinCurve001 to the first array element are identical. Where Revolve001 is placed does not matter, which explains why moving it to meet JoinCurve001 didn't accomplish what you thought it would.

MontyL
Attachments
offset revolve.png
offset revolve.png (77.97 KiB) Viewed 1443 times
drmacro
Veteran
Posts: 8865
Joined: Sun Mar 02, 2014 4:35 pm

Re: path array behavior

Post by drmacro »

I was tinkering with the Path Array just yesterday and noted behaviour, I think similar in nature.

You'll note in the attached file PathArray follows the selected path.

But, PathArray001 creates the array based on some offset. Obviously to do with the joincurve, but why?

(PathArray001 has not had the properties adjusted for perpendicular and follow, but that is not the difference.)

I have not explored why PathArray001 does this. It may be expected.
Snip macro screenshot-a4ee6f.png
Snip macro screenshot-a4ee6f.png (110.58 KiB) Viewed 1421 times
Attachments
BoilerNStack-3.FCStd
(42.11 KiB) Downloaded 27 times
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
montyl
Posts: 19
Joined: Tue Jan 22, 2019 5:08 am

Re: path array behavior

Post by montyl »

@drmacro

As above, the element you're using for the array is offset, so the result would have to be similar.

In your case, a point on the plane of JoinCurve needs to be 0,0,0. Since JoinCurve was created from Sketch009, which is NormalToEdge on Sketch On Surface, 0,0,0 lies elsewhere (upper left corner of the Mapped Sketch, to be precise.

Sketch010, copied from 009 and reoriented so that 0,0,0 is the same point JoinCurve meets Sketch On Surface, results in the same array as your Sketch009/Sketch On Surface. If Sketch010 is used to create a new JoinCurve (beyond my understanding), I expect it to do the same. (Believe me, this paragraph hurts my head to follow it, but it's the best I could manage.)

Got me curious, not that I can think of an application for the knowledge... :)

Even more curious is what the array represents to your boiler and stack...

MontyL
Attachments
BoilerNStack-3ML.FCStd
(52.26 KiB) Downloaded 23 times
User avatar
Vincent B
Veteran
Posts: 4713
Joined: Sun Apr 05, 2015 9:02 am
Location: La Rochelle, France

Re: path array behavior

Post by Vincent B »

Path array use internal offset. It's not useful with some objects. It should be have an option to avoid that.
Attachments
patharray_bad_behavior.FCStd
(15.38 KiB) Downloaded 26 times
drmacro
Veteran
Posts: 8865
Joined: Sun Mar 02, 2014 4:35 pm

Re: path array behavior

Post by drmacro »

montyl wrote: Tue Jan 25, 2022 6:03 pm ...
Well, a couple things.

The reason for the attempt using a joincurve was to avoid having to select each edge of each profile in PathArray to do a pipe sweep.

The same with you PathAray002.

In PathArray001, since the JoinCurve was used, each member of the array is a single edge.

But, because of of the offset involved the profiles are off in space somewhere.

This is similar to what happens in imported STEP or STL files where they are not a at global 0,0,0 and you move them there, then drop them into a Part Design Body, they revert back to their original location.

I understand why this happens, but, IMO, there should be a property "Stay Put" for such instances. (Well, maybe it would really be called something like "Maintain global position" :lol: )

As for what it is, it is the retaining ring at the bottom of this stack.
Stack.jpg
Stack.jpg (160.35 KiB) Viewed 1364 times
And, it actually is much easier with the PipeShell in Curves workbench. ;)
Snip macro screenshot-307eb7.png
Snip macro screenshot-307eb7.png (161.65 KiB) Viewed 1364 times
Star Trek II: The Wrath of Khan: Spock: "...His pattern indicates two-dimensional thinking."
User avatar
wandererfan
Veteran
Posts: 6268
Joined: Tue Nov 06, 2012 5:42 pm
Contact:

Re: path array behavior

Post by wandererfan »

Vincent B wrote: Tue Jan 25, 2022 6:29 pm Path array use internal offset. It's not useful with some objects. It should be have an option to avoid that.
Path array doesn't use an internal offset.

The geometry of Solid001 builds it at an offset from the origin (note Solid001.Placement is at the origin).

Cube, on the other hand, has geometry that builds the shape at the origin, then the Placement moves it to (61, 76, 0).

Path array can adjust for a Placement not at the origin, but there is no way for it to change the geometry of an object to move it.

See https://wiki.freecadweb.org/Placement#P ... Definition
montyl
Posts: 19
Joined: Tue Jan 22, 2019 5:08 am

Re: path array behavior

Post by montyl »

drmacro wrote: Tue Jan 25, 2022 6:40 pm
montyl wrote: Tue Jan 25, 2022 6:03 pm ...
This is similar to what happens in imported STEP or STL files where they are not a at global 0,0,0 and you move them there, then drop them into a Part Design Body, they revert back to their original location.

I understand why this happens, but, IMO, there should be a property "Stay Put" for such instances. (Well, maybe it would really be called something like "Maintain global position"
I agree, some way to move the origin of an object, not placement.

Ah, a retaining ring! :)

I would sweep the profile of the ring, rather than any array work.

MontyL
Attachments
BoilerNStack-3ML-2.FCStd
(60.99 KiB) Downloaded 23 times
Last edited by montyl on Tue Jan 25, 2022 8:19 pm, edited 1 time in total.
User avatar
Vincent B
Veteran
Posts: 4713
Joined: Sun Apr 05, 2015 9:02 am
Location: La Rochelle, France

Re: path array behavior

Post by Vincent B »

wandererfan wrote: Tue Jan 25, 2022 7:16 pm
The geometry of Solid001 builds it at an offset from the origin (note Solid001.Placement is at the origin).

Cube, on the other hand, has geometry that builds the shape at the origin, then the Placement moves it to (61, 76, 0).

Path array can adjust for a Placement not at the origin, but there is no way for it to change the geometry of an object to move it.
Agree with that. That's why PathArray has an extra-translation parameter. But an other parameter could be an automatic negative offset.
Post Reply