Back
[00:01:17] <andypugh> Maybe.
[00:03:40] <andypugh> I am a bit frazzled as AFAIK I never got into that function in the previous iterations. lots of segfaults and when it wasn't that a compiler saying that it wasn't happy with char[18] and char * being used together.
[00:04:17] <andypugh> (and I am sure that I have had this combination of references / dereferences before)
[00:04:20] <cradek> maybe more than one problem
[00:04:48] <cradek> but I think you've made a null pointer (explicitly set to 0) and then wrote through it here
[00:05:06] <cradek> which is sure wrong
[00:05:19] <andypugh> I do have somewhere new to look, certainly.
[00:07:01] <andypugh> Not as blatent as this:
http://www.linuxcnc.org/index.php/english/component/kunena/?func=view&catid=38&id=18729&limit=6&start=30 (pfred opined that it was never necessary to reboot linux)
[00:08:54] <mhaberler> queued MDI works:
http://git.mah.priv.at/gitweb/emc2-dev.git/shortlog/refs/heads/queued-mdi (it actually sports a queue now)
[00:09:30] <andypugh> You see, I wonder why I bother when there are actual competent folks out there.
[00:10:56] <andypugh> cradek: Ah, I think I did mean *inst, the compiler says "uart.c:156: error: incompatible types when assigning to type ‘struct hm2_uart_instance_t *’ from type ‘hm2_uart_instance_t’"
[00:11:09] -!-
ve7it has quit [Remote host closed the connection]
[00:12:08] <cradek> maybe you meant inst = &something
[00:13:02] <andypugh> That's the next thing I was going to try, but surely I should _know_ rather than compile and hope?
[00:13:45] <cradek> yeah they don't mean the same thing
[00:14:22] <andypugh> I know they don't mean the same thing. What I don't know is which one I mean.
[00:15:10] <andypugh> However, that didn't crash.
[00:15:11] -!-
PCW has quit [Quit: ChatZilla 0.9.88.1 [Firefox 3.6.13/20101203075014]]
[00:15:52] <andypugh> But if I was half-competent i would have known to use that structure in the first place..
[00:16:49] -!-
crib has quit [Ping timeout: 252 seconds]
[00:16:58] <andypugh> Though I guess when your structures get this metastasised and deep, it isn't trivial to keep track of levels of abstraction.
[00:17:02] <cradek> if p is a pointer and s is a struct, *p = s and p = &s will both compile. *p = s means copy the structure to where p points (and p was null for you), p = &s means set p so it points to s (set p to contain the address of s)
[00:18:47] <andypugh> Is it obvious that "hm2->uart.instance[i]" is a struct? It looked like a pointer to me.
[00:20:19] <andypugh> I think I have spent too long in "pass by reference" languages.
[00:20:28] <cradek> well s could also be an integer, it doesn't matter
[00:20:39] <cradek> in this case it's a hm2_uart_instance_t, whatever that is
[00:20:57] <andypugh> Well, that's a type, I guess.
[00:21:45] crib- is now known as
crib
[00:24:31] -!-
Loetmichel has quit [Ping timeout: 252 seconds]
[00:24:33] <andypugh> Thanks though. This has been very heplful. I think a large part of my problem has been because I assumed that the existing code was working because there were no complaints. So I was only looking in new code.
[00:25:48] <cradek> welcome!
[00:37:14] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[00:38:34] -!-
syyl_ has quit [Quit: Leaving]
[00:57:26] <andypugh> OK, I now seem to have almost the inverse problem. I want to kill RTAI from inside a void function.
[01:02:05] <andypugh> It seems like a flag to say "I have already raised an error message" is the easier option.
[01:10:48] -!-
rob__H has quit [Ping timeout: 260 seconds]
[01:35:30] <andypugh> http://code.google.com/p/android/issues/detail?id=20795
[01:38:50] -!-
JT-Shop-2 has quit [Ping timeout: 250 seconds]
[01:38:54] -!-
jthornton has quit [Ping timeout: 245 seconds]
[01:51:00] <andypugh> This is just nonsense, I assume? andypugh@mill:~/emc2-dev/src$ addr2line -e hm2_pci.ko 0xd71
[01:51:02] <andypugh> andypugh@mill:~/emc2-dev/src$ gedit /usr/src/linux-headers-2.6.32-122-rtai/arch/x86/include/asm/string_32.h
[01:51:54] <andypugh> Sorry, let me pastebin. the /chars are confusing IRC
[01:55:21] <andypugh> http://pastebin.com/t0cwLVi7
[01:56:21] <andypugh> does addr2line look inside include files?
[01:58:34] <jepler> that's the implementation of memcpy. in at least some cases, when you do a structure copy with "=", the compiler will make a call to "memcpy" to make the copy happen.
[01:59:50] <jepler> so I wouldn't assume it's wrong, but it may not be the most helpful information either
[02:00:47] <andypugh> So, I am probably back to rtapi_print("well, I got as far as line nnn in code xxxx") then?
[02:03:02] <jepler> you could try other tools like objdump -d -S to get a disassembly mixed with source
[02:03:22] <jepler> I'm not sure whether that'll work on a .ko
[02:03:30] <andypugh> I think I would find that more confusing still.
[02:03:37] <jepler> the output is big so you'll have to pipe it to less or something
[02:05:22] -!-
Hayro has quit [Ping timeout: 244 seconds]
[02:17:17] -!-
Hayro has quit []
[02:24:00] <andypugh> I am trying to pulll -32 bytes out of a 16-deep FIFO . That isn't going to work.
[02:29:02] -!-
pcw_home has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120423122624]]
[02:29:09] -!-
sumpfralle has quit [Ping timeout: 248 seconds]
[02:33:20] -!-
andypugh has quit [Quit: andypugh]
[02:54:12] -!-
jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[02:54:13] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[02:57:35] -!-
jthornton has quit [Read error: Connection reset by peer]
[02:57:35] -!-
JT-Shop has quit [Read error: Connection reset by peer]
[03:00:52] -!-
mhaberler has quit [Quit: mhaberler]
[03:25:56] Connor2 is now known as
Connor_CNC
[03:47:54] -!-
dunz0r has quit [Ping timeout: 252 seconds]
[03:59:14] -!-
cmorley [cmorley!~chris@d205-206-23-14.abhsia.telus.net] has joined #linuxcnc-devel
[03:59:33] -!-
jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[03:59:50] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[04:00:56] -!-
mozmck has quit [Remote host closed the connection]
[04:03:03] -!-
mozmck [mozmck!~moses@client-74.117.92.175.dfwtx.partnershipbroadband.com] has joined #linuxcnc-devel
[04:08:28] -!-
skunkworks__ has quit [Remote host closed the connection]
[04:18:55] -!-
FinboySlick has quit [Quit: Leaving.]
[04:32:08] -!-
factor has quit [Ping timeout: 240 seconds]
[04:35:44] -!-
kb8wmc [kb8wmc!~chatzilla@nat.mtp.cmsinter.net] has joined #linuxcnc-devel
[04:45:24] -!-
toastydeath has quit []
[04:53:38] -!-
cmorley has quit [Ping timeout: 260 seconds]
[04:58:56] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[05:20:55] -!-
mk0 has quit [Quit: Leaving]
[05:22:27] -!-
cevad has quit [Quit: Leaving]
[05:22:44] -!-
mk0 has quit [Client Quit]
[05:23:19] -!-
Keknom has quit [Quit: Leaving.]
[05:26:42] icarusfactor is now known as
factor
[05:37:05] -!-
factor has quit [Read error: Connection reset by peer]
[05:44:09] -!-
kb8wmc has quit [Quit: ChatZilla 0.9.88.2 [Firefox 12.0/20120423130206]]
[06:10:21] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[06:30:20] -!-
capricorn_1 has quit [Quit: Konversation terminated!]
[07:43:57] -!-
ScribbleJ has quit [Ping timeout: 260 seconds]
[07:52:53] -!-
psha has quit [Quit: Lost terminal]
[08:04:01] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has joined #linuxcnc-devel
[08:09:06] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[08:28:23] -!-
rob_h [rob_h!~rob_h@5e014ffd.bb.sky.com] has joined #linuxcnc-devel
[09:05:32] -!-
micges [micges!~micges@dce129.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[09:11:47] -!-
micges has quit [Quit: Leaving]
[09:37:33] -!-
mhaberler has quit [Quit: mhaberler]
[09:39:08] -!-
r00t4rd3d has quit [Ping timeout: 240 seconds]
[09:40:23] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[09:40:49] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[10:11:25] -!-
jackc has quit [Ping timeout: 256 seconds]
[10:26:18] cylly2 is now known as
Loetmichel
[10:30:52] -!-
jackc has quit [Ping timeout: 252 seconds]
[10:39:11] -!-
Guthur has quit [Ping timeout: 256 seconds]
[10:48:44] -!-
sumpfralle has quit [Ping timeout: 246 seconds]
[10:50:23] freespac1 is now known as
freespace
[10:59:23] -!-
A0Sheds has quit [Read error: Operation timed out]
[11:12:45] -!-
A0Sheds has quit [Changing host]
[11:19:32] -!-
A0Sheds has quit [Ping timeout: 246 seconds]
[12:03:57] -!-
mhaberler has quit [Quit: mhaberler]
[12:06:09] -!-
jackc has quit [Ping timeout: 265 seconds]
[12:10:58] -!-
jackc has quit [Ping timeout: 252 seconds]
[12:22:03] -!-
cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has joined #linuxcnc-devel
[12:25:25] -!-
jackc has quit [Ping timeout: 248 seconds]
[12:27:57] -!-
motioncontrol has quit [Ping timeout: 244 seconds]
[12:29:58] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[12:34:25] -!-
jackc has quit [Ping timeout: 250 seconds]
[12:49:34] -!-
mhaberler has quit [Quit: mhaberler]
[12:53:31] -!-
andypugh has quit [Read error: Connection reset by peer]
[12:54:16] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[13:14:47] -!-
jackc has quit [Ping timeout: 265 seconds]
[13:16:21] -!-
andypugh has quit [Ping timeout: 252 seconds]
[13:20:17] -!-
jackc has quit [Ping timeout: 246 seconds]
[13:25:13] -!-
jackc has quit [Ping timeout: 256 seconds]
[13:26:39] -!-
rob__H [rob__H!~rob_h@027c18f3.bb.sky.com] has joined #linuxcnc-devel
[13:28:29] -!-
toastydeath has quit [Read error: Connection timed out]
[13:29:25] -!-
rob_h has quit [Ping timeout: 248 seconds]
[13:29:37] -!-
jackc has quit [Ping timeout: 245 seconds]
[13:35:05] -!-
jackc has quit [Ping timeout: 265 seconds]
[14:21:11] -!-
jackc has quit [Ping timeout: 246 seconds]
[14:32:07] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[14:55:02] -!-
jackc has quit [Ping timeout: 260 seconds]
[14:59:38] -!-
jackc has quit [Ping timeout: 240 seconds]
[15:04:37] -!-
jackc has quit [Ping timeout: 245 seconds]
[15:10:12] -!-
jackc has quit [Ping timeout: 260 seconds]
[15:12:09] -!-
KimK has quit [Read error: Operation timed out]
[15:13:34] -!-
KimK [KimK!~Kim__@2001:470:1f0f:1042:4261:86ff:fe43:bcad] has joined #linuxcnc-devel
[15:16:29] -!-
jackc has quit [Ping timeout: 246 seconds]
[15:19:03] -!-
cncbasher [cncbasher!~quassel@cpc15-hart9-2-0-cust101.11-3.cable.virginmedia.com] has parted #linuxcnc-devel
[15:28:41] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[15:36:53] -!-
jackc has quit [Ping timeout: 248 seconds]
[15:47:59] -!-
skunkworks__ [skunkworks__!~chatzilla@str-bb-cable-south-3-102.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[15:51:30] <skunkworks__> logger[psha]:
[16:02:24] -!-
DJ9DJ has quit [Quit: bye]
[16:12:00] -!-
psha [psha!~psha@213.208.162.69] has joined #linuxcnc-devel
[16:29:21] -!-
andypugh [andypugh!~andy2@cpc2-basl1-0-0-cust639.basl.cable.virginmedia.com] has joined #linuxcnc-devel
[16:39:25] -!-
KimK has quit [Ping timeout: 248 seconds]
[16:49:54] -!-
mhaberler has quit [Quit: mhaberler]
[16:58:29] -!-
KimK [KimK!~Kim__@209.248.147.2.nw.nuvox.net] has joined #linuxcnc-devel
[16:58:53] -!-
ve7it [ve7it!~LawrenceG@S0106001c10b7770f.pk.shawcable.net] has joined #linuxcnc-devel
[17:16:04] -!-
IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 12.0/20120423130206]]
[17:42:27] -!-
toastydeath has quit [Read error: Connection timed out]
[18:07:47] -!-
micges [micges!~micges@dce129.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:08:57] -!-
syyl_ws has quit [Quit: Verlassend]
[18:13:59] -!-
mhaberler [mhaberler!~mhaberler@195.191.253.94] has joined #linuxcnc-devel
[18:34:29] -!-
WalterN has quit [Ping timeout: 248 seconds]
[19:09:10] -!-
Keknom has quit [Quit: Leaving.]
[19:19:27] -!-
mikegg has quit [Ping timeout: 272 seconds]
[19:30:25] -!-
Thetawaves has quit [Quit: This computer has gone to sleep]
[19:39:37] -!-
skunkworks has quit [Ping timeout: 245 seconds]
[19:47:47] -!-
X704 has quit [Read error: Connection reset by peer]
[19:54:37] -!-
toastydeath has quit [Read error: Connection timed out]
[20:07:37] -!-
maximilian_h [maximilian_h!~bonsai@130.255.104.157] has parted #linuxcnc-devel
[20:36:10] -!-
ve7it has quit [Remote host closed the connection]
[20:56:07] -!-
phantoxeD has quit [Ping timeout: 260 seconds]
[21:01:41] -!-
elmo40 has quit [Read error: Connection reset by peer]
[21:28:45] -!-
micges has quit [Quit: Leaving]
[21:46:21] -!-
theorbtwo has quit [Ping timeout: 244 seconds]
[21:46:25] theorb is now known as
theorbtwo
[21:48:25] -!-
JT-Shop has quit [Ping timeout: 244 seconds]
[21:48:50] -!-
jthornton has quit [Ping timeout: 252 seconds]
[22:02:44] -!-
psha has quit [Quit: Lost terminal]
[22:22:27] -!-
Diony [Diony!~Diony@fon31-2-78-240-230-109.fbx.proxad.net] has joined #linuxcnc-devel
[22:22:39] <Diony> Hi
[22:24:09] <Diony> I think I found a mistake in documentation :
http://linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a
[22:25:22] <Diony> #<_x> (and others) are offseted coordinate not "machine" one
[22:25:56] <Diony> Someone can check it?
[22:26:19] <Diony> Nobody awake?
[22:26:23] <Diony> ;)
[22:29:53] <andypugh> Yes, I think you are right
[22:30:54] -!-
JT-Shop [JT-Shop!~John@184.20.140.167] has joined #linuxcnc-devel
[22:31:14] <Diony> Ok thank you andy
[22:31:25] <andypugh> Diony: I will try to remember to mention it to somebody. I suppose I could try changing it myself, but he docs are a mystery to me.
[22:33:14] <Diony> Ok there is a way to easyly get the absolute current coordinates?
[22:33:20] <Diony> from parameters
[22:33:23] <Diony> ?
[22:34:08] <Diony> I found this solution : "[#[5203+20*#5220]+#5210*#5213+<_z>]"
[22:34:25] <Diony> but it's not easy ;)
[22:34:39] <Diony> (for z)
[22:35:03] <andypugh> I think you can use G30
[22:36:09] <Diony> http://linuxcnc.org/docs/devel/html/gcode/gcode.html#_g30_g30_1_go_to_predefined_position_a_id_sec_g30_g30_1_a
[22:36:19] <Diony> ? are you sure ?
[22:36:24] <andypugh> Yes, G30.1 stores the current position in 5181...
[22:36:51] <Diony> ok thanks a lot
[22:36:59] <andypugh> You can only use it (or G28) if you are not using them for toolchange or similar.
[22:37:06] -!-
jthornton [jthornton!~john@184.20.140.167] has joined #linuxcnc-devel
[22:37:52] <Diony> I am adapting remap code for manual tool change
[22:38:29] <Diony> I need to work in machine coordinates to calculate properly the tool length
[22:38:58] -!-
toastydeath has quit [Read error: Connection timed out]
[22:39:57] <Diony> The remap code for manual changing is going to work properly on my machine
[22:41:31] <andypugh> Auto probe, or something else?
[22:41:48] <Diony> yes autoprobe
[22:42:11] <Diony> but manual tool change
[22:42:44] <jthornton> so #<_x> gives you the current position of x including any offsets?
[22:43:01] <jthornton> andypugh, is that 2.5 or 2.6?
[22:43:12] <Diony> I work with 2.6
[22:43:29] <Diony> and it's including G5X and G92
[22:46:58] <jthornton> I wonder if that is some of mhaberler work?
[22:47:59] <Diony> Yes it is
[22:48:02] <jthornton> be better to get a comment from him on the intended usage of #<_x> before I change the docs
[22:48:11] <mhaberler> what's the issue?
[22:49:17] <mhaberler> manual says: #<_x> - Return absolute machine X coordinate. Same as #5420.
[22:49:22] <mhaberler> anything wrong with it?
[22:49:23] <jthornton> and by magic he appears, I've not looked but they say the docs say #<_x> is absolute position but it seems to include all offsets
[22:50:00] <mhaberler> uh, absolute might be wrong
[22:50:02] <jthornton> Diony, do you have a link to the doc page?
[22:50:13] <mhaberler> http://www.linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_aCurrent Position including all offsets and in the current program units for X, Y, Z, A, B, C, U, V & W. In absolute machine coordinates, volatile.
[22:50:25] <mhaberler> that's for #542x
[22:50:37] <Diony> http://linuxcnc.org/docs/devel/html/gcode/overview.html#_predefined_named_parameters_a_id_sec_predefined_named_parameters_a
[22:51:13] <mhaberler> hm, let me see what them codes say
[22:51:18] <jthornton> ok
[22:52:42] <mhaberler> the C code generating this stuff is here, just in case:
http://git.mah.priv.at/gitweb/emc2-dev.git/blob/43eda790e13bf3fa29832c984271ae490048931b:/src/emc/rs274ngc/interp_namedparams.cc
[22:53:39] <jthornton> yikes!
[22:54:17] <mhaberler> it does access the same internal fields as reported by #5420-#5429
[22:54:32] <jthornton> I'd assume the doc description of #<_x> and the rest are wrong if they just copy #5420-
[22:54:35] -!-
Guthur has quit [Ping timeout: 252 seconds]
[22:54:51] <jthornton> I can fix the docs if you like
[22:55:31] <mhaberler> in that case I guess the docs for #542- are wrong too.. I think my uhum, documentation was a c&p job
[22:56:07] <Diony> 5420-5428
[22:56:07] <Diony> Current Position including all offsets and in the current program units for X, Y, Z, A, B, C, U, V & W. In absolute machine coordinates, volatile.
[22:56:42] <Diony> It seems to be ok
[22:56:42] <mhaberler> right, I think cradek added those because I bitched about not being able to return to starting point after a probe
[22:57:06] <mhaberler> because there was no way to get at the absolute pos before
[22:57:38] <Diony> yes I know I am working on your remap manualchange code
[22:57:46] <Diony> (ngc part only)
[22:57:47] <mhaberler> I would be VERY surprised if #<_x> reported anything different than #5420 etc
[22:57:57] <mhaberler> oh, a user ;)
[22:58:23] <Diony> The one who promise you a bottle of wine
[22:58:30] <mhaberler> aja, Toulouse?
[22:58:35] <Diony> yep
[22:58:48] <Diony> sorry for the delay
[22:58:56] <mhaberler> now that you're saying it: my reds are finished, nil, zippo. Dry land here.
[22:58:56] <Diony> you will have it
[22:59:01] <mhaberler> ;)
[22:59:29] <mhaberler> ok, so do I get this right: you need abs pos in a param and cant get at it ?
[22:59:37] <Diony> there is a little bug in the remap code
[22:59:54] <mhaberler> I'm all ears
[23:00:13] <Diony> In your example config
[23:00:37] <mhaberler> remap/manual-toolchange-yadayada?
[23:00:49] <Diony> when a toll change are done (probe, get back to toolchange position)
[23:00:56] <Diony> yep
[23:01:30] <Diony> the ngc program should continue (G0 Z...)
[23:01:59] <Diony> but it does G0 Z... Xtouchprobe Ytouchprobe
[23:02:29] <Diony> I don't know why I do that
[23:03:48] <Diony> In the example the toolchange position have the same XY than the touch probe? 2s let me check
[23:03:58] <mhaberler> ok
[23:06:28] <Diony> Do you understand the problem?
[23:06:38] -!-
cevad has quit [Ping timeout: 256 seconds]
[23:07:05] -!-
factor has quit [Read error: Connection reset by peer]
[23:07:25] <mhaberler> no. assuming you are running my example unmodified - report steps you're doing and at which step it goes wrong
[23:07:36] <mhaberler> and which file/line you're suspecting
[23:07:52] <Diony> Ok
[23:08:08] * jthornton leaves you guys to sort this out and heads out to the shop
[23:08:13] <mhaberler> you mean because it backs up Z ?
[23:08:17] <Diony> open your example config
[23:08:24] <Diony> run the program
[23:08:42] <Diony> make the tool change, simulate the probe sw
[23:09:09] <Diony> at the end of the subroutine ther is
[23:09:24] <Diony> 5420-5428
[23:09:24] <Diony> Current Position including all offsets and in the current program units for X, Y, Z, A, B, C, U, V & W. In absolute machine coordinates, volatile.
[23:09:29] <andypugh> mhaberler: Gary Mc Roberts on the Forum is trying to use the remapped toolchange too. He is having problems because if you open an example from the selector you don't get any choice about copying the files to your home directory, but only some of the files come across, none of the Python or toolchange_ngc files. The rack change example works perfectly if invoked on-place in usr/share/docs though.
[23:09:39] <Diony> sorry
[23:09:41] <Diony> ; move back to toolchange position: z, then xy
[23:09:41] <Diony> g53 g0 Z #<_ini[change_position]z>
[23:09:41] <Diony> g53 g0 X #<_ini[change_position]x> Y #<_ini[change_position]y>
[23:10:23] <mhaberler> andypugh: will look into it
[23:10:42] <mhaberler> not fully resocialized yet
[23:10:43] <Diony> There is relative path in the .ini
[23:11:12] <mhaberler> ?
[23:12:28] <Diony> after the g53 line the program should continue
[23:12:37] <mhaberler> are you referring to [CHANGE_POSITION] ?
[23:12:43] <Diony> yes
[23:13:03] <andypugh> One bug (nothing to do with this) is that when you open an example you get the choice of making a copy, or simply not opening it. "Cance" cancels opening the example, rather than cancelling the copy.
[23:13:10] <Diony> the mouve just after g53 g0 Z #<_ini[change_position]z>
[23:13:10] <Diony> <Diony> g53 g0 X #<_ini[change_position]x> Y #<_ini[change_position]y>
[23:13:26] <Diony> is wrong
[23:13:49] <mhaberler> ok, then take it out
[23:13:57] <cradek> andypugh: that's on purpose, because if you run an unwritable config it won't work right (specifically because the var file can't be written).
[23:14:02] <Diony> should be only Z (see line 43 in tcdemo.ngc)
[23:14:21] <cradek> andypugh: it used to let you run it from there, and then it would act all broken (for example touch off did nothing)
[23:14:53] <andypugh> cradek: Ah, OK. Perhaps the dialog should stop pretending that you get a choice then? (Or perhaps I need to actually read it..)
[23:15:02] <Diony> mhaberler: no the proble don't come from nc_subroutine nor tcdemo
[23:15:37] <cradek> andypugh: yeah if the words are wrong, feel free to improve them - but I'm pretty sure the behavior is right
[23:16:13] <Diony> mhaberler: sorry for my very bad english. I'll try a other time
[23:16:39] <mhaberler> I dont understand the problem quite yet. If you think there's a superfluous move - adapt to your liking, thats the whole point of the remapping exercise. Is there something which isnt executed, or executed incorrectly?
[23:16:56] <Diony> mhaberler: I run the tcdemo.ngc from your example config Manualtoolchange (remap)
[23:17:02] <mhaberler> ok
[23:17:02] <cradek> (does g53 g0 X #<_ini[change_position]x> work if you're in your non-native g20/g21?)
[23:17:47] <Diony> run the program, begin the first tool change, => OK
[23:17:52] <mhaberler> I think I used M7x to push unit settings and explcitily set them, but let me see
[23:18:05] <Diony> click on "change complete =>OK
[23:18:32] <Diony> the tool go to the probe sw position => OK
[23:18:38] <mhaberler> yes I did, it's interpreted as G21 and restored to whatever it was on return
[23:18:46] <cradek> aha
[23:18:51] <Diony> click "simulate probe contact" => OK
[23:19:09] <mhaberler> ok, then it retracts Z
[23:19:22] <Diony> It retract Z =>OK
[23:19:42] <Diony> it go to YX toolchangeposition => OK
[23:19:55] <Diony> then it go back to the main program
[23:20:00] <mhaberler> then the program continues (for me)
[23:20:29] <Diony> line 43
[23:20:34] <Diony> for me too
[23:20:37] <Diony> but
[23:20:49] <Diony> line 43 is just a Z move
[23:21:08] <mhaberler> so that should execute as G0 Z1.0 I guess (from reading the code)
[23:21:31] <Diony> and the machine do the Z move + Xswitchposition Yswitchposition
[23:22:55] <mhaberler> hm, so line 43 returns Z down to just about workpiece. then g0 x/y to start of cut still above wp
[23:22:57] <Diony> In the example the toolchangeposition and the switchposition is near (10mm away in XY plane) and the problem is difficult to see
[23:23:22] <mhaberler> are you saying there's an erroneous move ?
[23:23:31] <Diony> yes
[23:23:41] <Diony> on line 43
[23:23:58] <mhaberler> can you change parameters such that even me can see it?
[23:24:14] <Diony> you can see it on you example
[23:24:44] <Diony> the tool shouldn't go back to the probe switch
[23:25:04] <andypugh> The example is just an example. I think the expectation is that you would change that G-code to suit your machine. That was the main point of moving toolchange into G-code and out of C-code.
[23:25:06] <mhaberler> oh, I see it. yes, the descent down to Z1.0
[23:25:07] <Diony> but just move down
[23:25:35] <mhaberler> hm, let me see
[23:25:42] <Diony> andypugh: no problem with the example :)
[23:27:05] <Diony> On my machine the switch position is at the opposite of the tool change position so the problem is much more easy to find
[23:27:16] <Diony> easier
[23:27:48] <Diony> mhaberler: do you reproduce the problem?
[23:28:16] <mhaberler> not quite. I'm inserting G4's and debugs so I see what causes which move
[23:28:20] <mhaberler> hold on
[23:28:31] <Diony> ok np
[23:32:19] <mhaberler> ok, there seems to be an issue - line 43 should move only Z but also moves XY
[23:32:39] <Diony> yes to the probe sw
[23:32:44] <mhaberler> right
[23:32:46] <Diony> (XY)
[23:33:58] <mhaberler> ok, I have it reproduced.. I understand the problem. Probably I missed some position save/restore. I'll look into it.
[23:34:06] <Diony> ok
[23:34:41] <Diony> for information, I change your subroutine script
[23:35:29] <Diony> why you don't use the tool table to store results (and know more or less what is the too length)?
[23:36:19] <mhaberler> is the z offset not saved? maybe that needs to be done explicitly
[23:36:31] <mhaberler> (this is a demo;)
[23:36:48] <Diony> ok
[23:36:54] <Diony> nice demo ;)
[23:39:57] <Diony> I have to go
[23:40:12] <Diony> mhaberler: Thanks again
[23:40:22] <mhaberler> too early..
[23:42:11] <Diony> mhaberler: so thank you to work on it
[23:43:09] <Diony> mhaberler: don't hesitate to ask me questions, I will take a video as soon as my machine will properly work with the remap manualtoolchange code (your code)
[23:43:35] <Diony> mhaberler: you have my email
[23:43:36] <mhaberler> great, agitprop is always helpful
[23:45:10] -!-
Diony has quit [Quit: Quitte]
[23:45:48] <mhaberler> ok, the problem seems to be that the remapped T1M6 changes x/y - if you print #<_x> and #<_y> before and after it becomes apparent
[23:45:54] <mhaberler> uh, gone
[23:47:19] <andypugh> Seems odd.
[23:54:08] <mhaberler> well in fact it's pretty easy to trample on state, it's all global; maybe the M7x goes overboard on return. But it's nicely isolated.
[23:54:29] -!-
Guthur has quit [Ping timeout: 248 seconds]
[23:54:55] -!-
Farthen has quit [Quit: ZNC -
http://znc.in]
[23:55:20] <andypugh> Well, I tried to edit pickconfig.tcl, but the file can not be saved. How odd.