--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> I assume you mean to run on the PC side rather than the DSP side.
>  
> Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.  Search for:
>  
> case M_Action_Program_PC:
>  
>  
> However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.  Maybe I don't understand your intent.
>  
> Regards
> TK
>  
>
>
> --- On Tue, 7/5/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Run python script from interpreter
> To: DynoMotion@yahoogroups.com
> Date: Tuesday, July 5, 2011, 8:50 AM
>
>
>  
>
>
>
> Hello
>
> I have seen in the sources where you can load and run a c program from a g-code file.
>
> I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
>
> Do you have any advice on the best way to intercept calls like this?
>
> -Brad Murry
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Tom,
>
>
> I now recall seeing the load file and Mcode as well.
>
> I will need to look further into the Mcodes.
>
> In Iron Python, scripts run int the DLR(Dynamic Language Runtime, but are compatible with CLR(Common Language Runtime - which is what .net languages compile to) objects.
>
> I can generate a dynamic runtime and add whichever variables I wish, including objects in my application(especially the c# wrappers I am creating for your DynoMotion devices).
>
> So basically how the framework is used at my work and how I wish to incorporate the DynoMotion hardware is:
>
> C/C++ :: dlls for device access
>
> c# :: dlls for wrapping the device in abstracted objects
>
> c#/WPF :: application for great GUI
>
> Iron Python :: for controlling the actual behavior of the c#/C/C++ objects.
>
> The python scripting is great to use on things like confiuring the UI so it can display different interfaces, options, etc.. at runtime. I also use the scripting for things like a tool changer or even to define what happens when an operator presses cycle start.
>
>
> I realize most if not all what I want to acomplish could be handed in your c scripts, but to maintain compatability with my existing framework and to enable the manipulation of CLR objects I need to use Iron Python.
>
>
>
>
> I am not sure loading from file will be as performant as I need it to be, I typically cache most scripts in a pre-compiled run-time for speedy execution.
>
>
>
> It would be great if there was a User Block Callback available in the interpreter.
>
>
> Thanks,
>
> Brad Murry
>
>
>
>
>
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Brad,
> >  
> > I assume you mean to run on the PC side rather than the DSP side.
> >  
> > Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.  Search for:
> >  
> > case M_Action_Program_PC:
> >  
> >  
> > However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.  Maybe I don't understand your intent.
> >  
> > Regards
> > TK
> >  
> >
> >
> > --- On Tue, 7/5/11, bradodarb <bradodarb@> wrote:
> >
> >
> > From: bradodarb <bradodarb@>
> > Subject: [DynoMotion] Run python script from interpreter
> > To: DynoMotion@yahoogroups.com
> > Date: Tuesday, July 5, 2011, 8:50 AM
> >
> >
> >  
> >
> >
> >
> > Hello
> >
> > I have seen in the sources where you can load and run a c program from a g-code file.
> >
> > I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
> >
> > Do you have any advice on the best way to intercept calls like this?
> >
> > -Brad Murry
> >
>

--- In DynoMotion@yahoogroups.com, "zenhacker@..." <zenhacker@...> wrote:
>
>
>
>
>
>
> I have been taking note of the recent rumblings on the C#/Dynomotion front, it has me excited.
>
> I must admit, I left C++ hat somewhere back in the early 90's with Borland Turbo C++ 3.0 and DOS, and just never succeeded in finding it again when moving into Windows programming and trying to do AFX/MFC in Visual C++. I dabbled some with VB6, but didn't really fall in love with programming windows again, until .NET 2.0 came out.
>
> Seeing a Managed Framework come to fruition that harnesses the power of Dynomotion is something I would welcome with open arms (is it too much to hope that access to the RS274 Interpreter, and trajectory planner make the managed transition too? I hope not). Forms (WPF or WinForms) in .NET are both very easy to layout dynamically relative to display resolution, and even built programmatically at runtime based on demand (relative to my intermediate skill set at least). WPF of course opens the door to create some very spectacular looking UI's. Adding Iron Python for scripting support would be icing on the proverbial cake (since you are looking at the DLR, Ruby, or any other language with a DLR Implementation could be supported). But I digress.
>
>
> Brad, I noticed the earlier post to your C# Wrapper but I have not had a chance to download and test anything yet. Is it your intention to create a Wrapper/Framework for public consumption (framework meaning the WPF/DLR aspects you discussed here), or is the wrapper portion all that is planned currently?
>
>
> Best Regards,
> Patrick Hall
>
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Tom,
> >
> >
> > I now recall seeing the load file and Mcode as well.
> >
> > I will need to look further into the Mcodes.
> >
> > In Iron Python, scripts run int the DLR(Dynamic Language Runtime, but are compatible with CLR(Common Language Runtime - which is what .net languages compile to) objects.
> >
> > I can generate a dynamic runtime and add whichever variables I wish, including objects in my application(especially the c# wrappers I am creating for your DynoMotion devices).
> >
> > So basically how the framework is used at my work and how I wish to incorporate the DynoMotion hardware is:
> >
> > C/C++ :: dlls for device access
> >
> > c# :: dlls for wrapping the device in abstracted objects
> >
> > c#/WPF :: application for great GUI
> >
> > Iron Python :: for controlling the actual behavior of the c#/C/C++ objects.
> >
> > The python scripting is great to use on things like confiuring the UI so it can display different interfaces, options, etc.. at runtime. I also use the scripting for things like a tool changer or even to define what happens when an operator presses cycle start.
> >
> >
> > I realize most if not all what I want to acomplish could be handed in your c scripts, but to maintain compatability with my existing framework and to enable the manipulation of CLR objects I need to use Iron Python.
> >
> >
> >
> >
> > I am not sure loading from file will be as performant as I need it to be, I typically cache most scripts in a pre-compiled run-time for speedy execution.
> >
> >
> >
> > It would be great if there was a User Block Callback available in the interpreter.
> >
> >
> > Thanks,
> >
> > Brad Murry
> >
> >
> >
> >
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Brad,
> > >  
> > > I assume you mean to run on the PC side rather than the DSP side.
> > >  
> > > Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.  Search for:
> > >  
> > > case M_Action_Program_PC:
> > >  
> > >  
> > > However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.  Maybe I don't understand your intent.
> > >  
> > > Regards
> > > TK
> > >  
> > >
> > >
> > > --- On Tue, 7/5/11, bradodarb <bradodarb@> wrote:
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > Subject: [DynoMotion] Run python script from interpreter
> > > To: DynoMotion@yahoogroups.com
> > > Date: Tuesday, July 5, 2011, 8:50 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Hello
> > >
> > > I have seen in the sources where you can load and run a c program from a g-code file.
> > >
> > > I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
> > >
> > > Do you have any advice on the best way to intercept calls like this?
> > >
> > > -Brad Murry
> > >
> >
>

On 7/5/2011 6:50 PM, zenhacker@... wrote:

 

I have been taking note of the recent rumblings on the C#/Dynomotion front, it has me excited.

I must admit, I left C++ hat somewhere back in the early 90's with Borland Turbo C++ 3.0 and DOS, and just never succeeded in finding it again when moving into Windows programming and trying to do AFX/MFC in Visual C++. I dabbled some with VB6, but didn't really fall in love with programming windows again, until .NET 2.0 came out.

Seeing a Managed Framework come to fruition that harnesses the power of Dynomotion is something I would welcome with open arms (is it too much to hope that access to the RS274 Interpreter, and trajectory planner make the managed transition too? I hope not). Forms (WPF or WinForms) in .NET are both very easy to layout dynamically relative to display resolution, and even built programmatically at runtime based on demand (relative to my intermediate skill set at least). WPF of course opens the door to create some very spectacular looking UI's. Adding Iron Python for scripting support would be icing on the proverbial cake (since you are looking at the DLR, Ruby, or any other language with a DLR Implementation could be supported). But I digress.

Brad, I noticed the earlier post to your C# Wrapper but I have not had a chance to download and test anything yet. Is it your intention to create a Wrapper/Framework for public consumption (framework meaning the WPF/DLR aspects you discussed here), or is the wrapper portion all that is planned currently?

Best Regards,
Patrick Hall

--- In DynoMotion@yahoogroups.com, Lee Studley <indigo_red@...> wrote:
>
> Hi, took the other path :-)
>
> I haven't embraced C# and really have tried to distance myself from
> Microsoft's iron grip on how
> they think things should be done( by you in their opinion ). They seem
> to want to control how you think.
>
> I have have always liked C++ since the turbo C days. It was a
> niceadvancement/alternative to Pascal object oriented
> development. Visual basic gives me the heaves. I have recently converted
> many of my programs to JAVA as speed is
> not much of an issue there today. And I can run/port to linux with
> minimum effort.
>
> I'm not just a novice speaking here: I professionally wrote C++ gui's
> for intersil/Sicom and others for control and evaluation of asic features.
> This included custom controls with subclassing etc.
>
> I now like JAVA, C++ w/ STL and Python as my tools of choice.
>
> just my 2 pennies.
>
> On 7/5/2011 6:50 PM, zenhacker@... wrote:
> >
> >
> >
> > I have been taking note of the recent rumblings on the C#/Dynomotion
> > front, it has me excited.
> >
> > I must admit, I left C++ hat somewhere back in the early 90's with
> > Borland Turbo C++ 3.0 and DOS, and just never succeeded in finding it
> > again when moving into Windows programming and trying to do AFX/MFC in
> > Visual C++. I dabbled some with VB6, but didn't really fall in love
> > with programming windows again, until .NET 2.0 came out.
> >
> > Seeing a Managed Framework come to fruition that harnesses the power
> > of Dynomotion is something I would welcome with open arms (is it too
> > much to hope that access to the RS274 Interpreter, and trajectory
> > planner make the managed transition too? I hope not). Forms (WPF or
> > WinForms) in .NET are both very easy to layout dynamically relative to
> > display resolution, and even built programmatically at runtime based
> > on demand (relative to my intermediate skill set at least). WPF of
> > course opens the door to create some very spectacular looking UI's.
> > Adding Iron Python for scripting support would be icing on the
> > proverbial cake (since you are looking at the DLR, Ruby, or any other
> > language with a DLR Implementation could be supported). But I digress.
> >
> > Brad, I noticed the earlier post to your C# Wrapper but I have not had
> > a chance to download and test anything yet. Is it your intention to
> > create a Wrapper/Framework for public consumption (framework meaning
> > the WPF/DLR aspects you discussed here), or is the wrapper portion all
> > that is planned currently?
> >
> > Best Regards,
> > Patrick Hall
> >
>

--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Tom,
>
>
> I now recall seeing the load file and Mcode as well.
>
> I will need to look further into the Mcodes.
>
> In Iron Python, scripts run int the DLR(Dynamic Language Runtime, but are compatible with CLR(Common Language Runtime - which is what .net languages compile to) objects.
>
> I can generate a dynamic runtime and add whichever variables I wish, including objects in my application(especially the c# wrappers I am creating for your DynoMotion devices).
>
> So basically how the framework is used at my work and how I wish to incorporate the DynoMotion hardware is:
>
> C/C++ :: dlls for device access
>
> c# :: dlls for wrapping the device in abstracted objects
>
> c#/WPF :: application for great GUI
>
> Iron Python :: for controlling the actual behavior of the c#/C/C++ objects.
>
> The python scripting is great to use on things like confiuring the UI so it can display different interfaces, options, etc.. at runtime. I also use the scripting for things like a tool changer or even to define what happens when an operator presses cycle start.
>
>
> I realize most if not all what I want to acomplish could be handed in your c scripts, but to maintain compatability with my existing framework and to enable the manipulation of CLR objects I need to use Iron Python.
>
>
>
>
> I am not sure loading from file will be as performant as I need it to be, I typically cache most scripts in a pre-compiled run-time for speedy execution.
>
>
>
> It would be great if there was a User Block Callback available in the interpreter.
>
>
> Thanks,
>
> Brad Murry
>
>
>
>
>
>
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> > Hi Brad,
> >  
> > I assume you mean to run on the PC side rather than the DSP side.
> >  
> > Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.  Search for:
> >  
> > case M_Action_Program_PC:
> >  
> >  
> > However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.  Maybe I don't understand your intent.
> >  
> > Regards
> > TK
> >  
> >
> >
> > --- On Tue, 7/5/11, bradodarb <bradodarb@> wrote:
> >
> >
> > From: bradodarb <bradodarb@>
> > Subject: [DynoMotion] Run python script from interpreter
> > To: DynoMotion@yahoogroups.com
> > Date: Tuesday, July 5, 2011, 8:50 AM
> >
> >
> >  
> >
> >
> >
> > Hello
> >
> > I have seen in the sources where you can load and run a c program from a g-code file.
> >
> > I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
> >
> > Do you have any advice on the best way to intercept calls like this?
> >
> > -Brad Murry
> >
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> Its not clear to me what you mean.  A callback from a GCode Block?  As an M Code?  What/when would register the call back?
>
> If you implement the change (and there is no major disadvantage for others) we will incorporate it in future releases.
>  
> Regards
> TK
>
> --- On Wed, 7/6/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Run python script from interpreter
> To: DynoMotion@yahoogroups.com
> Date: Wednesday, July 6, 2011, 10:21 AM
>
>
>  
>
>
>
> Any chance of seeing a User Block Callback in an upcoming build?
>
> Or if you have another suggestion that does not involvef changing you code? I do not want to implement it myself(and do so every subsequent update)
>
> -Brad Murry
>
> --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> >
> > Tom,
> >
> >
> > I now recall seeing the load file and Mcode as well.
> >
> > I will need to look further into the Mcodes.
> >
> > In Iron Python, scripts run int the DLR(Dynamic Language Runtime, but are compatible with CLR(Common Language Runtime - which is what .net languages compile to) objects.
> >
> > I can generate a dynamic runtime and add whichever variables I wish, including objects in my application(especially the c# wrappers I am creating for your DynoMotion devices).
> >
> > So basically how the framework is used at my work and how I wish to incorporate the DynoMotion hardware is:
> >
> > C/C++ :: dlls for device access
> >
> > c# :: dlls for wrapping the device in abstracted objects
> >
> > c#/WPF :: application for great GUI
> >
> > Iron Python :: for controlling the actual behavior of the c#/C/C++ objects.
> >
> > The python scripting is great to use on things like confiuring the UI so it can display different interfaces, options, etc.. at runtime. I also use the scripting for things like a tool changer or even to define what happens when an operator presses cycle start.
> >
> >
> > I realize most if not all what I want to acomplish could be handed in your c scripts, but to maintain compatability with my existing framework and to enable the manipulation of CLR objects I need to use Iron Python.
> >
> >
> >
> >
> > I am not sure loading from file will be as performant as I need it to be, I typically cache most scripts in a pre-compiled run-time for speedy execution.
> >
> >
> >
> > It would be great if there was a User Block Callback available in the interpreter.
> >
> >
> > Thanks,
> >
> > Brad Murry
> >
> >
> >
> >
> >
> >
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > >
> > > Hi Brad,
> > >  
> > > I assume you mean to run on the PC side rather than the DSP side.
> > >  
> > > Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.  Search for:
> > >  
> > > case M_Action_Program_PC:
> > >  
> > >  
> > > However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.  Maybe I don't understand your intent.
> > >  
> > > Regards
> > > TK
> > >  
> > >
> > >
> > > --- On Tue, 7/5/11, bradodarb <bradodarb@> wrote:
> > >
> > >
> > > From: bradodarb <bradodarb@>
> > > Subject: [DynoMotion] Run python script from interpreter
> > > To: DynoMotion@yahoogroups.com
> > > Date: Tuesday, July 5, 2011, 8:50 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Hello
> > >
> > > I have seen in the sources where you can load and run a c program from a g-code file.
> > >
> > > I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
> > >
> > > Do you have any advice on the best way to intercept calls like this?
> > >
> > > -Brad Murry
> > >
> >
>

On 7/6/2011 12:07 AM, bradodarb wrote:

 

Lee,

It's pretty cool that mono exists and I can run c# on Linux boxes these days with little to no additional effort. I can even port gorgeous WPF calm based vector drawn GUI's over with moonlight.

It truly is an incredible time to be a programmer.

I also think corporations are pretty much like politicians, they're all necessary evils. I'm not sure oracle is any more or less evil than Microsoft.....

I reckon we can agree that garbage collected languages with massive libraries are great to make software with as they let us focus more on the application and less on the implementation; python rules!(Iron Python is recorded as the most performant, BTW) and Dynomotion hardware is awesome enough to spend time in the wee hours on this group.

Anyhow, I think maybe this discussion has drifted outside the realm of this forum.... so -

It would be cool to see a java wrapper implementation as well.

How hard would it be to wrestle the DynoMotion codebase away from MS(MFC, etc..) I wonder?

-Brad Murry

--- In DynoMotion@yahoogroups.com, Lee Studley <indigo_red@...> wrote:
>
> Hi, took the other path :-)
>
> I haven't embraced C# and really have tried to distance myself from
> Microsoft's iron grip on how
> they think things should be done( by you in their opinion ). They seem
> to want to control how you think.
>
> I have have always liked C++ since the turbo C days. It was a
> niceadvancement/alternative to Pascal object oriented
> development. Visual basic gives me the heaves. I have recently converted
> many of my programs to JAVA as speed is
> not much of an issue there today. And I can run/port to linux with
> minimum effort.
>
> I'm not just a novice speaking here: I professionally wrote C++ gui's
> for intersil/Sicom and others for control and evaluation of asic features.
> This included custom controls with subclassing etc.
>
> I now like JAVA, C++ w/ STL and Python as my tools of choice.
>
> just my 2 pennies.
>
> On 7/5/2011 6:50 PM, zenhacker@... wrote:
> >
> >
> >
> > I have been taking note of the recent rumblings on the C#/Dynomotion
> > front, it has me excited.
> >
> > I must admit, I left C++ hat somewhere back in the early 90's with
> > Borland Turbo C++ 3.0 and DOS, and just never succeeded in finding it
> > again when moving into Windows programming and trying to do AFX/MFC in
> > Visual C++. I dabbled some with VB6, but didn't really fall in love
> > with programming windows again, until .NET 2.0 came out.
> >
> > Seeing a Managed Framework come to fruition that harnesses the power
> > of Dynomotion is something I would welcome with open arms (is it too
> > much to hope that access to the RS274 Interpreter, and trajectory
> > planner make the managed transition too? I hope not). Forms (WPF or
> > WinForms) in .NET are both very easy to layout dynamically relative to
> > display resolution, and even built programmatically at runtime based
> > on demand (relative to my intermediate skill set at least). WPF of
> > course opens the door to create some very spectacular looking UI's.
> > Adding Iron Python for scripting support would be icing on the
> > proverbial cake (since you are looking at the DLR, Ruby, or any other
> > language with a DLR Implementation could be supported). But I digress.
> >
> > Brad, I noticed the earlier post to your C# Wrapper but I have not had
> > a chance to download and test anything yet. Is it your intention to
> > create a Wrapper/Framework for public consumption (framework meaning
> > the WPF/DLR aspects you discussed here), or is the wrapper portion all
> > that is planned currently?
> >
> > Best Regards,
> > Patrick Hall
> >
>

--- In DynoMotion@yahoogroups.com, Lee Studley <indigo_red@...> wrote:
>
> Hi Brad,
> I meant no offense whatsoever :-) Not heard of "mono" will check into
> it. C# probably has more to offer
> than I realize: just my ignorance of getting immersed in it showing.
> I think this topic is ok for the forum: it shows areas of interest
> for Tom K to support is the desire is there.
>
> I use CodeProject.com a lot and they raz me some on my Java preferences,
> but whats nice is Java projects you
> had awhile back run perfectly when you revisit them years later.
>
> I took MFC training in 1995 when it was the "future", and then peeked
> into JAVA as it was touted in all the microsoft
> documentation/help( as new classes ) as the new pathway to success, then
> the legalities MS/SUN
> occurred, then .net and C# where born pretty much due to that falling out.
> http://en.wikipedia.org/wiki/Java_%28programming_language%29
>
> I will do a JAVA interface to access the DynoMotion code soon I hope. I
> was on sabbatical from work, but they called me back. Hoping to get
> a few more weeks somehow to play as I just bought the KFLOP and KAnalog
> to add to my BP seriesII-4J-4hp monstrocity.
>
> Glad we have members like you with code experiences and well written
> points to keep ( my ) mind flexible!
>
> Sincerely to you all :-) and please call me on being opinionated if I
> come across that way.
> Lee Studley
>
>
>
> On 7/6/2011 12:07 AM, bradodarb wrote:
> >
> >
> > Lee,
> >
> > It's pretty cool that mono exists and I can run c# on Linux boxes
> > these days with little to no additional effort. I can even port
> > gorgeous WPF calm based vector drawn GUI's over with moonlight.
> >
> > It truly is an incredible time to be a programmer.
> >
> > I also think corporations are pretty much like politicians, they're
> > all necessary evils. I'm not sure oracle is any more or less evil than
> > Microsoft.....
> >
> > I reckon we can agree that garbage collected languages with massive
> > libraries are great to make software with as they let us focus more on
> > the application and less on the implementation; python rules!(Iron
> > Python is recorded as the most performant, BTW) and Dynomotion
> > hardware is awesome enough to spend time in the wee hours on this group.
> >
> > Anyhow, I think maybe this discussion has drifted outside the realm of
> > this forum.... so -
> >
> > It would be cool to see a java wrapper implementation as well.
> >
> > How hard would it be to wrestle the DynoMotion codebase away from
> > MS(MFC, etc..) I wonder?
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com
> > <mailto:DynoMotion%40yahoogroups.com>, Lee Studley <indigo_red@> wrote:
> > >
> > > Hi, took the other path :-)
> > >
> > > I haven't embraced C# and really have tried to distance myself from
> > > Microsoft's iron grip on how
> > > they think things should be done( by you in their opinion ). They seem
> > > to want to control how you think.
> > >
> > > I have have always liked C++ since the turbo C days. It was a
> > > niceadvancement/alternative to Pascal object oriented
> > > development. Visual basic gives me the heaves. I have recently
> > converted
> > > many of my programs to JAVA as speed is
> > > not much of an issue there today. And I can run/port to linux with
> > > minimum effort.
> > >
> > > I'm not just a novice speaking here: I professionally wrote C++ gui's
> > > for intersil/Sicom and others for control and evaluation of asic
> > features.
> > > This included custom controls with subclassing etc.
> > >
> > > I now like JAVA, C++ w/ STL and Python as my tools of choice.
> > >
> > > just my 2 pennies.
> > >
> > > On 7/5/2011 6:50 PM, zenhacker@ wrote:
> > > >
> > > >
> > > >
> > > > I have been taking note of the recent rumblings on the C#/Dynomotion
> > > > front, it has me excited.
> > > >
> > > > I must admit, I left C++ hat somewhere back in the early 90's with
> > > > Borland Turbo C++ 3.0 and DOS, and just never succeeded in finding it
> > > > again when moving into Windows programming and trying to do
> > AFX/MFC in
> > > > Visual C++. I dabbled some with VB6, but didn't really fall in love
> > > > with programming windows again, until .NET 2.0 came out.
> > > >
> > > > Seeing a Managed Framework come to fruition that harnesses the power
> > > > of Dynomotion is something I would welcome with open arms (is it too
> > > > much to hope that access to the RS274 Interpreter, and trajectory
> > > > planner make the managed transition too? I hope not). Forms (WPF or
> > > > WinForms) in .NET are both very easy to layout dynamically
> > relative to
> > > > display resolution, and even built programmatically at runtime based
> > > > on demand (relative to my intermediate skill set at least). WPF of
> > > > course opens the door to create some very spectacular looking UI's.
> > > > Adding Iron Python for scripting support would be icing on the
> > > > proverbial cake (since you are looking at the DLR, Ruby, or any other
> > > > language with a DLR Implementation could be supported). But I digress.
> > > >
> > > > Brad, I noticed the earlier post to your C# Wrapper but I have not
> > had
> > > > a chance to download and test anything yet. Is it your intention to
> > > > create a Wrapper/Framework for public consumption (framework meaning
> > > > the WPF/DLR aspects you discussed here), or is the wrapper portion
> > all
> > > > that is planned currently?
> > > >
> > > > Best Regards,
> > > > Patrick Hall
> > > >
> > >
> >
> >
>

Hello Tom,

 That sounds like an ideal solution.

  I guess I had assumed the callback would be sent on a separate thread than the interpreter.  If the callback is blocking,  then yeah no need for the wait/resume.

  Syncing the interpreter sounds like the way to go.  I had considered that I might need to re-position the axes to their callback positions after the script fired but I think just letting the interpreter know where the current position is would suffice for most scenarios.

When you said:

 we could add
 
 (USR,DoFunction1)

Does this mean you will be implementing this new funtion?  If so do do you think it could be accomplished within the next 2-3 weeks?

This is when I plan to have the RS274 wrapper implemented and ready for beta.

Thanks,

Brad Murry

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
>
>
>
>
>
> Hi Brad,
>  
> There already is a kludge method of throwing up Windows message boxes and sending Console Script commands to KFLOP using a special form of a G Code comment.  I'm thinking it would be easier and more consistant to follow that same line.
>  
>  
> (MSG,Press OK to continue)
>  
> and
>  
> (CMD,MoveRel0=100)
>  
> we could add
>  
> (USR,DoFunction1)
>  
> I don't see why we need the wait/resume option because it would be up to your callback to either return immediately or wait.
>  
> There might be a need for an option to re-sync the interpreter.  We have this option with M Codes that launch C programs in KFLOP.  After the Program completes if the program moved the axes for example it is usually required to re-sync the interpreter state to the axes states.
>  
> Regards
> TK
>
>
> --- On Wed, 7/6/11, bradodarb bradodarb@... wrote:
>
>
> From: bradodarb bradodarb@...
> Subject: [DynoMotion] Re: Run python script from interpreter
> To: DynoMotion@yahoogroups.com
> Date: Wednesday, July 6, 2011, 10:51 AM
>
>
>  
>
>
>
> Sounds great Tom,
>
> This is what I am thinking:
>
> adding a string flag for user defined block:
>
> GO X0.0 Y1.0
> M6 T2
> [UserBlockFlag] UserMessage
> G1........
>
> Maybe the flag could be some thing like _UB
>
> GO X0.0 Y1.0
> M6 T2
> _UB UserMessage
> G1........
>
> Then an callback handler similar to
>
> G_STATUS_CALLBACK or G_COMPLETE_CALLBACK
>
> G_USERBLOCK_CALLBACK could be added and pass the user message to a function pointer where I can handle it in a delegate on the c# side.
>
> In my case, the UserMessage would be a script name and I would fire it off once the message was received.
>
> .....While thinking this through it would also be excellent to have a wait parameter on the callback.
>
> Just do the callback
> _UB 0 UserMessage
>
> do the callback and dwell until resume is called
> _UB 1 UserMessage
>
> Make sense? Any pitfalls to watch out for or pointers in the right direction is appreciated.
>
> Thanks for your time,
>
> Brad Murry
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes tk@ wrote:
> >
> > Hi Brad,
> >  
> > Its not clear to me what you mean.  A callback from a GCode Block?  As an M Code?  What/when would register the call back?
> >
> > If you implement the change (and there is no major disadvantage for others) we will incorporate it in future releases.
> >  
> > Regards
> > TK
> >
> > --- On Wed, 7/6/11, bradodarb bradodarb@ wrote:
> >
> >
> > From: bradodarb bradodarb@
> > Subject: [DynoMotion] Re: Run python script from interpreter
> > To: DynoMotion@yahoogroups.com
> > Date: Wednesday, July 6, 2011, 10:21 AM
> >
> >
> >  
> >
> >
> >
> > Any chance of seeing a User Block Callback in an upcoming build?
> >
> > Or if you have another suggestion that does not involvef changing you code? I do not want to implement it myself(and do so every subsequent update)
> >
> > -Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > >
> > > Tom,
> > >
> > >
> > > I now recall seeing the load file and Mcode as well.
> > >
> > > I will need to look further into the Mcodes.
> > >
> > > In Iron Python, scripts run int the DLR(Dynamic Language Runtime, but are compatible with CLR(Common Language Runtime - which is what .net languages compile to) objects.
> > >
> > > I can generate a dynamic runtime and add whichever variables I wish, including objects in my application(especially the c# wrappers I am creating for your DynoMotion devices).
> > >
> > > So basically how the framework is used at my work and how I wish to incorporate the DynoMotion hardware is:
> > >
> > > C/C++ :: dlls for device access
> > >
> > > c# :: dlls for wrapping the device in abstracted objects
> > >
> > > c#/WPF :: application for great GUI
> > >
> > > Iron Python :: for controlling the actual behavior of the c#/C/C++ objects.
> > >
> > > The python scripting is great to use on things like confiuring the UI so it can display different interfaces, options, etc.. at runtime. I also use the scripting for things like a tool changer or even to define what happens when an operator presses cycle start.
> > >
> > >
> > > I realize most if not all what I want to acomplish could be handed in your c scripts, but to maintain compatability with my existing framework and to enable the manipulation of CLR objects I need to use Iron Python.
> > >
> > >
> > >
> > >
> > > I am not sure loading from file will be as performant as I need it to be, I typically cache most scripts in a pre-compiled run-time for speedy execution.
> > >
> > >
> > >
> > > It would be great if there was a User Block Callback available in the interpreter.
> > >
> > >
> > > Thanks,
> > >
> > > Brad Murry
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > >
> > > > Hi Brad,
> > > >  
> > > > I assume you mean to run on the PC side rather than the DSP side.
> > > >  
> > > > Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.  Search for:
> > > >  
> > > > case M_Action_Program_PC:
> > > >  
> > > >  
> > > > However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.  Maybe I don't understand your intent.
> > > >  
> > > > Regards
> > > > TK
> > > >  
> > > >
> > > >
> > > > --- On Tue, 7/5/11, bradodarb <bradodarb@> wrote:
> > > >
> > > >
> > > > From: bradodarb <bradodarb@>
> > > > Subject: [DynoMotion] Run python script from interpreter
> > > > To: DynoMotion@yahoogroups.com
> > > > Date: Tuesday, July 5, 2011, 8:50 AM
> > > >
> > > >
> > > >  
> > > >
> > > >
> > > >
> > > > Hello
> > > >
> > > > I have seen in the sources where you can load and run a c program from a g-code file.
> > > >
> > > > I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
> > > >
> > > > Do you have any advice on the best way to intercept calls like this?
> > > >
> > > > -Brad Murry
> > > >
> > >
> >
>

--- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@...> wrote:
>
> Hi Brad,
>  
> I added the GCode User Callback feature and it basically seems to work.  See files at:
>  
> http://www.dynomotion.com/Software/UserCallBack/
>  
> There are 3 changed source files and the compiled DLL.
>  
> There is also a modified SimpleGCode example that I used to test and some GCode that makes the Callback.
>  
> Regards
> TK
>
>
> --- On Wed, 7/6/11, bradodarb <bradodarb@...> wrote:
>
>
> From: bradodarb <bradodarb@...>
> Subject: [DynoMotion] Re: Run python script from interpreter
> To: DynoMotion@yahoogroups.com
> Date: Wednesday, July 6, 2011, 7:01 PM
>
>
>  
>
>
>
>
> Hello Tom,
>  That sounds like an ideal solution.
>   I guess I had assumed the callback would be sent on a separate thread than the interpreter.  If the callback is blocking,  then yeah no need for the wait/resume.
>   Syncing the interpreter sounds like the way to go.  I had considered that I might need to re-position the axes to their callback positions after the script fired but I think just letting the interpreter know where the current position is would suffice for most scenarios.
>  
> When you said:
>  we could add
>  
>  (USR,DoFunction1)
>  
> Does this mean you will be implementing this new funtion?  If so do do you think it could be accomplished within the next 2-3 weeks?
>
> This is when I plan to have the RS274 wrapper implemented and ready for beta.
>  
> Thanks,
> Brad Murry
>
> --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> >
> >
> >
> >
> >
> >
> > Hi Brad,
> >  
> > There already is a kludge method of throwing up Windows message boxes and sending Console Script commands to KFLOP using a special form of a G Code comment.  I'm thinking it would be easier and more consistant to follow that same line.
> >  
> >  
> > (MSG,Press OK to continue)
> >  
> > and
> >  
> > (CMD,MoveRel0=100)
> >  
> > we could add
> >  
> > (USR,DoFunction1)
> >  
> > I don't see why we need the wait/resume option because it would be up to your callback to either return immediately or wait.
> >  
> > There might be a need for an option to re-sync the interpreter.  We have this option with M Codes that launch C programs in KFLOP.  After the Program completes if the program moved the axes for example it is usually required to re-sync the interpreter state to the axes states.
> >  
> > Regards
> > TK
> >
> >
> > --- On Wed, 7/6/11, bradodarb bradodarb@ wrote:
> >
> >
> > From: bradodarb bradodarb@
> > Subject: [DynoMotion] Re: Run python script from interpreter
> > To: DynoMotion@yahoogroups.com
> > Date: Wednesday, July 6, 2011, 10:51 AM
> >
> >
> >  
> >
> >
> >
> > Sounds great Tom,
> >
> > This is what I am thinking:
> >
> > adding a string flag for user defined block:
> >
> > GO X0.0 Y1.0
> > M6 T2
> > [UserBlockFlag] UserMessage
> > G1........
> >
> > Maybe the flag could be some thing like _UB
> >
> > GO X0.0 Y1.0
> > M6 T2
> > _UB UserMessage
> > G1........
> >
> > Then an callback handler similar to
> >
> > G_STATUS_CALLBACK or G_COMPLETE_CALLBACK
> >
> > G_USERBLOCK_CALLBACK could be added and pass the user message to a function pointer where I can handle it in a delegate on the c# side.
> >
> > In my case, the UserMessage would be a script name and I would fire it off once the message was received.
> >
> > .....While thinking this through it would also be excellent to have a wait parameter on the callback.
> >
> > Just do the callback
> > _UB 0 UserMessage
> >
> > do the callback and dwell until resume is called
> > _UB 1 UserMessage
> >
> > Make sense? Any pitfalls to watch out for or pointers in the right direction is appreciated.
> >
> > Thanks for your time,
> >
> > Brad Murry
> >
> > --- In DynoMotion@yahoogroups.com, Tom Kerekes tk@ wrote:
> > >
> > > Hi Brad,
> > >  
> > > Its not clear to me what you mean.  A callback from a GCode Block?  As an M Code?  What/when would register the call back?
> > >
> > > If you implement the change (and there is no major disadvantage for others) we will incorporate it in future releases.
> > >  
> > > Regards
> > > TK
> > >
> > > --- On Wed, 7/6/11, bradodarb bradodarb@ wrote:
> > >
> > >
> > > From: bradodarb bradodarb@
> > > Subject: [DynoMotion] Re: Run python script from interpreter
> > > To: DynoMotion@yahoogroups.com
> > > Date: Wednesday, July 6, 2011, 10:21 AM
> > >
> > >
> > >  
> > >
> > >
> > >
> > > Any chance of seeing a User Block Callback in an upcoming build?
> > >
> > > Or if you have another suggestion that does not involvef changing you code? I do not want to implement it myself(and do so every subsequent update)
> > >
> > > -Brad Murry
> > >
> > > --- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@> wrote:
> > > >
> > > > Tom,
> > > >
> > > >
> > > > I now recall seeing the load file and Mcode as well.
> > > >
> > > > I will need to look further into the Mcodes.
> > > >
> > > > In Iron Python, scripts run int the DLR(Dynamic Language Runtime, but are compatible with CLR(Common Language Runtime - which is what .net languages compile to) objects.
> > > >
> > > > I can generate a dynamic runtime and add whichever variables I wish, including objects in my application(especially the c# wrappers I am creating for your DynoMotion devices).
> > > >
> > > > So basically how the framework is used at my work and how I wish to incorporate the DynoMotion hardware is:
> > > >
> > > > C/C++ :: dlls for device access
> > > >
> > > > c# :: dlls for wrapping the device in abstracted objects
> > > >
> > > > c#/WPF :: application for great GUI
> > > >
> > > > Iron Python :: for controlling the actual behavior of the c#/C/C++ objects.
> > > >
> > > > The python scripting is great to use on things like confiuring the UI so it can display different interfaces, options, etc.. at runtime. I also use the scripting for things like a tool changer or even to define what happens when an operator presses cycle start.
> > > >
> > > >
> > > > I realize most if not all what I want to acomplish could be handed in your c scripts, but to maintain compatability with my existing framework and to enable the manipulation of CLR objects I need to use Iron Python.
> > > >
> > > >
> > > >
> > > >
> > > > I am not sure loading from file will be as performant as I need it to be, I typically cache most scripts in a pre-compiled run-time for speedy execution.
> > > >
> > > >
> > > >
> > > > It would be great if there was a User Block Callback available in the interpreter.
> > > >
> > > >
> > > > Thanks,
> > > >
> > > > Brad Murry
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > --- In DynoMotion@yahoogroups.com, Tom Kerekes <tk@> wrote:
> > > > >
> > > > > Hi Brad,
> > > > > ÃÆ'‚ 
> > > > > I assume you mean to run on the PC side rather than the DSP side.
> > > > > ÃÆ'‚ 
> > > > > Besides specifying .c files to be compiled, downloaded, and executed there is an option for an MCode or User Button to execute a Windows Executable.ÃÆ'‚  Search for:
> > > > > ÃÆ'‚ 
> > > > > case M_Action_Program_PC:
> > > > > ÃÆ'‚ 
> > > > > ÃÆ'‚ 
> > > > > However I would think the problem would be that the Python would run as a separate process and wouldn't have access to any of the variables in the libraries or Interpreter or your application.ÃÆ'‚  Maybe I don't understand your intent.
> > > > > ÃÆ'‚ 
> > > > > Regards
> > > > > TK
> > > > > ÃÆ'‚ 
> > > > >
> > > > >
> > > > > --- On Tue, 7/5/11, bradodarb <bradodarb@> wrote:
> > > > >
> > > > >
> > > > > From: bradodarb <bradodarb@>
> > > > > Subject: [DynoMotion] Run python script from interpreter
> > > > > To: DynoMotion@yahoogroups.com
> > > > > Date: Tuesday, July 5, 2011, 8:50 AM
> > > > >
> > > > >
> > > > > ÃÆ'‚ 
> > > > >
> > > > >
> > > > >
> > > > > Hello
> > > > >
> > > > > I have seen in the sources where you can load and run a c program from a g-code file.
> > > > >
> > > > > I would like to come up with some sort of way to keep the original functionality, but also have the ability to fire off an Iron Python script as well.
> > > > >
> > > > > Do you have any advice on the best way to intercept calls like this?
> > > > >
> > > > > -Brad Murry
> > > > >
> > > >
> > >
> >
>