Re: [Emc-users] Python g-code generator framework

2014-01-03 Thread andy pugh
On 3 January 2014 05:42, Kent A. Reed kentallanr...@gmail.com wrote: A case in point is RFC 2822 which defines the headers of the email we are exchanging. It defines a date as day month year. This isn't surprising since many early Internet RFCs codified the prevailing practices here in the

Re: [Emc-users] Python g-code generator framework

2014-01-03 Thread Mark Wendt
On Fri, Jan 3, 2014 at 5:57 AM, andy pugh bodge...@gmail.com wrote: Surely DD-MM-YY is not US conventional practice at all. Don't you use the illogical-no-matter-how-you-consider-it MM-DD-YY ? More conventional than you think when you consider we use dates like 03 January 2014. That's used

Re: [Emc-users] Python g-code generator framework

2014-01-03 Thread Gene Heskett
On Friday 03 January 2014 09:05:21 andy pugh did opine: On 3 January 2014 05:42, Kent A. Reed kentallanr...@gmail.com wrote: A case in point is RFC 2822 which defines the headers of the email we are exchanging. It defines a date as day month year. This isn't surprising since many early

Re: [Emc-users] Python g-code generator framework

2014-01-03 Thread Niemand Sonst
Am 03.01.2014 15:07, schrieb Gene Heskett: On Friday 03 January 2014 09:05:21 andy pugh did opine: On 3 January 2014 05:42, Kent A. Reed kentallanr...@gmail.com wrote: A case in point is RFC 2822 which defines the headers of the email we are exchanging. It defines a date as day month year.

Re: [Emc-users] Python g-code generator framework

2014-01-03 Thread andy pugh
On 3 January 2014 14:55, Niemand Sonst nie...@web.de wrote: On Friday 03 January 2014 09:05:21 andy pugh did opine: The British Standard for technical drawings uses a comma. But nowhere else is this used, Don't say nowhere else! It is used in Germany as standard! Sorry, I meant Nowhere else

Re: [Emc-users] Python g-code generator framework

2014-01-03 Thread Gregg Eshelman
On 1/3/2014 7:07 AM, Gene Heskett wrote: And that takes us full circle, back to the statement that standards are nice, there are so many to choose from. :) Cheers, Gene Like with USB. The idea was to have only two types of connector, A for the host end, B for the device end. Then they

[Emc-users] Python g-code generator framework

2014-01-02 Thread erik
Hello together, After fiddeling around with ngc subroutines for a while, I decided to give Python a chance and write g-code generators as a substitute. There are already serveral simple and useful g-code generators available from the LinuxCNCKnowledgeBase

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
Hi Erik, I wrote some of the simple G code generators on the wiki and have a 3rd generation of my learning curve in Python, Gtk, Glade3 G code generator on my web site. I quit using Tk a while back and prefer to use Gtk now. http://gnipsel.com/files/g-code-generator/ If you get a chance to

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
Hi Erik, You might want to disable the g-code buttons until after some G code has been created. JT On 1/2/2014 6:31 AM, erik wrote: Hello together, After fiddeling around with ngc subroutines for a while, I decided to give Python a chance and write g-code generators as a substitute.

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread Niemand Sonst
Am 02.01.2014 14:13, schrieb John Thornton: Hi Erik, I wrote some of the simple G code generators on the wiki and have a 3rd generation of my learning curve in Python, Gtk, Glade3 G code generator on my web site. I quit using Tk a while back and prefer to use Gtk now.

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread Jon Elson
On 01/02/2014 10:13 AM, erik wrote: I do not have enough experience with GTK and Glade3 to write applications for it (yet). Dive into Glade, I think you'll like it. I have developed some control GUIs with Glade on the Beagle Bone, and they worked quite well. I did the back end in C, as I was

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
Hi Norbert, A comma is not accepted by LinuxCNC as a decimal separator. You would need to modify the is_number function to accept a comma then change it to a dot in the G code. JT On 1/2/2014 9:40 AM, Niemand Sonst wrote: Am 02.01.2014 14:13, schrieb John Thornton: Hi Erik, I wrote some

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
Hi Erik, On the Preferences tab you need to change the preamble to G21 for metric. The rest of the facing page will not make any difference if you use metric or inch. The tapping hole making is in inch only at this point and I just discovered it doesn't add the preamble to the top of the G

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread Kent A. Reed
On 01/02/2014 10:40 AM, Niemand Sonst wrote: Will you localize it? Here in Germany we are used to give a , as decimal separator, your GUI says 0,12 is not a number. Ah, yes, the problem of localization. I've seen ISO committees come to blows over this. Check the Python locale module. There's

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread Niemand Sonst
Hallo JT, I know it is not accepted in GCode, but you are writing a GUI, so why not check from the GUI the locale settings and accept the comma. In the Gcode it has to be a dot, I know. Chris and I are doing that on Tooledit widget, here in Germany I can use my number pad without the need to

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread erik
Hi JT, I thought I used the preferences tab. Anyway, it helped to find something else ;-) Splitting up code into smaller files is typically the right way to go. I do it for every module/class when I code in c/c++. Concerning the direct write to AXIS: I personally do not use it too, but should

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
Hi Norbert, Mainly because I don't know how to check locale settings in Python or how to convert them back and forth as needed. If you have any ideas I'm all ears or eyes as the case might be. JT On 1/2/2014 12:06 PM, Niemand Sonst wrote: Hallo JT, I know it is not accepted in GCode, but

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
I uploaded a new version and figured out how to do the Send to Axis again. JT On 1/2/2014 9:40 AM, Niemand Sonst wrote: Am 02.01.2014 14:13, schrieb John Thornton: Hi Erik, I wrote some of the simple G code generators on the wiki and have a 3rd generation of my learning curve in Python,

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread Niemand Sonst
Hallo John, just see the sourcecode from tooledit_widget.py in the gladevcp folder. Norbert Am 02.01.2014 19:23, schrieb John Thornton: Hi Norbert, Mainly because I don't know how to check locale settings in Python or how to convert them back and forth as needed. If you have any ideas I'm

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread erik
Hi Kent, Will we live to see a common worldwide date format AND measurement system? ;-) You were right about the ambiguous dates. I changed it to a more clear variant and start working on a better metric/imperial handling of my program. Regards Erik Am 02.01.2014 19:02, schrieb Kent A. Reed:

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread John Thornton
Hi Norbert, I found 4 lines in master tooledit_widget.py. Seems simple enough, how do you change the locale to test different locales? JT On 1/2/2014 1:59 PM, Niemand Sonst wrote: Hallo John, just see the sourcecode from tooledit_widget.py in the gladevcp folder. Norbert Am 02.01.2014

Re: [Emc-users] Python g-code generator framework

2014-01-02 Thread Kent A. Reed
On 01/02/2014 05:06 PM, erik wrote: Hi Kent, Will we live to see a common worldwide date format AND measurement system?;-) You were right about the ambiguous dates. I changed it to a more clear variant and start working on a better metric/imperial handling of my program. Erik: For