AI Assistant
Notifications
Clear all

TopSurv 8.2 Quirk in line-line-corner offset routine

9 Posts
4 Users
0 Reactions
1,203 Views
stephen-ward
(@stephen-ward)
Posts: 2244
Member
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

I don't use this routine often, and yesterday is likely the first time I've used it since upgrading to TopSurv 8.2. I shot 15 building corners in consecutive order using non-prism mode. When I looked at the data in LDD this morning I realized that I had three points at most corners with identical elevations and slightly different horizontal positions. Took a while to decipher what had happened.

The line-line-corner routine works correctly for the first shot. Shoot line1, shoot line2, turn angle to corner, DC stores a single point. Apparently the DC does not clear the data from the previous corner. So, if you shoot addition corners, it will store a point each time you take reading with whatever data it has. This results in three points per corner with the first two of each set of three being bad because they are the result of data shot for two different corners.

I sent an explanation of the issue to my dealer along with a data file to forward to Topcon.


 
Posted : December 21, 2011 6:44 pm
TC
 TC
(@tc)
Posts: 68
Member
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Stephen,

I don't have an answer to your issue, but 8.2.1 has been posted on Topcon University. However, there are no release notes, but maybe that's a bug that's been corrected with that release.


 
Posted : December 21, 2011 7:39 pm
stephen-ward
(@stephen-ward)
Posts: 2244
Member
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Thanks TC, I'll check it out.

I really just wanted to put the info out there so someone else doesn't have to spend a morning trying to figure out why they have triple points seemingly scattered in random locations.:-(


 
Posted : December 21, 2011 7:52 pm
toivo1037
(@toivo1037)
Posts: 788
Member
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Is vertical O/S doing the same thing? Storing 2 points, instead of just the one?


 
Posted : December 21, 2011 8:30 pm
stephen-ward
(@stephen-ward)
Posts: 2244
Member
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

I don't know. I don't think I've used the vertical offset routine since I loaded 8.2 in October. I will likely load 8.2.1 and run it through a few tests over the weekend to see what changes they've made.


 
Posted : December 21, 2011 8:49 pm

djames
(@djames)
Posts: 850
Member
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

Hey watch out posting bugs on Topcon University they will ban you from the site . I have had multiple post sensored by Topcon. i was told that it was not a place to post bugs .


 
Posted : December 22, 2011 3:05 pm
stephen-ward
(@stephen-ward)
Posts: 2244
Member
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

I posted several bugs/issues back in the spring and early summer. Mostly they just ignored my posts. I got fed up with the lack of response from Topcon University and sent the following write-up to Topcon Support through my Topcon dealer. My write-up is in blue, the dealers comments are in green, and Topcon's responses are in red.

Hi Support,

This client is running a Topcon Robot 9000 series with RC3 and FC2500 Topsurv Ver 8.1.

Please see attached file with .tsj and here is statement of some problems he is having. I know 8.2 is close and maybe some of this may be resovled but these are really important to the surveyors.

This is to document a few issues I've been having with my FC-2500 running TopSurv 8.1.
For a typical job I start by calculating everything in Land Development 2000 and exporting a txt file containing the coordinates. Then I create a new job in TopSurv on the DC and import the txt file. In the field I set two control points, occupy one with assumed coordinates and back-sight and store the other with an AZ of 0deg. Of course TopSurv updates my back-sight from AZ to the new point number once it is stored. Then I shoot the existing monuments or control and translate and rotate the shot points into the calculated points from the office. This is where the problems begin:

Problem #1) Translating the attached file, which contains 120 points, takes an average of 1 minute on my FC-2500. My Huskey FS2 running TDS v2.2 with a fraction of the RAM and processor speed, translates the same file in an average of 10 seconds.

Answer: Unfortunately this is just a difference in the way the software re-calibrates the coordinates.

Problem #2) After rotating a group of points that contains the current occupied and back-sight points, TopSurv fails to update the AZ between the occupied and back-sight points. This results in any points located or staked after the rotation being located the correct horizontal and vertical distance from the occupied point, but being out of rotation by the difference between the previous and the current AZ between the OCC and BS points. The current work around is to open the Backsight screen before proceeding to the Survey or Stake menus. It is not necessary to actually re-backsight, just opening the screen does the trick.

In my opinion TopSurv should update the AZ automatically as long as I'm occupying the same point #'s, but at the very least the software should give a warning before allowing you to proceed that the back-sight solution needs attention.

Answer: This is a survey fundamental issue. Anytime you change anything with your setup (HI, HR, etc.) you should always do another backsight. Topsurv only knows the current backsigh setup and the angles that were turned based off the encoder and the distance measured from the edm.

Problem #3) The raw data does not contain data indicating translates, rotates, or clear info indicating if a point has been overwritten or renumbered. Currently it is unsafe to edit the raw data to change a busted HI or HR because when TopSurv recomputes the coordinates it does not account for translates and rotates. With good field notes this is a pain, with no notes or an inexperienced operator this can be a disaster. The raw data should clearly record any operation that modifies settings mid-job or that modifies coordinates in any way, anything less invites trouble.

Answer: Topsurv isn't programmed to write any (cogo) functionality into the raw data such as inverse, translate, etc.

Problem #4) When in the Point Staking screen, if I try to use the Topcon Icon in the upper left corner to access the inverse screen I get the following error "Could not load module tpsCogo.dll"

Answer: It appears that Topsurv could have gotten a bug so I would recommend reloading Topsurv 8.1 onto the FC-2500.


 
Posted : December 22, 2011 4:03 pm
djames
(@djames)
Posts: 850
Member
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

I get # 4 all the time on the FC2500 .


 
Posted : December 22, 2011 5:24 pm
stephen-ward
(@stephen-ward)
Posts: 2244
Member
Topic starter
Translate
English
Spanish
French
German
Italian
Portuguese
Russian
Chinese
Japanese
Korean
Arabic
Hindi
Dutch
Polish
Turkish
Vietnamese
Thai
Swedish
Danish
Finnish
Norwegian
Czech
Hungarian
Romanian
Greek
Hebrew
Indonesian
Malay
Ukrainian
Bulgarian
Croatian
Slovak
Slovenian
Serbian
Lithuanian
Latvian
Estonian
 

I loaded 8.2.1 on Friday and ran a couple of quick checks on a job site. Version 8.2.1 of TopSurv does still store 3pts per corner for all corners except the first in the line-line-corner routine. The same is true for the vertical offset routine, except it stores 2pts per corner after the first. I didn't have time to check all of the other routines, so to all who use the offset routines in TopSurv be careful and keep good field notes.

Edit: testing was completed using GPT-9003, RC3, FC-2500 w/TopSurv 8.2.1 in prismless mode.


 
Posted : December 25, 2011 10:50 pm