Is it possible to automatically...
Close
Login to Your Account
Results 1 to 5 of 5
  1. #1
    Join Date
    Nov 2017
    Country
    CANADA
    State/Province
    Ontario
    Posts
    10
    Post Thanks / Like
    Likes (Given)
    1
    Likes (Received)
    0

    Default Is it possible to automatically...

    Hi everyone,

    Does anyone know if it's possible to create a plunge program that incorporates a automatic offset after each cycle.

    Example. I have 50 pieces to grind. .75 diameters x 6" long. M4 material. I am removing 0.010 total in 2 stages, first .007" and the the last .003" finishing.

    After each part I finish my grinding wheel breakdown about .00002". Rather than manually going in after 4 parts and adjusting my offset to keep within my tolerances of .0002-.0005", I would like for it to be down automatically as part of my program after each part. To ensure each part comes out very close in size.

    Is this possible?

    Thanks.

  2. #2
    Join Date
    Sep 2003
    Location
    Arvada,CO
    Posts
    240
    Post Thanks / Like
    Likes (Given)
    1
    Likes (Received)
    21

    Default

    Maybe try roughing the parts closer to size. I like to rough .0005 to .0008 oversize then go to size. This way you are not grinding so much off on the finish pass and breaking the wheel down. Which will hold size better.

  3. #3
    Join Date
    Nov 2017
    Country
    CANADA
    State/Province
    Ontario
    Posts
    10
    Post Thanks / Like
    Likes (Given)
    1
    Likes (Received)
    0

    Default

    Thanks for the tip, I will try this.

  4. #4
    Join Date
    Sep 2009
    Location
    barcelona, spain
    Posts
    2,187
    Post Thanks / Like
    Likes (Given)
    446
    Likes (Received)
    1230

    Default

    Endless options ...

    One option that comes to mind.
    1.
    Use a variable, partly, to calculate the offset.

    Pseudocode:
    Offset = var# + offset.
    Each n cycles, probe for changed circumstances as needed.
    A simple contact probe is likely good enough.
    Var = probed_data OR var = var + probed_data (if measuring difference only).
    Repeat...

    2.
    You could maybe probe the part to see what size it came out as.
    Then use option (1) as appropriate.
    A metal surface might be better for probing than the wheel.

    3.
    You could measure the part using a simple inexpensive electronic 1 micron dti, 50€,
    + a data cable for 50€, and
    + a sw program that writes the values into a txt file every 0.5 secs.
    The programs come with the data cables.
    This is accurate to 1-2 microns and repeatable to about 1 micron +/-, easily.

    3. could be on-machine or offline.
    A simply jig with 2-3 cheap gage pins, and a plunger or magnet for preload (or a rubber ball suitably placed),
    would give you a very repeatable very accurate measuring rig for == 100€ in materials, or == 10$ since you likely have an electronic dti already.

    Actual code and implementation will vary with your controller and ability to link sw to it.

    4.
    A separate junk pc (30$) using the dti or probe could easily write the offset into a single named static file on your controller.
    The controller could use this value, by reading it into the variable on every loop.

    By making the variable very small, catastrophic errors are avoided.
    Ideally it would by a nr in microns 0-6 perhaps, and an error/stop if
    1. no value/file is detected or read correctly
    1.1 value is negative, null or not present
    1.2 value is over x, say 7 (microns).

    I dislike complex lashups that invoke machine_parameters directly, either via the network or clever coding in the gcode program using machine-specific stuff - mostly these rely on specific unusual codes that may change in various ways with updates to *anything* like the machine contoller sw, probes, etc.

    Simplex systems using discrete elements, like a specific text file, usually zeroed /created at startup, are best.

    When you break down a problem into simplex units like a single text file with a one-line value, for example, debugging and tracing and troubleshooting become very simple.
    And the solution is then easily transported to other problems, machines, controllers, probes in the future.

    The simplex_approach usually can do 60.000 to millions to hundreds of millions of transactions, perfectly reliably, with zero failures.
    Most of my profitable work involved similar stuff, often in large scale and or high volume.

    Recommend:
    1. Use simple text files.
    2. Delete (ie kill) the filename at start of run and end of run, every run.
    3. Avoid large text files.
    If you want, have the routine maintain a log file separately. This is often very useful and very valuable.
    4. Perhaps even use a dummy secondary file, to initialise on every cycle.
    5. Use timestamps.

    Example:
    "(This is the offset file value for probing and adjusting offsets on a grinder.
    Version 1.2.1. Last updated 24/11/2017, at 16:48.
    It holds one integer value, the offset as measured in microns.
    Values are 0-6.)
    1
    24/11/2017 16:48:01"


    Caveats:
    I highly dislike complex opaque canned stuff.
    E.g.
    Call (mystery_machine_function#32785235) => offset.
    This is very hard to debug and prone to all sorts of risks later on.

    And no-one can maintain it, including yourself, later on.

  5. #5
    Join Date
    Dec 2017
    Country
    UNITED STATES
    State/Province
    Illinois
    Posts
    3
    Post Thanks / Like
    Likes (Given)
    0
    Likes (Received)
    0

    Default

    rather than complicate a cycle with compiling offsets for just 50 Parts, add a dress cycle. Initial dress would ensure proper size every part unless you require a fine finish then add finish dress as well.


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
  •