4.2 Surprises

[firehaus]

Hi All,
We downloaded 4.2 last week and have been running test when time permits. We've noticed a few surprises and wondered is anyone else is encountering the same problems.
First, when measuring a stud with a surface sample, there is a move before the first sample hit of 100-200 mm. This condition does not happen on every stud, but enough to keep you awake. Second, the starting and ending angles on studs have randomly changed as well forcing you to partially re program your part. Haven't notice this on any holes, just studs. Third, when measuring certain round slots, PcDmis will cough up an error that states it "cannot create best fit for this feature", yet when using F9 on the feature and re measuring, all is fine.
The programs we normally run take approx one hour to run, so needlessly to say, we do not have time to reprogram a boat load of features just to upgrade to 4.2. For now, we are sticking with 3.7mr3 until there is a MR or new version released.
We are running a Dea Vento with a Dea controller, P4 with 1gb of ram, XPsp2 pro.
Maybe 4.2 will give different results depending on the type of controller.

[JamesMannes]

I have not encountered that particular "enhancement". Is this a program that was already written? Or new?

[firehaus]

These are pre established programs. We ran 3.7, did not take the part off the fixture, then immediatley ran 4.2.

[JamesMannes]

Does it happen with the same stud consistently? Can you email the program? Jot a quick note about which one (s) it would do it on if consistent.
[email protected]

[firehaus]

Jim,
It appears that once you make the corrections to the feature, it will probably be alright. Our issue is that our programs measure over at least 200 features per program.....and that is just the few we use on a regular basis. If we had to update every program we use, we would spend more time re programming then operating.

[JamesMannes]

Jim,
It appears that once you make the corrections to the feature, it will probably be alright. Our issue is that our programs measure over at least 200 features per program.....and that is just the few we use on a regular basis. If we had to update every program we use, we would spend more time re programming then operating.

Just to be nosey what are you doing to the feature to correct it?

[Don Ruggieri]

Corrections?

Jim,
It appears that once you make the corrections to the feature, it will probably be alright. Our issue is that our programs measure over at least 200 features per program.....and that is just the few we use on a regular basis. If we had to update every program we use, we would spend more time re programming then operating.

I must have messed up my first post. . .

What kind of corrections? As Jim asks, can we see the program? or a sample section of it?

[inspector212]

I have also noticed that previously written programs get "changed" when brought into V4.2. Example. Vector points get "Snap" checked and this normally shouldn't be a problem cosidering what the description for Snap is in the help section, but we get really weird numbers with this checked. We never use this feature normally. Is this a bug? Now every program brought into 4.2 will have to have every vector point checked to make sure. The program was written in V4.1.

[JamesMannes]

I have also noticed that previously written programs get "changed" when brought into V4.2. Example. Vector points get "Snap" checked and this normally shouldn't be a problem cosidering what the description for Snap is in the help section, but we get really weird numbers with this checked. We never use this feature normally. Is this a bug? Now every program brought into 4.2 will have to have every vector point checked to make sure. The program was written in V4.1.

I have seen what you are talking about as far as the strange values are concerned for snap point. I believe it is doing some probe comp black magic. Don't have an explanation of this yet. What I have been doing is checking to make sure programs don't use snap points via the find/replace function in DMIS. Alright guys, start feasting on my carcass, I/inspector212 found a bug.

[Wes Cisco]

I have seen what you are talking about as far as the strange values are concerned for snap point. I believe it is doing some probe comp black magic. Don't have an explanation of this yet. What I have been doing is checking to make sure programs don't use snap points via the find/replace function in DMIS. Alright guys, start feasting on my carcass, I/inspector212 found a bug.

Any one of you so much as move a finger to feast on Rusty's Carcass and I'll . . . every last _____________ of you !!! Unless of course you want to volunteer to be the next coal mine canary.

It was inevitable James, but you will always be Ironman in my book!

SCHLURP!

[craiger_ny]

I've heard about what happens to carcasses in Wisconsin. Not pretty, not pretty at all................

[Cumofo]

http://www.geocities.com/cumofogabriel/Richard.jpgWe shall never have equal rights until we take them, nor respect until we command it.





I still respect you Craiger...

[Glenn.Russell]

I have also noticed that previously written programs get "changed" when brought into V4.2. Example. Vector points get "Snap" checked and this normally shouldn't be a problem cosidering what the description for Snap is in the help section, but we get really weird numbers with this checked. We never use this feature normally. Is this a bug? Now every program brought into 4.2 will have to have every vector point checked to make sure. The program was written in V4.1.

Hi Inspector212 & James -
I wrote a program in 4.1 which has a simple alignment, and then a AutoVectorPoint with Snap turned off. When I bring the program into V42, snap is still turned off. There were a couple known issues with Snap that were fixed just prior to the release of 4.2. Are there any other details that you can provide? Thanks, -Glenn

[JamesMannes]

Glenn, I originally had a problem with snap point during iterative alignments. I believe you saw that email?

Yesterday or the day before I had a problem with a program written in 3.7(don't know which mr), that had some Auto-Vector snap points checked "yes". Upon execution of this program the points taken in the +Z direction(-Z vector) were comping in the wrong direction.

This program had no CAD and I believe the Auto-Vector points were created via a "to points" choice when I opened a Linear Closed scan. I can't be positive of this as it was a few years/brain cells ago. I'll see if I can retrieve the program in question from my backups, run it, and send the program for you to look at?

[Glenn.Russell]

Hi James-
If you could provide an example program which works in 3.7, but not in 4.2, that would be great. I'll PM you my email address to make sure you still have it. If the Snap value (On/Off) is consistent across the versions (3.7 to 4.2), then it's possible that the problem lies elsewhere. Thanks as always, -Glenn