ARRAY QUESTION

[Anonymous]

Would someone please explain why I have to explode a circular array of 72 objects BEFORE I can subtract it from another solid.  I am trying to create a tread on a tire and it seems that I have to explode the 72 object array and then subtract them in small groups.  That does not seem to me to be a very good thing.

Thanks

Bob Price

AutoCAD 2013 SP3 on a Lenovo S-30 workstation running Windows 7 SP2

[Alfred.NESWADBA]

Hi,

>> why I have to explode a circular array of 72 objects BEFORE I can subtract it from another solid

Because only SOLID-objects can be subtracted from a SOLID.

The result of the (current) _ARRAY command is not a solid, it is of type "Array".

- alfred -

[Anonymous]

You could duplicate your array so as to use the unexploded one in your final drawing.

[Anonymous]

But the objects in the array are solids.  The profile was extruded and then made into an array.  And proof of that is that if I explode the array I can subtract the individual objects from the solid tire. 

So the answer really is that someone at AutoDesk didn't think that solid arrays should be treated as ordinary solids.  Does anyone know if this silly oversight has been fixed in a later version of AutoCAD?

Thanks for the repsonse.

Bob Price

[Anonymous · Accepted solution]

Sure the array is made of Solids, but you would have the same problem if you try to create a union between a Solid and a block made of Solids. A block made of Solids is a Block, not a Solid, and that is not as silly as it looks. 

[Anonymous]

Well the next time that I get assigned to be God for a week, I will fix this probelem.

Thanks for the repsoonses.

Bob Price

[Alfred.NESWADBA]

Hi,

>> But the objects in the array are solids

Correct, the objects IN the array are solids.

It's like a block containing SOLID-objects, also a block can't be used to be subtracted from a SOLID even this block has SOLID-objects IN it.

And internally the result of an array is handled like a block, try the lisp statement

(entget (car (entsel)))

...and you'll see that this is internally a block-insertion (blockreference)

That's shown then:

((-1 . <Entity name: 7ff763805e00>) (0 . "INSERT") (5 . "1228") .....

>> Does anyone know if this silly oversight has been fixed in a later version of AutoCAD?

You call it silly, I would say that could result in a lot of issues (and up to 2016 as current release there is no change)

Let's say you have a block containing 1 solid, 1 hatch and some regions from which the solid was created.

You then create an array from that block

    (I'm sure you know that the subtract command work on SOLID objects, but also on REGION objects)

So you now start command _SUBTRACT. AutoCAD will then first have to check each position/scale/rotation of each of the arrayed block-insertions, the contents of each block-insertion and as the result (command _SUBTRACT using an array) it has to subtract the SOLID-objects from a SOLID and the REGION objects from a REGION ... or what should now be really subtracted. (besides of some problems with block-insertions that were not inserted unified (X-Scale = Y-Scale = Z-Scale).

Also check the layer situation/material config ... should the subtracted SOLID from within the block use the block's color/material or the SOLID-color/material from within the block

One step more: Also don't forget that the array could be on layer A, the block used for the array layer B, the solid within the block on layer C ... which one should now be used?

I would say it's easy to explode it, all is clear then, and continue with the SUBTRACT command.

But if you see this as very important (to avoid a single command call) you have the chance to report this as your wish >>>there<<<.

- alfred -

[Anonymous]

Attached is the finished model.

As for subtracting solids from solids, I have been doing that since Release 10 back when you were not supposed to be able to work in solids in AutoCAD.

None of the parts in the model are Blocks so I do not think that is an issue.  It seems to me that it is intuitive that an array of solids should be subtractable from another solid.  One should not have to explode an array of solids in order to subtract the array from another solid.  It is an oversight in the program.

Cheers

Bob Price

[Alfred.NESWADBA]

Hi,

>> None of the parts in the model are Blocks so I do not think that is an issue

Sorry for my English, seems my explantation was not well.

So again: today's array are resulting in one single object called "Array" and that is handled internally as a block, even if you don't create one (I showed you the LISP statement, which is the proof to that statement).

What I tried to describe was: it is not easy to handle blocks with command _SUBTRACT and I used some constellations which I hoped made the complexity more clear.

Your wish was that the arrayed objects should be handled as in the past (you also can now use command _ARRAYCLASSIC), but the results were not editable. So to change the distance, to change the number of array elements, ... you always had to erase the previous created objects and then you had to create the array from scratch. The current array command can modify the items, distances, ... so that's a big advantage. Only when using the components for boolean operations you have the "disadvantage" to start one extra command _EXPLODE.

- alfred -

[Anonymous]

Your English is just fine Alfred - certaionly infinitly better than my Indo-Aryan.  

But let's agree that I have learned that I MUST explode and array of solids in order to subtract them from another solid.

Again, thanks for your help

Cheers

Bob Price

Automation*Gears*Machinery