USER FORUM
(you are viewing a thread; or go back to list of threads)
Approach to model a NEMA 17 stepper motor (by Jack)
Hello, I'm new to CAD/solvespace and was trying to model a NEMA 17 motor. It's essentially a modified square. In order to get the right shape i drew it freehand and then applied constraints as shown in attachment. I'm curious as to how an experienced CAD user would approach the problem. I just worked it out via trial and error...
(no subject) (by Andrew)
Here is a better approach in nema.slvs, so that dimensions are only given once. Note use of a construction line to make the centering independent of size. and the use of eq-pt-line-distance..
To set the last equality for a corner select in order:
The point on the vertical line,
the horizontal line
the point on the horizontal line, the vertical line
for the points either end of the diagonal line for the corner. This also useful for offsetting a pair of shapes for a wall or similar.
To set the last equality for a corner select in order:
The point on the vertical line,
the horizontal line
the point on the horizontal line, the vertical line
for the points either end of the diagonal line for the corner. This also useful for offsetting a pair of shapes for a wall or similar.
(no subject) (by Jason)
I just modeled one of these recently myself, wouldn't say I'm an expert but my first sketch was similar to discribed. I modeled each part individually and made an assembly
(no subject) (by Jason)
oops, didn't add the sketch, here it is
(no subject) (by Andrew)
It is better to use constraints, like equal length,diameter and eq-pt-line-Distance than entering the same dimension twice, Attached is an extended version of my previous sketch, where the mounting holes have been added., and you will see that repeated dimension have been entered once so that four numbers define the size. The eq-pt-line-distance is particularly useful, With 3 instances of it, and the center distance positioning the mounting holes. (Selecting a constraint in the properties browesr highlights it the sketch).
That constraint has one bug, it will not allow the same point to be set an equal distance from two lines, although you can set two points to be the same distance from a single line. Hence the sketch uses a construction line to center it on the sketch plane, making the centering independent of any size changes.
That constraint has one bug, it will not allow the same point to be set an equal distance from two lines, although you can set two points to be the same distance from a single line. Hence the sketch uses a construction line to center it on the sketch plane, making the centering independent of any size changes.
(no subject) (by Jack)
Thank you for your response Andrew. Can you clarify this constraint.
"To set the last equality for a corner select in order:
The point on the vertical line, (I call this point 1 on the diagram)
the horizontal line (I call this line B on the diagram)
the point on the horizontal line, (Point 2)
the vertical line (Line A)"
I'm able to recreate what you've done, i'm just not exactly sure what this constraint is doing.
I attached a diagram and labeled each "part" of the constraint for reference.
Put into words is this saying that the distance between point 1 and line B must be equal to the distance between point 2 and line A?
"To set the last equality for a corner select in order:
The point on the vertical line, (I call this point 1 on the diagram)
the horizontal line (I call this line B on the diagram)
the point on the horizontal line, (Point 2)
the vertical line (Line A)"
I'm able to recreate what you've done, i'm just not exactly sure what this constraint is doing.
I attached a diagram and labeled each "part" of the constraint for reference.
Put into words is this saying that the distance between point 1 and line B must be equal to the distance between point 2 and line A?
Take advantage of symmetry (by ruevs)
One should try to exploit the symmetries in the object to the maximum. The attached zip contains two ways to draw the sketch while following this philosophy.
(no subject) (by ruevs)
And one more without using an angle constraint.
(no subject) (by Andrew)
The eq-pt-line.. makes the distance between the first point and line the same as the second point and line. The actual distance for one of the point line pairs has to be set by some other means, which for the nema sketch it is the difference between the overall size, and distance between the corner chamfers., which because of the symmetries become angled at 45%.
It is worth playing with simple sketches and constraints to get a feel for how they work and how many degrees of freedom each constrains.
It is worth playing with simple sketches and constraints to get a feel for how they work and how many degrees of freedom each constrains.
(no subject) (by Paul)
@Andrew. about that "bug" where equal point-distance can not use the same point for both distance... I'm assuming that's because it won't add the same point twice to its list of selected entities.
Should we add a "Q" constraint when 2 lines and a point are selected, to do what you suggest? This is all very familiar to me and @ruevs because we merged the variadic (multi) constraint stuff recently, so this seems easy. Should we add it?
Should we add a "Q" constraint when 2 lines and a point are selected, to do what you suggest? This is all very familiar to me and @ruevs because we merged the variadic (multi) constraint stuff recently, so this seems easy. Should we add it?
(no subject) (by Andrew)
Currently, selecting two points and a line has the expected effect of setting an eq-pt-line-distance, making the points the same orthogonal distance from the common line. With two line and a point Q sets eq-length-and-pt-in-distance where I would expect the point to be centered between the two lines. similarly a point and two line sets the same constraint, where I would expect the point to be constrained lie on the line that splits the angle between the two chosen lines, i.r. the 45% line for the corner of a rectangle.
hat said, I am not sure how you would set the constraint currently set, but I cannot see it being a common use case, where centering, and placing a feature the same distance from two edges are common requirement. For multiple features, it is possible to use a cycle point and line par to chive the equal offset from edge condition, as I have done is the second upload of Nema .slvs.
hat said, I am not sure how you would set the constraint currently set, but I cannot see it being a common use case, where centering, and placing a feature the same distance from two edges are common requirement. For multiple features, it is possible to use a cycle point and line par to chive the equal offset from edge condition, as I have done is the second upload of Nema .slvs.
(no subject) (by Paul)
Should we change the existing pt-line-line Q constraint to use the D key?
It sets the pt-line distance equal to the length of the first selected line, which is kind of like a distance constraint. It's also like equality, but between rather different things. Moving this odd one to D would allow Q to be used to set equal pt-line distance with one point and 3 lines.
Then we could also allow point and 3 lines selected with Q to make the distance from the point to all 3 lines the same. There is an obvious extension to point-plane distance where we currently only have a distance but not equality constraint.
It sets the pt-line distance equal to the length of the first selected line, which is kind of like a distance constraint. It's also like equality, but between rather different things. Moving this odd one to D would allow Q to be used to set equal pt-line distance with one point and 3 lines.
Then we could also allow point and 3 lines selected with Q to make the distance from the point to all 3 lines the same. There is an obvious extension to point-plane distance where we currently only have a distance but not equality constraint.
(no subject) (by Andrew)
That seems to make sense. Also, allow the common entity to be selected twice as currently happens with the second selection ignored, as the redundant selection is more natural, in that it is set this distance equal to that distance. Also consider using D ro set the distance between 2 points to the length of the line when 2 points an a line are selected.
The three lines and a point would be a bit of an outlier, and the same result can be obtained by using two lines and a point twice, and avoids expansion to 4, 5 etc. lines. That is Q set two lengths/distances to be the same, although extending it to sets of lines (a set of arcs to create a n-agon) or sets of points would be useful (equal spaced features like louvers, or the teeth of a comb).. The multi select should give an error if both points and lines are mixed in the selection, or ignore the points and only act on the line.
The three lines and a point would be a bit of an outlier, and the same result can be obtained by using two lines and a point twice, and avoids expansion to 4, 5 etc. lines. That is Q set two lengths/distances to be the same, although extending it to sets of lines (a set of arcs to create a n-agon) or sets of points would be useful (equal spaced features like louvers, or the teeth of a comb).. The multi select should give an error if both points and lines are mixed in the selection, or ignore the points and only act on the line.
(no subject) (by ruevs)
> That is Q set two lengths/distances to be the same, although extending it
> to sets of lines (a set of arcs to create a n-agon) or sets of points would be
> useful (equal spaced features like louvers, or the teeth of a comb)..
@Andrew this is already done in master. See here:
https://github.com/solvespace/.../CHANGELOG.md#3x---development
You can try with the edge builds:
https://github.com/solvespace/solvespace#via-automated-edge-builds
Or with my latest unofficial XP version:
https://github.com/ruevs/solvespace/releases
This turned into a rather interesting discussion. I need to sit down and play with the various options to get a "feeling" for how they work; and also check if all of them just create multiple existing constraints "behind the scenes" or would they introduce new ones.
As Paul said, he and I recently dug into those parts of the code. Even though they are fairly easy to understand and to change, they are quite... verbose... and it is easy to introduce regressions/bugs.
I have some ideas of how to totally refacor the code which should make it much easier to maintain and improve... but no time.
Here are some links for the curious, and for cross-reference:
https://github.com/solvespace/...l/1258#issuecomment-1181069394
https://github.com/solvespace/solvespace/pull/1348
https://github.com/solvespace/solvespace/pull/1327
https://github.com/solvespace/solvespace/issues/1325
https://github.com/solvespace/solvespace/pull/1322
https://github.com/solvespace/solvespace/pull/1318
https://github.com/solvespace/solvespace/pull/1317
https://github.com/solvespace/solvespace/pull/1314 - this it the original implementation that started the "avalanche" above :-)
> to sets of lines (a set of arcs to create a n-agon) or sets of points would be
> useful (equal spaced features like louvers, or the teeth of a comb)..
@Andrew this is already done in master. See here:
https://github.com/solvespace/.../CHANGELOG.md#3x---development
You can try with the edge builds:
https://github.com/solvespace/solvespace#via-automated-edge-builds
Or with my latest unofficial XP version:
https://github.com/ruevs/solvespace/releases
This turned into a rather interesting discussion. I need to sit down and play with the various options to get a "feeling" for how they work; and also check if all of them just create multiple existing constraints "behind the scenes" or would they introduce new ones.
As Paul said, he and I recently dug into those parts of the code. Even though they are fairly easy to understand and to change, they are quite... verbose... and it is easy to introduce regressions/bugs.
I have some ideas of how to totally refacor the code which should make it much easier to maintain and improve... but no time.
Here are some links for the curious, and for cross-reference:
https://github.com/solvespace/...l/1258#issuecomment-1181069394
https://github.com/solvespace/solvespace/pull/1348
https://github.com/solvespace/solvespace/pull/1327
https://github.com/solvespace/solvespace/issues/1325
https://github.com/solvespace/solvespace/pull/1322
https://github.com/solvespace/solvespace/pull/1318
https://github.com/solvespace/solvespace/pull/1317
https://github.com/solvespace/solvespace/pull/1314 - this it the original implementation that started the "avalanche" above :-)
(no subject) (by Andrew)
>check if all of them just create multiple existing constraints "behind the scenes" or would they introduce new ones.
I would suggest multiple instances, visible in the properties dialog, as that would make it easier to correct for 'mistakes', such as selection box including one or two two many
entities. For the same reason, Also, because of box selects, the selection set will need filtering for equality constraints , by ignoring points in mixed sets.
I would suggest multiple instances, visible in the properties dialog, as that would make it easier to correct for 'mistakes', such as selection box including one or two two many
entities. For the same reason, Also, because of box selects, the selection set will need filtering for equality constraints , by ignoring points in mixed sets.
Post a reply to this comment: