Back
[06:14:05] <jthornton> it does appear to be a problem with us and not hotmail. some googling on hotmail blocking emails gives this
http://paste.ubuntu.com/15537643/
[07:24:32] <jepler> Mar 28 07:17:18 forum postfix/smtp[7919]: 80B764007E: to=<nvxwax@outlook.com>, relay=mx4.hotmail.com[134.170.2.199]:25, delay=0.19, delays=0.02/0.01/0.15/0.01, dsn=5.0.0, status=bounced (host mx4.hotmail.com[134.170.2.199] said: 550 SC-001 (BLU004-MC1F34) Unfortunately, messages from 162.243.45.186 weren't sent. Please contact your Internet service provider since part of their network is on our bloc
[07:24:38] <jepler> k list. You can also refer your provider to
http://mail.live.com/mail/troubleshooting.aspx#errors. (in reply to MAIL FROM command))
[07:24:47] <jepler> hotmail rejects mails from forum.linuxcnc.org's IP address
[07:25:48] <jepler> they have no useful "appeals" process of these kinds of blocks
[07:26:11] <jepler> to the best of my knowledge
[07:26:39] <jthornton> darn
[07:46:04] <jthornton> looks like it could also be a malformed header causing the SPF to fail
http://tools.ietf.org/html/rfc4408
[07:51:51] <jepler> Authentication-Results: mx.google.com;
[07:51:52] <jepler> spf=pass (google.com: best guess record for domain of noreply@forum.linuxcnc.org designates 162.243.45.186 as permitted sender) smtp.mailfrom=noreply@forum.linuxcnc.org
[07:52:43] <jepler> we actually don't publish any spf records. we would need the cooperation of swp to initially publish or modify the spf records of linuxcnc.org, as those are administered on dreamhost.com and he is the one with the credentials to do it.
[07:55:58] <jthornton> well darn
[08:40:45] <jepler> I added a big fat note on the signup page, but then failed to add a note to the password recovery page
[08:42:11] <jepler> I hate the forum. I hate joomla. I hate communitybuilder. argh what an albatross.
[08:42:24] <jthornton> I saw the note just now
[08:42:33] <jthornton> agreed
[08:45:26] <cradek> don't you also hate hotmail?
[08:47:13] <cradek> their "troubleshooting" says "for policy reasons" - is there some other sign spf is involved?
[09:28:49] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal a1f500e 06linuxcnc 10(117 files in 8 dirs) FastSeal as stand alone, separated from gmoccapy * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a1f500e
[09:33:57] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal b8b6ba6 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py redone gmoccapy files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b8b6ba6
[09:41:28] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 24fdf53 06linuxcnc Merge branch 'touchscreen_slider' into EU_Surplus_FastSeal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=24fdf53
[10:27:52] <linuxcnc-build> build #1784 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1784 blamelist: Norbert Schechner <nieson@web.de>
[10:34:16] <linuxcnc-build> build #1786 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1786 blamelist: Norbert Schechner <nieson@web.de>
[10:40:47] <linuxcnc-build> build #3216 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3216 blamelist: Norbert Schechner <nieson@web.de>
[10:52:36] <linuxcnc-build> build #1131 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1131 blamelist: Norbert Schechner <nieson@web.de>
[10:53:53] <linuxcnc-build> build #3216 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3216 blamelist: Norbert Schechner <nieson@web.de>
[10:55:34] <linuxcnc-build> build #2044 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2044 blamelist: Norbert Schechner <nieson@web.de>
[11:00:30] <linuxcnc-build> build #206 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/206 blamelist: Norbert Schechner <nieson@web.de>
[11:03:51] <jepler> (that branch adds a lot of files to 'make install' that weren't added to the file lists in debian/)
[11:11:26] <jepler> cradek: it couldn't hurt if we published a correct spf record for (forum.)linuxcnc.org.
[11:11:55] <jepler> but the SMTP failure code says something about us being on a block list, which makes me think it is not about SPF, but about some kind of IP-based blacklist that is their own secret sauce
[11:11:57] <cradek> certainly
[11:12:15] <cradek> yep, bet so
[11:12:52] <cradek> they assume that only spammers use major hosting providers to send email; real people use 1 of about 3 "free" webmail services
[11:12:58] <jepler> and from a certain point of view, I bet not accepting e-mail from known by-the-hour cloud hosting services is a huge boon to users in terms of rejeced real spam
[11:13:34] <cradek> yes except for the collateral damage I'm sure it's great
[11:13:43] <archivist> usually the internet tells you how to get off those block lists
[11:13:45] <linuxcnc-build> build #1095 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1095 blamelist: Norbert Schechner <nieson@web.de>
[11:14:08] <jepler> yes, a "just" system would have an effective appeals process to being listed
[11:14:30] <cradek> archivist: the well-known dnsbls usually have a process that's fine, but hotmail aka live aka whateveritis doesn't apparently use them
[11:14:53] <archivist> they probably read those lists
[11:15:16] <cradek> I doubt flo's ip is on them
[11:15:31] <jepler> if you find that we're on a particular list, let me know
[11:15:58] <archivist> the list companies let you check your ip
[11:16:12] <cradek> dnsbl.info shows all green
[11:16:53] <cradek> so we're not on 61/61 of the dnsbls they check
[11:17:50] <cradek> but it was generous of you to assume they're doing something sane :-/
[11:18:25] <archivist> I had something similar with a server I admin sending into aol
[11:19:46] <linuxcnc-build> build #400 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/400 blamelist: Norbert Schechner <nieson@web.de>
[11:26:54] <linuxcnc-build> build #399 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/399 blamelist: Norbert Schechner <nieson@web.de>
[11:28:59] <linuxcnc-build> build #1476 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1476 blamelist: Norbert Schechner <nieson@web.de>
[11:29:59] <jepler> well, let'
[11:30:23] <jepler> well, let's try this: I've modified the forum to send e-mails out via g-mail
[11:31:05] <cradek> I didn't know that's a thing you could do
[11:31:27] <cradek> I bet that'll totally fix it
[11:31:54] <cradek> I mean it'll fix the immediate problem, not the real problem
[11:32:13] <jepler> I created a gmail account just for that purpose (linuxcncwebforum@gmail.com) and then set up joomla to use SMTP and those credentials for all its outgoing mail
[11:32:23] <cradek> awesome
[11:32:24] <jepler> the real problem is that e-mail is dead
[11:32:30] <seb_kuzminsky> thanks for dealing with this jepler
[11:32:50] <jepler> we'll see how it goes. *I* get my password reset e-mails, but then I always did before too
[11:33:00] <linuxcnc-build> build #460 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/460 blamelist: Norbert Schechner <nieson@web.de>
[11:33:17] <linuxcnc-build> build #461 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/461 blamelist: Norbert Schechner <nieson@web.de>
[11:34:03] <jepler> seb_kuzminsky: you're welcome
[11:34:11] <jepler> thanks for footing part of the bill on our hosting service
[11:34:20] <cradek> you're both amazing
[12:12:22] <JT-Shop> awesome
[12:35:09] <linuxcnc-build> build #3217 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3217 blamelist: Norbert Schechner <nieson@web.de>
[12:37:47] <linuxcnc-build> build #3217 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3217 blamelist: Norbert Schechner <nieson@web.de>
[12:43:47] <linuxcnc-build> build #2045 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2045 blamelist: Norbert Schechner <nieson@web.de>
[12:45:21] <linuxcnc-build> build #1132 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1132 blamelist: Norbert Schechner <nieson@web.de>
[12:47:59] <linuxcnc-build> build #1787 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1787 blamelist: Norbert Schechner <nieson@web.de>
[12:58:56] <linuxcnc-build> build #207 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/207 blamelist: Norbert Schechner <nieson@web.de>
[13:02:39] <linuxcnc-build> build #1785 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1785 blamelist: Norbert Schechner <nieson@web.de>
[13:17:17] <linuxcnc-build> build #1096 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1096 blamelist: Norbert Schechner <nieson@web.de>
[13:17:36] <linuxcnc-build> build #1477 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1477 blamelist: Norbert Schechner <nieson@web.de>
[13:18:22] <KGB-linuxcnc> 03Norbert Schechner 05EU_Surplus_FastSeal 7293042 06linuxcnc 10(15 files in 6 dirs) FastSeal_0_3 - code clearance and making it work. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7293042
[13:20:35] <linuxcnc-build> build #462 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/462 blamelist: Norbert Schechner <nieson@web.de>
[13:28:47] <linuxcnc-build> build #461 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/461 blamelist: Norbert Schechner <nieson@web.de>
[13:32:21] <linuxcnc-build> build #401 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/401 blamelist: Norbert Schechner <nieson@web.de>
[13:32:44] <linuxcnc-build> build #400 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/400 blamelist: Norbert Schechner <nieson@web.de>
[13:51:16] <jepler> wow I saw this in passing in a thread on -users, but the PCI standard permits a contact finish that has a durability of only 2 mating cycles, whith a durability half-life of one year when not mated, and the same for the connector
[13:51:23] <jepler> whith=with
[13:51:32] <cradek> that's horrifying
[13:52:16] <cradek> how can anything even work?
[13:52:27] <archivist> I have a video card that needs a jiggle every few weeks to keep one PC working
[13:52:53] <jepler> source:
https://pcisig.com/sites/default/files/specification_documents/ECN_PCI_Connector_Finish.pdf
[13:53:08] <jepler> cradek: after 366 days new in box on a shelf, by the PCI standard it doesn't even have to
[13:55:05] <jepler> I haven't found similar information for PCI Express, but the first actual connector (receptacle) I found, molex brand, specifies durability of 50 cycles
[14:07:08] <jepler> PCI Express[TM] Card Electromechanical Specification Revision 1.1 [2005] doesn't give a requirement for number of mating cycles
[14:18:36] <PCW> we use 30 iinch gold plating on PCI/PCIE so the card is good for a few 100 cycles (motherboard socket is the limitation)
[14:19:01] <jepler> I'm happy to hear it
[14:19:42] <PCW> adds maybe $0.50 to the card so no big deal
[14:21:11] <jepler> PCW: hm2 ethernet receive timeouts -- should the default be a constant value, or should it be a fraction of thread period? I tested at 500Hz using period/10 and at least the system stayed stable with my changes..
[14:21:43] <jepler> .. but 200us is inappropriate if you are trying to run at 4kHz
[14:23:33] <PCW> yeah in terms of not skipping cycles if the dats is going to get there but is just slow, then something like 75% of the se4rvo period might make sense
[14:23:43] <PCW> data
[14:26:02] <jepler> anyway next evening I have free, I'll jumper a stepgen in quadrature mode to an encoder and set it up like a PID servo to see how it behaves wrt ferrror and pid. There's no "did the last read fail" output yet, so that's necessary before it's possible to add "PID hold"
[14:29:15] <jepler> cradek suggested the possibility that hm2 could instead lie about (estimate) feedback positions when a read is missed, instead of adding "PID hold", but I worry that would be more complicated overall (have to do it once for stepgen, once for encoder, once for resolver, once for absolute encoder...)
[14:29:26] <linuxcnc-build> build #3218 of 4008.deb-precise-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4008.deb-precise-amd64/builds/3218 blamelist: Norbert Schechner <nieson@web.de>
[14:31:09] <jepler> .. if you give up waiting too soon, there's another problem: next time you try to read a packet, you'll get the old one
[14:31:27] <jepler> I wonder if there's a syscall to discard any waiting packets, could do that just before send() of the read request
[14:33:42] <linuxcnc-build> build #3218 of 4007.deb-precise-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4007.deb-precise-i386/builds/3218 blamelist: Norbert Schechner <nieson@web.de>
[14:34:38] <PCW> Right if theres a packet waiting at the start it should be discarded
[14:36:18] <jepler> > what to do about reads and writes with side effects (not idempotent), such as UART FIFOs, index/latch enable writes, etc
[14:36:26] <jepler> this is on my list as an unanswered question. do you have any thoughts?
[14:38:51] <linuxcnc-build> build #1097 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1097 blamelist: Norbert Schechner <nieson@web.de>
[14:40:19] <PCW> I guess he best is retry next cycle on failure but this quickly gets complicated
[14:40:57] <jepler> .. if you requested to read from UART, and the response packet goes missing, I think those bytes are just gone
[14:41:27] <PCW> writes need to be serialized to detect failure
[14:41:29] <jepler> .. if you set index-enable and next cycle it reads back false, you don't know if it was because index was already hit, or because the write got lost
[14:42:02] <linuxcnc-build> build #2046 of 4009.deb-precise-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4009.deb-precise-rtai-i386/builds/2046 blamelist: Norbert Schechner <nieson@web.de>
[14:42:03] <jepler> yes, if you read back the last successful write, then if the read succeeds you know whether the write did
[14:43:50] <linuxcnc-build> build #1133 of 4015.deb-wheezy-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4015.deb-wheezy-rtpreempt-amd64/builds/1133 blamelist: Norbert Schechner <nieson@web.de>
[14:47:10] <PCW> The loss of read data can be tackled a couple ways (requiring a commit in the write packet to update the FIFO pointers on read data is one)
[14:48:01] <PCW> maybe general commit for all read-side effects
[14:48:57] <PCW> not terribly worried about this yet as UARTs are not so widely used
[14:50:32] <PCW> or instead of commit a "restore pointers before last access cycle"
[14:55:10] <linuxcnc-build> build #1478 of 4018.deb-wheezy-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4018.deb-wheezy-rtai-i386/builds/1478 blamelist: Norbert Schechner <nieson@web.de>
[14:56:05] <jepler> PCW: yeah I think encoder index / latch is really the one that is most likely to hurt people
[15:06:09] <linuxcnc-build> build #208 of 4017.5.deb-wheezy-armhf is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.5.deb-wheezy-armhf/builds/208 blamelist: Norbert Schechner <nieson@web.de>
[15:09:40] <linuxcnc-build> build #1788 of 4017.deb-wheezy-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1788 blamelist: Norbert Schechner <nieson@web.de>
[15:11:01] <PCW> index is a bit of a special case, It may be possible to differentiate index events from write failures by using the just -once bit and latch-on-index bits
[15:11:03] <PCW> but a general write failure check is probably more valuable
[15:12:47] <linuxcnc-build> build #1786 of 4016.deb-wheezy-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4016.deb-wheezy-i386/builds/1786 blamelist: Norbert Schechner <nieson@web.de>
[15:21:06] <linuxcnc-build> build #462 of 4022.deb-jessie-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4022.deb-jessie-amd64/builds/462 blamelist: Norbert Schechner <nieson@web.de>
[15:23:15] <linuxcnc-build> build #401 of 4020.deb-jessie-rtpreempt-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4020.deb-jessie-rtpreempt-amd64/builds/401 blamelist: Norbert Schechner <nieson@web.de>
[15:23:26] <linuxcnc-build> build #402 of 4019.deb-jessie-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4019.deb-jessie-rtpreempt-i386/builds/402 blamelist: Norbert Schechner <nieson@web.de>
[15:24:11] <linuxcnc-build> build #463 of 4021.deb-jessie-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4021.deb-jessie-i386/builds/463 blamelist: Norbert Schechner <nieson@web.de>
[15:45:42] <cmorley> I now get emails from the forum - I use hotmail...in case you were wondering if it worked...
[15:55:26] <jepler> cmorley: thanks for the update
[15:55:30] <jepler> that is good to know
[15:55:38] <JT-Shop> yea you might be the first test
[15:55:47] <cmorley> yaay!
[20:58:11] <trentster1> Howdy, has anyone seen a auto Z probe routine ignore the limits for a Z axis as set in the .ini file?
[20:59:38] <trentster1> I have limits set for Z of Min and Max travel of +160 and -160 yet intermittently when I try and run a probe routine I get an immediate error " line 5 of probe routine would exceed the negative limit for that axis.
[21:00:54] <cradek> nope, there's no way to do that other than fix your g38.x destination to be within the machine limits
[21:01:11] <trentster1> This occurs when the routine only tells it to probe down 10mm and the current Z position both relative and absolute are e.g. 10 and 0 respectively.
[21:01:43] <trentster1> cradek: thats the point, my G38.x is within my machine limits
[21:02:27] <cradek> then I don't understand
[21:02:38] <cradek> you asked if you could make it ignore the limits - the answer is no
[21:02:54] <trentster1> 1 sec let me grab the code so I can show some tangible examples
[21:02:57] <cradek> ok
[21:03:17] <trentster1> my question is why does it ignore the limits , not how can I make it ignore the limits
[21:03:22] <cradek> (the destination has to be inside the machine limits, even if you expect it to hit something and stop before then)
[21:03:43] <cradek> oh I see! but it doesn't ignore the limits...
[21:04:21] <cradek> if you think it's doing something wrong, can you reproduce it in sim/axis and tell me how to do it here?
[21:04:56] <trentster1> cradek I can make the limits +200 and -200 and still the probe will fail with a move of 10mm when its currently sitting at relative z=17 and absolute z=0
[21:05:20] <trentster1> whereby it should only error out if it exceeds -200 or +200 correct?
[21:05:22] <cradek> that would be extremely surprising!
[21:05:45] <cradek> can you show me how to do it in sim/axis?
[21:06:55] <trentster1> I am just grabbing a past screenshot
https://monosnap.com/file/i8hxOG5A2SNL9VokEpTLr3Q2jWPw1D.png
[21:08:55] <cradek> you have both a g92 offset and g54 offset
[21:09:04] <cradek> you probably just aren't where you think you are
[21:11:02] <trentster1> cradek:
https://gist.github.com/trentster/b708157f1e3d304d1a93 Z azis is [AXIS_2]
[21:12:02] <trentster1> https://gist.github.com/trentster/0ccaa9e1ab82e15ac9c7 that is the Z probe routine
[21:13:29] <cradek> consider using G91 mode! you're nuking your work offsets
[21:13:29] <trentster1> so based on those gists surely the probe should work as long as I am within the limits of both Z positions as displayed in that screenshot?
[21:13:37] <trentster1> or am I missing something.?
[21:14:08] <trentster1> The weird thing is it sometimes works fine and sometimes gives the warning it will exceed negative limits
[21:14:32] <trentster1> Sorry I am a bit of a newb when it comes to gcode deep diving
[21:15:03] <trentster1> cradek: would you mind gisting an e.g. of a probe routine you think would be more suitable that would negate the issue?
[21:15:24] <cradek> I also notice if you're running a G20 program Z-10 would be outside of the -200mm limit
[21:16:10] <trentster1> I was following the article on
http://7xcnc.com/software/probing/z-touch-plate/
[21:17:55] <cradek> also check out
http://linuxcnc.org/docs/html/user/user-concepts.html#_when_you_8217_re_lost
[21:18:48] <trentster1> thanks - will bookmark that now
[21:18:49] <cradek> after probing you should use #5063 to get the result
[21:19:31] <trentster1> 5063?
[21:19:58] <cradek> see here:
http://linuxcnc.org/docs/html/gcode/g-code.html#gcode:g38
[21:20:59] <trentster1> cradek: thanks a ton, I really appreciate your help, this has been driving me nuts for ages ;-)
[21:21:37] <cradek> welcome! hope you get it going.
[21:21:58] <cradek> be sure to watch your offsets (see that "when you're lost") and your units
[21:22:25] <trentster1> I have to! - right now I would just be happy getting a probe routine to fire consistently
[21:28:25] <trentster1> cradek: What would you recommend as a good tutorial or resource to learning / understanding coordinate systems and gcode?
[22:28:57] <seb_kuzminsky> trentster1: have you read this?
http://linuxcnc.org/docs/2.7/html/gcode/coordinates.html
[22:45:40] <trentster1> seb_kuzminsky: I havent - and thanks for the link - reading now
[22:55:02] <kwallace> cradek: I noticed your and jepler's link here:
http://www.schlitt.net/index.html . I have been working on Elgin pocket watches and noticed that great minds seem to run in the same circles.
[23:19:02] <seb_kuzminsky> trentster1: hope it helps :-)
[23:20:10] <trentster1> seb_kuzminsky: its slowly sinking in, will have to play with actual machine and probably have to break some endmills to cement it in properly :P
[23:39:39] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 2b68b5c 06linuxcnc 10tcl/twopass.tcl twopass: handle loadrt's using multiple parms (JA) * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2b68b5c
