Back
[06:18:22] <ikcalB> file /usr/lib/tcltk/linuxcnc/bin/halshow.tcl @ line 220: makeNodesig {sigstring} ## Why does halshow 'assume more about hal signals than pins and params'? Is there any reason for that?
[06:19:36] <ikcalB> (i'd rather like halshow to group anything like under "Pins" or "Parameters")
[07:39:14] <jepler> if you read our sample configs, you'll see that using dots in signal names is uncommon. I assume the halshow author felt there was little value in implemeting a "group based on dot-separated components" feature for signals.
[08:47:58] <jepler> it's more difficult than it looks to make the ini pins appear early enough to be "net"table from [HAL]HALFILEs
[08:49:02] <jepler> for task to get far enough through startup to call hal_ready(), realtime threads have to be running; but we cannot do that until all [HAL]HALFILEs have been erad
[08:49:06] <jepler> s/erad/read/
[08:49:24] <jepler> so for now the limitation is likely to remain
[08:50:39] <jepler> ikcalB: there doesn't seem to be anything complicated about allowing haltcl files as POSTGUI files, and it would be a perfect chance for a new developer to learn how to use git and create a git patch
[08:51:05] <jepler> so I encourage you to do that. You can attach the patch to the bug, or if you like you can use the github pull request system at
https://github.com/jepler/linuxcnc-mirror/
[10:01:22] <pcw_home> jepler: 2000 for DPLL.time-const seems to be a good compromise
[10:05:34] <jepler> pcw_home: ok
[10:11:04] <jepler> (u32, in) hm2_<BoardType>.<BoardNum>.dpll.time-const
[10:11:04] <jepler> The filter time-constant for the PLL. The default value
[10:11:04] <jepler> is a compromise between insensitivity to single-cycle
[10:11:04] <jepler> variations and being resilient to changes to the Linux
[10:11:04] <jepler> CLOCK_MONOTONIC timescale, which can instantly change by
[10:11:07] <jepler> up to ±500ppm from its nominal value, usually by time‐
[10:11:10] <jepler> keeping software like ntpd and ntpdate. Default 2000
[10:11:12] <jepler> (0x7d0)
[10:11:15] <jepler> here's what I'll write in the docs, and change the value in the source accordingly
[10:14:11] <pcw_home> That sounds good
[10:17:48] <jepler> seb_kuzminsky: I just noticed this. should I pull the trigger?
[10:17:48] <jepler> > The `pet-watchdog` function will be removed before the 2.7.0 release.
[10:18:17] <KGB-linuxcnc> 03Jeff Epler 052.7 5f81230 06linuxcnc 10docs/man/man9/hostmot2.9 10docs/src/getting-started/updating-linuxcnc.txt 10src/hal/drivers/mesa-hostmot2/dpll.c hostmot2: don't let ntp cause following errors * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5f81230
[10:23:18] <jepler> seb_kuzminsky: to that end, and for your review: /shared/home/jepler/patches/0001-hostmot2-remove-pet_watchdog-hal-function.patch
[10:40:44] <seb_kuzminsky> err i can't read that
[10:40:55] <seb_kuzminsky> wonder if i can guess the http url from that
[10:42:47] <ikcalB> jepler: Thank you Sir! The halshow issue is easily fixed by changing one function call. I asked, because I wanted to know, whether this is worth putting upstream. (As there were reasons not to group signals that way. although i understood the HAL manual, dots are used for this purpose)
[10:43:33] <cradek> seb_kuzminsky: that path wfm, haha
[10:43:55] <ikcalB> jepler: i can see race conditions there... going to work around for now
[10:43:57] <cradek> - // the function
[10:45:15] <ikcalB> jepler: will put that up. any other gui than axis|gscreen|gmocappy|touchy supportgin POSTGUI_HALFILEs atm? (i may have overlooked some)
[10:47:33] <ikcalB> (beeing new to git: are pull requests for the main repo likely to be accepted only from known devs?)
[10:49:01] <seb_kuzminsky> ikcalB: no, pull requests are welcome from everyone
[10:49:31] <seb_kuzminsky> all pull requests will be evaluated on the merits of the code, not on the personage of the requestor
[10:53:48] <ikcalB> seb_kuzminsky: trying my best!
[10:54:43] <seb_kuzminsky> ok :-)
[11:00:47] <jepler> seb_kuzminsky: oops I used the wrong alias to share that patch, jas
[11:01:05] <jepler> seb_kuzminsky:
http://emergent.unpythonic.net/files/sandbox/0001-hostmot2-remove-pet_watchdog-hal-function.patch
[11:02:06] <jepler> cradek: I don't understand your comment about my patch
[11:06:01] <seb_kuzminsky> jepler: yes please
[11:07:27] <KGB-linuxcnc> 03Jeff Epler 052.7 9ab13aa 06linuxcnc 10docs/src/drivers/hostmot2_fr.txt 10docs/src/getting-started/updating-linuxcnc.txt 10src/hal/drivers/mesa-hostmot2/hostmot2-lowlevel.h 10src/hal/drivers/mesa-hostmot2/watchdog.c hostmot2: remove pet_watchdog hal function * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9ab13aa
[11:14:14] <cradek> jepler: it's nothing, sorry
[11:15:50] <cradek> I was making fun of a silly comment that you rightfully removed
[11:23:56] <jepler> cradek: ok thanks
[12:06:17] <ikcalB> as i'm changing the guis to accept POSTGUI_HALFILE '.tcl' files, I encountered: touchy.py has mixed tabs/spaces for indentation. shall i :retab the file right away!?
[12:07:09] <jepler> ikcalB: no
[12:07:26] <jepler> leave the whitespace alone. changing whitespace makes diff useless.
[12:07:35] <jepler> just work in the area where you need to work, and be consistent with nearby code.
[12:08:09] <jepler> http://www.linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_follow_the_style_of_the_surrounding_code
[12:09:17] <ikcalB> jepler: tnx, i know that convention. just asked, because on some recent python versions, mixed indendation does not even execute.
[12:10:15] <jepler> I agree with that statement about Python.
[12:11:51] <ikcalB> jepler: i disagree, that they encountered that in version 2.5.too-late
[12:14:37] <jepler> as far as I know, all python 2.x versions follow a rule substantially like the following one when it comes to treatment of indentation where tabs and spaces are mixed:
[12:14:40] <jepler> > First, tabs are replaced (from left to right) by one to eight spaces such that the total number of characters up to and including the replacement is a multiple of eight (this is intended to be the same rule as used by Unix). The total number of spaces preceding the first non-blank character then determines the line's indentation. Indentation cannot be split over multiple physical lines using back
[12:14:46] <jepler> slashes; the whitespace up to the first backslash determines the indentation.
[12:15:16] <jepler> in any case, whatever is currently in the linuxcnc 2.7 branch seems to work with our required python versions, 2.6 and 2.7
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?MinimumSoftwareVersions
[12:17:16] <jepler> bbl
[12:22:10] <ikcalB> jepler: interesting. still, imo it is insane, for a language using indentation for defining blocks, to allow mixing.... (enough OT, tnx for discussing!)
[12:23:34] <ikcalB> jepler: added a pull request - pls call back, whether that was alright that way (btw: how do i know, these changes going upstream, without checking the main repo?)
[12:37:50] <jepler> ikcalB: one small change to your commit message is required.
http://www.linuxcnc.org/docs/2.7/html/code/contributing-to-linuxcnc.html#_signed_off_by_policy
[13:22:54] <jepler> seems they may be playing with this stuff in linux kernel timekeeping. this went into the kernel in the 3.16 era, according to the thread that mentioned it:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=dc491596f6394382fbc74ad33
[13:23:03] <jepler> I don't think we have NOHZ in our preempt-rt kernels but I'm not sure
[13:23:31] <jepler> # CONFIG_NO_HZ is not set
[13:23:42] <jepler> (in the 3.14-rt kernel from wheezy-backports)
[13:24:04] <ikcalB> jepler: tnx for your support. shall i submit a pull request for both branches, or just the 2.7 then?
[13:25:29] <cradek> just the earliest branch, because we use "merging upwards" workflow
[13:25:29] <jepler> ikcalB: you only need to submit a pull request for the earliest branch where you would like to see your work included
[13:25:44] <jepler> all work in the 2.7 branch is "merged up" into master by other developers
[13:25:46] <ikcalB> k.
[13:25:49] <cradek> if you're not familiar with it, this is described in man gitworkflows
[13:26:11] <cradek> ikcalB: thanks for doing the work to contribute your fix
[13:27:15] <ikcalB> cradek: will have to go through the git workflow mor toroughly, yes (+, not used to git at all)
[13:27:40] <ikcalB> cradek: the work was pushing that to git... more to come!
[13:28:14] <jepler> I don't understand how Norbert likes to manage his release notes file, but what you wrote is clear and he will be able to put it into his desired form later.
[13:29:22] <ikcalB> jepler: ack. am i correct, '2.7' is the branch to put the fixes. (not '2.7-jessie', i.e.)
[13:30:07] <jepler> ikcalB: yes, "2.7"
[13:34:08] <andypugh> http://linuxcnc.org/index.php/english/forum/21-axis/29586-shown-axis-tlo-z-offset-not-stored-in-5403#62098
[13:35:14] <andypugh> #5403 does not necessarily agree with the Axis TLO display (or the actual TLO) after a G43.1 or a G10 L1
[13:35:53] <cradek> ick
[13:36:05] <cradek> you expected 1,2, ...?
[13:36:18] <cradek> 1, 2, ?, 5
[13:37:40] <andypugh> I expected 1,2,10,2
[13:38:01] <andypugh> Ah, no, wait, 1,2,10,5 is right.
[13:38:05] <cradek> are you aware that G43 goes before G10, according to order of ops
http://linuxcnc.org/docs/html/gcode/overview.html#sec:Order-of-Execution
[13:38:32] <andypugh> No, but that isn’t really the problem.
[13:38:49] <andypugh> (does G10 need a G43?)
[13:39:00] <cradek> I think I expect 1,2,2,5 that you are getting
[13:39:13] <cradek> it shows the tool table's value, not the active g43 value
[13:39:38] <cradek> none of you g43 matter
[13:39:39] <andypugh> And what does Axis show?
[13:39:39] <cradek> your
[13:39:46] <cradek> the active TLO
[13:40:07] <cradek> trying to find the docs now
[13:40:08] <andypugh> So why isn’t Axis showing 10?
[13:40:24] <andypugh> Ah, because I G43-ed it
[13:40:52] <cradek> yes I think AXIS should show TLO Z: 2 after running the program
[13:41:03] <cradek> because the last G43 happens before your G10 tool table change
[13:41:17] <andypugh> Yes, if #5403 is tool table value, not active TLO, I think the results are consistent
[13:41:42] <cradek> docs say #540[3]: Tool Offsets for X, Y, Z, A, B, C, U, V & W. Volatile.
[13:41:56] <cradek> could sure be clearer
[13:42:06] <andypugh> Tool _table_ offsets
[13:42:31] <cradek> followed by front angle, orientation, etc that you can not apply/unapply with any gcode
[13:43:39] <cradek> perhaps: X...W values from the currently-loaded tool's entry in the tool table
[13:45:00] <cradek> active diameter you can set with gcodes, and I'd expect #5410 to not change when you do that
[13:45:07] <jepler> my intuition would have been that the use cases of #540x are more likely to be aligned with "the tool offsets currently in effect" than "the tool offsets in the table", but I'm content to be wrong if people who use the feature know better.
[13:45:51] <andypugh> No, clearly the user in question is wanting the offsets currently in effect, for whatever reason
[13:46:06] <cradek> I wonder what problem the user is trying to solve
[13:46:29] <andypugh> He hasn’t said, I don’t think.
[13:46:41] <andypugh> While you are all here:
[13:46:45] <andypugh> spindle homing…
[13:47:35] <andypugh> The point of the feature request is to have zeroed the spindle encoder to the index before trying to align the spindle for a toolchange
[13:48:08] <cradek> R: Position to rotate to from 0
[13:48:14] <cradek> (what on earth is that supposed to mean?)
[13:48:39] <andypugh> (at the very least I would like to propose that spindle.index-enable is set to 1 at system startup.
[13:48:42] <cradek> it says it requires index, so I assume this is supposed to be absolute positioning
[13:48:57] <andypugh> There isn’t much point otherwise
[13:49:00] <cradek> yeah
[13:49:15] <cradek> so it's just busted - it currently orients relative to startup position?
[13:49:40] <andypugh> I don’t have an index on my machine, and it all works. I have a resolver :-)
[13:49:46] <cradek> ha
[13:50:27] <jepler> ISTR there was some kind of ladder-based spindle orient on the mazak, way back in the day
[13:50:33] <andypugh> orient isn’t “busted”, LinuxCNC just needs to adapt to spindles being orientable.
[13:51:02] <archivist> and then live milling in spindles :)
[13:51:07] <jepler> and it had a problem where the I(?) term got huge because initially the command was some small number, and the feedback was huge
[13:51:13] <andypugh> This isn’t related to orient or M19 really, any previous oriented spindle stuff needs to have found a way to work round this.
[13:51:57] <andypugh> All you need to do is set spindle-enable and rotate the spindle through the index.
[13:52:05] <cradek> does the rotate-direction stuff work?
[13:52:40] <andypugh> cradek: I think you are looking at the wrong thing
[13:52:49] <cradek> http://linuxcnc.org/docs/html/gcode/m-code.html#sec:M19
[13:53:01] <cradek> I'm trying to answer the question "what is it supposed to be able to do"
[13:53:07] <andypugh> This is nothing specifically to do with M19
[13:53:21] <cradek> I don't understand why not
[13:53:28] <cradek> please say again?
[13:54:04] <andypugh> Bacause you could always orient a spindle for a toolchanger that required it before M19 and before the orient comp, and people did.
[13:54:08] <cradek> things that use the spindle position, like threading, control index when needed. seems like M19 should do the same.
[13:54:09] <jepler> of course, mazak was way before linuxcnc had motion.spindle-index-enable probably
[13:54:32] <andypugh> But you have to jump through hoops to ensure that the spindle encoder counter has zeroed to an index
[13:55:12] <jepler> "Spindle orientation requires a *differential* encoder"?
[13:55:26] <cradek> I assume people use/used a variety of ways :-/
[13:55:36] <cradek> jepler: surely he meant incremental, but that's also wrong
[13:55:46] <andypugh> yeah, that should be scrubbed.
[13:56:13] <cradek> I think M19 should use index as necessary to do what you ask
[13:56:30] <andypugh> I don’t think it should.
[13:56:30] <jepler> how does M19 know whether using spindle-index-enable is necessary?
[13:56:36] <andypugh> quite
[13:56:51] <cradek> one incidental reason I think that is because my spindle always loses position when it goes fast
[13:56:53] <andypugh> This is like saying that G1 should always home first :-)
[13:57:21] <andypugh> cradek: No reason to break LinuxCNC because your spindle encoder is broken
[13:57:24] <cradek> jepler: good question. how about each time like threading?
[13:57:32] <jepler> it is sure true that *just to support orient* you could have an encoder that works at some low speed but doesn't work at the maximum spindle speed
[13:57:50] <cradek> "just to support everything you need to do with a spindle encoder"
[13:58:12] <cradek> but I guess I don't see how you can do the go-cw go-ccw stuff
[13:58:27] <cradek> I also don't know why that was in the design
[13:58:27] <jepler> yeah you'd just ignore the P-value
[13:58:32] <andypugh> I don’t understand the problem
[13:59:09] <cradek> does the direction ever matter?
[13:59:19] <andypugh> This just looks like a homing problem to me. If cradeks’s spindle loses home then that is his problem to work around.
[13:59:29] <cradek> for tool change, no - the only other thing I can think of is a boring head extraction
[13:59:55] <andypugh> Ah, there is a canned cycle for that isn’t there?
[14:00:08] <cradek> andypugh: it makes me feel ooky that you need a special homing step for orient, but not threading or tapping
[14:00:20] <cradek> and I don't understand why it's BETTER to require the special homing step
[14:00:33] <archivist> anyone using the parallel port for the spindle encoder
[14:00:42] <jepler> in general, spindles don't have to keep position during all operations, just during some
[14:01:42] <andypugh> <gives up in disgust> Once again a reasonable proposal has been countered with several wierd corner-cases to justify doing nothing
[14:02:06] <cradek> I'm not suggesting doing nothing. I'm suggesting that M19 should be fixed to locate the right position, like threading does
[14:02:20] <cradek> as it is, it's busted
[14:02:49] <jepler> for certain kinds of blind operations you sure need to know that M19 is really going to go in the way you ask it to
[14:02:59] <cradek> I must be bad at explaining what I mean
[14:03:13] <cradek> jepler: can you think of one?
[14:03:46] <archivist> any bayonet type fitting
[14:06:17] <cradek> the direction thing is incompatible with what I suggest, except if you allow an extra full turn
[14:07:11] <jepler> I don't know the name of the thing I'm thinking of. I have in my mind that there's a picture in the very old emc manual about the thing i'm thinking of, and that's it.
[14:07:14] * jepler <-- no machinist
[14:07:45] <cradek> back boring is certainly a time you need orient (to withdraw) but the direction or extra turns during orient don't matter because you were just boring anyway
[14:08:21] <cradek> think of an L shaped boring bar you stick through a hole and then center the | part in the hole, to bore the back face
[14:08:33] <jepler> yes I think that matches my image
[14:08:52] <cradek> then you have to orient the L again, and move (the correct way) sideways a bit to withdraw it
[14:09:06] <cradek> but while orienting the L the _ part is in free space below the part
[14:11:44] <cradek> wait does M19 use any of the spindle position and index pins at all? it doesn't look like it, it's just a simple loopback
[14:11:53] <cradek> now I'm more puzzled
[14:11:58] <jepler> cradek: no, you have to build a lot of stuff in HAL to use it
[14:12:13] <jepler> something that muxes between the velocity command of linuxcnc's regular spindle command, and a position command mode
[14:12:20] <cradek> would you even have it hooked to the spindle pins?
[14:13:42] <jepler> halcmd: loadrt tristate_bit count=3
[14:13:46] <jepler> halcmd: net x tristate-bit.0.out tristate-bit.1.out
[14:13:52] <jepler> halcmd: sets x 1
[14:14:35] <jepler> you're allowed to set a signal which is connected to I/O pins, so if setting spindle index-enable once at startup is enough then it's possible now in hal
[14:14:54] <archivist> someone has to retrofit a sliding head lathe with live tooling to test all this
[14:16:32] <cradek> is there a reference implementation of the orient hal hookups that everyone is using?
[14:16:47] <cradek> (a broken one that doesn't know about index)
[14:17:16] <jepler> zconfigs/sim/axis/spindle_orient ?
[14:17:21] <jepler> s/z//
[14:17:48] <cradek> no
[14:18:08] <cradek> looks like that was for testing
[14:19:32] <jepler> yeah having run that it looks like you're right
[14:19:44] <jepler> the user gets to poke the "motion.spindle-is-oriented" signal true
[14:21:20] <jepler> ugh that's weird. panels never have worked very well integrated in axis, have they?
[14:21:44] <jepler> somehow I'm in a situation where alphanumerics type in the mdi command entry, but hitting enter clicks motion.spindle-is-oriented
[14:23:16] <cradek> ugh everything's a rabbit hole
[14:26:14] <cradek> sim/axis/vismach/VMC_toolchange/spindle.hal:loadrt orient
[14:26:39] <cradek> > This component is designed to support a spindle orientation PID loop
[14:28:43] <cradek> but this doesn't do the muxy stuff
[14:28:53] <jepler> no, it doesn't seem to
[14:29:05] <cradek> there must be another piece to the puzzle
[14:30:12] <jepler> On motion.spindle-orient disconnect the spindle control and connect to
[14:30:15] <jepler> the orient-pid loop:
[14:30:33] <jepler> [this margin is too small to contain the proof]
[14:31:49] <jepler> I do see what andy's getting at now, if the M19 P- is an absolute requirement and not a best-effort requirement
[14:32:02] <jepler> and I am also seeing we still don't have good building blocks for this in hal
[14:32:25] <cradek> homing would have to turn on the spindle too, right?
[14:32:53] <jepler> in andy's original proposal, yes, there would be a "homed" flag for the spindle, and "homing" it would involve enabling the spindle amplifier in many cases
[14:33:02] <jepler> .. I think
[14:33:42] <jepler> are there concerns which exist for making the spindle rotate (up to 1 turn) that don't exist for moving axes?
[14:34:00] <jepler> certainly you'd better be able to get to coord mode before the spindle is homed
[14:35:11] <cradek> I think he was saying to just blindly turn on index at startup, and then whatever moves the spindle first will eventually cause a reset
[14:35:44] <cradek> but that doesn't give the P- guarantee
[14:37:26] <jepler> if the first spindle motion is an M19 you might still get it wrong
[14:37:30] <cradek> it seems like our two choices are have an explicit homing step that's just like index-only homing on joints, and ditch the P guarantee (which opens up several solutions)
[14:37:43] <cradek> yes that's what I meant by doesn't give the P guarantee
[14:37:56] <jepler> no, I think you might go to the wrong location still
[14:38:37] <jepler> at startup, encoder feedback = 0, but real spindle = 39 degrees
[14:38:40] <cradek> this is so complicated there must be a reference setup somewhere, but I can't find it
[14:38:46] <jepler> you command M19 R0, and the spindle doesn't move
[14:38:59] <cradek> oh I see what you mean
[14:39:19] <cradek> yes I think just turning on index and forgetting it is really not going to be good enough
[14:39:34] <jepler> no, in a rare circumstance it'll bite you
[14:39:50] <cradek> also, when you later reset you'll get an uncompensated position jump
[14:40:25] <jepler> yes, if you had real = 350, feedback = 0, index-enable set, and M19 P45
[14:40:28] <cradek> don't you have to expect the reset and handle it by watching the index-enable line?
[14:40:35] <jepler> ... it'll start rotating and then position will jump from 10 back to 0
[14:42:36] <jepler> so if you - set index-enable high once at start
[14:42:42] <jepler> - hook index-enable into a read pin of spindle-orient
[14:42:54] <jepler> - and say that the P value is best-effort
[14:43:27] <jepler> then orient can look at its index-enable input and decide whether it has to go until hitting the index, or whether it can initially trust the angle input
[14:43:47] <jepler> I wish we hadn't lost andypugh from the discussion
[14:44:13] <cradek> yeah
[14:46:06] <cradek> hm, say you're at 20, and you ask for ccw to 10, but as soon as you start moving ccw you get an index - you'll jump to 0 and start counting down and never see 10
[14:47:50] <jepler> real = 1, feedback = 20, target = 10 ?
[14:49:10] <cradek> yes exactly
[14:49:46] <cradek> so feedback goes 20 19 0 -1 -2 -3
[14:50:14] <jepler> I asume that when you get to feedback = real = 0, target = 10, your PID command changes sign
[14:50:27] <jepler> maybe with a whopping big thunk if it's a nice powerful spindle
[14:51:18] <cradek> usually the spindle drive handles steps in velocity command fine (because that's normal)
[14:51:29] <cradek> and direction too
[14:52:34] <cradek> so maybe it'll be fine, except it violates your P- direction request
[14:52:54] <cradek> seems like the only way to fix P is to have an early and explicit homing step
[14:53:41] <cradek> which means motion has to manipulate the motion.spindle-* including enabling the spindle
[14:56:16] <jepler> yes
[14:57:03] <jepler> even so, some particular machines will not be able to obey P-. maybe they have a single-directional spindle, for instance
[14:57:12] <jepler> heck there might just be one special R value they can align to
[14:57:39] <cradek> sure but that's not our problem is it?
[14:57:42] <jepler> well
[14:58:01] <jepler> you mean the person on such a machine has to always take care to write M19 P2 if it's a CCW-only spindle?
[14:58:16] <cradek> I ... guess
[14:58:22] <jepler> or you mean that the integrator had better write down "no matter what P value is given, it will rotate CCW"
[14:58:43] <jepler> either would be OK, I suppose
[15:01:02] <jepler> if the documentation said something like "P0 will move in either direction, favoring the shorter direction if possible" then the problem may be simpler
[15:01:41] <cradek> I wish I knew whether the direction requirement is important or just simple overengineering
[15:02:34] <jepler> maybe you want to "bore" an area just 45 degrees wide, so you write M19 P0 R0 / M19 P0 R45 over and over again
[15:02:35] <cradek> one way we must make it work; the other way we should remove it
[15:02:46] <cradek> a "please if you feel like it" direction is just stupid
[15:03:28] <cradek> jepler: not sure if serious
[15:04:23] <jepler> aside from "bore" not being the right term, ...
[15:04:45] <jepler> > For example, M19 P270 will orient the spindle to 270 degrees. The R-value allows the programmer to specify up to two decimal places; for example, M19 R123.45.
[15:05:06] <jepler> so far I've learned that Haas uses P for whole-numered degrees and R for hundredths-of-degrees
[15:07:32] <jepler> another reference has turned up M19 M3 / M19 M4 to control direction
http://bkinfosys.beckhoff.com/english.php?content=../content/1033/tccncprogramming/html/positioningspindlem19pos1.htm&id=29487
[15:07:43] <jepler> N10 S[REV100 POS45 M19 M3] (Spindle rot. cw with 100 U/min. to pos. 45)
[15:07:55] <jepler> N60 S[REV200 M19 POS90] (Move at shortest distance with 200 U/min. to)
[15:07:56] <jepler> (position 90)
[15:45:39] <cpresser> hi. i am having troubles with scarakins on the 2.6 release. would you recommend the joint-axes branch? is it up to date?
[15:53:42] <cpresser> joint_axes6 seems to be the newest branch.
[15:53:58] <cpresser> is it worth to build it, or should I try to port it to master?
[15:54:26] <seb_kuzminsky> cpresser: the newest one is called cradek/joints_axes7
[15:54:46] <seb_kuzminsky> what problems are you having with scarakins?
[15:55:22] <cpresser> the speeds are to fast
[15:55:26] <cpresser> about the factor of 60
[15:55:32] <cpresser> compared to trivialkins
[16:24:39] <KGB-linuxcnc> 03Florian Kerle 052.7 fcc8031 06linuxcnc 10(5 files in 4 dirs) add support for '.tcl' files set by [HAL]POSTGUI_HALFILE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fcc8031
[16:24:48] <cradek> yay!
[16:26:15] <seb_kuzminsky> thanks jeff and florian!
[16:40:48] <cpresser> seb_kuzminsky: i think that one is a serious bug since it is able to crash your machine (I had to weld once because of a broken arm caused by that)
[16:41:30] <cpresser> wehn i just replace 'loadrt trivkins' with 'loadrt scarakins' (and set some paramaters for scarakins), the speed isnt the same anymore
[16:42:16] <cpresser> when i run the robot with trivialkins everything seems fine. servos tuned nicely, speeds and accelleration are okay
[16:46:42] <cpresser> thats the config:
https://ca.rstenpresser.de/~cpresser/tmp/hirata_v2/ running on debian wheezy, linuxcnc version 2.6.9
[16:49:35] <jepler> what does it mean to run trivkins on a scara robot? Does that mean that when you command G1 X100 you are moving just one joint of the robot?
[16:49:51] <cpresser> jepler: yes. i did that for initial setup and tuning
[16:50:18] <jepler> I have not kept up with the development of the various joints-axes branches, but it's certainly true that 2.6, 2.7 and master branch linuxcnc *do not have any joint constraints*
[16:50:35] <jepler> I think the inifile values are used as cartesian axis constraints
[16:50:50] <cradek> yes
[16:51:28] <cradek> especially an inch might be much larger than a degree of rotation or however you had it scaled before
[16:52:02] <cpresser> the scara robot has a linear z-axis. i cen reproduce this error on that axis
[16:52:13] <jepler> if you use inverse time feed mode G93, you can at least control how long each specific motion takes, but there is still no enforcement of joint acceleration constraints
[16:52:20] <cpresser> basically the z-joint is the same as the z-axis, so it _should_ be the same!?
[16:52:30] <andypugh> (tantrum over)
[16:53:21] <linuxcnc-build> build #43 of 1502.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1502.rip-jessie-amd64/builds/43 blamelist: Florian Kerle <flo.kerle@gmx.at>
[16:53:24] <cpresser> the fact that there is no joint constraints doesn't sound so good for various non trivial kinematics. that information should be part of the manpage
[16:53:45] <jepler> Failed:
[16:53:46] <jepler> /home/buildslave/emc2-buildbot/jessie-amd64/rip-jessie-amd64/build/tests/hm2-idrom
[16:53:49] <jepler> whaaa
[16:58:27] <jepler> as far as I can tel, Florian Kerle / ikcalB is blameless for that test failure. but now I'm sad that we have yet another known-flaky test or something
[17:04:37] <linuxcnc-build> build #3430 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3430 blamelist: Florian Kerle <flo.kerle@gmx.at>
[17:27:33] <jepler> linuxcnc-build: force build --branch=2.7 0000.checkin
[17:27:34] <linuxcnc-build> build forced [ETA 1h30m28s]
[17:27:35] <linuxcnc-build> I'll give a shout when the build finishes
[17:51:05] <seb_kuzminsky> jepler: here's the failed part of that test
[17:51:08] <seb_kuzminsky> + TEST_PATTERN=2
[17:51:09] <seb_kuzminsky> + '[' '!' -z 'hm2/hm2_test\.0: invalid IDROM type' ']'
[17:51:09] <seb_kuzminsky> + export TEST_PATTERN
[17:51:09] <seb_kuzminsky> + halrun -f broken-load-test.hal
[17:51:09] <seb_kuzminsky> + ./check-dmesg 'hm2/hm2_test\.0: invalid IDROM type'
[17:51:11] <seb_kuzminsky> test pattern 2 didnt produce error 'hm2/hm2_test\.0: invalid IDROM type'
[17:51:13] <seb_kuzminsky> + result=1
[17:53:14] <seb_kuzminsky> unfortunately this is a uspace machine, so the information we seek isn't in the dmesg, like the test shows us, but in a file called halrun-stderr, which the buildbot does not show us
[17:59:52] <jepler> I guess I should run that test in a tight loop and see what shakes loose
[18:22:10] <linuxcnc-build> Hey! build 0000.checkin #3431 is complete: Success [3build successful]
[18:22:10] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3431
[18:35:08] <cpresser> is there a guide for non-trivial kinematics? example configs? some documentation?
[19:16:40] <Tom_itx> thought some of you might find some of these amusing:
https://c3.nasa.gov/dashlink/static/media/other/ObservedFailures42.html
[19:21:42] <malcom2073> These are good, what are they from?
[19:22:28] <Tom_itx> not sure, it's a NASA link
[19:22:43] <malcom2073> Oh,
https://c3.nasa.gov/dashlink/resources/624/
[19:29:27] <malcom2073> I can only imagine them trying to diagnose this one:
https://c3.nasa.gov/dashlink/static/media/other/ObservedFailures24.html
[19:31:00] <CaptHindsight> hmm 18KV pulse
[19:31:32] <CaptHindsight> should have used a few more layers of electrical tape :)
[19:32:11] <malcom2073> More E6000!
[19:32:27] <malcom2073> Well, I'm gonna go pick up a free wood stove. Here's hoping it's not a total rust bucket POS
[21:57:14] <jepler> seb_kuzminsky: 7359 runs so far on my desktop and no failures on that test :-/
[22:20:09] <seb_kuzminsky> jepler: yeah, i've never seen it fail on the buildbot before
[22:20:19] <seb_kuzminsky> i think we may have all hallucinated that
[22:20:25] <seb_kuzminsky> or the buildbots drunk or something
[22:20:27] <seb_kuzminsky> who knows