Problem- SprutCAM Bugs

[mgp]

I've been using various builds of SprutCAM for about a year and I've noticed quite a litany of bugs. Does anyone know if there is a remedy for any of these or if I just have to wait for them to be fixed in a later release?

-When editing the parameters of an operation, the program refuses keyboard input and won't start accepting it again until the program is restarted. (This usually happens when I'm inputing a value with the num pad)

-I think this has been discussed elsewhere, but SprutCAM seems to have a very difficult time outputing STL files from simulation results when there is any sort of curved feature on the part.

-Sometimes when I try to replace a tool in my library with another with updated parameters, it adds a second tool instead of replacing the original.

-Related to the last item, when a tool is added (even though it was supposed to replace an existing one), I often I can't delete the duplicate.

-Maybe this isn't a bug, but I can't seem to figure out how to cancel the drawing of a line in 2D geometry mode after the first point is placed without switching to a different tab (e.g. 2D to model).

-Related to the previous, I frequently can't delete 2D geometry by any means other than deleting the appropriate lines from the debugger text (shouldn't I be able to select a line on the screen and hit delete?).

-Sometimes tools will load in an upside down position. SprutCAM will then try to simulate cutting with the tool holder down and the tool up (and I've checked that my rotary axis is correct).

-If I accidentally load an incorrect IGES file, I can't delete it from the model tree, only its associated faces and curves. Usually this isn't actually a problem, but sometimes SprutCAM seems to think the old part is still there for the purposes of creating the workpiece around the part (i.e. there ends up being workpiece where there shouldn't be).

-My favorite one of all: SprutCAM frequently crashes for no apparent reason. There is no repeatable cause, and it usually happens at the most inopportune time.

I'm sure there are more that I've encountered, but those are the ones that come to mind at the moment. If anyone has any suggestions for overcoming these issues, it would be greatly appreciated! Also, if you've noticed other bugs, please list them here so we can develop a semi-comprehensive list of issues to look out for. Thanks!

[RTP_Burnsville]

It would help if there were version numbers listed for each issue. I have found the SprutCam staff to be very responsive in resolving bugs and issues with their software. Are you using the official release versions or the nightly build versions? If it is the later, I would expect those not to be completely tested.

Several versions back I had issues with the hole drilling routines but that has been fixed and not reappeared in about a year. Other than that everything has pretty much worked as expected.

Robert

[Eric_Tormach]

I have seen some of these bugs but have not encountered anywhere near the issues you have. I use SprutCAM everyday as I am the SprutCAM tech support for Tormach. Please include the build number and rev number of the version you have and also include the OS you are using. If you are a Tormach customer, you can contact me at eric@tormach.com

[mgp]

I'm using Version 7, build 0.6, revision 33254, running on Windows XP Professional SP3. I have seen all of these bugs running this version, though I've seen several of them in earlier revisions and in SprutCAM 2007 (though I forget which).

[Magnum164]

Originally Posted by mgp -My favorite one of all: SprutCAM frequently crashes for no apparent reason. There is no repeatable cause, and it usually happens at the most inopportune time.

SprutCam crashes on me alot as well and I have sent Tormach files but never heard anything back. Frustrating does it to me on two separate systems.

[mayhugh1]

I had plenty of problems with what seemed random crashes with the early releases of Sprutcam 7. Having both SC2007 and SC7 installed, it even affected the stability of SC2007-so much so I uninstalled SC7 went back to SC2007 until release 1.0 of SC7. Now using 1.1 SC7 seems very stable in my workflow. But, Sprutcam has never been real robust against wondering off the tried and proven workpath. I can probably still cause it crash by not waiting for it to finish before I try to move on to a next step, or by putting in certain unreasonable values for parameters. I also learned with SC2007 that in my computer system I could not use on-board graphics with shared video memory. A cheap NVidia card solved that. I've learned to save my project after creating the toolpaths and before going into simulation which, for me, seems to be where the dragons lay waiting. - Terry

[Magnum164]

The new version does seem to be more stable with less crashes, but I am not working with STL files right now. I have noticed it gets slow with very simple models and I have to wait for ever when I would think it would be pretty quick. Selecting faces is still real slow on simple parts.

[Eric_Tormach]

Remember that CAM software is almost as much of a processor hog as most gaming applications, thus the more advanced the project, or complicated the stl files are, the more pc power it takes to rotate and view the project. The computer that I run has 6GB of RAM and a 2.8GHz processor, and I very seldom have a crash.

[Magnum164]

Originally Posted by Eric_Tormach Remember that CAM software is almost as much of a processor hog as most gaming applications, thus the more advanced the project, or complicated the stl files are, the more pc power it takes to rotate and view the project. The computer that I run has 6GB of RAM and a 2.8GHz processor, and I very seldom have a crash.

Eric,

As a Game Programmer/Designer I have to disagree. Games are not much of a processor hog. Think of the Xbox 360, very small processor, most games are graphic intensive though. Based on that you have two different type systems for games and CAD/CAM design. My system that I was crashing on would probably put your system to shame, with a Quad Core (at work at lunch, can't recall speed) and 12MB memory and dual GTX-260 video cards with 1GB memory each. Video and memory is overclocked and the system is liquid cooled. (and my laptop is close to the same specs). I can run Crysis at 60+FPS as well as other applications on my second monitor. And current games only use a single core, very few are designed currently that take advantage of multi-core processors.

You have to understand the difference in program crashes vs system crashes. When a program crashes it can generally be a driver issues or more than likely improperly memory allocation, failing to clear a memory location before using it for something else. That will crash a program hard, which SprutCam was doing. A system crash is when the OS crashes and you basically have to restart the OS, which is not happening.

On a slow system it may take longer to do a task, but the program should not crash. It may come up and say resources are low and the program must halt, but it should not crash. It you have a large enough swap space it should keep running, but in SprutCams case it never maxed my swap file before crashing either.


Also one thing to note. My system as it is designed for gaming supports multiple monitors. However, most CAD applications do not support multi-monitors and instead recommend a larger single monitor. I know Siemens currently does not. The problem is with timing on sending data between the monitors, that can cause a crash. basically the same reason Tormach does not recommend running networks on the controller machine. My guess since I am not crashing on my laptop now with a single monitor, SprutCam was having an issue there and may have resolved it. Or it could be that I upgraded my Alibre, which I understand had issues with exporting iges files.

Dismissing people complaining of crashing, simply because your system is not is irresponsible in my opinion. I also do software testing and there is no way I could get away with that logic. we generally test on no less than 4 different system configurations.

By the way, does that model I sent you a few weeks back crash on you as well? I never heard back from you.

[Eric_Tormach]

I am not sure of who you are, If I did not get back to you It may be that I never received your model, depending on the size and type of file sent my spam filers kick it out. You have to understand that I am not irresponsible for blaming individual systems. I have hundreds of SprutCAM customers and crashing is not a very common issue brought to me. Most crashes are caused by strange systems or ridiculous values placed in a DRO for instance a step-over of .0002 on a large 3D part. By the way I have a dual monitor system and Sprut runs just fine on it, and 8 teaching laptops and my personal laptops and most all of my customers. Can you please e-mail me at eric@tormach.com and I will either look for your model or request another one.

[Magnum164]

Originally Posted by Eric_Tormach I am not sure of who you are, If I did not get back to you It may be that I never received your model, depending on the size and type of file sent my spam filers kick it out. You have to understand that I am not irresponsible for blaming individual systems. I have hundreds of SprutCAM customers and crashing is not a very common issue brought to me. Most crashes are caused by strange systems or ridiculous values placed in a DRO for instance a step-over of .0002 on a large 3D part. By the way I have a dual monitor system and Sprut runs just fine on it, and 8 teaching laptops and my personal laptops and most all of my customers. Can you please e-mail me at eric@tormach.com and I will either look for your model or request another one.

I'll send you a note on the model. But I do get frustrated when people dismiss problems because they are not having that problem.

Even SprutCam recognizes people are having this access error problem and if you listen to the video you will notice he hints at improper closing as corrupting files or graphics issues (as I noted). Nonetheless if you remove the files as mentioned SC will be running again on startup as normal. My zooming/panning has returned to normal as well as it no longer stresses my computer as the file should take very little processing power to run, it's not that big of file.

So for now, I can live with removing the setup files once I notice things starting to slow down. I suspect the problem may be in clicking the red X to close SC instead of using close from the file menu, other programs have this issue in Vista especially, corrupting files.

Access Violation Error - SprutCAM forum