> bool m_ReadToolFile;obsolete - always reads

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> See below
> TK
>
> --- On Fri, 7/29/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Interpreter Interpretations....
> To: DynoMotion@yahoogroups.com
> Date: Friday, July 29, 2011, 11:52 AM
>
>
>  
>
>
>
> Hello Tom,
>
> I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
>
> bool m_InitializeOnExecute; don't export 
> bool m_ReadToolFile;obsolete - always reads
> int m_start, m_end;obsolete - unused
>
>  
> After a Halt and a possible Tool replacement or Offset change
> there is a mechanism to "Resume"
>
> bool m_Resume;  Set if any part of the resume sequence is desired
> double m_ResumeSafeZ; Safe Z height to be raised to 
> int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> double m_ResumeTraverseSafeX;  Position in X
> double m_ResumeTraverseSafeY;  Position in Y
> BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
>
> Thanks,
> Brad Murry
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> See below
>
>
> --- On Fri, 7/29/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Interpreter Interpretations....
> To: DynoMotion@yahoogroups.com
> Date: Friday, July 29, 2011, 12:36 PM
>
>
>  
>
>
>
> Excellent Tom- Thanks!
>
> I do have a concern and a few more methods to clarify...
>
> > bool m_ReadToolFile;obsolete - always reads
>
> I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
>
> If the filenames are not set (they default to NULL) then they will not be read
>
> Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
>
> In case you are interested as to why I do not want to use the existing file formats:
>
> The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
>
> This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
>
> Ok, so that is a concern, here are some remaining members I am not quite sure about:
>
> MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
>
> int ExecutePC(const char *Name);
> Calling this spawns a Windows PC Application by the specified name
>
> char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
>
> CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
>
> These below are all for internal Interpreter use only
> int m_CurrentLine;
> int m_GCodeReads;
> CString m_InFile; Gcode File?
> int m_exitcode;
> int DoExecute();
> int DoExecuteComplete();
>
>
> I think after this I will have some questions on some members in the setup_struct...
>
> Thank you for your time, I think this is the last thing I need to wrap!
>
> I've heard that before :}
> Thanks
> TK
>  
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > See below
> > TK
> >
> > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> >
> >
> > From: bradodarb <bradodarb@>
> > Subject: [DynoMotion] Interpreter Interpretations....
> > To: DynoMotion@yahoogroups.com
> > Date: Friday, July 29, 2011, 11:52 AM
> >
> >
> >  
> >
> >
> >
> > Hello Tom,
> >
> > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> >
> > bool m_InitializeOnExecute; don't export 
> > bool m_ReadToolFile;obsolete - always reads
> > int m_start, m_end;obsolete - unused
> >
> >  
> > After a Halt and a possible Tool replacement or Offset change
> > there is a mechanism to "Resume"
> >
> > bool m_Resume;  Set if any part of the resume sequence is desired
> > double m_ResumeSafeZ; Safe Z height to be raised to 
> > int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> > BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> > BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> > double m_ResumeTraverseSafeX;  Position in X
> > double m_ResumeTraverseSafeY;  Position in Y
> > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> > BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> > double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> > double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> >
> > Thanks,
> > Brad Murry
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> "Thank you for your time, I think this is the last thing I need to wrap!
>
> I've heard that before :} "
>
> Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
>
> There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
>
>
> -Brad Murry
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > See below
> >
> >
> > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> >
> >
> > From: bradodarb <bradodarb@>
> > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > To: DynoMotion@yahoogroups.com
> > Date: Friday, July 29, 2011, 12:36 PM
> >
> >
> >  
> >
> >
> >
> > Excellent Tom- Thanks!
> >
> > I do have a concern and a few more methods to clarify...
> >
> > > bool m_ReadToolFile;obsolete - always reads
> >
> > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> >
> > If the filenames are not set (they default to NULL) then they will not be read
> >
> > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> >
> > In case you are interested as to why I do not want to use the existing file formats:
> >
> > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> >
> > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> >
> > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> >
> > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> >
> > int ExecutePC(const char *Name);
> > Calling this spawns a Windows PC Application by the specified name
> >
> > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> >
> > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> >
> > These below are all for internal Interpreter use only
> > int m_CurrentLine;
> > int m_GCodeReads;
> > CString m_InFile; Gcode File?
> > int m_exitcode;
> > int DoExecute();
> > int DoExecuteComplete();
> >
> >
> > I think after this I will have some questions on some members in the setup_struct...
> >
> > Thank you for your time, I think this is the last thing I need to wrap!
> >
> > I've heard that before :}
> > Thanks
> > TK
> >  
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > See below
> > > TK
> > >
> > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > Subject: [DynoMotion] Interpreter Interpretations....
> > > To: DynoMotion@yahoogroups.com
> > > Date: Friday, July 29, 2011, 11:52 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Hello Tom,
> > >
> > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > >
> > > bool m_InitializeOnExecute; don't export 
> > > bool m_ReadToolFile;obsolete - always reads
> > > int m_start, m_end;obsolete - unused
> > >
> > >  
> > > After a Halt and a possible Tool replacement or Offset change
> > > there is a mechanism to "Resume"
> > >
> > > bool m_Resume;  Set if any part of the resume sequence is desired
> > > double m_ResumeSafeZ; Safe Z height to be raised to 
> > > int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> > > BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> > > BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> > > double m_ResumeTraverseSafeX;  Position in X
> > > double m_ResumeTraverseSafeY;  Position in Y
> > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> > > BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> > > double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> > > double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > >
> > > Thanks,
> > > Brad Murry
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Tom,
>
> I see some of the setup params are not commented(mut most are)
>
> Can you clarify these?:
> ON_OFF block_delete;
> int cutter_radius_compensation;
> double cycle_z;
> int current_line;
>
> fpos_t sub_stack_pos[MAX_SUB_STACK];
> fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> int sub_stack_lineno[MAX_SUB_STACK];
> int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> int sub_stack_call_cnt[MAX_SUB_STACK];
> int stacki;
>
> Thank you,
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > "Thank you for your time, I think this is the last thing I need to wrap!
> >
> > I've heard that before :} "
> >
> > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> >
> > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> >
> >
> > -Brad Murry
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > See below
> > >
> > >
> > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > To: DynoMotion@yahoogroups.com
> > > Date: Friday, July 29, 2011, 12:36 PM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Excellent Tom- Thanks!
> > >
> > > I do have a concern and a few more methods to clarify...
> > >
> > > > bool m_ReadToolFile;obsolete - always reads
> > >
> > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > >
> > > If the filenames are not set (they default to NULL) then they will not be read
> > >
> > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > >
> > > In case you are interested as to why I do not want to use the existing file formats:
> > >
> > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > >
> > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > >
> > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > >
> > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > >
> > > int ExecutePC(const char *Name);
> > > Calling this spawns a Windows PC Application by the specified name
> > >
> > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > >
> > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > >
> > > These below are all for internal Interpreter use only
> > > int m_CurrentLine;
> > > int m_GCodeReads;
> > > CString m_InFile; Gcode File?
> > > int m_exitcode;
> > > int DoExecute();
> > > int DoExecuteComplete();
> > >
> > >
> > > I think after this I will have some questions on some members in the setup_struct...
> > >
> > > Thank you for your time, I think this is the last thing I need to wrap!
> > >
> > > I've heard that before :}
> > > Thanks
> > > TK
> > >  
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > See below
> > > > TK
> > > >
> > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > To: DynoMotion@yahoogroups.com
> > > > Date: Friday, July 29, 2011, 11:52 AM
> > > >
> > > >
> > > >  
> > > >
> > > >
> > > >
> > > > Hello Tom,
> > > >
> > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > >
> > > > bool m_InitializeOnExecute; don't export 
> > > > bool m_ReadToolFile;obsolete - always reads
> > > > int m_start, m_end;obsolete - unused
> > > >
> > > >  
> > > > After a Halt and a possible Tool replacement or Offset change
> > > > there is a mechanism to "Resume"
> > > >
> > > > bool m_Resume;  Set if any part of the resume sequence is desired
> > > > double m_ResumeSafeZ; Safe Z height to be raised to 
> > > > int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> > > > BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> > > > BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> > > > double m_ResumeTraverseSafeX;  Position in X
> > > > double m_ResumeTraverseSafeY;  Position in Y
> > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> > > > BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> > > > double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> > > > double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > >
> > > > Thanks,
> > > > Brad Murry
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello,
>
> Int the case of:
>
>
> int tool_table_index; // tool index used with cutter comp
>
> double tool_length_offset; // current tool length offset
>
> int length_offset_index; // for use with tool length offsets
>
> and
>
> double cutter_comp_radius; // current cutter compensation radius
>
>
> How do these values interact/override each other?
>
> Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> by updating the tool_length_offset and cutter_comp_radius?
>
> Just trying to get my head wrapped 'round it all.
>
> Thanks,
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Tom,
> >
> > I see some of the setup params are not commented(mut most are)
> >
> > Can you clarify these?:
> > ON_OFF block_delete;
> > int cutter_radius_compensation;
> > double cycle_z;
> > int current_line;
> >
> > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > int sub_stack_lineno[MAX_SUB_STACK];
> > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > int sub_stack_call_cnt[MAX_SUB_STACK];
> > int stacki;
> >
> > Thank you,
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > "Thank you for your time, I think this is the last thing I need to wrap!
> > >
> > > I've heard that before :} "
> > >
> > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > >
> > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > See below
> > > >
> > > >
> > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > To: DynoMotion@yahoogroups.com
> > > > Date: Friday, July 29, 2011, 12:36 PM
> > > >
> > > >
> > > >  
> > > >
> > > >
> > > >
> > > > Excellent Tom- Thanks!
> > > >
> > > > I do have a concern and a few more methods to clarify...
> > > >
> > > > > bool m_ReadToolFile;obsolete - always reads
> > > >
> > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > >
> > > > If the filenames are not set (they default to NULL) then they will not be read
> > > >
> > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > >
> > > > In case you are interested as to why I do not want to use the existing file formats:
> > > >
> > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > >
> > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > >
> > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > >
> > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > >
> > > > int ExecutePC(const char *Name);
> > > > Calling this spawns a Windows PC Application by the specified name
> > > >
> > > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > > >
> > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > >
> > > > These below are all for internal Interpreter use only
> > > > int m_CurrentLine;
> > > > int m_GCodeReads;
> > > > CString m_InFile; Gcode File?
> > > > int m_exitcode;
> > > > int DoExecute();
> > > > int DoExecuteComplete();
> > > >
> > > >
> > > > I think after this I will have some questions on some members in the setup_struct...
> > > >
> > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > >
> > > > I've heard that before :}
> > > > Thanks
> > > > TK
> > > >  
> > > >
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > See below
> > > > > TK
> > > > >
> > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > >
> > > > >
> > > > >  
> > > > >
> > > > >
> > > > >
> > > > > Hello Tom,
> > > > >
> > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > >
> > > > > bool m_InitializeOnExecute; don't export 
> > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > int m_start, m_end;obsolete - unused
> > > > >
> > > > >  
> > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > there is a mechanism to "Resume"
> > > > >
> > > > > bool m_Resume;  Set if any part of the resume sequence is desired
> > > > > double m_ResumeSafeZ; Safe Z height to be raised to 
> > > > > int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> > > > > BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> > > > > BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> > > > > double m_ResumeTraverseSafeX;  Position in X
> > > > > double m_ResumeTraverseSafeY;  Position in Y
> > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> > > > > BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> > > > > double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> > > > > double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > >
> > > > > Thanks,
> > > > > Brad Murry
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> Again I think most of these are used internally.  For example to change the Tool Index the User would execute a Hxx command in G Code.  However KMotionCNC does display some settings on the screen like current tool and allows the User to change the tool directly, but I think it simulates GCode to effect the change rather than modifying the internal variables.
>
> TK
>
> --- On Fri, 7/29/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Interpreter Interpretations....
> To: DynoMotion@yahoogroups.com
> Date: Friday, July 29, 2011, 3:40 PM
>
>
>  
>
>
>
> Hello,
>
> Int the case of:
>
> int tool_table_index; // tool index used with cutter comp
>
> double tool_length_offset; // current tool length offset
>
> int length_offset_index; // for use with tool length offsets
>
> and
>
> double cutter_comp_radius; // current cutter compensation radius
>
> How do these values interact/override each other?
>
> Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> by updating the tool_length_offset and cutter_comp_radius?
>
> Just trying to get my head wrapped 'round it all.
>
> Thanks,
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Tom,
> >
> > I see some of the setup params are not commented(mut most are)
> >
> > Can you clarify these?:
> > ON_OFF block_delete;
> > int cutter_radius_compensation;
> > double cycle_z;
> > int current_line;
> >
> > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > int sub_stack_lineno[MAX_SUB_STACK];
> > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > int sub_stack_call_cnt[MAX_SUB_STACK];
> > int stacki;
> >
> > Thank you,
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > "Thank you for your time, I think this is the last thing I need to wrap!
> > >
> > > I've heard that before :} "
> > >
> > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > >
> > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > >
> > >
> > > -Brad Murry
> > >
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > See below
> > > >
> > > >
> > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > To: DynoMotion@yahoogroups.com
> > > > Date: Friday, July 29, 2011, 12:36 PM
> > > >
> > > >
> > > >  
> > > >
> > > >
> > > >
> > > > Excellent Tom- Thanks!
> > > >
> > > > I do have a concern and a few more methods to clarify...
> > > >
> > > > > bool m_ReadToolFile;obsolete - always reads
> > > >
> > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > >
> > > > If the filenames are not set (they default to NULL) then they will not be read
> > > >
> > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > >
> > > > In case you are interested as to why I do not want to use the existing file formats:
> > > >
> > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > >
> > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > >
> > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > >
> > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > >
> > > > int ExecutePC(const char *Name);
> > > > Calling this spawns a Windows PC Application by the specified name
> > > >
> > > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > > >
> > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > >
> > > > These below are all for internal Interpreter use only
> > > > int m_CurrentLine;
> > > > int m_GCodeReads;
> > > > CString m_InFile; Gcode File?
> > > > int m_exitcode;
> > > > int DoExecute();
> > > > int DoExecuteComplete();
> > > >
> > > >
> > > > I think after this I will have some questions on some members in the setup_struct...
> > > >
> > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > >
> > > > I've heard that before :}
> > > > Thanks
> > > > TK
> > > >  
> > > >
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > See below
> > > > > TK
> > > > >
> > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > >
> > > > >
> > > > >  
> > > > >
> > > > >
> > > > >
> > > > > Hello Tom,
> > > > >
> > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > >
> > > > > bool m_InitializeOnExecute; don't export 
> > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > int m_start, m_end;obsolete - unused
> > > > >
> > > > >  
> > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > there is a mechanism to "Resume"
> > > > >
> > > > > bool m_Resume;  Set if any part of the resume sequence is desired
> > > > > double m_ResumeSafeZ; Safe Z height to be raised to 
> > > > > int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> > > > > BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> > > > > BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> > > > > double m_ResumeTraverseSafeX;  Position in X
> > > > > double m_ResumeTraverseSafeY;  Position in Y
> > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> > > > > BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> > > > > double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> > > > > double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > >
> > > > > Thanks,
> > > > > Brad Murry
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> As far as CoordMotion class is concerned Sequence number and ID they are just two arbitrary pieces of information that the caller (normally a Gcode Interpreter) passed in with entered path calls (arcs and lines), and passed through and kept associated with Trajectory Planner Motion Segments, so that in the event of a Halt, the Library can determine which segment we halted within and determine the corresponding Sequence Number an ID.  Realize that the Application generating the motion needs to be working seconds ahead of the actual machine tool which could easily be thousands of segments behind.  So if a Halt occurs the Application is likely to want to rewind back to the place that was actually executed last.  So the Sequence Number and ID can be used to identify what point the application needs to return to to re-sync with the actual current halted machine tool position.
>  
> Realize that sometimes multiple pieces of path that are passed in might be combined together into a single motion segment if they are tiny or collinear for example.  Conversely a single piece of path may be broken into multiple segments for various reasons such as it would take excessively long to execute or needs to be non-linearly corrected at more than just the end points.  Or if 3D facet rounding is performed.
>  
> With regard to the G Code Interpreter we basically want to return to the line of GCode that created the motion where we Halted.  Passing the GCode line number through all the processes doesn't work well because of subroutine calls in the GCode.  Rewinding thousands of GCode lines might loop backwards through the same G Code line multiple times but with the Interpreter in a different state each time.  So instead a unique "Sequence" Number is used that simply increments for each GCode Block.
>  
> Furthermore simply returning to the correct line of GCode is not sufficient to know how to resume and correctly advance to the next line of GCode from that point.  This is because in some cases several operations are created by a single line of Gcode mainly because of tool radius compensation.  For example with compensation on, to cut a rectangle (which is defined by a rectangle with 4 G1 commands), 4 lines and 4 arcs are actually needed.  The ID code is used in these cases to know which phase of the GCode block to properly reset the Interpreter back to.
>  
> If you are using our Interpreter all this functionality should be handled automatically for you without having to worry about it.
>  
> HTH
> TK
>  
>  
>
>
> --- On Fri, 7/29/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Interpreter Interpretations....
> To: DynoMotion@yahoogroups.com
> Date: Friday, July 29, 2011, 4:15 PM
>
>
>  
>
>
>
> Sorry for the constant deluge.....
>
> I am confused by a common pair of variables I see throughout coordmotion and interpreter
>
> Sequence and ID
>
> What are they used for and what is the diff?
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Hello,
> >
> > Int the case of:
> >
> >
> > int tool_table_index; // tool index used with cutter comp
> >
> > double tool_length_offset; // current tool length offset
> >
> > int length_offset_index; // for use with tool length offsets
> >
> > and
> >
> > double cutter_comp_radius; // current cutter compensation radius
> >
> >
> > How do these values interact/override each other?
> >
> > Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> > by updating the tool_length_offset and cutter_comp_radius?
> >
> > Just trying to get my head wrapped 'round it all.
> >
> > Thanks,
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > Tom,
> > >
> > > I see some of the setup params are not commented(mut most are)
> > >
> > > Can you clarify these?:
> > > ON_OFF block_delete;
> > > int cutter_radius_compensation;
> > > double cycle_z;
> > > int current_line;
> > >
> > > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > > int sub_stack_lineno[MAX_SUB_STACK];
> > > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > > int sub_stack_call_cnt[MAX_SUB_STACK];
> > > int stacki;
> > >
> > > Thank you,
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > >
> > > > "Thank you for your time, I think this is the last thing I need to wrap!
> > > >
> > > > I've heard that before :} "
> > > >
> > > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > > >
> > > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > See below
> > > > >
> > > > >
> > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Date: Friday, July 29, 2011, 12:36 PM
> > > > >
> > > > >
> > > > >  
> > > > >
> > > > >
> > > > >
> > > > > Excellent Tom- Thanks!
> > > > >
> > > > > I do have a concern and a few more methods to clarify...
> > > > >
> > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > >
> > > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > > >
> > > > > If the filenames are not set (they default to NULL) then they will not be read
> > > > >
> > > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > > >
> > > > > In case you are interested as to why I do not want to use the existing file formats:
> > > > >
> > > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > > >
> > > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > > >
> > > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > > >
> > > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > > >
> > > > > int ExecutePC(const char *Name);
> > > > > Calling this spawns a Windows PC Application by the specified name
> > > > >
> > > > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > > > >
> > > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > > >
> > > > > These below are all for internal Interpreter use only
> > > > > int m_CurrentLine;
> > > > > int m_GCodeReads;
> > > > > CString m_InFile; Gcode File?
> > > > > int m_exitcode;
> > > > > int DoExecute();
> > > > > int DoExecuteComplete();
> > > > >
> > > > >
> > > > > I think after this I will have some questions on some members in the setup_struct...
> > > > >
> > > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > > >
> > > > > I've heard that before :}
> > > > > Thanks
> > > > > TK
> > > > >  
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > See below
> > > > > > TK
> > > > > >
> > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > >
> > > > > >
> > > > > > From: bradodarb <bradodarb@>
> > > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > > >
> > > > > >
> > > > > >  
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > > >
> > > > > > bool m_InitializeOnExecute; don't export 
> > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > int m_start, m_end;obsolete - unused
> > > > > >
> > > > > >  
> > > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > > there is a mechanism to "Resume"
> > > > > >
> > > > > > bool m_Resume;  Set if any part of the resume sequence is desired
> > > > > > double m_ResumeSafeZ; Safe Z height to be raised to 
> > > > > > int m_ResumeSafeRelAbs;  Specifies if the Z heights are absolute or relative
> > > > > > BOOL m_ResumeMoveToSafeZ;  Specifies whether or not the Z should be first moved up
> > > > > > BOOL m_ResumeTraverseXY;  Specifies whether an xy motion should be made back to some position
> > > > > > double m_ResumeTraverseSafeX;  Position in X
> > > > > > double m_ResumeTraverseSafeY;  Position in Y
> > > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > > int m_ResumeSafeSpindleCWCCW;  Specifies Spindle direction if it is to be re-started
> > > > > > BOOL m_ResumeDoSafeFeedZ;  Specifies if the Z should then be fed down to some height
> > > > > > double m_ResumeFeedSafeZ;  Specifies height Z should be fed down to
> > > > > > double m_ResumeResumeFeedRate;  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > > >
> > > > > > Thanks,
> > > > > > Brad Murry
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Yes.  If you search in KMotionCNC if the User clicks on the MM or inch Radio buttons it calls:
>  
> void CKMotionCNCDlg::Onmm()
> {
>     DoGCodeLine("G21");
> }
> void CKMotionCNCDlg::Oninch()
> {
>     DoGCodeLine("G20");
> }
>  
>  
> Which creates a 1 line GCode File and executes it like the MDI.
>
> TK
>  
>
> --- On Fri, 7/29/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Interpreter Interpretations....
> To: DynoMotion@yahoogroups.com
> Date: Friday, July 29, 2011, 4:32 PM
>
>
>  
>
>
>
> I see, so perhaps some/all setup params should be made as "read only"(only provide get value functions) when I export?
>
> " I think it simulates GCode to effect the change rather than modifying the internal variables"
>
> Does this mean it drops it into MDI mode and makes the calls and then back? I guess I would be able to tell in the code...
>
> Thanks again,
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Brad,
> >  
> > Again I think most of these are used internally.  For example to change the Tool Index the User would execute a Hxx command in G Code.  However KMotionCNC does display some settings on the screen like current tool and allows the User to change the tool directly, but I think it simulates GCode to effect the change rather than modifying the internal variables.
> >
> > TK
> >
> > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> >
> >
> > From: bradodarb <bradodarb@>
> > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > To: DynoMotion@yahoogroups.com
> > Date: Friday, July 29, 2011, 3:40 PM
> >
> >
> >  
> >
> >
> >
> > Hello,
> >
> > Int the case of:
> >
> > int tool_table_index; // tool index used with cutter comp
> >
> > double tool_length_offset; // current tool length offset
> >
> > int length_offset_index; // for use with tool length offsets
> >
> > and
> >
> > double cutter_comp_radius; // current cutter compensation radius
> >
> > How do these values interact/override each other?
> >
> > Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> > by updating the tool_length_offset and cutter_comp_radius?
> >
> > Just trying to get my head wrapped 'round it all.
> >
> > Thanks,
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > Tom,
> > >
> > > I see some of the setup params are not commented(mut most are)
> > >
> > > Can you clarify these?:
> > > ON_OFF block_delete;
> > > int cutter_radius_compensation;
> > > double cycle_z;
> > > int current_line;
> > >
> > > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > > int sub_stack_lineno[MAX_SUB_STACK];
> > > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > > int sub_stack_call_cnt[MAX_SUB_STACK];
> > > int stacki;
> > >
> > > Thank you,
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > >
> > > > "Thank you for your time, I think this is the last thing I need to wrap!
> > > >
> > > > I've heard that before :} "
> > > >
> > > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > > >
> > > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > > >
> > > >
> > > > -Brad Murry
> > > >
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > See below
> > > > >
> > > > >
> > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Date: Friday, July 29, 2011, 12:36 PM
> > > > >
> > > > >
> > > > >  
> > > > >
> > > > >
> > > > >
> > > > > Excellent Tom- Thanks!
> > > > >
> > > > > I do have a concern and a few more methods to clarify...
> > > > >
> > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > >
> > > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > > >
> > > > > If the filenames are not set (they default to NULL) then they will not be read
> > > > >
> > > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > > >
> > > > > In case you are interested as to why I do not want to use the existing file formats:
> > > > >
> > > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > > >
> > > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > > >
> > > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > > >
> > > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > > >
> > > > > int ExecutePC(const char *Name);
> > > > > Calling this spawns a Windows PC Application by the specified name
> > > > >
> > > > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > > > >
> > > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > > >
> > > > > These below are all for internal Interpreter use only
> > > > > int m_CurrentLine;
> > > > > int m_GCodeReads;
> > > > > CString m_InFile; Gcode File?
> > > > > int m_exitcode;
> > > > > int DoExecute();
> > > > > int DoExecuteComplete();
> > > > >
> > > > >
> > > > > I think after this I will have some questions on some members in the setup_struct...
> > > > >
> > > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > > >
> > > > > I've heard that before :}
> > > > > Thanks
> > > > > TK
> > > > >  
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > See below
> > > > > > TK
> > > > > >
> > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > >
> > > > > >
> > > > > > From: bradodarb <bradodarb@>
> > > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > > >
> > > > > >
> > > > > > ÃÆ'‚ 
> > > > > >
> > > > > >
> > > > > >
> > > > > > Hello Tom,
> > > > > >
> > > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > > >
> > > > > > bool m_InitializeOnExecute;ÃÆ'‚ don't exportÃÆ'‚ 
> > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > int m_start, m_end;obsolete - unused
> > > > > >
> > > > > > ÃÆ'‚ 
> > > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > > there is a mechanism to "Resume"
> > > > > >
> > > > > > bool m_Resume;ÃÆ'‚  Set if any partÃÆ'‚ of theÃÆ'‚ resume sequence is desired
> > > > > > double m_ResumeSafeZ; Safe Z height to be raised toÃÆ'‚ 
> > > > > > int m_ResumeSafeRelAbs;ÃÆ'‚  Specifies if the Z heights are absolute or relative
> > > > > > BOOL m_ResumeMoveToSafeZ;ÃÆ'‚  Specifies whether or not the Z should be first moved up
> > > > > > BOOL m_ResumeTraverseXY;ÃÆ'‚  Specifies whether an xy motion should be made back to some position
> > > > > > double m_ResumeTraverseSafeX;ÃÆ'‚  Position in X
> > > > > > double m_ResumeTraverseSafeY;ÃÆ'‚  Position in Y
> > > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > > int m_ResumeSafeSpindleCWCCW;ÃÆ'‚  Specifies Spindle direction if it is to be re-started
> > > > > > BOOL m_ResumeDoSafeFeedZ;ÃÆ'‚  Specifies if the Z should then be fed down to some height
> > > > > > double m_ResumeFeedSafeZ;ÃÆ'‚  Specifies height Z should be fed down to
> > > > > > double m_ResumeResumeFeedRate;ÃÆ'‚  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > > >
> > > > > > Thanks,
> > > > > > Brad Murry
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
>
>
> I saw that, and my first response is...really? I realize this is a potential
> issue with the EMC and I am not knocking DM. It just seems to be a odd way to
> go about it.
>
> Is it absolutely necesary to create a file?
>
>
> Anyone else here doing this?
>
> Andrew Erwwod, how did you handle this(assuming you did) in your
> implementation?
>
> -Brad Murry
>
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Yes.  If you search in KMotionCNC if the User clicks on the MM or inch Radio buttons it calls:
> >  
> > void CKMotionCNCDlg::Onmm()
> > {
> >     DoGCodeLine("G21");
> > }
> > void CKMotionCNCDlg::Oninch()
> > {
> >     DoGCodeLine("G20");
> > }
> >  
> >  
> > Which creates a 1 line GCode File and executes it like the MDI.
> >
> > TK
> >  
> >
> > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> >
> >
> > From: bradodarb <bradodarb@>
> > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > To: DynoMotion@yahoogroups.com
> > Date: Friday, July 29, 2011, 4:32 PM
> >
> >
> >  
> >
> >
> >
> > I see, so perhaps some/all setup params should be made as "read only"(only provide get value functions) when I export?
> >
> > " I think it simulates GCode to effect the change rather than modifying the internal variables"
> >
> > Does this mean it drops it into MDI mode and makes the calls and then back? I guess I would be able to tell in the code...
> >
> > Thanks again,
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Brad,
> > >  
> > > Again I think most of these are used internally.  For example to change the Tool Index the User would execute a Hxx command in G Code.  However KMotionCNC does display some settings on the screen like current tool and allows the User to change the tool directly, but I think it simulates GCode to effect the change rather than modifying the internal variables.
> > >
> > > TK
> > >
> > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > To: DynoMotion@yahoogroups.com
> > > Date: Friday, July 29, 2011, 3:40 PM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Hello,
> > >
> > > Int the case of:
> > >
> > > int tool_table_index; // tool index used with cutter comp
> > >
> > > double tool_length_offset; // current tool length offset
> > >
> > > int length_offset_index; // for use with tool length offsets
> > >
> > > and
> > >
> > > double cutter_comp_radius; // current cutter compensation radius
> > >
> > > How do these values interact/override each other?
> > >
> > > Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> > > by updating the tool_length_offset and cutter_comp_radius?
> > >
> > > Just trying to get my head wrapped 'round it all.
> > >
> > > Thanks,
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > >
> > > > Tom,
> > > >
> > > > I see some of the setup params are not commented(mut most are)
> > > >
> > > > Can you clarify these?:
> > > > ON_OFF block_delete;
> > > > int cutter_radius_compensation;
> > > > double cycle_z;
> > > > int current_line;
> > > >
> > > > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > > > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > > > int sub_stack_lineno[MAX_SUB_STACK];
> > > > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > > > int sub_stack_call_cnt[MAX_SUB_STACK];
> > > > int stacki;
> > > >
> > > > Thank you,
> > > >
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > > >
> > > > > "Thank you for your time, I think this is the last thing I need to wrap!
> > > > >
> > > > > I've heard that before :} "
> > > > >
> > > > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > > > >
> > > > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > > > >
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > >
> > > > > > See below
> > > > > >
> > > > > >
> > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > >
> > > > > >
> > > > > > From: bradodarb <bradodarb@>
> > > > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > > > To: DynoMotion@yahoogroups.com
> > > > > > Date: Friday, July 29, 2011, 12:36 PM
> > > > > >
> > > > > >
> > > > > >  
> > > > > >
> > > > > >
> > > > > >
> > > > > > Excellent Tom- Thanks!
> > > > > >
> > > > > > I do have a concern and a few more methods to clarify...
> > > > > >
> > > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > >
> > > > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > > > >
> > > > > > If the filenames are not set (they default to NULL) then they will not be read
> > > > > >
> > > > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > > > >
> > > > > > In case you are interested as to why I do not want to use the existing file formats:
> > > > > >
> > > > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > > > >
> > > > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > > > >
> > > > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > > > >
> > > > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > > > >
> > > > > > int ExecutePC(const char *Name);
> > > > > > Calling this spawns a Windows PC Application by the specified name
> > > > > >
> > > > > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > > > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > > > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > > > > >
> > > > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > > > >
> > > > > > These below are all for internal Interpreter use only
> > > > > > int m_CurrentLine;
> > > > > > int m_GCodeReads;
> > > > > > CString m_InFile; Gcode File?
> > > > > > int m_exitcode;
> > > > > > int DoExecute();
> > > > > > int DoExecuteComplete();
> > > > > >
> > > > > >
> > > > > > I think after this I will have some questions on some members in the setup_struct...
> > > > > >
> > > > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > > > >
> > > > > > I've heard that before :}
> > > > > > Thanks
> > > > > > TK
> > > > > >  
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > See below
> > > > > > > TK
> > > > > > >
> > > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > > >
> > > > > > >
> > > > > > > From: bradodarb <bradodarb@>
> > > > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > > > >
> > > > > > >
> > > > > > > ÃÆ'‚ 
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Hello Tom,
> > > > > > >
> > > > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > > > >
> > > > > > > bool m_InitializeOnExecute;ÃÆ'‚ don't exportÃÆ'‚ 
> > > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > > int m_start, m_end;obsolete - unused
> > > > > > >
> > > > > > > ÃÆ'‚ 
> > > > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > > > there is a mechanism to "Resume"
> > > > > > >
> > > > > > > bool m_Resume;ÃÆ'‚  Set if any partÃÆ'‚ of theÃÆ'‚ resume sequence is desired
> > > > > > > double m_ResumeSafeZ; Safe Z height to be raised toÃÆ'‚ 
> > > > > > > int m_ResumeSafeRelAbs;ÃÆ'‚  Specifies if the Z heights are absolute or relative
> > > > > > > BOOL m_ResumeMoveToSafeZ;ÃÆ'‚  Specifies whether or not the Z should be first moved up
> > > > > > > BOOL m_ResumeTraverseXY;ÃÆ'‚  Specifies whether an xy motion should be made back to some position
> > > > > > > double m_ResumeTraverseSafeX;ÃÆ'‚  Position in X
> > > > > > > double m_ResumeTraverseSafeY;ÃÆ'‚  Position in Y
> > > > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > > > int m_ResumeSafeSpindleCWCCW;ÃÆ'‚  Specifies Spindle direction if it is to be re-started
> > > > > > > BOOL m_ResumeDoSafeFeedZ;ÃÆ'‚  Specifies if the Z should then be fed down to some height
> > > > > > > double m_ResumeFeedSafeZ;ÃÆ'‚  Specifies height Z should be fed down to
> > > > > > > double m_ResumeResumeFeedRate;ÃÆ'‚  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Brad Murry
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Having a look at
> rs274ngc.cpp
>
>
> This could be good ;) , it looks like it is using the settings inside the methods.
>
> Anyone willing to test some of this out?
>
> I guess I can overwrite the current DoGCodeLine and see if it affects my axis positions....
>
>
>
> -Brad
>
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> >
> >
> > I saw that, and my first response is...really? I realize this is a potential
> > issue with the EMC and I am not knocking DM. It just seems to be a odd way to
> > go about it.
> >
> > Is it absolutely necesary to create a file?
> >
> >
> > Anyone else here doing this?
> >
> > Andrew Erwwod, how did you handle this(assuming you did) in your
> > implementation?
> >
> > -Brad Murry
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Yes.  If you search in KMotionCNC if the User clicks on the MM or inch Radio buttons it calls:
> > >  
> > > void CKMotionCNCDlg::Onmm()
> > > {
> > >     DoGCodeLine("G21");
> > > }
> > > void CKMotionCNCDlg::Oninch()
> > > {
> > >     DoGCodeLine("G20");
> > > }
> > >  
> > >  
> > > Which creates a 1 line GCode File and executes it like the MDI.
> > >
> > > TK
> > >  
> > >
> > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > To: DynoMotion@yahoogroups.com
> > > Date: Friday, July 29, 2011, 4:32 PM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > I see, so perhaps some/all setup params should be made as "read only"(only provide get value functions) when I export?
> > >
> > > " I think it simulates GCode to effect the change rather than modifying the internal variables"
> > >
> > > Does this mean it drops it into MDI mode and makes the calls and then back? I guess I would be able to tell in the code...
> > >
> > > Thanks again,
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Brad,
> > > >  
> > > > Again I think most of these are used internally.  For example to change the Tool Index the User would execute a Hxx command in G Code.  However KMotionCNC does display some settings on the screen like current tool and allows the User to change the tool directly, but I think it simulates GCode to effect the change rather than modifying the internal variables.
> > > >
> > > > TK
> > > >
> > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > To: DynoMotion@yahoogroups.com
> > > > Date: Friday, July 29, 2011, 3:40 PM
> > > >
> > > >
> > > >  
> > > >
> > > >
> > > >
> > > > Hello,
> > > >
> > > > Int the case of:
> > > >
> > > > int tool_table_index; // tool index used with cutter comp
> > > >
> > > > double tool_length_offset; // current tool length offset
> > > >
> > > > int length_offset_index; // for use with tool length offsets
> > > >
> > > > and
> > > >
> > > > double cutter_comp_radius; // current cutter compensation radius
> > > >
> > > > How do these values interact/override each other?
> > > >
> > > > Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> > > > by updating the tool_length_offset and cutter_comp_radius?
> > > >
> > > > Just trying to get my head wrapped 'round it all.
> > > >
> > > > Thanks,
> > > >
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > > >
> > > > > Tom,
> > > > >
> > > > > I see some of the setup params are not commented(mut most are)
> > > > >
> > > > > Can you clarify these?:
> > > > > ON_OFF block_delete;
> > > > > int cutter_radius_compensation;
> > > > > double cycle_z;
> > > > > int current_line;
> > > > >
> > > > > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > > > > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > > > > int sub_stack_lineno[MAX_SUB_STACK];
> > > > > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > > > > int sub_stack_call_cnt[MAX_SUB_STACK];
> > > > > int stacki;
> > > > >
> > > > > Thank you,
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > > > >
> > > > > > "Thank you for your time, I think this is the last thing I need to wrap!
> > > > > >
> > > > > > I've heard that before :} "
> > > > > >
> > > > > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > > > > >
> > > > > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > > > > >
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > >
> > > > > > > See below
> > > > > > >
> > > > > > >
> > > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > > >
> > > > > > >
> > > > > > > From: bradodarb <bradodarb@>
> > > > > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > Date: Friday, July 29, 2011, 12:36 PM
> > > > > > >
> > > > > > >
> > > > > > >  
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Excellent Tom- Thanks!
> > > > > > >
> > > > > > > I do have a concern and a few more methods to clarify...
> > > > > > >
> > > > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > >
> > > > > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > > > > >
> > > > > > > If the filenames are not set (they default to NULL) then they will not be read
> > > > > > >
> > > > > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > > > > >
> > > > > > > In case you are interested as to why I do not want to use the existing file formats:
> > > > > > >
> > > > > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > > > > >
> > > > > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > > > > >
> > > > > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > > > > >
> > > > > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.  This structure defines what is to be performed for various M Codes.  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > > > > >
> > > > > > > int ExecutePC(const char *Name);
> > > > > > > Calling this spawns a Windows PC Application by the specified name
> > > > > > >
> > > > > > > char ToolFile[MAX_PATH];  Can be used to define Tool Parameters
> > > > > > > char SetupFile[MAX_PATH];  Can be used to define inital Interpreter Settings
> > > > > > > char GeoFile[MAX_PATH];  Can be used to define a 2.5D Geometric correction file
> > > > > > >
> > > > > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > > > > >
> > > > > > > These below are all for internal Interpreter use only
> > > > > > > int m_CurrentLine;
> > > > > > > int m_GCodeReads;
> > > > > > > CString m_InFile; Gcode File?
> > > > > > > int m_exitcode;
> > > > > > > int DoExecute();
> > > > > > > int DoExecuteComplete();
> > > > > > >
> > > > > > >
> > > > > > > I think after this I will have some questions on some members in the setup_struct...
> > > > > > >
> > > > > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > > > > >
> > > > > > > I've heard that before :}
> > > > > > > Thanks
> > > > > > > TK
> > > > > > >  
> > > > > > >
> > > > > > > -Brad Murry
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > See below
> > > > > > > > TK
> > > > > > > >
> > > > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > From: bradodarb <bradodarb@>
> > > > > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > > > > >
> > > > > > > >
> > > > > > > > ÃÆ'‚ 
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Hello Tom,
> > > > > > > >
> > > > > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > > > > >
> > > > > > > > bool m_InitializeOnExecute;ÃÆ'‚ don't exportÃÆ'‚ 
> > > > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > > > int m_start, m_end;obsolete - unused
> > > > > > > >
> > > > > > > > ÃÆ'‚ 
> > > > > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > > > > there is a mechanism to "Resume"
> > > > > > > >
> > > > > > > > bool m_Resume;ÃÆ'‚  Set if any partÃÆ'‚ of theÃÆ'‚ resume sequence is desired
> > > > > > > > double m_ResumeSafeZ; Safe Z height to be raised toÃÆ'‚ 
> > > > > > > > int m_ResumeSafeRelAbs;ÃÆ'‚  Specifies if the Z heights are absolute or relative
> > > > > > > > BOOL m_ResumeMoveToSafeZ;ÃÆ'‚  Specifies whether or not the Z should be first moved up
> > > > > > > > BOOL m_ResumeTraverseXY;ÃÆ'‚  Specifies whether an xy motion should be made back to some position
> > > > > > > > double m_ResumeTraverseSafeX;ÃÆ'‚  Position in X
> > > > > > > > double m_ResumeTraverseSafeY;ÃÆ'‚  Position in Y
> > > > > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > > > > int m_ResumeSafeSpindleCWCCW;ÃÆ'‚  Specifies Spindle direction if it is to be re-started
> > > > > > > > BOOL m_ResumeDoSafeFeedZ;ÃÆ'‚  Specifies if the Z should then be fed down to some height
> > > > > > > > double m_ResumeFeedSafeZ;ÃÆ'‚  Specifies height Z should be fed down to
> > > > > > > > double m_ResumeResumeFeedRate;ÃÆ'‚  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > > Brad Murry
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> I'm not sure exactly what the issue is - and any Application is free to make use of the Interpreter however it wishes - but the _setup structure is basically used to save the entire internal state of the Interpreter, and the Interpreter assumes a certain coherency and relationships between the data.  So to modify things on your own would involve your application into all these internal workings which would be undesirable from an encapsulation stand point.  Also changing things on-the-fly asynchronously to the Interpreter would be even more dangerous.   So my thinking in KMotionCNC was to treat the Interpreter as a Black Box where all we need to know for example is that G21 will switch it to MM mode (which turns out to involve lots of internal conversions) the best thing for a GUI button that says "switch to MM mode" should do is submit a G21 to the Interpreter.  Admittedly, writing the 1 line disk file is hokey, but there certainly shouldn't be
> any performance consideration as it only happens once per User operation.
>  
> Thanks
> TK
>
> --- On Fri, 7/29/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Interpreter Interpretations....
> To: DynoMotion@yahoogroups.com
> Date: Friday, July 29, 2011, 7:19 PM
>
>
>  
>
>
>
> Answering my own post again... This is why I need to hoook my board up to a proper machine. Maybe I will look into resurrecting and old project of mine so I can prove this stuff out without bogging down support.
>
> Anywho-
>
> I am hoping someone else can confirm, but it definitely appears that changing the settings values while running will have an immediate effect. I think in my actual CNC application I will limit which commands can be issued depending on the current modal situation, but I will make them get/sets for a robust implementation.
>
> I just put these lines at the beginning of
> void CKMotionCNCDlg::OnSend()
> in KMotionCNC.sln
> ~
> Interpreter.p_setup->tool_length_offset = 23;
> Interpreter.p_setup->plane = 2;
> return;
> ~
>
> And I saw the Z increase immediately by 23 and my next arc call yeilded an error because of the plane change.
>
> Anyone caring to explore this further please let me know your findings.
>
> I will see what people think over at the EMC forum as well.
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Having a look at
> > rs274ngc.cpp
> >
> >
> > This could be good ;) , it looks like it is using the settings inside the methods.
> >
> > Anyone willing to test some of this out?
> >
> > I guess I can overwrite the current DoGCodeLine and see if it affects my axis positions....
> >
> >
> >
> > -Brad
> >
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > >
> > >
> > > I saw that, and my first response is...really? I realize this is a potential
> > > issue with the EMC and I am not knocking DM. It just seems to be a odd way to
> > > go about it.
> > >
> > > Is it absolutely necesary to create a file?
> > >
> > >
> > > Anyone else here doing this?
> > >
> > > Andrew Erwwod, how did you handle this(assuming you did) in your
> > > implementation?
> > >
> > > -Brad Murry
> > >
> > >
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Yes.  If you search in KMotionCNC if the User clicks on the MM or inch Radio buttons it calls:
> > > >  
> > > > void CKMotionCNCDlg::Onmm()
> > > > {
> > > >     DoGCodeLine("G21");
> > > > }
> > > > void CKMotionCNCDlg::Oninch()
> > > > {
> > > >     DoGCodeLine("G20");
> > > > }
> > > >  
> > > >  
> > > > Which creates a 1 line GCode File and executes it like the MDI.
> > > >
> > > > TK
> > > >  
> > > >
> > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > To: DynoMotion@yahoogroups.com
> > > > Date: Friday, July 29, 2011, 4:32 PM
> > > >
> > > >
> > > >  
> > > >
> > > >
> > > >
> > > > I see, so perhaps some/all setup params should be made as "read only"(only provide get value functions) when I export?
> > > >
> > > > " I think it simulates GCode to effect the change rather than modifying the internal variables"
> > > >
> > > > Does this mean it drops it into MDI mode and makes the calls and then back? I guess I would be able to tell in the code...
> > > >
> > > > Thanks again,
> > > > -Brad Murry
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Brad,
> > > > >  
> > > > > Again I think most of these are used internally.  For example to change the Tool Index the User would execute a Hxx command in G Code.  However KMotionCNC does display some settings on the screen like current tool and allows the User to change the tool directly, but I think it simulates GCode to effect the change rather than modifying the internal variables.
> > > > >
> > > > > TK
> > > > >
> > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Date: Friday, July 29, 2011, 3:40 PM
> > > > >
> > > > >
> > > > >  
> > > > >
> > > > >
> > > > >
> > > > > Hello,
> > > > >
> > > > > Int the case of:
> > > > >
> > > > > int tool_table_index; // tool index used with cutter comp
> > > > >
> > > > > double tool_length_offset; // current tool length offset
> > > > >
> > > > > int length_offset_index; // for use with tool length offsets
> > > > >
> > > > > and
> > > > >
> > > > > double cutter_comp_radius; // current cutter compensation radius
> > > > >
> > > > > How do these values interact/override each other?
> > > > >
> > > > > Are some of them to be considered read only, or can I override values pulled from tool_table_index and length_offset_index
> > > > > by updating the tool_length_offset and cutter_comp_radius?
> > > > >
> > > > > Just trying to get my head wrapped 'round it all.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > -Brad Murry
> > > > >
> > > > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > > > >
> > > > > > Tom,
> > > > > >
> > > > > > I see some of the setup params are not commented(mut most are)
> > > > > >
> > > > > > Can you clarify these?:
> > > > > > ON_OFF block_delete;
> > > > > > int cutter_radius_compensation;
> > > > > > double cycle_z;
> > > > > > int current_line;
> > > > > >
> > > > > > fpos_t sub_stack_pos[MAX_SUB_STACK];
> > > > > > fpos_t sub_stack_sub_start_pos[MAX_SUB_STACK];
> > > > > > int sub_stack_lineno[MAX_SUB_STACK];
> > > > > > int sub_stack_sub_start_lineno[MAX_SUB_STACK];
> > > > > > int sub_stack_call_cnt[MAX_SUB_STACK];
> > > > > > int stacki;
> > > > > >
> > > > > > Thank you,
> > > > > >
> > > > > > -Brad Murry
> > > > > >
> > > > > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > > > > >
> > > > > > > "Thank you for your time, I think this is the last thing I need to wrap!
> > > > > > >
> > > > > > > I've heard that before :} "
> > > > > > >
> > > > > > > Ha!, I should clarify that what I meant is : the Interpreter is the last thing I plan to wrap - I'm sure there will be many clarifications needed down the road epecially once I get this thing connected to a real world machine.
> > > > > > >
> > > > > > > There are too many assumptions I have used in implementing everything (for the sake of progress), and I think I may email you the source first so you can tell me if it is on the right track - plus there are likely a lot of members that may not need to be/should not be exported. Once you approve of the exported members and such I will release the source publicly. Sound like a plan?
> > > > > > >
> > > > > > >
> > > > > > > -Brad Murry
> > > > > > >
> > > > > > >
> > > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > >
> > > > > > > > See below
> > > > > > > >
> > > > > > > >
> > > > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > From: bradodarb <bradodarb@>
> > > > > > > > Subject: [DynoMotion] Re: Interpreter Interpretations....
> > > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > > Date: Friday, July 29, 2011, 12:36 PM
> > > > > > > >
> > > > > > > >
> > > > > > > > ÃÆ'‚ 
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Excellent Tom- Thanks!
> > > > > > > >
> > > > > > > > I do have a concern and a few more methods to clarify...
> > > > > > > >
> > > > > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > > >
> > > > > > > > I may have mentioned before that I wish to directly set all setup params and tool tables. Will this impede my intentions?
> > > > > > > >
> > > > > > > > If the filenames are not set (they default to NULL) then they will not be read
> > > > > > > >
> > > > > > > > Also, are there any other pitfalls I may run into while trying to set params you are normally using a file for from memory?
> > > > > > > >
> > > > > > > > In case you are interested as to why I do not want to use the existing file formats:
> > > > > > > >
> > > > > > > > The plan is to have .net classes that contain all the data memebers dor things like tools and also the members in setup_struct.
> > > > > > > >
> > > > > > > > This will allow me to serialize and de-serialize using XML so there is no manual parsing required by my application. I am also using these data classes for MVVM, so they are all implementing INotifyPropertyChanged.
> > > > > > > >
> > > > > > > > Ok, so that is a concern, here are some remaining members I am not quite sure about:
> > > > > > > >
> > > > > > > > MCODE_ACTION McodeActions[MAX_MCODE_ACTIONS];ÃÆ'‚  MCodes(in GCode) can be configured to do various "Actions" such as Set/Clear a bit, Run a C Program in KFLOP, Run a Windows Program, etc.ÃÆ'‚  This structure defines what is to be performed for various M Codes.ÃÆ'‚  User Buttons also use this mechanism as "pseudo M codes" and so can be configured to do likewise "Actions"
> > > > > > > >
> > > > > > > > int ExecutePC(const char *Name);
> > > > > > > > Calling this spawns a Windows PC Application by the specified name
> > > > > > > >
> > > > > > > > char ToolFile[MAX_PATH];ÃÆ'‚  Can be used to define Tool Parameters
> > > > > > > > char SetupFile[MAX_PATH];ÃÆ'‚  Can be used to define inital Interpreter Settings
> > > > > > > > char GeoFile[MAX_PATH];ÃÆ'‚  Can be used to define a 2.5D Geometric correction file
> > > > > > > >
> > > > > > > > CCoordMotion CoordMotion; -- There is only one CoordMotion object per board, right? Yes
> > > > > > > >
> > > > > > > > These below are all for internal Interpreter use only
> > > > > > > > int m_CurrentLine;
> > > > > > > > int m_GCodeReads;
> > > > > > > > CString m_InFile; Gcode File?
> > > > > > > > int m_exitcode;
> > > > > > > > int DoExecute();
> > > > > > > > int DoExecuteComplete();
> > > > > > > >
> > > > > > > >
> > > > > > > > I think after this I will have some questions on some members in the setup_struct...
> > > > > > > >
> > > > > > > > Thank you for your time, I think this is the last thing I need to wrap!
> > > > > > > >
> > > > > > > > I've heard that before :}
> > > > > > > > Thanks
> > > > > > > > TK
> > > > > > > > ÃÆ'‚ 
> > > > > > > >
> > > > > > > > -Brad Murry
> > > > > > > >
> > > > > > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > > > > > >
> > > > > > > > > See below
> > > > > > > > > TK
> > > > > > > > >
> > > > > > > > > --- On Fri, 7/29/11, bradodarb <bradodarb@> wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > From: bradodarb <bradodarb@>
> > > > > > > > > Subject: [DynoMotion] Interpreter Interpretations....
> > > > > > > > > To: DynoMotion@yahoogroups.com
> > > > > > > > > Date: Friday, July 29, 2011, 11:52 AM
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hello Tom,
> > > > > > > > >
> > > > > > > > > I am implementing the interpreter today and although some of the public members below seem intuitive, I would like to make sure I have everything right. Can you give me brief descripts on each member and tell me whether you think they should be exposed as properties or not?
> > > > > > > > >
> > > > > > > > > bool m_InitializeOnExecute;ÃÆ'Æ'‚ÃÆ'‚ don't exportÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > > bool m_ReadToolFile;obsolete - always reads
> > > > > > > > > int m_start, m_end;obsolete - unused
> > > > > > > > >
> > > > > > > > > ÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > > After a Halt and a possible Tool replacement or Offset change
> > > > > > > > > there is a mechanism to "Resume"
> > > > > > > > >
> > > > > > > > > bool m_Resume;ÃÆ'Æ'‚ÃÆ'‚  Set if any partÃÆ'Æ'‚ÃÆ'‚ of theÃÆ'Æ'‚ÃÆ'‚ resume sequence is desired
> > > > > > > > > double m_ResumeSafeZ; Safe Z height to be raised toÃÆ'Æ'‚ÃÆ'‚ 
> > > > > > > > > int m_ResumeSafeRelAbs;ÃÆ'Æ'‚ÃÆ'‚  Specifies if the Z heights are absolute or relative
> > > > > > > > > BOOL m_ResumeMoveToSafeZ;ÃÆ'Æ'‚ÃÆ'‚  Specifies whether or not the Z should be first moved up
> > > > > > > > > BOOL m_ResumeTraverseXY;ÃÆ'Æ'‚ÃÆ'‚  Specifies whether an xy motion should be made back to some position
> > > > > > > > > double m_ResumeTraverseSafeX;ÃÆ'Æ'‚ÃÆ'‚  Position in X
> > > > > > > > > double m_ResumeTraverseSafeY;ÃÆ'Æ'‚ÃÆ'‚  Position in Y
> > > > > > > > > BOOL m_ResumeSafeStartSpindle; Specifies if the Spindle should be re-started
> > > > > > > > > int m_ResumeSafeSpindleCWCCW;ÃÆ'Æ'‚ÃÆ'‚  Specifies Spindle direction if it is to be re-started
> > > > > > > > > BOOL m_ResumeDoSafeFeedZ;ÃÆ'Æ'‚ÃÆ'‚  Specifies if the Z should then be fed down to some height
> > > > > > > > > double m_ResumeFeedSafeZ;ÃÆ'Æ'‚ÃÆ'‚  Specifies height Z should be fed down to
> > > > > > > > > double m_ResumeResumeFeedRate;ÃÆ'Æ'‚ÃÆ'‚  double m_ResumeZFeedRate;Specifies Rate at which feed rate should be restored to
> > > > > > > > > BOOL m_ResumeRestoreFeedRate; Specifies whether or not the specified feed rate should be restored
> > > > > > > > >
> > > > > > > > > Thanks,
> > > > > > > > > Brad Murry
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello,
>
> I am testing out the Interpreter.Interpret(args....)
>
> and I get an error window complaining about cannot load\Gcode Programs\emc.var
>
>
>
> Any thoughts on bypassing this?
>
> Thank you
> -Brad Murry
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
>
> OK, so I was not exposing
>
> CoodMotion->MainPathRoot
> and
> CoodMotion->MainPath
>
> I thought it would fix this, so I imported those two public members(as well as m_Simulated).
>
> But no dice, I am still getting the emc.var error below.
>
>
> I am wondering if these char arrays are getting reinitialized somehow.
>
> -Brad Murry
>
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Hello,
> >
> > I am testing out the Interpreter.Interpret(args....)
> >
> > and I get an error window complaining about cannot load\Gcode Programs\emc.var
> >
> >
> >
> > Any thoughts on bypassing this?
> >
> > Thank you
> > -Brad Murry
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> It seems that CoordMotion is not a singleton and that the Interpreter uses a separate instance...
>
> So Setting the MainPathRoot in the CoorMotion worked, but was obviously empty in the Interpreter's CoordMotion.
>
> I will try to get the Interpreter's instance pointing to the same CoorMotion and see how that goes
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> >
> > OK, so I was not exposing
> >
> > CoodMotion->MainPathRoot
> > and
> > CoodMotion->MainPath
> >
> > I thought it would fix this, so I imported those two public members(as well as m_Simulated).
> >
> > But no dice, I am still getting the emc.var error below.
> >
> >
> > I am wondering if these char arrays are getting reinitialized somehow.
> >
> > -Brad Murry
> >
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > Hello,
> > >
> > > I am testing out the Interpreter.Interpret(args....)
> > >
> > > and I get an error window complaining about cannot load\Gcode Programs\emc.var
> > >
> > >
> > >
> > > Any thoughts on bypassing this?
> > >
> > > Thank you
> > > -Brad Murry
> > >
> >
>

