RiSCAN Pro 2.4.2 crashes

Discuss all Riegl related products here.
I have made <0 posts
I have made <0 posts
Posts: 6
Joined: Tue Feb 28, 2012 6:27 pm
Full Name: David Railton
Company Details: Met Police CAMB
Company Position Title: Surveyor
Country: UK
Linkedin Profile: Yes

RiSCAN Pro 2.4.2 crashes

Post by dagenhamdave4 » Tue Apr 04, 2017 3:49 pm

Afternoon folks,

I've been using the latest version of RiSCAN Pro (2.4.2) and I'm having a problem with it crashing fairly regularly. My project contains 100 scans or so, and of those I will be cleaning a few scans in one object view when, inexplicably, Pro will hang and then go unresponsive, forcing me to close and reopen it. I may not have had many points selected, or I may have just run a terrain filter on a small area which on previous versions has not been an issue, but after a few edits Pro will just stop.

It seems that once I reopen Pro and try and access the object view again the software will crash again. I'm guessing that one of the scans will be corrupted as a result of the crash, which means that I have to reopen each scan in a 3D view in turn to see which has been affected, reopen Pro as it will inevitably crash at the duff scan, reconvert the corrupted main scan, reapply images and deviation filter and redo all my edits.

I thought this might have been an issue with working with networked data, but it happens if I'm working from data on my local machine. I have recreated the project a couple of times which has required the import, conversion, colourising, matrix import etc for these 100 scans, and still the same problem occurs.

I was wondering if anyone else have this bug with this version, or if there's a fix on the horizon?

Also, on a separate (and relatively small / petty) note, it would appear that if you have exported a camera calibration and then tried to reimport it, you will find that the .cam file is missing. If you change the file type from .cam to .jpg and then back again the .cam file now appears. Nothing like as frustrating as the programme crashing though...

Any help would be gratefully received.


User avatar
Christian Sevcik
I have made 40-50 posts
I have made 40-50 posts
Posts: 47
Joined: Fri Dec 09, 2011 7:47 pm
Full Name: Christian Sevcik
Company Details: RIEGL Laser Measurement Systems GmbH
Company Position Title: Strategic Software Alliances
Country: AT
Linkedin Profile: Yes
Location: Austria

Re: RiSCAN Pro 2.4.2 crashes

Post by Christian Sevcik » Wed Apr 05, 2017 8:10 am


It is hard to tell without seeing the data, so the following is just my personal thought:
RiscanPro checks on opening, saving and closing a project, whether the project.rsp content is synced to the folder content. So I guess the project structure is not corrupted. In case there is an entire file missing the respective entry in project tree is yellow flagged.
Now i assume you haven't come across such a yellow flag in your project. Therefore I somehow share your guess of a corrupted file.
I agree opening all 100+ scans in a seperate view is a bit boring.
Personally i would try to identify suspicious Scanpositions by the file size of the scandata first. Assuming you are running a Windows machine open the File explorer go to the SCANS folder of your project and search for all .rdbx files. Sorting by file size should give you the outliers on top of the list. Be aware, they may mix up with the tiepointscan rdbx files, in case you got tiepoints in the project.
Repeat the search in the project.rdb folder. You can also check for suspicious polydata files when searching for small files with the extension .vtp in the SCANS folder.

You can also search for .lock files from the root folder of your project. When data is written to a rdbx file it is locked to prevent other tasks from acessing it. When the file operation is finished the lock is released and the .lock is deleted. Make sure the project is not opened in RiscanPro when searching.

So i would start checking the data where there are surprisingly small .rdbx or .vtp files or .lock files.

If this doesn't help, I would recommend contacting support, but this might require to send over some data.


Return to “Riegl”