CAMworks. Beware!!! - Page 2
Close
Login to Your Account
Page 2 of 6 FirstFirst 1234 ... LastLast
Results 21 to 40 of 102
  1. #21
    Join Date
    Feb 2006
    Location
    Republic of Texas
    Posts
    2,267
    Post Thanks / Like

    Default

    Quote Originally Posted by Joe788 View Post
    Ahhhh, I knew that name looked familiar.

    I'm not a Camworks user, but the majority of his issues sound like training issues.
    More than a passing resemblance to JB. Could it be yet another personality emerging from the cesspool of his mind?

  2. #22
    Join Date
    May 2002
    Location
    South Central PA
    Posts
    12,714
    Post Thanks / Like
    Likes (Given)
    1708
    Likes (Received)
    2862

    Default

    Quote Originally Posted by alphonso View Post
    More than a passing resemblance to JB. Could it be yet another personality emerging from the cesspool of his mind?
    He's way too reasonable and lucid to be JB. Then again, maybe we should check his briefcase for pizza.

  3. #23
    Join Date
    Jun 2005
    Location
    North Central Montana
    Posts
    4,510
    Post Thanks / Like
    Likes (Given)
    730
    Likes (Received)
    610

    Default

    ahhhh...the legend lives on......

  4. #24
    Join Date
    Aug 2008
    Location
    SouthEastern Pennsylvania
    Posts
    1,027
    Post Thanks / Like
    Likes (Given)
    12
    Likes (Received)
    40

    Default

    Now ya just gotta elaborate on that one... JB? Do tell...

    Joe

  5. #25
    Join Date
    Mar 2009
    Location
    Valencia, CA, USA
    Posts
    339
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    44

    Default

    Quote Originally Posted by Mud View Post
    Before you get too caught up in this, martin_05 is the guy who ranted that G-code should be obsoleted and replaced because he didn't understand it. Check his oldest posts.
    That's cool. Shoot the messenger.

    I write g-code by hand just fine, thank you. I have made many parts that way. The fact that I thought that an improvement could be made does not disqualify everything I say.

    Maybe I'll take the time to capture a video and post it on youtube for everyone to see. I don't really have the time for an argument on this list though. So, assume I know nothing and go ahead and buy this program. It really isn't my problem, is it?

    -Martin

  6. #26
    Join Date
    Mar 2009
    Location
    Valencia, CA, USA
    Posts
    339
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    44

    Default

    Quote Originally Posted by Joe788 View Post
    I'm not a Camworks user, but the majority of his issues sound like training issues.
    They are not. They are mostly legitimate. A lot of them have to do with really bad user interface issues with the program. Others have to do with the post delivered with the program being lousy. For example, this is how programs start:

    %
    O0001
    N1 G00 G90 G49 G20 Z0

    Right. Don't load a work offset and don't load a tool length offset and rapid right to wherever Z0 happens to be. Which could be the table, the stock, the vise or a fixture. And, if you just happen to have a nice beefy tool on the spindle, crash the machine and bust up the transmission or something else (mine is direct drive).

    So, maybe I didn't have the best opinion of g-code, but that does not mean that I cannot use it and that I cannot judge issues with some of the tools I use.

    Here's a screenshot of a very simple part with a pocket that has two bosses inside. Using a normal entry all is fine:

    no-crash.jpg

    You then go specify a spiral entry and this happens:

    crash.jpg

    CAMworks decides to rapid into the stock. The thin dashed red line is easy to miss in a complicated part.

    I've also attached the actual Solidworks file with CAMworks data so that anyone may verify that this is not a matter of training but rather a real bug, and a dangerous one at that.

    Tool crash.zip


    I have also verified that the CAMworks simulator does actually have a collision detection feature. And, yes, it works, and yes, it detects the above. However, there are two problems with it: First, they ship the program with all the collision detection settings turned off. Second, they violate so many user interface standards in this program that it is very easy to make the mistake of assuming that collision detection is in fact ON when it is not:

    Here's what the simulation control dialog looks like right out of the box:

    factory-simulation-settings.jpg

    I could not capture the quick help that appears as you hover the mouse over the button. It reads "Tool Ignore Collision". As the button is NOT pressed this means that collisions will NOT be ignored. I asked about six different people what it meant when the "Tool Ignore Collision" button was not pushed down. They all said the same thing.

    The reality is that CAMworks means that, with the button in this state, collisions ARE BEING IGNORED.

    This is what happens if you press the button:

    button-action.jpg

    ...A little menu appears that gives you these options:

    Ignore Collision
    Cut Collision
    Pause on Collision

    The one you want is the last one, of course. And, yes, it works.

    The problem here is that this is a badly executed user interface which led to a serious error. I don't know of any UI standard that makes it OK to use a button to display a state this way. And with good reason.

    Solidworks makes good use of buttons that are used to choose from among various options. One such case is the "Fillet" button. When you click it you go into the "Fillet" creation dialog. However, if you click the little arrow next to it you get to choose from making a chamfer or a fillet. In either case the graphic of the button does not change.

    There is one case in SW where the button graphic changes based on the selection made. That is the rectangle tool while in sketch mode. However, the button always means the same thing: If you click this button you will make a rectangle.

    The problem with the CAMworks button is that the legend means one thing and clicking the button does somthing entirely different. The legend leads the user to believe that collision detection is actually enabled.

    Whatever the case may be. The fact remains that simulator or not, CAMworks software turns a perfectly good feed into stock into a rapid. This happened to me with a couple of small 1/8in tools. Had it happened with a shell mill I would have experienced a rapid at 1500 inches per minute into a very solidly clampled piece of stock. This would have caused very serious damage to the tool and my machine and who knows what else.

    Another important point is that the CAMworks simulator does not match what happens at the machine. Case in point is tool diameter offsets. I won't go into details but I'll just say that what you see isn't necessarily what you'll get.


    Oh, BTW, we did get training. And we did spend lots of time on the phone and swapping files with our VAR. Nobody every mentioned the little collision detection buttons. Not once.

    But, hey, I'm the guy who didn't like g-code, what do I know?

    -Martin

  7. #27
    Join Date
    Mar 2009
    Location
    Valencia, CA, USA
    Posts
    339
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    44

    Default

    Quote Originally Posted by BadBeta View Post
    I'm sorry Rainman, but to me any program knowingly rapid plunging into material has issues far beyond training.
    Exactly my point. You can learn to run a crappy program. That is certainly true and four years (like someone mentioned) is certrainly long enough to do so.

    However, if the software is programmed to take a perfectly good toolpath and make a decision to make it perfectly dangerous it means that there's a fundamental flaw in the underlying logic. Simulator or not. The path went from good to bad with a simple entry strategy change. I could be a comple idiot and grossly unqualified to do as much as ride a bicycle, but that does not remove the fact that a simple selection in CAMworks turns a safe path into a dangerous machine-busting rapid into the stock.

    So, shoot the messenger all you want. I can prove everything I've claimed.

    -Martin

  8. #28
    Join Date
    Aug 2005
    Location
    CT
    Posts
    7,606
    Post Thanks / Like
    Likes (Given)
    254
    Likes (Received)
    1582

    Default

    Quote Originally Posted by martin_05 View Post
    %
    O0001
    N1 G00 G90 G49 G20 Z0

    Right. Don't load a work offset and don't load a tool length offset and rapid right to wherever Z0 happens to be.

    -Martin
    Ahhmm... Martin.

    Tough I agree that no rapid into a part ..... I also did not look at all the other comments you've made.
    But.

    While the code above surely does not load the workoffset, it however also won't rapid into the table, or for that matter anywhere dangerous...
    That G49 cancels tool length offset, therefore it most likely moves to the toolchange Z0.
    The workoffset tough is simply a change to the post, which is curiously forgotten by the developers.
    Sometimes it makes you wonder if the guy behind the keyboard at the CAM company has ever seen a machinetool.

  9. #29
    Join Date
    Mar 2009
    Location
    Valencia, CA, USA
    Posts
    339
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    44

    Default

    Quote Originally Posted by SeymourDumore View Post
    While the code above surely does not load the workoffset, it however also won't rapid into the table, or for that matter anywhere dangerous...
    That G49 cancels tool length offset, therefore it most likely moves to the toolchange Z0.
    The workoffset tough is simply a change to the post, which is curiously forgotten by the developers.
    Sometimes it makes you wonder if the guy behind the keyboard at the CAM company has ever seen a machinetool.
    I don't think that's right. G49 cancels tool length compensation. It does NOT change the work offset.

    I have a 1.5 inch subplate on my machine.

    I was machining a part that required me to touch-off Z right on the surface of the subplate. I was machining a thin piece that had to have a precise web machined onto the bottom.

    Anyhow, the point is that G55 was set to have Z0 equal to the top of my subplate. For those who still think that I have an aversion to g-code, this program was written by hand, BTW, no CAM involved. I do a lot of progams by hand. Sometimes it is faster than CAD/CAM.

    The next program I ran came out of CAMworks. The post I used is one supplied by the VAR with the comment that "we have lots of customers using it". So, being cautious, I slowed down my rapids to 5% and set the machine up to single-step through the g-code.

    Sure enough, it loads a nice long 1 inch drill and heads for the table. G49 has no effect on the position of Z0 for the currently loaded work offset.

    I stopped it within a couple of inches of the table and noted the "Distance to go" reading for the Z axis. It would have rammed into my subplate at full 1500 inches per minutes if I was stupid enough to not test with very controlled settings.

    Lousy g-code. Even I can tell! If any real customer is actually using programs that start like that I'll eat a cow.

    This is how I start all my programs:

    G54 (or whatever applies)
    G90
    M05
    M09
    G53 G00 Z0
    G53 X-20. Y0.


    I don't bother with G49 because the right length compensation will be loaded with my toolchange anyway. I am sure that there are cases where G49 is needed, but I have not come across one yet.

    This is how I end my programs:

    G90
    M05
    M09
    G53 G00 Z0
    G53 X-20. Y0.
    M30

    Again, I am sure it is not perfect, but so far it works for me. It simply turns off the obvious stuff, gets the spindle out of the way and brings the table front and center so I can do whatever I need to do. G53 is neat for something like this.

    I've also done some automatic work offset setting routines in g-code, which has really neat applications. Again, the code was written by hand, not CAM. Here's an example.

    The following code uses the toolsetter routine for measuring the Z coordinate of the top of a workpiece. I use that to reset my G54 Z in real time as the program is running to whaever the workpiece's Z might be. We then face off some amount automatically based on this measurement and probe again to reset G54's Z one more time to the new surface. What follows are a bunch of test cuts into the piece relative to the newly created surface with a stop after each cut.

    We used this test to very precisely calibrate the probing system due to the potential error created by the microswitch in the probe. I have evolved this into a more complex subroutine in its own right that does a lot more and is very useful for high accuracy parts.

    %
    O00200 (PROBING ERROR TEST)

    G54
    G90
    G53 G00 Z0.0000

    G00 X1.0000 Y0.5000 (TEST SITE XY)

    (PROBE WORKPIECE Z SURFACE)
    T24 M06
    G43 H24

    (CALL TOOLSETTER PROBING ROUTINE)
    G53 G01 Z2.0000 F5. (PROBE SETUP Z)

    G65 P9359 W54. (Set new Z for G54 by probing)

    G53 G00 Z0.0000


    (FACE MILL SURFACE)
    G54
    G90
    T16 M06
    S10000 M03
    G43 H16
    G53 G00 Z0
    G91
    G00 Y-3.000
    G90
    G00 Z-0.025
    G91
    G01 Y3.0000 F50.
    G01 X5.0000 F50.
    G00 Z1.0000
    G00 X-5.0000
    G90
    G53 G0 Z0.0000


    (PROBE NEW SURFACE)
    G54
    G90
    T24 M06
    G43 H24
    G01 Z0.9000 (PROBE SETUP Z)
    G65 P9359 W54.
    G53 G00 Z0.0000

    (TEST CUT)
    G54
    G90

    T3 M06
    S750 M03
    G43 H03
    G90
    G53 G00 Z0

    G00 Z0.1


    G01 Z0.001 F5. (STARTING Z)

    G91
    X0.2
    M00
    (+0.0010)

    Z-0.0001
    X-0.2
    M00
    (+0.0009)

    Z-0.0001
    X0.2
    M00
    (+0.0008)

    Z-0.0001
    X-0.2
    M00
    (+0.0007)

    Z-0.0001
    X0.2
    M00
    (+0.0006)

    Z-0.0001
    X-0.2
    M00
    (+0.0005)

    Z-0.0001
    X0.2
    M00
    (+0.0004)

    Z-0.0001
    X-0.2
    M00
    (+0.0003)

    Z-0.0001
    X0.2
    M00
    (+0.0002)

    Z-0.0001
    X-0.2
    M00
    (+0.0001)

    Z-0.0001
    X-0.2
    M00
    (+0.0000)

    Z-0.0001
    X-0.2
    M00
    (-0.0001)

    Z-0.0001
    X-0.2
    M00
    (-0.0002)

    Z-0.0001
    X-0.2
    M00
    (-0.0003)

    Z-0.0001
    X-0.2
    M00
    (-0.0004)

    Z-0.0001
    X-0.2
    M00
    (-0.0005)

    Z-0.0001
    X-0.2
    M00
    (-0.0006)

    Z-0.0001
    X-0.2
    M00
    (-0.0007)

    Z-0.0001
    X-0.2
    M00
    (-0.0008)

    Z-0.0001
    X-0.2
    M00
    (-0.0009)

    Z-0.0001
    X-0.2
    M00
    (-0.0010)

    Z1.0

    G90
    M05
    M09
    G53 G00 Z0
    G53 X-20. Y0.
    M30
    %

    Once again, the intent here isn't to demonstrate pristine or elegant g-code, just an application that would be neat to integrate with CAM in some way...

    Except that CAMworks does not seem to have a way to program the calling of subroutines, like these probing routines. If you are doing really precise work and have a good probing system it would be invaluable to be able to do the kind of thing that I did above and have the work offset you are using automatically adjust X, Y and Z to the the actual reference cuts made on the part rather than a relatively arbitrary number that could be off by a few thousands.

    -Martin

  10. #30
    Join Date
    Aug 2005
    Location
    CT
    Posts
    7,606
    Post Thanks / Like
    Likes (Given)
    254
    Likes (Received)
    1582

    Default

    Quote Originally Posted by martin_05 View Post
    I don't think that's right. G49 cancels tool length compensation. It does NOT change the work offset.

    -Martin
    No it doesn't change workoffset.
    BUT!
    With G49 canceling toolength, it effectively becomes 0, which in turn puts the spindle to toolchange position, aka Max Z travel.
    That is regadless to where your effective workoffset Z is set to.

    Just try and MDI it in.

  11. #31
    Join Date
    Jan 2005
    Country
    CANADA
    State/Province
    Saskatchewan
    Posts
    9,629
    Post Thanks / Like
    Likes (Given)
    1189
    Likes (Received)
    3301

    Default

    If the machine is set up using the gage line on the spindle as a reference, and positive tool length offsets, calling Z0 with tool length offset cancelled, is going to want to bring the gage line down to the Z0 of the current work offset. Doesn't sound too healthy for the machine if there is a tool in the way!

  12. #32
    Join Date
    Aug 2005
    Location
    CT
    Posts
    7,606
    Post Thanks / Like
    Likes (Given)
    254
    Likes (Received)
    1582

    Default

    Hu

    Are you sure about that?
    I mean the length is effective cancelled???
    What I mean is that it does not know about the tool???
    I use negative offsets so can't test, but I tought that was the discussion about a while back.

    Here is why I'm thinking it would not make a difference.
    In my machine, if I call a tool with a 0 length and activate it, it will travel to G53 Z0
    That is:
    T1 M06
    G00 G43 H1
    G00 Z0

    Then the spindle will be in Z-home

    If however I key in:
    G00 G49 Z0

    Then the spindle moves to psitive G53 Z, as in Z-max travel.
    On my machine it's like Z4. something in mach. coord.

  13. #33
    Join Date
    Mar 2009
    Location
    Valencia, CA, USA
    Posts
    339
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    44

    Default

    Quote Originally Posted by SeymourDumore View Post
    Here is why I'm thinking it would not make a difference.
    In my machine, if I call a tool with a 0 length and activate it, it will travel to G53 Z0
    That is:
    T1 M06
    G00 G43 H1
    G00 Z0

    Then the spindle will be in Z-home

    If however I key in:
    G00 G49 Z0

    Then the spindle moves to psitive G53 Z, as in Z-max travel.
    On my machine it's like Z4. something in mach. coord.
    I'll test this on my machine tomorrow. Maybe there's something to be learned here.

    However, here's the official NIST verbiage on G43/G49 usage:

    http://tinyurl.com/ya37pg2

    For what it's worth, it seems to say that offsets are supposed to be positive...but this may be a can of worms I know nothing about...


    Thanks,

    -Martin

  14. #34
    Join Date
    Feb 2006
    Location
    Republic of Texas
    Posts
    2,267
    Post Thanks / Like

    Default

    Quote Originally Posted by martin_05 View Post
    This is how I start all my programs:

    G54 (or whatever applies)
    G90
    M05
    M09
    G53 G00 Z0
    G53 X-20. Y0.
    FWIW, this is how I start all my Fanuc machines.

    N10 G17 G40 G49 G80
    N20 G91 G28 Z.0
    N30 T02 (3" FACE MILL) M6
    N40 G54
    N50 G0 G90 X3.5385 Y.0 S443 M3
    N60 G43 Z1.1 H02 T12
    N70 Z.905 M8

    Start of next tool:

    N400 T12 (3/4 KILLER BEE) M6
    N410 G54
    N420 G0 G90 G41 D112 X2.0549 Y-1.513 S2500 M3
    N430 G43 Z1.0 H12 T08
    N440 G1 Z.8 F12. M7

    Go to tool change or end of program:

    N340 M09
    N350 M05
    N360 G28 G40 G91 Z.0
    N370 G28 Y.0
    N380 G90
    N390 M00 (or M30) After program is proved, M00 is changed to M01.

  15. #35
    Join Date
    Jan 2005
    Country
    CANADA
    State/Province
    Saskatchewan
    Posts
    9,629
    Post Thanks / Like
    Likes (Given)
    1189
    Likes (Received)
    3301

    Default

    I've never gotten into the habit of using G49 on Haas, because there is no need to in the circumstances I work within. On Haas, the length cancellation is combined with the next Z axis movement, so you would not see anything happen unless you both cancel the length offset and move somewhere. If you move in G53, you'd probably be okay if G53 Z0 is "up". But if you happen to still be in one of the work offsets, and Z0 is the top of the part, then that is where the spindle reference is going to move to, if G00 G54 G49 Z0 is commanded. Those commands might not even be in that sequence or on the same line to have that effect, as some of them are modal.

    Those comments all refer to the 'positive tool length offset' method. That is why I won't have anything to do with it: bugaboos from my past with Bandit and Shadow

  16. #36
    Join Date
    Mar 2009
    Location
    Valencia, CA, USA
    Posts
    339
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    44

    Default

    Quote Originally Posted by BadBeta View Post
    If a program can show that it is rapid plunging into material, and thus knows that, why on earth can't it correct for that itself?
    I just caught this comment.

    Exactly! Whatever the logic might be that causes this, at some point the blue lines showing the toolpath turn into red dashed lines --indicating a rapid. On that assumption that one choses to live with that (why would it ever be OK to rapid plunge into stock?) at the very least a warning message should appear immediately saying something like: "Detected rapid into stock!". You shouldn't even have to get to the simulator to see it...

    -Martin

  17. #37
    Join Date
    Nov 2006
    Location
    Jupiter, Florida
    Posts
    233
    Post Thanks / Like
    Likes (Given)
    87
    Likes (Received)
    7

    Default

    I just glanced over the long list of "problems". I, too, had a list like that when I started on CamWorks...and SmartCam...and MasterCam. Doesn't everybody when they learn a new Cam program? The majority of your problems are solved through training and a decent post. Do you honestly think that MasterCam, SurfCam or FeatureCam or... whatever, don't have their quirks/bugs? Really?
    As for bugs, we're still on CamWorks2007 because of money issues but mainly due to our policy NOT to ungrade as soon as the newest version comes out. We wait at least a year. There's a long thread on upgrading so I'm not going more into it here.
    One thing I've learned is never to trust the posts of anybody who foams at the mouth either for or against anything. Just not reasonable.
    I've posted before about CamWorks. I like it but I keep an open mind toward other software. Because I will work with whatever software, the company I work for, has. That simple.

  18. #38
    Join Date
    Feb 2006
    Location
    Northern Europe
    Posts
    1,248
    Post Thanks / Like
    Likes (Given)
    15
    Likes (Received)
    80

    Default

    Quote Originally Posted by Chris59 View Post
    I just glanced over the long list of "problems". I, too, had a list like that when I started on CamWorks...and SmartCam...and MasterCam. Doesn't everybody when they learn a new Cam program? The majority of your problems are solved through training and a decent post. Do you honestly think that MasterCam, SurfCam or FeatureCam or... whatever, don't have their quirks/bugs? Really?
    Most computer programs of any complexity have bugs. But there are bugs and there are Bugs. Microsoft Windows apparently got thousands of them, but none of them formats your hard drive or wipe your BIOS. A CAM program knowingly programming crashes is a disaster waiting to happen, and I think any potential buyer would like to know about it.

    As for the rest of the list I imagine some can be solved in post, and others by training or learning to work around. That is not to say they are not issues that can be improved upon, and which can be major annoyances in daily life. Most programs got those unfortunately, but again, I think potential buyers would like to know about them up front.

    I can see that martin_05 likely has posted this in a frustrated state, but that in itself doesn't make it invalid. (Just a bit more colorful with some attitude). Still I value his post and info quite highly - indeed I'd like to hear about similar bugs and annoyances in all other programs as well. Maybe we should start a thread with Top 5 pro's and con's of CAM programs?

  19. #39
    Join Date
    Nov 2006
    Location
    Jupiter, Florida
    Posts
    233
    Post Thanks / Like
    Likes (Given)
    87
    Likes (Received)
    7

    Default

    You quoted me but you missed my point. I said "Do you honestly think that MasterCam, SurfCam or FeatureCam or... whatever, don't have their quirks/bugs? Really?"
    Then to compare a cam system, any cam system, to Windows, doesn't apply. I assure you, that with limited training and a bad post, I can crash any machine using any cam system. Yes, I said crash. You still need skilled people to run these things. Thankfully.
    That said, you made some other points and made them reasonably. Thanks.

  20. #40
    Join Date
    May 2002
    Location
    South Central PA
    Posts
    12,714
    Post Thanks / Like
    Likes (Given)
    1708
    Likes (Received)
    2862

    Default

    indeed I'd like to hear about similar bugs and annoyances in all other programs as well.
    When I was using Smartcam, early on before I knew what to watch for, and before I created a solid code generator specifically for my machine and my programming practices, I had the same problems.

    Then I switched to Edgecam when Smartcam died. In the beginning, before I created a solid code generator specifically for my machine and my programming practices, I had the same problems.


Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •