hexagon logo
Register Sign in
  • State Not Answered
  • Replies 12 replies
  • Subscribers 226 subscribers
  • Views 1666 views
  • Users 0 members are here
Options
Related

Issues with large Programs

Richmond White

Hey there!

So, I'm running this program that takes a while (think 1-2 hours) and crunches a ton of data (around 700 dimensions worth). The problem is, every time I run it, the program just freezes and crashes if it gets any kind of error. The program running slow or laggy makes sense for a long program, but the crashing part is a real pain.

I was thinking of breaking the program down into smaller chunks, like subroutines. I haven't really done this before, so any advice would be awesome!

Here's what I'm curious about:

    • Finding Subroutine Material: How can I spot those parts of the code that would work well as separate subroutines, especially the bits that deal with all those dimensions?

    • Break Down Plan: What's the best way to tackle breaking down this program? Should I start small and work my way up, or is there a better approach?

  • Subroutine Secrets: Any tips on designing good subroutines? What should I keep in mind for naming, what data should they take in and spit out, and how should they work in general?
Parents
  • 0

    In general, It is hard to answer you questions unless you read through the drawings and understand what kinds of sequence it is on based on different datums or alignments. For example:

    1. Start with datum ABC, then measure 1-150 features, 

    2. Datum DEF, then measure 1510-300 features.

    3. Datum GHI ...

    Then you could separate the program into small piece....

    My thought  

  • 0 in reply to RobOntario

    I'd have to agree that several smaller programs would work better than using subroutines to make it all work in one program.  During execution, when a subroutine is called, the Edit window will just highlight the line calling the subroutine.  You can not see the code of the subroutine and if there are any errors you can not see where the problems are.  You also can't just go back and re-run a single feature in the subroutine or execute from the cursor somewhere in the middle.  

    A 2 hour run time with 700 dimensions is a pretty big measuring routine, but I often work with much larger measuring routines.  The software is capable of doing it.  I suggest you look closer into what is causing the slowness and the crashes.  You might benefit from a hardware upgrade.  It is also possible that you are using a software feature that is really resource intensive.  I find that sticking to legacy reporting helps a lot.  Also, avoiding any measuring strategies that have multiple imbedded features - like the Adaptive Cylinder Concentric Circle Scan.  When using that measuring strategy it will create the main cylinder feature and several imbedded circle features.  Too many features like that make my system agonizingly slow.  Unfortunately, it can be hard to tell sometimes what is causing slowness and crashes. 

  • 0 in reply to Cris_C

    I didn't know those auto features  had more info than other ones. I did end up removing nearly all the scanning I was doing. It seems to run better now, but the cycle time is much longer.

  • 0 in reply to Richmond White

    A workaround is to scan 2 or more auto circles at different depths and then construct a cylinder from those.  It is a pain to do all that programming, and it may seem counterintuitive to have 3 or more times as many features to make the program execute faster, but somehow it works.  

Reply Children
© 2024 Hexagon AB and/or its subsidiaries. Privacy Policy | Cloud Services Agreement