Name X

Can you post a screen shot of what it looks like at the lower frequency and %?

If all you changing is those 2 parameters then I would suspect that the scanning hardware and software combination is unable to process the higher scan rate data while still getting regular arm position updates.

It might also be interesting to see what the processor(s) usage is like at the two different scan settings by watching it in the Task Manager

From my experience not many Polyworks functions are multithreaded. Unfortunately the one you are trying to use , reduce overlap is slow and not multi-threaded  :( The ones that are multi-threaded off the top of my head are: Aligning in IMAlign, IMMerge and IMCompress in Huge mode. Hopefully reduce overlap and file import are on the short list for multi-threading.

I would be interested in hearing what other users find as slow operations in PW besides the above.

I like the V11 layout. Generally easier to navigate, once you get used to it. We've been having issues with units now that they are introduced in Align, Merge and workspace manager, but hopefully the first patch will fix that.

If the scanner is small enough and you can travel with it then you can take your chances on calling it a camera (for personal use) and I haven't been stopped before. If you're shipping it or it's not going to be easily passed off as a camera then I would go the official (and legally correct) route of getting a Carnet, which is a ?Merchandise Passport? for temporary import. A bit of a pain the first time, but once you've done it once it's not too bad.

For Carnet info see: http://www.uscib.org/index.asp?documentID=1843

Regardless of how you ship it I would stay away from terms like scanner and laser as they are often affected by import, radiation and other controls and we've had a few customers have systems tied up for weeks while the customs officials ask for paperwork.

Come to think of it the Brazilian Customs has had a brand new laser scanner in it's possession for the last 3 years that was shipped with the wrong paperwork. The cost of duties on it was more than a new system so it got left with them. So it is definitely worth being a careful to make the correct choices up front.

I think it's worth noting that block size is the size of the bucket that is used to process each specific merge job iteration and is not specifically related to the amount of ram or number of processors you have. Although you will hit the wall by running out if memory if you don't adhere somewhat to the suggested calculation above, give or take a factor of 2 or 3 :-) The size of the required block size varies hugely depending on the type and density of data, the amount of overlap and the number of iterations used. Hopefully one of these days it will be calculated automatically by immerge