Export to GCS900 - Creates segmented arcs in machine controller

Does anyone know what the logic is for TBC breaking lines to send to GCS900? Some lines are segmented, some are whole.

This creates issues in the GCS900 system because lines like edges of pavement that should be long connected lines are segmented and make it hard to use as a reference line. This seems to be a bigger issue with lines that have arcs. In some cases, GCS900 will join these back but it appears to have a hard time if there are overlapping lines on different layers or lines that cross.

Is there a way to not break these lines?

This is an issues from the TBC exporter and via WorksManager.

Videos and support data to follow

I’ve pulled out a lot of hair on this as it matters a lot for slipform curb machine alignments. Not a huge problem on roadways, but do a parking lot and you’ll quickly understand. 2d arcs won’t cord and should remain as arcs. 3d arcs will definitely cord in the SCS export. If anything touches a line, there is a pretty good chance it will be broken at the intersection. Lines over lines will pretty much break and stay borken at every node. Or lines that you don’t want to be joined will be. If you have two seperate lines that touch at the ends, they will likely be joined which is a major issue in corners. We need to trim back (.02 - 0.10) every line that we can not have joined together by the SCS export. You can’t imagine the hoops we had to jump thru to get productive with the machine and the SCS software transfer (not to mention the actual controller bugs we had to deal with and getting CTC to even listen). It’s a mess and completely unintuitive, but fortunately we’ve been able to adapt.

I have been told the areas are broken into smaller grid areas for memory management needs.

That’s annoying.

I always noticed this with the grader when trying to reference edge of pavement and centerline but never had the time to look into it until today. Seems like something that could be fixed with he exporter though. There is not chance that they will fix it with the GCS900 system at this point with that be a “legacy” device now.

yea I don’t see it getting fixed period, ever. CTC knows better what we need. Just remember, 2d lines won’t cord the arcs and nothing can touch anything if you expect it to be the same on the controller.

Annoying is an understatement but we persevere if we know and understand what we’re up against.

And I’m pretty sure it’s the controllers that do the breaking apart but I’m not 100% sure as I never got a straight answer, about anything really.
Bring the .svl back into TBC for some real fun. I was told that that’s not a valid way to verify your data and get this, there is no real way to verify the exported data other then running the emulator on each and every line. What a joke.

That is why I grin at this sometimes:

Hey we got features!
I’m just waiting for the day RPS gets hired to do the inevitable re-write. Hoping it’s before I retire. LOL

Unless something has changed - here is what I know

  1. the svd svl or dsz format breaks up all linework into squares of I believe 50m or 50’ - it loads 9 squares of data around the machine at all times - the machine square, one ahead, one behind, one left and one right and then the 4 corner squares. It loads and unloads data as the machine moves from square to square. This goes back to Sitevision which ran on a box with next to zero memory and so data had to be managed effectively. The map otherwise is an image I believe.

The lines are broken by TBC because that is the definition of the file types in use. However the machine knows this and will connect the lines over these breaks or it should do - if you reinsert an SVD SVL the lines are broken in tbc but in the machine this should not have any effect on line selection for guidance

Second - the machine when it reads the lines - if it finds lines that cross each other eg a Centerline Nd centerline label ticks for example - the machine breaks the lines at all crossings - same would apply to curb and contours for example. If this is the issue them you have to use eg crop crossing to break out a section of the ticks or contours either side of the lines you want to use for guidance - then the machine doesn’t see the crossings and doesn’t break the lines.

I have tested this in the past and validated with the machine simulator to prove this to be correct

Unless something changed or Unless works manager is not prepping the files correctly from the VCLs it is given then I think this is correct - however I am pretty sure that WM is not breaking out the crossings- you have to do that in TBC

2 Likes

I agree with Alan.
I have found over many years that if the data is prepared in Trimble Business Center correctly removing any unnecessary data, such as text, contour lines and duplicate lines then only exporting the actual break lines required to define the surface as well as the alignment, if a corridor, then all is well. The surface will be as it was in TBC and the lines will be 2D as required. Should one import an svl file back into TBC it may well have broken lines and therefore, if it is required to export it again, it’s best to join the lines using “Project Clean-up”.

1 Like

That make sense. It just becomes daunting making specific models for every scenario. Earthworks definitely helps with this by supporting the lines and allowing user to toggling things on and off but one of the issue I run into all of the time is the difference between dozers and excavators. Excavators need to see everything under the ground whereas dozer do not.

Newer tech is making it easier by allowing you to send everything out and letting users a la carte to their needs.

1 Like