Share:
Notifications
Clear all

FBK and Civil3D database corruption

fretbuzz
(@fretbuzz)
FNG Member

Hi all, We are having a problem and I can't seem to resolve it. Civil3D database corruption occurs after to many FBK imports and I am not finding anything out there to resolve it. to understand what I am about to share, I will explain our procedure.

Our procedure:

  1. Import JOB files from Trimble TCS to PC
  2. Convert JOB files to FBK with Trimble provided "ASCII File Generator" program, found here. I also am using Trimble recommended stylesheet converter found here.
  3. Make any known corrections to FBK coding and such.
  4. Import FBK to Civil3D database
  5. look for errors in drawing
  6. edit any visible errors in FBK and re-import (or delete and re-import)
  7. this process goes on until the FBK comes in with no errors

 

The situation:

ERRORS:

  • PROCESS TOPO:
    • Day one comes in perfect. All codes correct
    • Bring in day two and a big giant "S" Survey Figure connects, as one line, all over the drawing, including points from day one.
    • Check codes in day two FBK. All good
    • Delete all FBK files from DWG
    • Bring in day two alone and everything is perfect
    • Bring in day one and a totally different Survey Figure connects all over the place
    • Both files codes are perfect
    • Combine the two into a single FBK file
    • Process
  • Try a second time with new database and drawing
    • I decided to get screenshots of everything to post here, not wanting to mess up our actual project:
      • I decided to create a new drawing and database.
      • I impost my CSV of adjusted control
      • I bring in the day one FBK
      • I bring in the day two FBK
      • Everything works perfect
    • CONCLUSION:
      • When you process FBK files over and over eliminating the errors in coding, rod heights, etc, it corrupts the database with each process. There must be some way around this.
      • Choice #1: combine all FBK files and process at once
        1. This option can screw your database on a large job from way back as it will inevitably jack up your database should you ever add field data at a later date.
      • Choice #2: Create a new database and drawing for every import of a FBK file, export a coordinate file and then import to main database. (Coordinate file seem to do less damage to the database)
      • Choice #3: Fall prey to the forced proprietary regime of proprietary systems, of which I am not a proponent of (I am more for open source and decentralized resources), and buy Trimble Business Center.
      • Choice #4: Make all edits in the data collector, then process and check for errors, which would start the cycle all over again.
      •  

Any one experience these problems or have a solution?

2021 04 01 10 10 03 AdApplicationButton
2021 04 01 10 13 50 Figure Properties
2021 04 01 10 19 04 C  Users HeathM.BRANCHENGINEER OneDrive   Branch Engineering Projects 21 004B Co

 

SIDE NOTE: We have tried using TRIMBLE LINK from within Civil3D and found it to mess up the prism constants erroneously.

Quote
Topic starter Posted : April 1, 2021 10:35 am
WA-ID Surveyor
(@wa-id-surveyor)
500+ posts Member

Just export and import csv files.  FBK files are getting extremely dated and have always been a little finicky at times.

It sounds like you're using Trimble equipment so I assume you have TBC. Bring all your data into TBC and make the appropriate adjustments, if any, to your conventional data.  Then just export a csv file.  That's what we do and have done for a decade and it works just fine.

ReplyQuote
Posted : April 1, 2021 11:21 am
RobertUSA, pwdesign, Jitterboogie and 1 people liked
BStrand
(@bstrand)
1,000+ posts Member

Yeah, I've actually never used FBK files but they always sounded buggy to me.  Clean up the things that need fixing in the data collector (what I prefer) or during processing and then use an excel file or even a simple text file.

As far as that big whacky line it looks like a field code mistake is all.

ReplyQuote
Posted : April 1, 2021 11:34 am

David Livingstone
(@david-livingstone)
1,000+ posts Member

One thing I discovered is not to end a line.  Just beginning a new line with the same code will end the previous line.  This may or may not be your problem.

ReplyQuote
Posted : April 1, 2021 4:50 pm
pwdesign liked
Murphy
(@murphy)
200+ posts Member

I use Trimble for all my GNSS work, Leica for TS, Star*Net for corrections, then create a txt file from Star*Net that I import into C3D.  

I tried the Survey Database route with C3D and found it buggy and inflexible.  To me, it has the feel of software that was designed as an afterthought. 

