It would be great, if we have the possibility to do the “pallet Run” with Inspect – like Operator Interface. 

Just enter the number of the parts and their offset and let’s go.

If a part does not exist, just uncheck it.

Some programs may have support files like pcdmis forms, basic scripts, bitmaps, external commands, etc.  Very often, the best way to manage a program is to create a folder for it and then allow the program to reside within that folder with all its supporting files in same location.

This is because it is often impractical to have many programs in folders with all their support files intermix.

It would be nice to be able to specify whether to treat a folder as a program container that can be selected for execution.  (On main Measurement routine screen).  Bitmap association to it.

The rule would have to be that a folder name must be identical to the program name.

I know this is a complicated request.  This is how one of our customers that has 50+ CMMs has his custom interface (developed by us Hexagon) configured.

Location of programs is remote (network).

Executing measurement routine is actually a local copy of the folder and its contents.

It's a bit irritating that INSPECT always closes PC-DMIS when closing, even when PC-DMIS was already started before INSPECT.

This may not be a real problem for end users, only for those that run a lot of tests of different things...

At the moment, INSPECT is not very useful for Vision machines, as without seeing the camera view, then the manual alignment features are impossible to position.

In inspect 5.1 we have been given the opportunity to schedule a calibration or Swift check. could it be possible to extend the "schedule" function so it becomes possible to schedule a specific program to run every  hour, day, week or year.

see example:

In Inspect, the serial numbers (or other trace) can be entered in the pallet screen prior to measurement.

It would be useful to have an option where the serial number for each cell could be scanned in using barcode, to make this process more efficient and less error prone

Filed on behalf of a customer.

Inspect users with multiple CMM's - and who want to have the same settings (playlists, tracefields et cetera) on all the stations - are storing these settings locally on every station. This is time consuming every time they update the playlist and tracefields. Users need to update every station in this case and they loose a lot of time and make possibly erros. 

It would be nice if Inspect users can store these settings on the network drive, so that you can change the playlists and tracefields from your offline station and then all your other Inspect stations are up-to-date. 

When you have the barcode option linked to a COM port, then it always checks if there is an input from the barcode reader. Even if you're not in the input field for Inspect. With the link to a COM port, you are always sure that the routine starts. 

Currently there is a hardware keyboard wege and sends the input from the barcode reader to the keyboard. It would be nicer if there is a software keyboard wedge. A software keyboard wege connects directly to the COM port and not the keyboard. Data from the barcode scanner is sent to the COM port and is rerouted to the keyboard buffer. This way you're sure that Inspect is always reading the input from the barcode scanner even if you're in another input field. 

Add possibly two modes of error handling whenever a cell part is not fixtured correctly.

1. Advance to next cell and keep all index/counter trace fields sequenced correctly to cell.  This would be best for operator environments.

Allow only the  bad cells to then be rerun after correction maintaining trace field sequence as noted.

As they can currently select cells for execution, the trace field sequence is the the important piece.

Also, if they are running successive fixtures, allow for control of Index/counter trace inputs, stop start or override with specific cell value.

2. Create or use existing notification tools to text programmer, or set stack/message light status to raise awareness.

Allow programmer to reset poorly fixtured part and resume execution from that cell maintaining trace sequence as previously stated.

This appears to be similar to one Lupe added previously.

In lieu of a multi-fixture sequential execution, provide  a means of controlling count and/or prompting for next fixture load.  Also, it would be important for index/counter trace fields to be sequence with fixture/cell.