Something unexpected happens to me, the _Diameter command starts but it has nothing to do with the _Circle command option, in practice both the first option after clicking the point of the _Circle command and the separate command have the same nomenclature. . .
_Circle
_Pause
_Diameter
_Enter
20
It’s true that I avoided the problem with this other macro, but would it be a suitable solution if the options in the commands didn’t have the same names as the actual commands?
or maybe there is a way/method that allows you to change option like this: (_Diameter/_Radius)
There is a separate command for circle diameter, you can find in the circle toolbox. This allows you to set where you want the second point to be located and or the rotation of the circle, whereas in your second macro you only locate the center of the circle. Don’t know if that matters.
Try this macro and you will see the difference.
! _Circle
_Diameter
pause
20
What is happening was that Rhino thinks you want to measure a diameter in that first macro below is from my V7 command history. So by adding the enter you force Rhino into knowing you want to draw the circle by diameter. Or somethings screwy either way you do have the option of using both your method for auto diameter circles and the macro I posted for orientating the diameter circle.
Command: _Circle
Center of circle ( Deformable Vertical 2Point 3Point Tangent AroundCurve FitPoints ): _Pause
Center of circle ( Deformable Vertical 2Point 3Point Tangent AroundCurve FitPoints )
Diameter <16’7-1/4"> ( Radius Orientation Circumference Area ProjectOsnap=Yes ): _Diameter
Select point on curve for diameter measurement. Press Enter when done ( Units=Model_Units SelectCurve MarkDiameter=No ): 20
Unknown command: 20
if Radial is chosen in the _Circle command then the problem does not arise since when sending the _Diameter command there is actually a choice option within the command, but if _Diameter is already set as an option and therefore in the “possible” options of the _Circle command you do not find the _Diameter option but _Radius at this point when you send the _Diameter command not finding it in the _Circle options it goes to look for it as a separate command that exists with the same name therefore: _Diameter as an option in the _Circle command and _Diameter as the actual command and not as an option of another command. I know it’s a bit of a mess but I hope the concept is clear, in conclusion I don’t think it’s a good thing to have command and command options with the same name. . .
I think that’s a small bug, good catch. Rhino shouldn’t activate the diameter measure command as you point out above when you go back to the radius option. Luckily at this point you can get around it. Lets hope McNeel will fix it. What version of Rhino are you using they might ask you for your system info, I’m on V7.
Rhino has a circle by diameter icon which works slightly differently as I pointed out in the supplied macro. I don’t know if McNeel was thinking most people would use either circle by radius or circle by diameter as the two icons work differently and then let this bug creep in.
I have a Rhino Python script that will work for this but will require a bit of setting up (and testing I guess). Let me know if you’re interested. You’ll be able to setup a custom command for any given diameter.
Thanks for the replies, mine was first of all a question about a situation that has happened lately but which concerns macros in a “generic” way since I have also encountered this in the past on other commands that switch between two options. in my case with _Diameter the command starts and not option and indicating _Enter as the next operation makes me move forward with the macro without problems or I also tried with _Diam or just _D and in this way the problem is circumvented since if Radius is selected the Diameter option appears and therefore the indicated commands fall within the possible ones, while if Diameter is already indicated, _Diam or _D are seen as unknown commands/options and therefore ignored, but as mentioned, it’s a way to get around this obstacle, but using the same system with another command to switch between two options doesn’t mean this will work. Perhaps a solution could be to remain fixed in only one of the two settings, so by creating a macro, you’re I’m sure which commands to enter to change, but that way I’d have to do it with all the commands and would lose the mamorization of the last selected options, and in some cases I wouldn’t be very happy. It’s a big dilemma: it’s better not to be in the shoes of MCNeel developers with the infinite requests/needs of all users:) perhaps if in the cases of swiping for two options you could display in this case a label like “Rad/Diam Swich” instead of sometimes finding me Diameter or Radius or who knows “I gamble” indicate index of the options menu in this case “0 zero” and be able to recover the stored value if Radius or Diameter and therefore at least in a script be able to manage any possibilities But maybe if it had been possible, the developers would have already done it. After all this, I wouldn’t be surprised by an answer like this: the solution is simple, just learn more advanced programming languages so you can customize all the commands as you see fit! and this is also true
That’s exactly what I was thinking. I think it’s the best and most stable solution. Plus, for those who’ve already created macros, one of the conveniences is being able to easily change them.
