#linuxcnc-devel | Logs for 2012-03-09

Back
[00:27:16] -!- Rogue_ has quit [Quit: Page closed]
[00:31:05] -!- rob_h has quit [Ping timeout: 255 seconds]
[01:25:57] -!- ries has quit [Quit: ries]
[01:28:19] -!- bedah has quit [Ping timeout: 246 seconds]
[01:32:59] Tom_L is now known as Tom_itx
[01:36:54] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[01:37:48] -!- Valen has quit [Quit: Leaving.]
[02:07:02] -!- factor has quit [Read error: Connection reset by peer]
[02:22:23] -!- Tom_L has quit []
[02:49:26] -!- jsr__ has quit [Quit: Leaving]
[02:53:54] -!- jackc_ has quit [Ping timeout: 245 seconds]
[02:57:58] -!- phantoxe has quit []
[03:22:19] -!- cstop has quit [Quit: Leaving]
[03:36:49] -!- demacus has quit [Ping timeout: 245 seconds]
[04:00:20] icarusfactor is now known as factor
[04:17:12] -!- vladimirek has quit [Remote host closed the connection]
[04:19:29] -!- elmo40 has quit [Quit: Leaving.]
[04:50:49] -!- pcw has quit [Ping timeout: 252 seconds]
[05:00:37] -!- FinboySlick has quit [Quit: Leaving.]
[05:06:08] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[05:24:49] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[05:39:13] -!- vladimirek has quit [Remote host closed the connection]
[06:11:17] -!- psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[06:23:22] -!- zlog has quit [Ping timeout: 246 seconds]
[06:35:01] -!- vaughnstein has quit [Ping timeout: 245 seconds]
[06:36:06] <psha> jepler: why not to setup post-commit hook to push to github?
[06:42:56] -!- vaughnstein has quit [Quit: Bye]
[06:45:36] -!- VaughnStein has quit [Client Quit]
[06:46:41] -!- Thetawaves has quit [Quit: This computer has gone to sleep]
[07:04:24] -!- isssy has quit [Quit: Bye Bye]
[07:43:21] -!- psha has quit [Quit: Lost terminal]
[07:49:06] e-ndy|afk is now known as e-ndy
[07:58:32] -!- mhaberler has quit [Quit: mhaberler]
[08:01:28] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[08:04:14] -!- capricorn_one has quit [Remote host closed the connection]
[08:06:06] -!- ewidance has quit [Client Quit]
[08:11:27] -!- bootnecklad has quit [Client Quit]
[08:12:46] -!- vladimirek has quit [Remote host closed the connection]
[08:15:20] bootnecklad1 is now known as bnl
[08:43:34] -!- crib has quit [Ping timeout: 255 seconds]
[08:56:37] -!- rob_h [rob_h!~rob_h@5ace7011.bb.sky.com] has joined #linuxcnc-devel
[09:04:53] -!- vladimirek has quit [Remote host closed the connection]
[09:08:20] -!- Thetawaves has quit [Quit: Leaving]
[10:23:37] -!- mhaberler has quit [Quit: mhaberler]
[10:28:54] -!- herat has quit [Ping timeout: 245 seconds]
[10:33:13] e-ndy is now known as e-ndy|afk
[10:43:45] -!- machine1 has quit [Ping timeout: 260 seconds]
[10:47:44] theorbtwo is now known as randomyoof
[10:48:04] randomyoof is now known as theorbtwo
[10:52:24] -!- Tugge has quit [Ping timeout: 260 seconds]
[11:09:27] -!- adb has quit [Read error: Connection reset by peer]
[11:13:59] -!- Tugge has quit [Ping timeout: 252 seconds]
[11:16:36] -!- adb [adb!~adb@178-211-227-60.dhcp.voenergies.net] has joined #linuxcnc-devel
[11:24:34] -!- Tugge has quit [Ping timeout: 244 seconds]
[11:47:01] -!- The_Ball has quit [Ping timeout: 248 seconds]
[11:49:13] -!- theos has quit [Ping timeout: 245 seconds]
[12:07:03] -!- Rogue_ has quit [Quit: Page closed]
[12:19:45] e-ndy|afk is now known as e-ndy
[12:46:19] -!- The_Ball has quit [Ping timeout: 244 seconds]
[12:48:59] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[12:55:22] -!- Tugge has quit [Remote host closed the connection]
[12:58:36] <CIA-6> 03tissf 07v2.5_branch * r6b0028ce8729 10/docs/src/ (5 files in 4 dirs): French doc: update
[13:00:10] -!- Tugge has quit [Ping timeout: 255 seconds]
[13:03:00] <jepler> psha: in the short term? because I don't have the necessary level of access to do that.
[14:05:03] -!- Loetmichel has quit [Ping timeout: 245 seconds]
[14:22:27] -!- factor has quit [Ping timeout: 252 seconds]
[14:33:59] -!- Valen has quit [Quit: Leaving.]
[14:35:06] Cylly is now known as Loetmichel
[15:03:11] -!- ewidance has quit [Quit: ewidance]
[15:32:43] -!- mhaberler has quit [Quit: mhaberler]
[15:37:45] -!- pcw has quit [Ping timeout: 260 seconds]
[15:57:48] e-ndy is now known as e-ndy|afk
[16:00:47] -!- psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[16:00:59] -!- skunkworks has quit [Ping timeout: 260 seconds]
[16:04:47] -!- skunkworks [skunkworks!~chatzilla@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[16:22:34] -!- VaughnStein has quit [Ping timeout: 260 seconds]
[16:31:59] -!- VaughnStein has quit [Ping timeout: 244 seconds]
[16:46:02] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-241-192-dynip.superkabel.de] has joined #linuxcnc-devel
[16:46:50] <IchGuckLive> hi the new Documentation dioes not make it clear on CRC use that you can mix every ToolDiameter with every tool
[16:47:12] <IchGuckLive> G41 D12 can be used ecven if T1 is loaded
[16:47:25] <IchGuckLive> today studens referd to that
[16:47:50] <IchGuckLive> it is comen to us as we use it every day but not to beginners
[16:48:27] <IchGuckLive> http://www.linuxcnc.org/docs/2.5/html/gcode/tool_compensation.html#sec:cutter-radius-compensation question
[16:48:39] <IchGuckLive> i will make a mail to the devels list
[16:50:04] -!- VaughnStein has quit [Ping timeout: 244 seconds]
[16:50:36] <JT-Shop> looks pretty clear if you use D that your using that tool and that may not be the tool that is in the spindle
[16:50:48] <JT-Shop> unless I'm totally off base
[16:52:34] <IchGuckLive> i use 3Times D for every tool
[16:52:55] <IchGuckLive> as you can describe a pocket
[16:53:23] -!- tehDarkAura has quit [Ping timeout: 272 seconds]
[16:54:28] <IchGuckLive> nometter what it has to be in the documentation described
[16:54:50] <JT-Shop> I'm not understanding...
[16:56:00] tehDarkAura1 is now known as tehDarkAura
[16:56:01] <IchGuckLive> as the programm is always up you only need to change the D number for CRC change and leave the actily real Radius to the actully tool
[16:58:10] <IchGuckLive> T1 D2.98 REAL ( D101=3.1) D201 = 4.00
[16:58:18] -!- pingufan has quit [Quit: Konversation terminated!]
[16:59:54] <IchGuckLive> some of my folks like to have the D in .1 set to the D but this is realy only if you know your mashine so for Tool 3mm D30 is in place
[17:00:46] <IchGuckLive> the tooltable says then T1 D0.1 T2 D0.2 and so on
[17:02:58] <JT-Shop> I guess I'm dense as I can't comprehend what your trying to say is wrong with the manual
[17:03:01] <IchGuckLive> as there are so many workarounds i teatch it the first example to the 1500 folks a year that pases my course
[17:03:44] <IchGuckLive> JT-Shop: the documentation says nothing on this
[17:04:01] <IchGuckLive> it even gives in the example no D at all
[17:04:18] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[17:04:49] <IchGuckLive> hi mhaberler im on with the G12
[17:05:03] <mhaberler> so, what's the state of affairs
[17:05:05] <jepler> is this the documentation we're talking about? http://www.linuxcnc.org/docs/2.5/html/gcode/gcode.html#_g41_g42_tool_radius_compensation_a_id_sec_g41_g42_a
[17:05:34] <GoSebGo> The docs jepler just linked seem very clear to ne
[17:05:38] <GoSebGo> To me
[17:05:45] <JT-Shop> and ne too
[17:05:46] <IchGuckLive> jepler: no http://www.linuxcnc.org/docs/2.5/html/gcode/tool_compensation.html#sec:cutter-radius-compensation
[17:06:12] <psha> logger[mah]: .
[17:06:12] <logger[mah]> psha: Log stored at http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2012-03-09.html
[17:06:16] <IchGuckLive> there are 2 examples
[17:06:29] <cradek> clear but wrong: "The D word is optional; if there is no D word, the radius of the tool currently loaded with G43 will be used."
[17:06:43] <psha> jepler: and in long term? :)
[17:07:24] <jepler> psha: my understanding is that the solar output will increase to the point where no liquid water will exist on the earth's surface. At this point, there are unlikely to be any further commits to the linuxcnc git repository.
[17:07:37] <IchGuckLive> if no D it will use the D in the tooltable at the T Number
[17:08:15] <GoSebGo> jepler: i plan to move off-world before then so i can keep working on linuxcnc
[17:08:52] <IchGuckLive> Has the Mailinglist name also changed to linuxcnc ?
[17:09:35] <IchGuckLive> emc-developers@lists.sourceforge.net
[17:09:41] <CIA-6> 03cradek 07v2.5_branch * r66b015f2dd0f 10/docs/src/gcode/gcode.txt: fix doc error for G41/42 with no D word
[17:10:11] <IchGuckLive> or linuxcnc-developers@lists.sourceforge.net
[17:10:17] <jepler> IchGuckLive: it hasn't changed yet, but sometime soon we hope to move to new self-hosted mailing lists that will have "linuxcnc" in the name. http://mid.gmane.org/20120309015103.GB26045@unpythonic.net
[17:10:56] <IchGuckLive> B)
[17:11:15] <JT-Shop> cradek: did you correct all 4 files?
[17:11:26] <jepler> all .. four .. files ?
[17:11:28] <cradek> ??
[17:11:51] <JT-Shop> yes, we are blessed with 3 untranslated copies of each file
[17:12:31] <JT-Shop> quite a pain to keep them in sync until someone translates them
[17:13:02] <cradek> if they are not yet translated, aren't they just a copy of the english file? and if so, why is the copy needed?
[17:13:05] <jepler> GoSebGo: I am impressed with the depth of your committment to the project
[17:13:06] <IchGuckLive> my eng is so bad to translate it into german
[17:13:24] <JT-Shop> I've asked that question to myself a few times in the past
[17:13:34] <GoSebGo> Well i also have other motives
[17:14:19] <IchGuckLive> we all have ower different motives
[17:15:27] <mhaberler> cradek: because kimk set it up that way
[17:15:48] <IchGuckLive> cradek: if posible at some time can there be a example of a G2-3 helix downdrill
[17:16:11] <mhaberler> translation is a REAL mess with these dupe files.. very hard to track changes IMO
[17:16:53] <psha> jepler: in your opinion adding post-commit hooks will make that long term commit shortage or not?
[17:17:06] <psha> s/make/move closer/
[17:17:20] <mhaberler> it is crying for some tool support - or cleanup
[17:17:22] <JT-Shop> mhaberler: I agree having the duplicates is a mess
[17:17:58] <mhaberler> one way would be to consolidate the multiple files into one, and conditional formatting with some language tag
[17:18:32] <IchGuckLive> im of moving home By
[17:18:38] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 10.0.2/20120216080748]]
[17:19:49] <cradek> in the short term, we can use symlinks until we have translations
[17:19:51] <JT-Shop> I'm all for just changing the links to the engish files until one gets translated
[17:20:06] <cradek> but yeah there must a tool to use. this has to be a solved problem.
[17:21:49] <JT-Shop> at this time there are 3 files that have been translated to Spanish and all the rest are just duplicates of the English files
[17:22:13] <jepler> psha: sometime soon we'll get something set up to go from git.linuxcnc.org directly to github without going through my own system.
[17:22:24] -!- Mjolinor has quit [Quit: Leaving]
[17:22:39] <cradek> the duplicates are silly but I absolutely don't know how to fix it (aside from the brute force of using symlinks)
[17:22:39] <jepler> psha: it remains unsettled whether it'll happen in a hook or by cron, because there's a concern that if github can't be contacted a push to git.linuxcnc.org would seem to hang..
[17:24:38] <psha> need to check last part though - i've used post-commit hook to push to external repo and don't remember that even when it was not available i had serious problems
[17:24:42] <JT-Shop> the only thing I can think of is to just copy the english pdf and html files and delete all the duplicates and when a file gets translated make a small correction to the link in the pdf and html files
[17:25:05] <cradek> tested that a symlink for gcode.txt works
[17:25:54] <JT-Shop> how do you add/subtract a symlink
[17:26:02] <jepler> let me cook up something to symlink all the identical files
[17:26:16] <JT-Shop> ok
[17:26:31] <cradek> should I push the symlink change for gcode.txt (which is no longer identical)
[17:26:53] <jepler> cradek: if that's the approach we want to take, sure. I will handle that case in my script
[17:27:07] <jepler> but maybe there's an asciidoc include directive we should use instead?
[17:27:10] <jepler> I was just looking for that
[17:27:23] <cradek> I will do nothing
[17:27:25] <mhaberler> this is a common problem, so I assume we can learn a bit by looking around
[17:28:04] <JT-Shop> System_Requirements_ex.txt, Getting_EMC_es.txt, and Updating_EMC_es.txt have been translated
[17:28:18] <jepler> my script will handle the case where the files have been translated
[17:28:31] <JT-Shop> ok
[17:29:07] <mhaberler> well, let's think a bit what actually would help the translators, the dupe files are not prio #1
[17:29:44] <mhaberler> for instance, change tracking in a translated page wrt to the original one is a pain
[17:30:09] <cradek> I think we all agree with you
[17:31:59] <mhaberler> so, let's look around how other projects using asciidoc handle multilingual manuals, and talk about it in a few days
[17:33:16] <cradek> I look forwarding to hearing what you find
[17:33:19] <cradek> forward!
[17:37:23] <GoSebGo> po4a looks promising
[17:37:39] <jepler> well, I went ahead and finished knocking out my script: http://emergent.unpythonic.net/files/sandbox/relink-linuxcnc-docs.sh
[17:37:44] <JT-Shop> I am looking forward to not having to edit 4 files each time to keep them in sync
[17:39:01] <GoSebGo> It's in hardy through precise
[17:39:06] <JT-Shop> all the _fr files are translated
[17:39:48] <jepler> http://emergent.unpythonic.net/files/sandbox/0001-docs-symlink-nearly-identical-docs.patch
[17:39:59] <cradek> I don't see any harm in removing the duplicates right now, and then continuing to work toward a larger goal of making translations easier
[17:40:00] <GoSebGo> I think the french translation has changed more than words...
[17:41:23] <cradek> hm yes po4a looks useful
[17:41:52] <jepler> (that patch needs more review, I accidentally merged at least one _fr.txt that I shouldn't have)
[17:44:25] <JT-Shop> they may not have been translated yet
[17:44:38] <GoSebGo> I propose that we not re-redo our docs infrastructure for 2.5
[17:44:54] <jepler> GoSebGo: that's a very sensible suggestion
[17:44:55] <mhaberler> nono, too late
[17:44:56] <cradek> oh hey, that's the voice of reason
[17:45:10] <GoSebGo> Let's get 2.5 out, then fix this in 2.6
[17:45:22] <jepler> now that the time horizon for the project is extended at least to 1.5Gya from now (thanks seb!) we can take the long view
[17:45:37] -!- ewidance has quit [Quit: ewidance]
[17:45:41] <GoSebGo> I'm afraid that merging the french & english docs will be hard
[17:46:16] <jepler> (er, "Gy" not "Gya"; though it would be neat if we'd have been able to start the software that long ago)
[17:47:14] <GoSebGo> And will require a good french-speaker & a good english-speaker to work closely together to do the merge
[17:48:02] <GoSebGo> Hmm, tissf's not around, let's assign the action item to him
[17:48:08] <JT-Shop> looks like opto22_fr and servo_to_go_fr are still in English
[17:48:18] <JT-Shop> LOL
[17:49:07] <JT-Shop> as well as AX5214H_fr is still in English
[17:51:03] <JT-Shop> the main thing I'd like to do in 2.6 is have only one PDF document so you can link from anywhere
[17:58:09] -!- VaughnStein has quit [Read error: Connection reset by peer]
[18:03:17] * JT-Shop wonders why G64 is listed twice http://linuxcnc.org/docview/2.5/html/gcode/gcode.html#_g64_path_blending_a_id_sec_g64_path_blending_a
[18:03:40] <mhaberler> cool: http://pepipopum.dixo.net/
[18:03:50] <mhaberler> for a first cut
[18:04:55] <GoSebGo> JT-Shop: that link doesnt take me to the g64 section...
[18:05:25] <JT-Shop> seems to work for me
[18:05:51] -!- isssy has quit [Quit: Bye Bye]
[18:05:57] <JT-Shop> http://linuxcnc.org/docview/2.5/html/gcode/gcode.html
[18:06:03] <JT-Shop> then click on G64
[18:22:51] -!- phantoxe has quit []
[18:30:28] -!- VaughnStein has quit [Read error: Connection reset by peer]
[18:34:36] -!- deuplonicus has quit [Ping timeout: 245 seconds]
[18:46:25] -!- vladimirek has quit [Ping timeout: 246 seconds]
[18:50:08] -!- IchGuckLive [IchGuckLive!~chatzilla@95-89-241-192-dynip.superkabel.de] has joined #linuxcnc-devel
[18:50:54] <IchGuckLive> why diddent find the GRID modification a way into the new git master ?
[18:51:20] <IchGuckLive> its so usefull
[18:58:31] <jepler> The last revision of your code that I am aware of (Jan 28) had the grid stuff and the foam stuff all in one. I felt the foam stuff could still be improved further by building it on top of changes to the C++ code that I suggested. I have not looked in depth at the grid code.
[18:59:06] <IchGuckLive> ok
[18:59:58] <IchGuckLive> Thanks on to got a look at it to be inspired B)
[19:00:15] -!- VaughnStein has quit [Read error: Connection reset by peer]
[19:00:45] <jepler> my "foam" branch is here: http://git.unpythonic.net/view?p=emc2-jepler.git;a=summary
[19:01:10] <jepler> I can also put it online as a patch if that is easier for you
[19:01:52] <IchGuckLive> no i will tell from now people that want to go on Foam to use your git repro
[19:02:24] <jepler> well, i'm not 100% sure it's as good as yours for a user
[19:02:41] <jepler> it does some things better in the structure of the code (in my opinion)
[19:02:47] <IchGuckLive> i think it is even better then mine
[19:03:28] <jepler> but there may be some elements of your work that are missing from mine
[19:03:40] <jepler> have you tried my foam code?
[19:03:47] <IchGuckLive> i take alok right now
[19:04:13] <IchGuckLive> yes it works all over the world as there are good feedbacks
[19:05:33] <jepler> my version or your version?
[19:05:57] <IchGuckLive> mine i got notice of yours just seconds ago
[19:06:08] <jepler> OK, thought that's what you meant
[19:06:27] <jepler> basically, the structure of my code will give better performance with complex ngc files
[19:06:32] <jepler> because it does more in C++
[19:06:57] <IchGuckLive> agree
[19:07:30] <jepler> would you like me to teach you about "git remote" and how to easily use the code from git.unpythonic.net with your linuxcnc?
[19:08:35] <IchGuckLive> no im not as depth into the system
[19:09:59] <IchGuckLive> jepler: did you ever work with a real EDM ?
[19:10:10] <jepler> IchGuckLive: no, I haven't ever actually used an EDM or foam machine
[19:10:28] bnl is now known as bootnecklad
[19:10:43] <jepler> my experience is 99% 3-axis milling, 1% 5-axis milling
[19:11:04] <IchGuckLive> as i read the code you try(are) doing it will run in problems with a real edm as there are real 6Axis
[19:11:08] bootnecklad is now known as bnl
[19:11:26] <jepler> you mean there are Z and W axes too?
[19:11:49] <IchGuckLive> yes UVW are mounted on Z
[19:13:10] <jepler> hmm
[19:13:41] <jepler> for 3- and 5-axis machines we have [DISPLAY]GEOMETRY which can describe a range of configurations
[19:13:52] <IchGuckLive> if self.is_foam: comes from ini i guess where does self.foam_z, self.foam_w come from
[19:13:59] <jepler> in my foam code I've hardcoded 'XY' and 'UV' as the geometry of the two parts
[19:14:14] <IchGuckLive> thats ok
[19:14:26] -!- isssy has quit [Quit: Bye Bye]
[19:14:38] <IchGuckLive> Z is the part height + cool wire dist
[19:14:45] <jepler> it could be made configurable, so that you can describe 'UVW is mounted on Z'
[19:14:53] <IchGuckLive> W is the ofset for the wire
[19:15:28] <jepler> can you find me a picture or diagram of this to help me understand?
[19:15:57] <IchGuckLive> i only have seen 3 selfmade EDM so far as there are not in Hobbyists room present
[19:16:02] <jepler> foam_z and foam_w are the values from the gcode comments (XY_Z_POS and UV_Z_POS). They go on the canon object. I think this is similar to your code, but I'm not 100% sure.
[19:16:38] <IchGuckLive> Thanks to that it has to be in the Gcode file
[19:17:23] <jepler> there's also a default value in case none is found in the gcode file. It would be possible to make that an inifile option too
[19:17:53] <jepler> arbitrarily, the defaults are Z at 0 and W at 1.5 (inches)
[19:19:47] <IchGuckLive> agree also in mine patch
[19:20:28] -!- sumpfralle has quit [Quit: Leaving.]
[19:25:10] <IchGuckLive> i only fond a picture from the inside of mine edm but the sheeds are all in place so there is no sign for the UV so loosless
[19:29:09] -!- VaughnStein has quit [Read error: Connection reset by peer]
[19:29:12] <IchGuckLive> google pic search "agie evolution 2" does only give a small indication as it is all water tight seald
[19:30:21] <jepler> yes it doesn't help me understand how Z and W are used
[19:31:25] <jepler> with the foam patches I can visualize what XY and UV are doing
[19:32:12] <jepler> if I had "G1 W0" and later "G1 W1", is something 'moving up' after the G1 W1?
[19:32:12] <IchGuckLive> i think also that W isent used in the cheep EDM at all and UV is on limit 50mm +-
[19:32:59] <IchGuckLive> on AGIE D200 yes
[19:33:44] <jepler> would it be like the (UV_Z_POS) was increased by 1?
[19:33:53] -!- VaughnStein has quit [Client Quit]
[19:33:56] <IchGuckLive> nio
[19:34:03] <IchGuckLive> no
[19:34:32] <IchGuckLive> it moves the plastic 45deg wiser that holds the wire up 1mm
[19:35:28] <jepler> wiser?
[19:35:52] <IchGuckLive> this does also not mather in Gcode leave it your way and we are done
[19:36:37] <IchGuckLive> http://www.maschinensucher.de/ma2/bilder/Drahterodiermaschine-AGIE-AGIECUT-Evolution-2/1020427-4.jpg
[19:37:08] <IchGuckLive> the uper green block is the UVW the gray/black square is the Z
[19:38:02] <IchGuckLive> the Z axis stays in post prozessor Z as the XY UV W moves
[19:38:26] <IchGuckLive> UV folows xy and gives the cone angle
[19:40:04] <IchGuckLive> max Z is 315 W is 5mm UV also 50 mm X600 Y500
[19:41:50] <IchGuckLive> the calibration cycle for the wire plumb is what you need to see in real its fantastic how the axis move around
[19:46:37] <IchGuckLive> jepler: http://www.youtube.com/watch?v=KqsDaMuupJo as the camera comes out of the water you can see the axis mount UVW
[19:49:41] <jepler> the part that is rotating is advancing the wire?
[19:51:36] <IchGuckLive> deficult to discribe there are no motors or actuators in place it is all on push pull from the main frame
[19:52:13] <IchGuckLive> but as i said dont care noone will decide to do edm with linuxcnc in the neer futher i think
[19:53:21] <IchGuckLive> o need to leave thanks for the talk BY
[19:53:27] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 10.0.2/20120216080748]]
[19:58:54] -!- VaughnStein has quit [Read error: Connection reset by peer]
[20:00:59] <jepler> anybody else have an opinion about merging my foam changes into master?
[20:01:50] <cncbasher> i'm going edm with emc if i can get the time to do it
[20:01:53] <jepler> I don't think it breaks anything, I think it's a good foundation, and if IGL wants to work on what I've missed it would be an easier starting point technically
[20:02:34] -!- pcw has quit [Ping timeout: 260 seconds]
[20:04:27] <jepler> cncbasher: I don't suppose you understand what IchGuckLive was trying to explain about Z and W axes on wire edm, do you?
[20:04:44] <cradek> jepler: I have no objection or other strong feeling
[20:06:03] <cradek> jepler: did you ever merge plug-interp?
[20:06:16] <jepler> cradek: I don't think so
[20:06:19] <jepler> do you think I should?
[20:06:25] <cradek> definitely
[20:06:33] <jepler> I'll dust it off..
[20:06:56] <cradek> I see it as the basis for all the kinds of work that people periodically get excited about
[20:06:58] <cncbasher> not sure need to re -read , but for edm and foam , you'd need 2 independant axis top and bottom
[20:07:09] <jepler> yes
[20:07:30] <cncbasher> and to control wire length as the axis length would increase on the z
[20:08:06] <cncbasher> if for argument the wire was at 45 degrees
[20:08:17] <cncbasher> in the verticle
[20:08:30] -!- VaughnStein has quit [Read error: Connection reset by peer]
[20:09:14] <cncbasher> so the cone angle would be calculated also
[20:10:13] -!- mhaberler has quit [Read error: Operation timed out]
[20:10:57] <jepler> hm
[20:11:08] <jepler> I can see that at an angle you'd need a greater length of wire than when vertical
[20:11:35] <cncbasher> you would need the wire length to be calculated between the 2 cones , dependant on the positions of the top and bottom axis
[20:12:43] <cncbasher> wire angle would need to be calculated on not only the distances between the cones , but also the angle produced
[20:13:43] <cncbasher> as the angle would be different , due to the distance between the cones
[20:14:34] <cncbasher> so if your cutting say a 2" deep peice of foam , the angle would be different if the foam block was say 10"
[20:15:53] -!- psha has quit [Quit: leaving]
[20:16:05] <cncbasher> as well as the axis positons
[20:16:33] <cncbasher> so we are talking a 3d space
[20:16:45] -!- FinboySlick has quit [Quit: Leaving.]
[20:17:16] <jepler> so is this distance explicit in the part program, or does the control have to internally determine the distance ?
[20:18:04] <CIA-6> 03jepler 07master * r652b681f8b03 10/configs/sim/axis/axis_foam.ini: configs: a new sim config for xyuv (foam cutters)
[20:18:05] <CIA-6> 03jepler 07master * r4ef396ad1320 10/nc_files/foam.ngc: nc_files: add a foam demo file
[20:18:06] <CIA-6> 03jepler 07master * rf3568a4bf376 10/src/emc/usr_intf/axis/extensions/minigl.c: minigl: add needed functions and constants
[20:18:09] <CIA-6> 03jepler 07master * r751970b37cb9 10/lib/python/hershey.py: hershey: add UVW letters
[20:18:10] <CIA-6> 03jepler 07master * ra704a229a172 10/src/emc/usr_intf/axis/scripts/axis.py: axis: check an inifile flag for foam machine mode
[20:18:10] <CIA-6> 03jepler 07master * r40d36244c612 10/src/emc/usr_intf/axis/extensions/emcmodule.cc: live plotter: begin support of foam live plot
[20:18:10] <CIA-6> 03jepler 07master * r9457b45adfe5 10/ (3 files in 2 dirs): foam: define colors for foam preview plot
[20:18:11] <CIA-6> 03jepler 07master * rc2414ec125cd 10/lib/python/rs274/glcanon.py: foam: begin support of foam in GLCanon
[20:18:12] <CIA-6> 03jepler 07master * r21cdae4500a3 10/src/emc/usr_intf/axis/scripts/axis.py: foam: axis must pass in the foam flag
[20:18:13] <CIA-6> 03jepler 07master * r0e7e6d500126 10/lib/python/rs274/glcanon.py: glcanon: add accessors for foam z and w
[20:18:14] <CIA-6> 03jepler 07master * re4a044c188a9 10/lib/python/rs274/glcanon.py: foam: display uv and xy cones
[20:18:14] -!- motioncontrol has quit [Quit: Sto andando via]
[20:18:15] <CIA-6> 03jepler 07master * r6f43290c04be 10/lib/python/rs274/glcanon.py: glcanon: add ability to plot UVW origin; use it
[20:18:16] <CIA-6> 03jepler 07master * r038301baaa13 10/lib/python/rs274/glcanon.py: glcanon: parse foam-specific comments
[20:18:16] <CIA-6> 03jepler 07master * re980b8cab112 10/lib/python/rs274/glcanon.py: foam: fix appearance of selected line
[20:18:17] <CIA-6> 03jepler 07master * re75d99e9ccec 10/lib/python/rs274/glcanon.py: foam: use foam w and z for extents
[20:18:18] <CIA-6> 03jepler 07master * r196afcc6e6b4 10/src/emc/usr_intf/axis/scripts/axis.py: foam: change live plot depth according to preview
[20:18:20] <CIA-6> 03jepler 07master * r2e9e28faa0cb 10/ (8 files in 6 dirs): Merge remote branch 'jepler/foam'
[20:18:28] <cncbasher> i'd go with the control to determine the distance between axis
[20:18:55] <cncbasher> but i must admit , i'm not 100% convinced
[20:20:08] <cncbasher> think of a verticle wire as a pendlum , now move the lower end 6" right
[20:21:27] <cncbasher> if you now move the top of the wire 6 inches right and your material your cutting is 2" thick
[20:21:42] <cncbasher> your wire is going to go slack
[20:22:00] <cncbasher> so you'll need to control the wire tension
[20:22:08] <cncbasher> as the axis is moved
[20:22:12] <jepler> yeah, I was just thinking that a purely mechanical method to tension the wire sounds nice
[20:22:35] <cncbasher> could be feedback from the distance to say a stepper
[20:22:44] <cncbasher> to wind out or in
[20:22:59] <jepler> but failing that you could have CNC control of the amount of wire between the two ends, or CNC control to change the height of one end to keep the distance constant
[20:23:05] <cncbasher> so that is kept out the main gcode loop
[20:23:51] <cncbasher> it becomes worse the more you think about it
[20:24:21] <jepler> the same problem must exist in foam and edm
[20:24:27] <jthornton> cncbasher: hot wire cutters the wire is spring loaded as it sags when heated
[20:24:39] <cncbasher> yea correct John
[20:24:55] <jthornton> wire edm doesn't the take up roller take all it can?
[20:25:01] <CIA-6> 03jepler 07v2.5_branch * r0daa4473ad84 10/src/emc/ (ini/initool.cc task/emctask.cc): use %zu for object sizes
[20:26:00] <jepler> cradek: lots of conflicts in plug-interp
[20:26:11] <cncbasher> on an edm the wire is slowly being wound to the lower reel all the time
[20:26:39] <cncbasher> so you need a tensioner type system too
[20:26:55] <cncbasher> similar to a sewing machine to take up the slack
[20:27:08] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[20:27:57] <cncbasher> so you'd have a feed similar to a mig , and a spring loaded takeup spool winding the slack
[20:28:53] <cncbasher> so as the length between the cones increases then the feed of the wire would need to be proportional to feed rate
[20:29:20] <cncbasher> so speed up the feed to keep tension
[20:29:44] <jthornton> 3-9-12 SG 1.012
[20:29:51] <jthornton> opps wrong window
[20:31:43] <cncbasher> so how do you control the feed of the wire dependant on the positon of the 4 axis in relation to each other
[20:32:30] <cncbasher> i.e reel in faster on the lower , or speed up the feed roll
[20:33:16] <cncbasher> and linked to the feed rate programmed
[20:35:24] <cncbasher> using a seperate bow in foam cutting is much easier of course , as the bow is suspended and the length can vary as it slides through the cone points
[20:37:10] <jthornton> so, is it safe to just make changes to the English docs or should I continue changing them all?
[20:38:15] -!- VaughnStein has quit [Read error: Connection reset by peer]
[20:41:34] -!- VaughnStein has quit [Read error: Connection reset by peer]
[20:46:24] -!- factor has quit [Quit: Leaving]
[20:46:55] <jepler> I think for now just change the english docs
[20:47:45] -!- ewidance has quit [Client Quit]
[20:48:12] <jepler> but .. nobody takes my advice anyway
[20:53:44] <JT-Shop> thanks
[20:53:51] <JT-Shop> I know the feeling
[21:02:48] -!- VaughnStein has quit [Quit: Bye]
[21:41:50] <jepler> mharbler: if you see this, can you clarify what this change is about?
[21:41:50] <jepler> -# cludge around linking issue in taskclass
[21:41:50] <jepler> -$(call TOOBJSDEPS,$(SAISRCS)) : EXTRAFLAGS=-Dinterp_new=interp
[22:00:15] -!- mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[22:01:05] <jepler> 15:41:50 <jepler> mharbler: if you see this, can you clarify what this change is about?
[22:01:08] <jepler> 15:41:50 <jepler> -# cludge around linking issue in taskclass
[22:01:11] <jepler> 15:41:50 <jepler> -$(call TOOBJSDEPS,$(SAISRCS)) : EXTRAFLAGS=-Dinterp_new=interp
[22:01:47] <jepler> I'm reviving plug-interp at cradek's prodding and I ran into a conflict near there
[22:01:53] <mhaberler> I'll look
[22:02:01] <jepler> I've resolved it fairly arbitrary, and all tests pass .. but I don't know what it was about
[22:02:14] <jepler> (my change ends up removing the lines; you added them)
[22:02:19] <mhaberler> oh, great
[22:02:29] <jepler> 48b3c8726784b27584558ed8f5d3e605748fa640
[22:02:42] <jepler> well, I am worried I'm re-breaking whatever you were fixing :-/
[22:03:31] <jepler> anyway, I have the following change in driver.cc:
[22:03:32] <jepler> -Interp interp_new;
[22:03:32] <jepler> +InterpBase *pinterp;
[22:03:32] <jepler> +#define interp_new (*pinterp)
[22:03:37] <mhaberler> dont worry, go ahead, that's just sau
[22:03:41] <mhaberler> sai
[22:03:51] <mhaberler> I read your shlib code and tried it
[22:03:51] <jepler> which really didn't play nice with the commandline -D
[22:04:05] <jepler> any comments to make?
[22:04:20] <jepler> I think I can have it ready to go into current master today..
[22:04:49] <mhaberler> let me look what that was.. it' been a while
[22:05:40] <mhaberler> oh, I remember
[22:08:19] <mhaberler> taskclass.cc calls upon interp.on_abort, so it needs the interp global, not interp_new
[22:08:45] <mhaberler> a global s/interp_new/interp/ in sai/driver.cc should work
[22:10:05] e-ndy|afk is now known as e-ndy
[22:10:33] <mhaberler> that mirrors the symbol task expects
[22:11:41] e-ndy is now known as e-ndy|afk
[22:11:55] <mhaberler> actually that on_abort cant be called from sai, it's just a linking issue
[22:15:39] <jepler> does that mean that if I don't get a linker error it's OK?
[22:17:17] <mhaberler> yep
[22:20:45] <jepler> that's weird. there's a veeerrrrryyyy long pause just before the first G1 move in the splash gcode
[22:21:08] <jepler> apparently it takes a very long time for the simulated spindle to get to 10krpm
[22:21:10] <mhaberler> that's the spinup of the spindle;)
[22:21:14] <mhaberler> yess
[22:21:35] <jepler> I haven't run master lately, so the first time I assumed it was something i'd broken
[22:21:54] <mhaberler> the delay probably needs to be tuned down
[22:22:00] -!- DJ9DJ has quit [Quit: bye]
[22:22:20] <mhaberler> rampup, or lowpass, or whatever it is
[22:22:52] <mhaberler> other that that, the sim spindle was extremely useful working with spindle-sync cycles
[22:25:15] <mhaberler> since you're on a related warpath… I'm making canon has an abstract base class and emc,sai,previewcanon instances; interp state is spun out into classes; interp_config, interp_execstate, interp_modalstate, and the global machinestate become classes; the tooltable as such becomes a loadable shlib and a class which is part of machinestate
[22:25:57] <mhaberler> the default tooltable is the legacy scheme; the other one will be a python instance of this class so folks can use what they want
[22:26:59] <mhaberler> the toolstore adt also encapsulates the knowledge what needs to be done for a given changer type
[22:27:54] <mhaberler> the part on how the toolstore information is distributed is still undecided; redis works fine but I'm shooting for a solution where redis is optional
[22:32:32] -!- thebuc has quit [Quit: Page closed]
[22:34:29] <jepler> If you mean that there should be a class on which the current CANNON_UPPER_CASE calls are methods, I agree heartily
[22:34:55] <jepler> I'm not sure how the interp state split fits with the InterpBase abstract class I am introducing in this branch
[22:35:20] <mhaberler> that isnt visible at the abc
[22:35:49] <jepler> so it's something that would apply to rs274 but not to some other unrelated interpreter like canterp?
[22:36:08] -!- syyl_ws has quit [Quit: Verlassend]
[22:36:10] <mhaberler> oh, not quite. the 4 state classes are ctor args.
[22:36:15] <jepler> oh, hm
[22:36:38] <mhaberler> they might be reuired syntactically but probably be deadweight for canterp
[22:36:50] <mhaberler> yes, CANON is CLASSFIIED
[22:37:20] <mhaberler> man, somebody had the elbow at the shift key over at Nist.. or a former cobol career
[22:37:22] <jepler> it doesn't seem like there's a lot of commonality between the modal state of rs274 and a totally-not-gcode-at-all interpreter, so the class you'd pass to the constructor of one is inappropriate for the other
[22:37:29] <jepler> CAN YOU HEAR ME NOW
[22:37:35] <mhaberler> SORT OF
[22:38:32] <jepler> as far as tools go (did I say this once already?) what's important is addressing the actual practical problems with tools as they exist now (like arbitrary limitations in table size); I know I don't have a good handle on what those problems are because of how simple my machine is
[22:38:44] <mhaberler> maybe I can fudge that away so its required onyl for rs274ngc instantiation, I'm not totatlly firm in c++ class esotera
[22:38:58] <jepler> I have no idea how heavy/light Redis is compared to the problem it's to solve
[22:39:41] <mhaberler> it is very light. the key asset wrt NML is late binding of the namespace
[22:39:51] <jepler> one thing that would be nice about canon-as-class is that it would do away with a terrible dynamic loader hack I have to introduce, and also remedy some lintian errors about our packages
[22:40:30] <mhaberler> yes, the canon instance pointer becomes a Interp ctor argument
[22:40:32] <jepler> +RTLD_NOW, RTLD_GLOBAL = 0x1, 0x100 # XXX portable?
[22:40:32] <jepler> +old_flags = sys.getdlopenflags()
[22:40:33] <jepler> +sys.setdlopenflags(RTLD_NOW | RTLD_GLOBAL);
[22:40:33] <jepler> +import gcode
[22:40:35] <jepler> +sys.setdlopenflags(old_flags)
[22:40:37] <jepler> namely this ^^^
[22:40:40] <jepler> can you say "eew"?
[22:41:20] <mhaberler> asthetics is technically a death march
[22:41:22] <jepler> so do you see any red flags as far as whether plug-interp will make your goals harder?
[22:41:33] <jepler> if not, I think I have it ready to push to master
[22:41:48] <jepler> now that I fixed the "splash gcode won't run" problem
[22:42:01] <mhaberler> no, not really
[22:42:11] <jepler> OK, in that case, let them eat cake
[22:42:22] <mhaberler> that saying was inspired by: http://despair.com/quality.html
[22:42:36] <jepler> aha
[22:42:38] <mhaberler> which has lots of motifs applicable to emc-users
[22:43:37] <CIA-6> 03jepler 07master * r2e0e7925c938 10/src/emc/rs274ngc/ (rs274ngc_interp.hh rs274ngc_pre.cc): interp: don't use a default argument on methods
[22:43:38] <CIA-6> 03jepler 07master * rb049c335e3fa 10/src/emc/rs274ngc/ (rs274ngc_interp.hh rs274ngc_pre.cc): interp: use size_t for sizes; return buffers
[22:43:39] <CIA-6> 03jepler 07master * r20cb3efccc87 10/src/emc/rs274ngc/ (6 files): interp: introduce a base class for interpreters
[22:43:39] <mhaberler> the only thing I could think of is the python plugin instantiation; thats a singleton and either task or interp wins
[22:43:39] <CIA-6> 03jepler 07master * r48f8ad0397ab 10/src/emc/rs274ngc/ (Submakefile interp_base.cc interp_base.hh): interp: allow creation of pluggable interpreters
[22:43:41] <CIA-6> 03jepler 07master * ra4e8d60d2478 10/src/emc/task/emctask.cc: interp: allow use of pluggable interpreters
[22:43:41] <CIA-6> 03jepler 07master * rafde7679c331 10/src/emc/canterp/ (Submakefile canterp.cc): canterp: revive as pluggable interpreter
[22:43:42] <CIA-6> 03jepler 07master * r95c6d82b5d6f 10/src/emc/sai/ (Submakefile driver.cc saicanon.cc): sai: allow use of pluggable interpreter
[22:43:43] <CIA-6> 03jepler 07master * red3b1332644f 10/tests/interp/plug/ (README canon expected test.sh): canterp: test that plugging canterp in sai works
[22:43:44] <CIA-6> 03jepler 07master * r4ea57f9b19da 10/configs/sim/axis/canterp.ini: add a configuration that uses canterp
[22:43:45] <CIA-6> 03jepler 07master * rc91e3421bf7b 10/lib/python/rs274/ (glcanon.py interpret.py): axis: be robust when canon calls don't happen
[22:43:46] <CIA-6> 03jepler 07master * r4a4fb1af1d5d 10/ (3 files in 3 dirs): axis: allow plugabble interpreters
[22:44:14] <mhaberler> great!
[22:44:41] <jepler> # Unmerged paths:
[22:44:41] <jepler> # (use "git add/rm <file>..." as appropriate to mark resolution)
[22:44:41] <jepler> #
[22:44:41] <jepler> # both modified: ../docs/src/gcode/overview.txt
[22:44:41] <jepler> #
[22:44:43] <jepler> jepler@dopey:/usr/local/jepler/src/linuxcnc-master/src$ git mergetool
[22:44:46] <jepler> No files need merging
[22:44:48] <jepler> hmmm
[22:44:51] <jepler> no files need merging, you say?
[22:45:17] <mhaberler> duh?
[22:46:09] <jepler> not sure why, but git mergetool is trying to trick me
[22:46:39] <jepler> that file sure has conflict markers in it
[22:46:54] <jepler> oh, hm, it's "my fault": "git mergetool" in src/ only looks in src/ not in docs/
[22:47:05] <jepler> once I know that it is handy
[22:47:46] <mhaberler> I've switched to git from kernel.org a while ago and some weirdnesses just went away; but that one isnt,ye
[22:47:46] <mhaberler> s
[22:49:26] <jepler> like everything else I'm running a modestly old version of git -- 1.7.0.4!
[22:49:41] <jepler> though at home I'm now on debian testing so a lot of things are newer
[22:49:52] <mhaberler> oh, and an important redis bonus point: youporn is now a redis-backed site
[22:50:20] <jepler> a testament to their robustness, I imagine
[22:50:34] <CIA-6> 03jepler 07master * r27d9913b1fb2 10/ (36 files in 9 dirs): Merge remote branch 'origin/v2.5_branch'
[22:50:37] <mhaberler> it's called 'staying power'
[22:50:49] <mhaberler> or 'uptime'
[22:51:20] <mhaberler> anyway, re recent git - since they added asked if you want to add untracked files I rarely forget to add one
[22:51:56] <jepler> you cannot imagine how jealous I am of someone who can pun well in a second language.
[22:52:34] <jepler> anyway, I'm off for an evening of debauchery: one beer, or maybe two if I'm feeling extremely wild.
[22:52:46] <mhaberler> enjoy!
[22:52:50] <jepler> see you around.
[22:53:11] <GoSebGo> Seeya jeff, ya wild man you :-)
[22:53:34] <mhaberler> oh. we've been stalked.
[22:54:05] <GoSebGo> Well you *are* in public ;-)
[22:54:38] <mhaberler> move over to the emc-users mailing list and you feel *very* lonely at times
[22:54:38] <GoSebGo> Is this pluggable intetpret
[22:54:42] <mhaberler> yep
[22:55:09] <mhaberler> it is not 'instantiable interp' yet, but along that path
[22:55:32] <GoSebGo> Plug interp stuff going to let me issue canon commands directly from python or whatnot?
[22:55:40] <mhaberler> yes
[22:55:45] <GoSebGo> Neat
[22:56:03] <mhaberler> provided someone cooks up a canterp which understands python
[22:56:15] <mhaberler> but that's straightforward
[22:56:32] <mhaberler> do you see a use case for that?
[22:57:05] <mhaberler> there are some gotchas, like the broken 'source location' concept, on which RFL depends
[22:57:22] <GoSebGo> Many of my nerdy friends are interested in cnc but get turned off when i show them gcode
[22:57:27] -!- elmo40 has quit [Read error: Connection reset by peer]
[22:58:02] <mhaberler> those would be customers for rs274author.py
[22:58:25] <GoSebGo> Generating gcode as an intetmediate is an option, buti coding directly in another language might be moe appealing
[22:59:01] <mhaberler> well that's possible now, and it would be an interesting experiment to plug in python with canon bindings
[23:00:42] <mhaberler> 'some plumbing required' for rotation, offsets, blending, uh
[23:00:54] -!- adb has quit [Ping timeout: 252 seconds]
[23:00:57] <GoSebGo> Cutter comp...
[23:01:16] <GoSebGo> Where's that rs274author.py?
[23:01:28] <mhaberler> I think wiki
[23:01:39] <GoSebGo> Ah yes
[23:01:50] <mhaberler> yes, a lot of the important stuff has fuzzy demarcation lines between interp and canon, sometimes distributed between both
[23:03:09] <CIA-6> 03tissf 07v2.5_branch * r280b0eaf6447 10/docs/ (html/gcode_fr.html src/gcode/gcode_fr.txt): French doc: update and cleaning
[23:03:49] <mhaberler> have you used po4a?
[23:03:59] -!- bedah has quit [Quit: Ex-Chat]
[23:04:51] <GoSebGo> Nope
[23:36:28] <mhaberler> jepler: no negative impact I can discern so far
[23:49:34] -!- theorbtwo has quit [Ping timeout: 276 seconds]