Once I edit and adjust my points in Star*Net, all my linework that was generated with both Trimble Access and Carlson SurvCE will be slightly off from my adjusted points.  Sometimes the separation is negligible, but usually it's a problem that needs fixing.  The quickest way I've found is to take the txt file containing the adjusted points and import them into a new job in SurvCE.  SurvCE automatically redraws all the lines, and does a better job with curves than C3D.  Then I simply export the dxf.  Sounds like a pain, but it is much faster than messing around with C3D.

 

ReplyQuote
Posted : April 2, 2021 3:52 am
WA-ID Surveyor
(@wa-id-surveyor)
500+ posts Member

@david-livingstone 

Good point David, that is the way we do it as well. Can't get much easier when having a properly coded set of points to simply export and import a .txt or .csv file with all your linework and breaklines together.

ReplyQuote
Posted : April 2, 2021 6:17 am

Rover83
(@rover83)
500+ posts Member

Civil3D is good for drafting, but clunky, inefficient and occasionally flawed for linework, or adjusting/QCing data.

I have never used FBK imports for the reasons stated upthread. When I have had to use the survey database, I have always found CSVs to work far better. But the process of importing/fixing codes/reimporting is still a pain, and we often had to wipe the database and reimport in a new one due to errors similar to the OP. That would be the easiest fix for the time being.

If you don't have TBC for QC/QA, get it. Not only is it far faster and easier for QA/QC of raw data, it will let you process the linework and fix it on the fly without having to reimport over and over. It'll save tons of time and money...plus allow for analysis and adjustment of control data at the same time. What are you currently using for adjustment of control, baseline processing, etc.?

ReplyQuote
Posted : April 2, 2021 6:29 am
MightyMoe
(@mightymoe)
5,000+ posts Supporter

I control F to F by coding and .csv files. It works well in C3D. In fact that has worked through autocad since I first set up coding in 1987. Although at that time is wasn't .csv coordinate files. 

I have only very briefly tried out surveying routines in C3D and each one has been a disappointment. So I don't use FBK files, adjustment routines, ect.

The import I use from Trimble to C3D is a simple point file, the problems are taken care of before importing into C3D. 

I'm assuming you don't have TBC so you are using a trimble import/export program to get it to the PC instead of importing the DC into TBC which would allow for a more robust editing environment. 

I would be editing the HI issues in the DC before export or be sure and keep the job in the DC in case you need to edit it later when you find an issue.

Code editing can be done in an editor outside C3D.

We do this all the time for partner engineers that use our data. There always seems to be something in the coding sequence that needs an adjustment. 

ReplyQuote
Posted : April 2, 2021 7:06 am
Jitterboogie
(@jitterboogie)
1,000+ posts Supporter

We create a debug database to import the initial field data to make sure it got coded correctly and then once cleaned up export all points to a final DB that doesn't receive new import events but can have objects like blocks or similar added but not import through the database import process.

Autodesk changed the database platform in the 2019 to 2020 and that also created a littany of issues.

ReplyQuote
Posted : April 2, 2021 7:07 am

Norman Oklahoma
(@norman-oklahoma)
5,000+ posts Member

The problem the OP is experiencing isn't in the .fbk files specifically.  C3d just doesn't like data added to the survey database piecemeal, no matter what form is used.

That said, the .fbk format is a legacy format. I use other means to reduce my data to coordinates (principally StarNet in my case). I recommend moving away from .fbk. Too limiting.

ReplyQuote
Posted : April 2, 2021 8:21 am
WA-ID Surveyor
(@wa-id-surveyor)
500+ posts Member

@norman-oklahoma

I agree.  Each day needs to be imported either completely separately or multiple days need to be imported at once.  Never ever re-import data already in the database as that's a recipe for disaster.  I prefer an import event for each day as it's much easier to keep track of and process.

ReplyQuote
Posted : April 2, 2021 10:02 am
RobertUSA
(@robertusa)
100+ posts Member

@david-livingstone conversely, I never begin lines for C3D, I only end lines. C3D by default will draw lines when the code is setup in the figure prefix database.

ReplyQuote
Posted : April 2, 2021 6:14 pm

fretbuzz
(@fretbuzz)
FNG Member

I appreciate the responses to my questions here. Thanks all.

ReplyQuote
Topic starter Posted : April 14, 2021 10:21 am
Share: