I have a script that is SOO close to working where it will draw linework in profile view, but it requires knowing the base elevation of the profile view being automatically created by Civil 3D. I thought I could write a python code to round the lowest point of the surface profile to find what the bottom elevation of the graph should be automatically, but that has been failing for me. Any ideas on how to retrieve the bottom elevation of a profile view that is generated from the Dynamo script?
Hi @jbrunkhorst,
Does the ProfileView.MinElevation node give you what you need?
Unfortunately, no. That is what I am trying to do now, and then round down to the nearest even elevation, but that is still inconsistent. That node appears to give me the lowest elevation of the surface profiles shown.
Mmm, I see what you mean. I think it might be a quirk with how Civil 3D handles the different elevation modes. Does it do what you expect when the elevation range is set to user-specified instead of automatic?
That could fix it, but the problem is I have thousands of alignments on my site that I could be called upon at random during a quality and control analysis, so manually setting up the elevation range would be a challenge.
Agreed it’s not ideal, I was just wondering if that gave you the result you need. If so, then there may be a workaround to get there. I think the behavior you’re seeing in automatic mode may be a bug.
You could try this workaround and see if it meets your needs. Again, you shouldn’t have to do this, so I think it might be a bug in Civil 3D. Will keep investigating.
I appreciate you looking into it! I tried your workaround and I think it is still giving me the lowest elevation of the surface profile in the profile view.
Ah sorry, I made a rookie mistake in my own example 
Basically, the order of operations is not guaranteed in the above example. Even though the ProfileView.SetElevationRangeAutomatic is visually to the right of the ProfileView.MinElevation, that doesn’t mean that it gets executed afterwards. So sometimes the minimum elevation will be returned before setting automatic back to true, and sometimes it will be returned after it has already been set to true. The order is not guaranteed since they are in parallel branches. This is referred to as a race condition in computer science parlance. Whenever an output appears to be randomly different between runs, it’s an indication that there’s probably a race condition somewhere.
Anyway, so you just need to force Dynamo to execute things in a specific order. It’s a helpful technique in many other cases as well. You basically set up a simple “gate” that makes sure that certain things have to finish before passing along the output.
More info here: