Back
[13:01:34] <maxcnc> Good evening from germany
[13:01:47] <maxcnc> someone on ?
[13:02:08] <maxcnc> i tryed to upload to the mailinglist but it did not go thrue
[13:02:16] <cradek> 46 people are here
[13:02:22] <cradek> the mailing list has a small file size limit
[13:02:35] <cradek> often it's better to host a file on the web somewhere, and send just a URL to the mailing list
[13:02:38] <maxcnc> i think i need to subscripe but then i will get mails in hundreds
[13:02:50] <cradek> yes you must subscribe to the list to post
[13:03:21] <maxcnc> what if i paste the patch and someone looks into it
[13:03:34] <maxcnc> as you said you woudt welcome a patch
[13:04:10] <cradek> patches are always welcome! the devel mailing list is a good place to share a patch, and also a github pull request is a good way
[13:04:54] <maxcnc> do i need to subscripe to the mailinglist for a git pull 2
[13:05:07] <cradek> you need to be a github member to use that method
[13:05:42] <maxcnc> lots of hints to get a simple var into the system
[13:05:46] <cradek> sometimes, a patch needs some revision for acceptance, and people on the mailing list can help with that process. it is best if you subscribe and participate, in order to allow that process to work
[13:06:32] <cradek> yeah, I'm sorry getting started in participating can be a lot of work, I understand it seems like a lot of obstacles.
[13:07:04] <cradek> is there somewhere I can see your patch now?
[13:07:18] <maxcnc> 10sec
[13:08:09] <maxcnc> http://pastebin.com/ZqGGKVKH
[13:09:41] <maxcnc> this is for #5440... and for the <_ax> ...
[13:11:27] <cradek> interesting! which gcode offset is origin_offset_* ?
[13:12:24] <maxcnc> the G53 point is shown axis.x.motor-pos-cmd
[13:13:29] <maxcnc> Why woudt someone need this the toolprobe onplasma with THC can trouble on G91 to hit the mashine min
[13:14:28] <maxcnc> so i disidet to calculate the G38 move by getting the G53 point where i am and subtract from the mashin min so i can go that far on G91 Z- where ever i hit probe
[13:14:31] <cradek> so this will show the current G54/G55/G56... offset, not including G92/G52
[13:15:01] <maxcnc> yes
[13:16:08] <cradek> I see, so you want the unoffset (like G53) coordinate? I have seen a lot of similar requests
[13:16:29] <maxcnc> for xyz this is the only position you may need the otheres ABCUVW are upset to the G53 system as they are mounted on one
[13:17:09] <maxcnc> NO i want to work with this motor position coordinates in gcode
[13:17:37] <cradek> it seems like to get the G53 (unoffset) coordinate you need to have current + tool offset + origin offset + axis offset
[13:17:39] <maxcnc> like lots of Zero path Milling people do
[13:18:02] <jepler> I am not familiar with the term "zero path milling".
[13:18:40] <maxcnc> G53 point Eq Part zero Eq Tool zero
[13:18:50] <maxcnc> thats zero path milling
[13:19:17] <maxcnc> lots of Hobbyist do this
[13:19:36] <cradek> that just sounds like you do not use offsets and do not home the machine repeatably?
[13:19:52] <jepler> fwiw, G53 and "motor-pos-cmd" are different. Motor positions are not necessarily cartesian positions at all (for instance, consider a tripod machine of the type popular with 3d printing enthusiasts)
[13:20:00] <maxcnc> they work hours on CAD to get parts to zero path insted G-code Eq the Drawing and work with G41G42
[13:20:08] <jepler> .. but it also includes the effects of screw compensation and backash compensation even on a trivial kinematics machine
[13:20:53] <cradek> I think you mean the _unoffset_ coordinate system (like what you get with G53). is my understanding right?
[13:20:53] <maxcnc> ok diddent consider that
[13:21:06] <maxcnc> yes crad
[13:21:34] <jepler> So another way to put it is, if you execute G0 G53 X1234, then immediately after that motion you want #<_ax> to be 1234
[13:22:02] <cradek> yes that is my understand so far too - is that correct maxcnc?
[13:22:11] <maxcnc> yes
[13:22:21] <cradek> ok, I can help with that
[13:22:23] <jepler> and if that same X axis position was reached by G0 X456 due to coordinate system offsets and rotation, #<_ax> would still be 1234
[13:22:42] <maxcnc> yes
[13:23:12] <maxcnc> <_ax> eqals also #5440
[13:23:27] <cradek> your patch only handles G5x offsets right now - to make it work how jepler says, it needs to also handle tool offset (g43) and axis offset (g52/92) and rotation
[13:24:09] <maxcnc> its my first one so forgive me to not understand the full system
[13:24:21] <jepler> that's OK, it's a very complicated system.
[13:24:22] <cradek> no that's fine! I want to help.
[13:25:04] <maxcnc> i faild n that /settings->current_ax = GET_EXTERNAL_ORIGIN_X();
[13:27:50] <maxcnc> i think for better understanding GOAL it to calculate against the Homing point
[13:28:11] <cradek> maxcnc: look in interp_find.cc at Interp::find_current_in_system
[13:28:39] <maxcnc> ok
[13:28:41] <cradek> this is almost what you need to put in _ax, _ay...
[13:29:14] <cradek> I think you will NOT want the block that is like *x -= USER_TO_PROGRAM_LEN(p[5201 + system * 20]); because you don't want to add in any other system's offsets
[13:29:43] <cradek> but this shows the order of correctly applying axis offset, rotate, origin offset
[13:31:53] <cradek> also, please do all 9 axes xyzabcuvw, not only xyz, otherwise it will be confusing
[13:33:04] <maxcnc> ok
[13:34:24] <maxcnc> Question on debug can i get some vars out to test lots of gcode to understand what var holds on this point what number
[13:35:05] <cradek> some of the tests use a magic gcode comment like (debug, ax is #<_ax>) and that will cause the value to print
[13:35:29] <maxcnc> ok
[13:35:42] <maxcnc> but i mean in the c files
[13:35:58] <cradek> for example look at tests/interp/g10/g10-l1/test.ngc
[13:36:02] <maxcnc> i will get to it
[13:36:45] <cradek> in the interpreter you could just use gdb, or add printf to the code
[13:39:37] <jepler> maxcnc: are you aware of the program "rs274"? It is much easier to debug than all of linuxcnc
[13:40:14] <jepler> When you start it as "rs274 -g", you can just type gcode into it, and it prints lines that describe what happens
[13:40:22] <jepler> this is what the tests use, as well
[13:40:29] <maxcnc> cradek: what to call then in the files _x_absolut or absolut_x
[13:40:47] <jepler> (the word is "absolute" with an "e" in english)
[13:40:58] <jepler> (without the "e", it is a brand of vodka:-P)
[13:41:17] <cradek> I don't like using absolute; I prefer "unoffset" if talking about the coordinates that have no offsets applied
[13:41:20] <maxcnc> "*x = s->absolit_x;"
[13:41:36] <maxcnc> ok
[13:41:47] <cradek> absolute/relative are how we describe g90/g91 modes, so I think it is a mistake to use them when talking about offsets
[13:41:55] <maxcnc> "*x = s->unoffset_x;"
[13:42:45] <maxcnc> eq <_ux> eq #5440
[13:42:56] <maxcnc> thats what im going fo
[13:43:44] <cradek> can I recommend #<_unoffset_x>? it might be confusing to use U because U is also a coordinate
[13:43:50] <maxcnc> <ux> to <uw> and #5440 to #5448
[13:44:15] <maxcnc> ok
[13:44:26] <cradek> thanks for considering all my suggestions
[13:44:35] <cradek> I am happy to review again when you are ready
[13:45:32] <maxcnc> so how do i reset the git id changed to start over
[13:47:32] <maxcnc> IchGucksLive got about 10-15 linuxcnc gits on the pc
[13:47:45] <maxcnc> i added one mpore git pull
[13:48:14] <maxcnc> Gn8 im off
[13:49:19] <skunkworks_> skunkworks@skunkworks-Studio-XPS-1645:~$ cd linuxcnc
[13:49:20] <skunkworks_> linuxcnc/ linuxcnc-garrett/ linuxcnc-rob27final/
[13:49:22] <skunkworks_> linuxcnc-2.6/ linuxcnc-improv27/ linuxcnc-robimprov/
[13:49:23] <skunkworks_> linuxcnc-2.7/ linuxcnc-ja4-cba4/ linuxcnc-rr/
[13:49:25] <skunkworks_> linuxcnc-2.8/ linuxcncja4configs/ linuxcnc-rrrebase/
[13:49:26] <skunkworks_> linuxcnc-424/ linuxcnc-jerk/ linuxcnc-scurve/
[13:49:28] <skunkworks_> linuxcnc-andy/ linuxcnc-kink/ linuxcnc-scurve1/
[13:49:29] <skunkworks_> linuxcnc-cab4/ linuxcnc-last/ linuxcnc-spiral/
[13:49:31] <skunkworks_> linuxcnc-cab5/ linuxcnc-rapidov/ linuxcnc-tp/
[13:49:33] <skunkworks_> linuxcnc-dev/ linuxcnc-rc3/ linuxcnc-uvw/
[13:49:34] <skunkworks_> linuxcnc-exp2/ linuxcnc-rigid/
[13:49:36] <skunkworks_> linuxcnc-features/ linuxcnc-rob/
[13:49:37] <skunkworks_> and I am just a user....
[13:50:26] <skunkworks> granted some could be deleted...
[13:50:35] <jepler> maxcnc: there is a version of the git book in german. I believe it is of good quality, it might be of help to you.
https://git-scm.com/book/de/v1
[16:57:25] <andypugh> I just had some really odd behacviour with G18 and G33.1
[16:57:50] <andypugh> Hitting the hard-stop style ofd behaviour.
[16:58:17] <andypugh> But, I tried it in a sim (2.7.3) and it all seemed fine.
[16:58:18] <andypugh> http://www.pastebin.ca/3341003
[16:58:46] <cradek> g33.1 shouldn't care about the plane
[16:58:51] <andypugh> My mill is using something joints-axes-ey, I don’t even know what
[16:59:32] <andypugh> It seemed to be doing a rapid at the end of the unscrew portion.
[16:59:47] <andypugh> And building up a cumulative wrongmess
[17:00:04] <andypugh> Until it did a rapid into the limit switch.
[17:00:51] <andypugh> I don’t know whether it is my setup, the version I am using, or something related to resolvers. I bet nobody else is rigid-tapping with a spindle resolver.
[17:01:02] <cradek> but 2.7 works fine...?
[17:01:08] <andypugh> In a sim.
[17:01:20] <cradek> hm, if index reset is wrong, it might go wonky fast
[17:01:38] <andypugh> Which should be the same. but clearly isn’t a real encoder.
[17:01:50] <cradek> specifically if it reports reset but the position doesn't zero
[17:02:10] <cradek> plot motion.spindle-revs and index-enable and commanded position?
[17:02:25] <andypugh> I will do that tomorrow.
[17:02:26] <cradek> Y position I guess
[17:02:41] <andypugh> It got cold, and I had had enough
[17:03:01] <cradek> seems like the wrongmess (great word, accidentally created) should be obvious in that plot
[17:03:17] <cradek> cold sure can cut a project short
[17:03:40] <andypugh> Well, I had been out there for 4 hours.
[17:03:45] <cradek> tapping in new-tp had some serious wrongness, but it's been a while
[17:04:02] <andypugh> I don’t think I have the new tp
[17:04:25] <andypugh> I might even have a JA5 with MAH-jog while paused still.
[17:05:20] <cradek> I suppose that could be uniquely broken in some way
[17:05:29] <cradek> he touched a lot of the tp goop
[17:05:39] <andypugh> Yes, quite, which is why I tried it in a sim first
[17:10:08] <cradek> on the other hand, I bet few people have tried tapping in Y
[17:13:23] <andypugh> Yes, I wasa wondering about that. Does the plane matter for G33.1? I don’t see a reason for it to
[17:13:49] <cradek> no, plane only affects canned cycles, which fbofw tapping is not
[17:14:04] <cradek> upside is you can tap in any direction, not just planar
[17:15:47] <andypugh> Yes, I found that out. Potentially useful, I have a tilting head.
[17:17:33] <cradek> I have to run
[17:18:01] <cradek> anxiously await the verdict (of whether it's my problem!)
[17:18:05] <cradek> g'night :-)
[19:29:22] <jepler> woo new largest proven mersenne prime
[19:29:35] <jepler> GIMPS Project Discovers
[19:29:36] <jepler> Largest Known Prime Number: 274,207,281-1
[19:29:44] <jepler> that's 2^74,207,281 - 1
[19:36:49] <jepler> the last digits of it are ...36351 if I got my little program right