Moving forward.. Issues solved and workarounds figured out.

As you can tell on my pop-up project, I’ve been experiencing a huge amount of pain (well not really, cause it was fun) on trying to use heekcad parametric solver for my little popup card project. Apparently there was at least 2 confirmed root causes and a suspect 3’rd at play here.

  1. Non-implemented code (no biggy Jonpry did a update R1303. Thank you soooo much)
  2. Design flaws in mergecommonobjects hosing up constraints (JonPry and David Nicholl’s have discussed this amongst themselves and hopefully this will be resolved soon)
  3. Undo/Redo [?]

1) My little angle box project I think pushes the constraint solver pretty hard..   I used alot of the constraints available in heekcad but not all of them.  I guess there where a couple more that if I would have run across they would have caused me the same pain as that setfixedpoint constraint had.  Difference in the code can be viewed at revision R1303.  I think I could have figured it out, but I would have taken a while.

2) These mergecommonobject thing is driven by the needs of people using heekscnc.   Apparently at the level where this is being used, constraints are not really a primary concern so when they hosed up the works no one really noticed.   The constraint bugs introduced by mergeCommonObject are pretty insidious.  They only manifest themselves in saving and are not really noticed until you reload a file.    So you’re working on a long project and what do you do? Well, you save periodically along the way.  It can be hours, till you reload the actual file.   Basically this bug caused me to have to manually delete all the constraints, renumber the sketch and point id’s and start from scratch.  Not a big deal if your talking 3 or 4 constraints, but my anglebox project has about 108 constraints in it.  That’s about 1/2 – hour each time I had to redo the constraints from scratch, (~1/2 dozen times).
Heekscad will only improve if more people start using it and really start pounding on the code.  The only way to pound on the code is with more complex projects exploring all the nooks and crannies of what heekcad has to offer. If you have an application that causes you to loose hours out of your life, because of insidious save/load bugs only anal retentive nuts like me are going to take the time to stick with it,
Just thinking out loud here, but I wonder if Heekscad might benefit by a backup file system… Sort of a auto back up along the way. Say you could set a parameter for frequency of backup, could be time or it could be by number of keystrokes. Or for that matter if you suspect a certain section of code to be the culprit, wouldn’t it be cool to have heeks data file dumped out before and after.
For me at the moment, this mergecommonobjects is an impediment to the things I want to do. Apparently this thing is real important to the heekscnc/heekscam folks since it’s been committed/uncommitted a bunch of times.
For me at moment the path of least resistance is to go around rather that through. In other words:

/*
// where operations are pointing to the same sketch, for example, make sure that they are not duplicated sketches
for (std::list::iterator itObject = objects.begin(); itObject != objects.end(); itObject++)
{
*itObject = MergeCommonObjects( unique_set, *itObject );
}
*/

I’m more than willing to test on a developed back up file, but this thing has been a major pain for me.

3) The undo/redo engine was disabled, but has been turned back on in the latest versions. It think it’s only been in the last couple of weeks, but I can’t tell exactly where,from the titles.. It’s really not that important to me. Anyway.. This to me is more of a suspicion rather than a confirmed bug. Drag and drop is a relatively new, rather cool feature in heekscad. Unfortunately, it hasn’t been idiot proofed. Currently, you can drag a line to be the child of a point if you are not careful. To me that’s a bug.. who knows what that does to the solver and undo/redo. Is that fair to expect the solver/ undo/redo to handle a wacky condition like that… Me think not.
This is a situation where if your real real careful you can avoid this. While undo/redo is an incredible cool feature, for the moment my approach to it is:

//#define USE_UNDO_ENGINE

I was going to post a couple of pictures of the ultimate coolness of using heekcad constraints to create a parametric model of an angle box, real handy stuff for paper engineering, but I have this karma thing catching up with me. I neglected my little one yesterday and and uninterrupted pounding at the keyboard is not an option today… (rightly so….)

This entry was posted in Uncategorized. Bookmark the permalink.

One Response to Moving forward.. Issues solved and workarounds figured out.

  1. David Nicholls says:

    There is an auto-backup system within heeksCAD. If you go to the ‘file options’ in the ‘options’ window you will see an ‘auto save interval (in minutes)’. If this is anything greater than zero, it will automatically save the current memory tree to a temporary file. If the application crashes, it finds this temporary file and asks if you want to use it to recover from the crash. If you shutdown HeeksCAD gracefully then part of the shutdown process is to remove this temporary file.

Leave a Reply

Your email address will not be published. Required fields are marked *