--- In DynoMotion@yahoogroups.com, "Neville Bonwit" <nevilleb@...> wrote:
>
> Hi Brad,
>
>
>
> You could make them separate instances for flexibility but then assign them
> to be the same in most cases, like this:
>
> KM_Controller.CoordMotion = new CoordMotion() // Or whatever the actual
> syntax is
>
> KM_Controller.Interpreter.CoordMotion = KM_Controller.CoordMotion // If the
> user wanted them to be separate, they would comment out this line and
> uncomment the following line
>
> //KM_Controller.Interpreter.CoordMotion = new CoordMotion()
>
>
>
> I'm not sure if there would be problems with this approach or not, but I
> thought I'd throw it out there since there might be a way to make it work
> and it seems like it could offer flexibility and tightness of code at the
> same time.
>
>
>
> -Neville
>
>
>
>
>
> From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On
> Behalf Of bradodarb
> Sent: Sunday, August 14, 2011 9:43 AM
> To: DynoMotion@yahoogroups.com
> Subject: [DynoMotion] Re: Interpreter Interpretations....
>
>
>
>
>
> Looking for feedback:
>
> I am not sure whether I should set things up so that
> KM_Controller.CoordMotion uses the same instance of CCoordMotion as
> KM_Controller.Interpreter.CoordMotion
>
> I guess I cannot decide whether there could be a possible use case where the
> interpreter and direct CoordMotion calls will be made on the same machine
> (and) possibly requiring different parameters for both(especially
> Motion_Params).
>
> Any thoughts?
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "bradodarb" <bradodarb@> wrote:
> >
> > It seems that CoordMotion is not a singleton and that the Interpreter uses
> a separate instance...
> >
> > So Setting the MainPathRoot in the CoorMotion worked, but was obviously
> empty in the Interpreter's CoordMotion.
> >
> > I will try to get the Interpreter's instance pointing to the same
> CoorMotion and see how that goes
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com> ,
> "bradodarb" <bradodarb@> wrote:
> > >
> > >
> > > OK, so I was not exposing
> > >
> > > CoodMotion->MainPathRoot
> > > and
> > > CoodMotion->MainPath
> > >
> > > I thought it would fix this, so I imported those two public members(as
> well as m_Simulated).
> > >
> > > But no dice, I am still getting the emc.var error below.
> > >
> > >
> > > I am wondering if these char arrays are getting reinitialized somehow.
> > >
> > > -Brad Murry
> > >
> > >
> > > --- In DynoMotion@yahoogroups.com <mailto:DynoMotion%40yahoogroups.com>
> , "bradodarb" <bradodarb@> wrote:
> > > >
> > > > Hello,
> > > >
> > > > I am testing out the Interpreter.Interpret(args....)
> > > >
> > > > and I get an error window complaining about cannot load\Gcode
> Programs\emc.var
> > > >
> > > >
> > > >
> > > > Any thoughts on bypassing this?
> > > >
> > > > Thank you
> > > > -Brad Murry
> > > >
> > >
> >
>