HSM Express - Drill Retract Bug?
Close
Login to Your Account
Results 1 to 8 of 8
  1. #1
    Join Date
    Jul 2008
    Location
    Ontario, Canada
    Posts
    248
    Post Thanks / Like
    Likes (Given)
    5
    Likes (Received)
    83

    Default HSM Express - Drill Retract Bug?

    I haven't been using HSM Express (in Solidworks, if that matters) for that long, but I'm not exactly "new" at this sort of thing either. So this morning, I'm trying to drill & tap 8 holes M4 in the end of a tube about 10" OD, 3" long. The part was held on the table with strap clamps so I defined the retract height as 3" above the stock top to clear them.

    Here's the kicker: the simulation showed the tool being retracted to 3" after EVERY hole before moving in X/Y. But looking at the generated code (and running it) the retract value seems to be ignored. I didn't catch this before it got to the machine, but fortunately my clamp wasn't between the first and second hole.

    Has anyone else experienced this? It may be the custom post, but I've run it through some other post processors and the code looks similar.

  2. #2
    Join Date
    Apr 2006
    Location
    Ga.
    Posts
    118
    Post Thanks / Like
    Likes (Given)
    2
    Likes (Received)
    4

    Default

    It may be a G99 instead Of a G98.

  3. #3
    Join Date
    Jun 2002
    Country
    CANADA
    State/Province
    British Columbia
    Posts
    2,225
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    1520

    Default

    Hi Sparky961:
    I am certainly no expert on things related to HSM Express, but there is a strategy Keith (one of the technical consultants when HSMWorks was first developed) taught me that works very well in HSMWorks.
    He models the clamps in Solidworks as part of the assembly, then includes the clamps in the model definition for the operations where their presence is relevant like your drilling ops.
    That makes HSMWorks recognize and avoid them as part of the model, so it makes the retracts efficient because HSMWorks knows exactly where they are and what size and shape they are and will avoid them.

    It's a "cheat" in the sense that you're lying to the CAM system but it is an effective one.
    It's also quite possible they've refined HSM to allow a clamp or fixture definition by now so this may be a totally obsolete workaround.

    In any event, I've found things like retract height definitions and tool path entry points and other dialogue box options that work predictably in other CAM systems to be generally very temperamental in HSMWorks.
    I've learned quite painfully at times, that the model definition, the stock definition and how you choose them for each operation is KING in HSMWorks; other dialog box choices get ignored or interpreted in weird ways, so you have to watch the simulation like a hawk to be sure you get what you intended.
    Oddly though; I've found the simulation generally to be very accurate, so it puzzles me that your sim is fine but your code is not.
    That's unusual for my limited experience of HSMWorks.

    Cheers

    Marcus
    Implant Mechanix • Design & Innovation > HOME
    Vancouver Wire EDM -- Wire EDM Machining

    On Edit: Another thing that occurred to me; when you write code using HSMWorks, it is often quite a bit more difficult to interpret it by just looking at it; the reason is that it will set the absolute values of retract heights based on the combination of where you set your origin in the CAD/CAM system, how you defined your retract plane in the "Heights" dialogue box, what feature of the CAD file you defined them from, and what you included in your stock and model definitions for each operation.
    If, for example, you pick the sidewall of a modeled hole from your CAD file, HSM will want to default to defining the top of the hole as the starting point for it's retract plane calculation for that operation.

    You have to make another choice of feature if you want it to define the retract plane differently.
    If you pick "top of model" or "top of stock" it will again define those planes differently and code them accordingly.

    So depending on the details of your definitions you can get totally different G code results and when you look at the code it's confusing to interpret because it looks like it's all over the map.

    MC

  4. Likes Sparky961 liked this post
  5. #4
    Join Date
    Jul 2008
    Location
    Ontario, Canada
    Posts
    248
    Post Thanks / Like
    Likes (Given)
    5
    Likes (Received)
    83

    Default

    Thanks for the thorough reply, Marcus. Very helpful, as usual.

    I'm going to be watching it more closely from now on. I'm glad to hear that it (probably) isn't just something I'm missing.

    I usually like to model everything that's going to be on the table and potentially in the way, but this was one of those "I'll just knock this off quick" things and I didn't think all that was necessary. I also hadn't figured out exactly where the holes where and if my clamps were in the way, planning to move them on the fly if needed. I'll keep in mind the bit about tricking it though. It sounds like it could come in handy in the future.

    Having spent most of my time with MasterCAM, I'm reserving judgement whether I like HSM Express.

  6. #5
    Join Date
    Sep 2008
    Country
    CANADA
    State/Province
    Nova Scotia
    Posts
    220
    Post Thanks / Like
    Likes (Given)
    13
    Likes (Received)
    101

    Default

    If it's showing the proper retract in simulation but not doing it in the program, it's a post issue. It's probably outputting canned drill cycles for multiple XY positions from your feed plane. You can probably get around it quickly by setting the "top" to 3" above the part, but you'll be feeding for 3" before you hit the part.

    I had to do a bunch of screwing around with my HSMWorks post for a Bridgeport DX32 to make it output drill cycles properly, but luckily the posts are pretty easy to edit. Somewhere in the HSMWorks installation folder there's a file called "post.chm" which documents the post language pretty well.

  7. #6
    Join Date
    Jul 2008
    Location
    Ontario, Canada
    Posts
    248
    Post Thanks / Like
    Likes (Given)
    5
    Likes (Received)
    83

    Default

    Correct, it's outputting canned cycles rather than long form code. I suspect you might be right about the post, as I also thought this might be the case initially. I considered setting the feed plane way up there but I didn't have all day to wait for it.

    Thanks for pointing out the reference for posts. I hadn't gotten there yet but this will speed up the process.

  8. #7
    Join Date
    Sep 2008
    Country
    CANADA
    State/Province
    Nova Scotia
    Posts
    220
    Post Thanks / Like
    Likes (Given)
    13
    Likes (Received)
    101

    Default

    An expedient fix would be to disable outputting canned cycles which is I think a configuration variable at the very beginning of the post. It might even be an option in the "post process" dialog.

  9. #8
    Join Date
    May 2012
    Location
    Mid-Iowa, USA
    Posts
    3,559
    Post Thanks / Like
    Likes (Given)
    3458
    Likes (Received)
    2049

    Default

    Which post(s) are you using? Generally the heights should be good except for some strange use-cases like the Bridgeport and even then (at least in the one I attempted to help with) was due to the retract plane being lower than the clearance plane for the same reasons.


Tags for this Thread

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
  •