Possible bug?

[farmertom]

Hi,
I noticed this the other day and it happen to me again. Using Aspire 8. I have a shape to be cut with a 2D profile tool-path. I have placed tabs on the shape to keep it in the sheet while cutting. I decided that some of the internal corners need a T-bone fillet. After I apply the fillets my tabs have moved.
I reproduced the bug to make the picture. Kind of a pain to have to redo the tabs after you spend a lot of time trying to get them in the right spot. But I still love the software.

[TReischl]

I would not call it a bug. Adding dog bones changes the geometry. How tabs are referenced in software has never been an easy thing.

I cannot speak for Vectric, obviously, since I do not write their software. But back in the day, a cutting path is an ordered list. Each line, arc has a reference or index assigned to it. Then things like tabs are assigned to a piece of geometry in that list. For instance, the first tab goes on geometry item number 12 in the list. When you change that list by adding or subtracting geometry, that reference points to a different piece of geometry.

At first glance it would seem easy to somehow keep that reference updated, but unfortunately it is not. What I did was actually remove all tabs if that list was changed. That did not make anyone happy either. I spent 25 years working on my software on a continuous basis. That problem was never solved. When I say continuous, I mean every working day, it was what I did for a career.

BTW, I am not running V8, and mine does it too.

Another thought about this: Geometry is usually all adjusted before toolpathing which includes tabs. That is the normal flow.

[IslaWW]

Wouldn't one normally add the dogbones prior to the toolpath operations? I would consider your case of adding tabs after tabs an unusual case of getting processes slightly out of order. Unless I am missing something, that is.

[Ms Wolffie]

I fail to see why it is a pain to manually move a few tabs.
However, in the first pic you have 5 tabs an in the second you only have 3 so something must have been change in the tab setup.

[farmertom]

I fail to see why it is a pain to manually move a few tabs.
However, in the first pic you have 5 tabs an in the second you only have 3 so something must have been change in the tab setup.

Really! the sample was just to show the problem. If you had a 4 x 8 foot sheet of shapes to "re-tab" you would complain too. I did nothing to the tabs between the two shapes.

[farmertom]

Wouldn't one normally add the dogbones prior to the toolpath operations? I would consider your case of adding tabs after tabs an unusual case of getting processes slightly out of order. Unless I am missing something, that is.

What! It should not make any difference the order you perform the operations. One you set a tab it should stay!

[farmertom]

I would not call it a bug. Adding dog bones changes the geometry. How tabs are referenced in software has never been an easy thing.

I cannot speak for Vectric, obviously, since I do not write their software. But back in the day, a cutting path is an ordered list. Each line, arc has a reference or index assigned to it. Then things like tabs are assigned to a piece of geometry in that list. For instance, the first tab goes on geometry item number 12 in the list. When you change that list by adding or subtracting geometry, that reference points to a different piece of geometry.

At first glance it would seem easy to somehow keep that reference updated, but unfortunately it is not. What I did was actually remove all tabs if that list was changed. That did not make anyone happy either. I spent 25 years working on my software on a continuous basis. That problem was never solved. When I say continuous, I mean every working day, it was what I did for a career.

BTW, I am not running V8, and mine does it too.

Another thought about this: Geometry is usually all adjusted before toolpathing which includes tabs. That is the normal flow.

I am sure with all of the smart people at Vectric they can fix the problem? If you are building prototypes and make slight changes to geometry, fixing moved tabs can be a pain. Unless the geometry where the tab is placed has changed the tab should not move. In object oriented programming the tabs should be separated for the geometry.

[Adrian]

I am sure with all of the smart people at Vectric they can fix the problem? If you are building prototypes and make slight changes to geometry, fixing moved tabs can be a pain. Unless the geometry where the tab is placed has changed the tab should not move. In object oriented programming the tabs should be separated for the geometry.

So how would you do it? If you put a tab 10cm along a vector that position would be stored. You then put a couple of dog bone fillets in before that tab which means the effective length of the vector has now changed. Should the tab be at the same distance it was before or at the same percentage distance? With either approach someone is going to complain that it's not correct.

[Ms Wolffie]

I fail to see why it is a pain to manually move a few tabs.
However, in the first pic you have 5 tabs an in the second you only have 3 so something must have been change in the tab setup.

Really! the sample was just to show the problem. If you had a 4 x 8 foot sheet of shapes to "re-tab" you would complain too. I did nothing to the tabs between the two shapes.

Oh my oh my.
You seem to be a very angry aggressive person, take some deep breaths.

I do not really understand, do you dogbone every single piece manually?
I guess not.
Obviously you didn't tell the program how many tabs you wanted.
If you shift the tabs the same way you make the dogbones, you only need to do it once and they will all be fixed.

[scottp55]

F,
You probably already know this, But.... If you Proto ONE and then toolpath it exactly( Including tabs!), then when you linear array/nest... the tabs are automatically copied!
Rather than Dogbone all and tab all, just make 1 all the way and THEN multiply them?
scott

[CYS-ARTISANS]

Well is an unwanted behavior. I had the same issue in Aspire 4.5. So is still there in version 8.

[farmertom]

I am sure with all of the smart people at Vectric they can fix the problem? If you are building prototypes and make slight changes to geometry, fixing moved tabs can be a pain. Unless the geometry where the tab is placed has changed the tab should not move. In object oriented programming the tabs should be separated for the geometry.

So how would you do it? If you put a tab 10cm along a vector that position would be stored. You then put a couple of dog bone fillets in before that tab which means the effective length of the vector has now changed. Should the tab be at the same distance it was before or at the same percentage distance? With either approach someone is going to complain that it's not correct.

Well, IMHO the tabs should have a xy location and associated with a geometry. Changing the geometry should not change the location of the tab. When the toolpath is calculated the tabs inserts itself into the final solution. At that time it could check to see if geometry exist at that location, if not a warning is thrown to alert the user that the tab will be omitted. We get other errors during toolpath calculation. Maybe there are three choices or tabs. Constant distance, constant percent distance, and fixed. All selectable the "Add tabs" dialogue. Thanks for listening

[farmertom]

F,
You probably already know this, But.... If you Proto ONE and then toolpath it exactly( Including tabs!), then when you linear array/nest... the tabs are automatically copied!
Rather than Dogbone all and tab all, just make 1 all the way and THEN multiply them?
scott

Yes, but all of my parts are unique. No Array copies here.

[farmertom]

Well is an unwanted behavior. I had the same issue in Aspire 4.5. So is still there in version 8.

Yes, thanks you!

[TReischl]

If one looks closely at Aspire (and VCarve) it becomes apparent that a certain "flow" of work is intended.

The program starts with the left hand window visible. This allows creating and editing of geometry. Adding dog bones falls into this category. Once all the geometry is massaged to the users satisfaction, then the right hand pathing pane is opened. Tabs are not part of geometry so they are not in the left hand pane.

As for object oriented programming solving all issues? Hooey, just plain hooey. It works very nicely in many situations, this is not one of them. Interestingly enough, CAM programming was using "object" techniques long before a propeller head thought he invented the concept. Chained geometry is for all practical purposes an object. When any portion of it is selected the user can assign properties to that chain independent of all other chains in existence at the time. One can also perform operations on that object, such as adding tabs, setting feedrates, etc.

The classic example used in OOP is cars. An object is created that represents a car, then one is instantiated. Properties can be set such as color, size of wheels, etc. A new instance of that car can be created then properties modified, this is called inheritance. But, if one were running a car simulation, one of the tasks the user would have to enter would be to put gas in the car, turn the key or push the button to start it, and guide it down a road, stop when a red light appears, ad nauseam. If the user did not put gas in the car, then the rest of the program could be considered "buggy" by some because it did not do things the way THEY think they should work.

Frankly, I am impressed by the lack of "bugs" in Vectric software. I am also astounded by the number of users who want to believe there must be a bug when they have not figured out how to put gas in the car or turn the key BEFORE driving down the road.