Loading ...
Sorry, an error occurred while loading the content.
 

G-10 Implementation

Expand Messages
  • Carol & Jerry Jankura
    Folks: I m looking at continuing to modify TurboCNC. This time, it s trying to implement the G-10 service, which loads the Parameters array with various values
    Message 1 of 8 , Mar 2, 2002
      Folks:

      I'm looking at continuing to modify TurboCNC. This time, it's trying to
      implement the G-10 service, which loads the Parameters array with various
      values of X,Y,Z,A,B,C which the G54-G59 services use to translate the axes
      zeroes.

      My problem is this:

      Dave's "parseline" function not only parses out the X, Y, Z, A, B, and C
      values, but also updates the destination array for each of these, based on
      whether you're using absolute or incremental motion. I'm thinking that I
      shouldn't update the destination array when I'm simply storing values into
      an array for later use by the computer. It would seem that the procedure
      "executeline" should be the one that updates the destination array?

      I'd appreciate hearing any of your comments on the matter. What do you think
      would be the best way of dealing with this?

      -- Carol & Jerry Jankura
      Strongsville, Ohio
      So many toys, so little time....
    • ballendo
      Jerry, The fixture offsets params are part of the 5500+ values control params array in most controls. The location within this array for any given param is
      Message 2 of 8 , Mar 3, 2002
        Jerry,

        The fixture offsets params are part of the 5500+ values "control
        params" array in most controls. The location within this array for
        any "given" param is largely consistent across MOST commercial
        controls, within these 5500 available "holes". Each offset value and
        parameter is in a fixed locations within the control array, as are
        all other "settings" (settings are those control parameters which are
        typically changed by operators or the control during operation of the
        control/machine). This "Sets you up" for higher level functionality
        later. Things like parametric programming, for example. And cutter
        radius comp, trajectory planning, and CVV.

        Implementing this 5500+ value control param array is key, IMO, to
        making your continuing efforts easier.

        So you have 36 "holes" in this large control array for fixture offset
        values, which are designed to be filled with xyzabc offset info. (one
        for each xyzabc axis offset location value, repeated 6 times;i.e.,
        one group of six per fixture offset, of which there are six, making
        the 36 total) Many modern controls have expanded upon the original 6
        (G54-59) to allow for MANY fixture offsets.

        Now the parser, upon reading a G10; just fills the holes (or replaces
        existing values) in the "correct" location(s) within the 5500+ value
        aray. When the dest values are computed from the "programmed" values
        (just before they are put in the fifo record, the relevant values (of
        the 36 params) are used to "adjust" the dest value(s) so that
        the "expected" motion happens.

        I agree that "execute line" is a better place to fill the "dest array
        holes" in the gblock array of lookahead moves, IF you only have one
        gblock available to fill.

        Most controls have a FIFO array setup, whose size used to be fixed at
        2 to 5 "blocks" of gcode. In other words, this FIFO structure (array
        of records) had one UDT record per block of lookahead allowed; which
        was filled with a single block of input gcode, from the parser.
        nowadays, this FIFO is dynamically allocated to give "enough" room to
        have enough blocks to do trajectory planning, cutcomp, gouge
        avoidance, etc. In EMC, it is up to 150 blocks in size. At least 2
        block lookahead is necessary to accomplish cutter radius comp. Many
        older controls used five blocks, to allow for the possibility of non-
        motion blocks between those required to keep cutcomp from "breaking
        down".

        So here's the way it is normally done: One large array of about 5500
        values, which include every possible variable in the control. Of the
        locations in this array, some are called settings, whose distinction
        is that they change more often than the "parameters".

        Next you have the FIFO structure (indexerLPT calls this the queue).
        As the parser does its job, this fifo is filled with one-block-at-a-
        times' info, until either the fifo is full (in the case of a fixed
        size), OR until 'enough" moves are queued to satisfy the controls
        need with regard to decel distance, etc. (This is why indexer says
        they have an Nsize lookahead; it looks ahead far enough to accomplish
        the desired motion accurately. This may require looking ahead one
        block or a thousand. (think of entering a decreasing radius spiral
        made up of short line segments, at a high speed)

        Since you have several blocks worth of "holes to fill" in the fifo,
        you CAN set the dest values directly from the parser. Then the
        execute line function will use pointers and stack techniques to
        execute the fifo and clear it as necessary, so that new block info
        can be "entered" by the parser, always working FIFO except when loops
        and subs are being processed. There you use stack pointers within the
        fifo, OR between the fifo and your sub or looped code to set
        the "active record" (UDT, representing one block of code).

        The "active record" in the fifo includes/is the source of the
        currently executing motion modes and values, and can draw upon the
        control parameters or settings as needed to carry out the commands in
        the block.

        Hope this helps you stay out of painting yourself into a corner...
        There's a pretty big difference between a control which processes one
        block at a time, and one with lookahead for all that it(Lookahead)
        allows.

        Ballendo

        P.S. Have you looked at the source for the EMC interpreter? Even
        without an understanding of C, the documentation is such that much of
        this is made clear. I can help with any "muddy" parts, drawing from
        control programs besides EMC.



        --- In turbocnc@y..., "Carol & Jerry Jankura" <jerry.jankura@s...>
        wrote:
        > Folks:
        >
        > I'm looking at continuing to modify TurboCNC. This time, it's
        trying to
        > implement the G-10 service, which loads the Parameters array with
        various
        > values of X,Y,Z,A,B,C which the G54-G59 services use to translate
        the axes
        > zeroes.
        >
        > My problem is this:
        >
        > Dave's "parseline" function not only parses out the X, Y, Z, A, B,
        and C
        > values, but also updates the destination array for each of these,
        based on
        > whether you're using absolute or incremental motion. I'm thinking
        that I
        > shouldn't update the destination array when I'm simply storing
        values into
        > an array for later use by the computer. It would seem that the
        procedure
        > "executeline" should be the one that updates the destination array?
        >
        > I'd appreciate hearing any of your comments on the matter. What do
        you think
        > would be the best way of dealing with this?
        >
        > -- Carol & Jerry Jankura
        > Strongsville, Ohio
        > So many toys, so little time....
      • Alan Marconett KM6VV
        Hi Jerry, I haven t come across the G10, nor have I implemented G54-G59, which I d like to do. I d separate the parsing of the blocks for the various parm
        Message 3 of 8 , Mar 3, 2002
          Hi Jerry,

          I haven't come across the G10, nor have I implemented G54-G59, which I'd
          like to do. I'd separate the "parsing" of the blocks for the various
          parm values, from the destination and working parms. Depending on G90,
          G20, G54, etc, you calculate the working parms.

          Alan KM6VV

          Carol & Jerry Jankura wrote:
          >
          > Folks:
          >
          > I'm looking at continuing to modify TurboCNC. This time, it's trying to
          > implement the G-10 service, which loads the Parameters array with various
          > values of X,Y,Z,A,B,C which the G54-G59 services use to translate the axes
          > zeroes.
          >
          > My problem is this:
          >
          > Dave's "parseline" function not only parses out the X, Y, Z, A, B, and C
          > values, but also updates the destination array for each of these, based on
          > whether you're using absolute or incremental motion. I'm thinking that I
          > shouldn't update the destination array when I'm simply storing values into
          > an array for later use by the computer. It would seem that the procedure
          > "executeline" should be the one that updates the destination array?
          >
          > I'd appreciate hearing any of your comments on the matter. What do you think
          > would be the best way of dealing with this?
          >
          > -- Carol & Jerry Jankura
          > Strongsville, Ohio
          > So many toys, so little time....
        • Carol & Jerry Jankura
          Hi, Alan: G-10 is the code that stores the X, Y, - C coordinates for G54- G59 (plus .1-.3) into a parameters array. The syntax is something like G10 P3 X1.4
          Message 4 of 8 , Mar 3, 2002
            Hi, Alan:

            G-10 is the code that stores the X, Y, -> C coordinates for G54->G59 (plus
            .1-.3) into a parameters array. The syntax is something like G10 P3 X1.4
            Y3.3 Z2.1 where P3 means that I'm storing information for G56.

            The problem that I'm having is that TurboCNC calculates new distances, based
            on abs/inc, in/mm, etc. in the parseline routine. Which is fine if you're
            going to use the X->C values as new locations or increments. However, with
            G10, you want to simply store the X->C values in the Parameters array and
            not modify the motor distances at all.

            So, doing this will involve playing around with the code at the bottom of
            ParseLine as well. I'm looking for ideas on the best way to do that. I've
            already got the Parameters array and can also assign values to elements in
            that array. I also write and read a .PRM file, so the values stored in the
            parameters array are persistent from execution to execution.

            -- Jerry


            |-----Original Message-----
            |From: Alan Marconett KM6VV [mailto:KM6VV@...]
            |Sent: Sunday, March 03, 2002 12:01 PM
            |To: turbocnc@yahoogroups.com
            |Subject: Re: [turbocnc] G-10 Implementation
            |
            |
            |Hi Jerry,
            |
            |I haven't come across the G10, nor have I implemented G54-G59, which I'd
            |like to do. I'd separate the "parsing" of the blocks for the various
            |parm values, from the destination and working parms. Depending on G90,
            |G20, G54, etc, you calculate the working parms.
            |
            |Alan KM6VV
            |
            |Carol & Jerry Jankura wrote:
            |>
            |> Folks:
            |>
            |> I'm looking at continuing to modify TurboCNC. This time, it's trying to
            |> implement the G-10 service, which loads the Parameters array with various
            |> values of X,Y,Z,A,B,C which the G54-G59 services use to
            |translate the axes
            |> zeroes.
            |>
            |> My problem is this:
            |>
            |> Dave's "parseline" function not only parses out the X, Y, Z, A, B, and C
            |> values, but also updates the destination array for each of
            |these, based on
            |> whether you're using absolute or incremental motion. I'm thinking that I
            |> shouldn't update the destination array when I'm simply storing
            |values into
            |> an array for later use by the computer. It would seem that the procedure
            |> "executeline" should be the one that updates the destination array?
            |>
            |> I'd appreciate hearing any of your comments on the matter. What
            |do you think
            |> would be the best way of dealing with this?
            |>
            |> -- Carol & Jerry Jankura
            |> Strongsville, Ohio
            |> So many toys, so little time....
            |
            |
            |
            |To unsubscribe from this group, send an email to:
            |turbocnc-unsubscribe@yahoogroups.com
            |
            |
            |
            |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            |
            |
            |
          • Alan Marconett KM6VV
            HI Jerry, OK, I hadn t seen it before. Then G54-59 just SELECTS the coordinate set. Sounds ambitious! I m not sure I d want to add EMC s 50,000+ parameters!
            Message 5 of 8 , Mar 4, 2002
              HI Jerry,

              OK, I hadn't seen it before. Then G54-59 just SELECTS the coordinate
              set. Sounds ambitious! I'm not sure I'd want to add EMC's 50,000+
              parameters! But a PRM file to save a few would be nice.

              Alan KM6VV


              Carol & Jerry Jankura wrote:
              >
              > Hi, Alan:
              >
              > G-10 is the code that stores the X, Y, -> C coordinates for G54->G59 (plus
              > .1-.3) into a parameters array. The syntax is something like G10 P3 X1.4
              > Y3.3 Z2.1 where P3 means that I'm storing information for G56.
              >
              > The problem that I'm having is that TurboCNC calculates new distances, based
              > on abs/inc, in/mm, etc. in the parseline routine. Which is fine if you're
              > going to use the X->C values as new locations or increments. However, with
              > G10, you want to simply store the X->C values in the Parameters array and
              > not modify the motor distances at all.
              >
              > So, doing this will involve playing around with the code at the bottom of
              > ParseLine as well. I'm looking for ideas on the best way to do that. I've
              > already got the Parameters array and can also assign values to elements in
              > that array. I also write and read a .PRM file, so the values stored in the
              > parameters array are persistent from execution to execution.
              >
              > -- Jerry
            • ballendo
              Alan, That would be 5400, or 5K+. You slipped a zero in there! Anyway, If you want to continue improving TurboCNC towards the functionality of EMC, or
              Message 6 of 8 , Mar 5, 2002
                Alan,

                That would be 5400, or 5K+. You slipped a zero in there!<G>

                Anyway, If you want to continue "improving" TurboCNC towards the
                functionality of EMC, or other commercial controls, you will
                eventually have scads of parms. So do you wanna "pay for it" now, or
                later...? If you wait, it is very likely that the parms will
                be "scattered" throughout the program, and maintennance and updates
                will be difficult, or impossible.

                I have seen this pattern over and over... a guy gets excited about
                cnc, starts writing a control. It works, so he starts selling it. As
                others add their wish list, the control code is "patched" to include
                the add-ins. This keeps getting more and more difficult, until...

                He discovers a total re-write is necessary, and THEN implements the
                kind of things I have been mentioning here. (trying to help you guys
                avoid this common path)

                Flashcut, Ah-ha!, and Master5 are three recent examples of this path.

                Hope this helps,

                Ballendo

                P.S. Really, how difficult/problematic is a 5400 element array? And
                it doesn't NEED to be the "same" as commercial controls, BUT if it
                is, then when TurboCNC eventually gets to parametric capability,
                users can use code developed from other controls; or for other
                machines (legacy code).

                P.P.S. From Jerrys message, he seems to have implemented some of this
                already.

                Starting well when programming is over half the battle... Kind of
                like putting the sewers, roads, electricity and water lines in before
                thehouses


                --- In turbocnc@y..., Alan Marconett KM6VV <KM6VV@a...> wrote:
                > HI Jerry,
                >
                > OK, I hadn't seen it before. Then G54-59 just SELECTS the
                coordinate
                > set. Sounds ambitious! I'm not sure I'd want to add EMC's 50,000+
                > parameters! But a PRM file to save a few would be nice.
                >
                > Alan KM6VV
                >
                >
                > Carol & Jerry Jankura wrote:
                > >
                > > Hi, Alan:
                > >
                > > G-10 is the code that stores the X, Y, -> C coordinates for G54-
                >G59 (plus
                > > .1-.3) into a parameters array. The syntax is something like G10
                P3 X1.4
                > > Y3.3 Z2.1 where P3 means that I'm storing information for G56.
                > >
                > > The problem that I'm having is that TurboCNC calculates new
                distances, based
                > > on abs/inc, in/mm, etc. in the parseline routine. Which is fine
                if you're
                > > going to use the X->C values as new locations or increments.
                However, with
                > > G10, you want to simply store the X->C values in the Parameters
                array and
                > > not modify the motor distances at all.
                > >
                > > So, doing this will involve playing around with the code at the
                bottom of
                > > ParseLine as well. I'm looking for ideas on the best way to do
                that. I've
                > > already got the Parameters array and can also assign values to
                elements in
                > > that array. I also write and read a .PRM file, so the values
                stored in the
                > > parameters array are persistent from execution to execution.
                > >
                > > -- Jerry
              • Carol & Jerry Jankura
                Hi, Alan - From EMC s documentation, it appears that the total is 5400, with most of those being available for the user. Relatively few are used by G-Codes --
                Message 7 of 8 , Mar 5, 2002
                  Hi, Alan -

                  From EMC's documentation, it appears that the total is 5400, with most of
                  those being available for the user. Relatively few are used by G-Codes

                  -- Jerry


                  |-----Original Message-----
                  |From: Alan Marconett KM6VV [mailto:KM6VV@...]
                  |Sent: Monday, March 04, 2002 10:46 AM
                  |To: turbocnc@yahoogroups.com
                  |Subject: Re: [turbocnc] G-10 Implementation
                  |
                  |
                  |HI Jerry,
                  |
                  |OK, I hadn't seen it before. Then G54-59 just SELECTS the coordinate
                  |set. Sounds ambitious! I'm not sure I'd want to add EMC's 50,000+
                  |parameters! But a PRM file to save a few would be nice.
                  |
                  |Alan KM6VV
                  |
                  |
                  |Carol & Jerry Jankura wrote:
                  |>
                  |> Hi, Alan:
                  |>
                  |> G-10 is the code that stores the X, Y, -> C coordinates for
                  |G54->G59 (plus
                  |> .1-.3) into a parameters array. The syntax is something like G10 P3 X1.4
                  |> Y3.3 Z2.1 where P3 means that I'm storing information for G56.
                  |>
                  |> The problem that I'm having is that TurboCNC calculates new
                  |distances, based
                  |> on abs/inc, in/mm, etc. in the parseline routine. Which is fine if you're
                  |> going to use the X->C values as new locations or increments.
                  |However, with
                  |> G10, you want to simply store the X->C values in the Parameters array and
                  |> not modify the motor distances at all.
                  |>
                  |> So, doing this will involve playing around with the code at the bottom of
                  |> ParseLine as well. I'm looking for ideas on the best way to do that. I've
                  |> already got the Parameters array and can also assign values to
                  |elements in
                  |> that array. I also write and read a .PRM file, so the values
                  |stored in the
                  |> parameters array are persistent from execution to execution.
                  |>
                  |> -- Jerry
                  |
                  |
                  |
                  |To unsubscribe from this group, send an email to:
                  |turbocnc-unsubscribe@yahoogroups.com
                  |
                  |
                  |
                  |Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
                  |
                  |
                  |
                • Alan Marconett KM6VV
                  Hi Jerry, Well, that s a better number then someone posted recently! Still, a lot of parms! And if only a few are used by gcodes. Alan KM6VV
                  Message 8 of 8 , Mar 5, 2002
                    Hi Jerry,

                    Well, that's a better number then someone posted recently! Still, a lot
                    of parms! And if only a few are used by gcodes.

                    Alan KM6VV

                    Carol & Jerry Jankura wrote:
                    >
                    > Hi, Alan -
                    >
                    > >From EMC's documentation, it appears that the total is 5400, with most of
                    > those being available for the user. Relatively few are used by G-Codes
                    >
                    > -- Jerry
                    >
                    > |-----Original Message-----
                    > |From: Alan Marconett KM6VV [mailto:KM6VV@...]
                    > |Sent: Monday, March 04, 2002 10:46 AM
                    > |To: turbocnc@yahoogroups.com
                    > |Subject: Re: [turbocnc] G-10 Implementation
                    > |
                    > |
                    > |HI Jerry,
                    > |
                    > |OK, I hadn't seen it before. Then G54-59 just SELECTS the coordinate
                    > |set. Sounds ambitious! I'm not sure I'd want to add EMC's 50,000+
                    > |parameters! But a PRM file to save a few would be nice.
                    > |
                    > |Alan KM6VV
                  Your message has been successfully submitted and would be delivered to recipients shortly.