Back
[08:21:31] <skunkworks> so this is what I should get with ub
http://pastebin.com/E2KzNmWc
[08:21:36] <skunkworks> I assume
[08:22:06] <skunkworks> I forgot I had a rtnet 10.04 hd setup
[08:25:42] <skunkworks> (without the new linuxcnc.log setup)
[08:27:28] <skunkworks> but the newer nic did fix my comunication issues..
[09:25:52] <skunkworks> doesn't stderr just ouput in the terminal?
[09:39:27] <archivist_> skunkworks, unless you put it somewhere else, yes
[09:42:23] <skunkworks> hmm
[09:42:43] <skunkworks> then it does't output the data that I can see anywhere
[09:44:28] <archivist_> you can use the pipe to put stderr some other place
[09:45:46] <archivist_> tricks like grep da * 2> grep-errors.txt
[09:45:58] <archivist_> http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html
[10:16:32] <skunkworks> This is what I get out of terminal
http://pastebin.ca/2434246?srch=7i80
[10:17:58] <jepler> I think the problem is that it was creating too much debug output from a realtime context
[10:18:06] <jepler> that buffer of only 32768 bytes got full
[10:18:15] <jepler> but you tried increasing the size and it flaked out, so I dunno what to do
[10:18:21] <skunkworks> heh
[10:18:32] <jepler> you could try doubling it instead of inserting a new leading digit .. sometimes these things have to be powers of 2 or multiples of 4096 or who knows what
[10:18:41] <skunkworks> I will try
[10:33:11] <skunkworks> http://pastebin.com/yyKd0MPN
[10:33:36] <skunkworks> Sep 26 10:17:07 empire-System-Product-Name msgd:0: rtapi:-1:rt RTAPI:0 ERROR: unexpected global shm size: expected: 40240 actual:73008
[10:33:54] <skunkworks> can I increase the shm size?
[10:35:33] * skunkworks starts down the rabit hole
[10:43:32] <KGB-linuxcnc> 03seb 05vfd-b-2 c25ed82 06linuxcnc 10docs/man/man1/vfdb_vfd.1 * vfd-b: improve manpage (still have a ways to go)
[10:50:40] <cradek> is that a new driver?
[10:55:46] <jepler> skunkworks: just for grins, make clean and make again. if that clears things up then there's a dependency analysis problem in that branch..
[10:55:57] <skunkworks> oh - I can do that
[10:56:34] <mhaberler> hi.. back in coverage
[10:56:41] <jepler> mhaberler: welcome
[10:56:59] <skunkworks> mhaberler, Good vacation?
[10:57:04] <mhaberler> mountain time, julian alps
[10:57:35] <skunkworks> nice
[10:57:50] <mhaberler> anyway.. where were we.. licensing methinks..
[10:58:27] <skunkworks> mhaberler, I have a couple of questions...
[10:58:31] <skunkworks> :)
[10:58:41] <mhaberler> uh.. go ahead
[10:58:49] <skunkworks> I am missing output it seems going to linuxcnc.log
[10:59:21] <mhaberler> right, I just saw that.. the ringbuffer is in fact a tad small, and I'll make that configurable - could well be it overran
[10:59:34] <mhaberler> you can resize it to any power of 2
[10:59:38] <KGB-linuxcnc> 03seb 05vfd-b-2 e4dc088 06linuxcnc 10docs/man/man1/vfdb_vfd.1 * vfd-b: add a quick-start section to the manpage
[11:00:09] <skunkworks> oh - ok - let me try that.
[11:00:09] <mhaberler> actually I made it small so I could test the adaptive rate polling.. well.
[11:00:12] <seb_kuzminsky> cradek: that's the driver that yishin li wrote to talk to the Delta VFD-B
[11:00:35] <mhaberler> just make it (1024*1024) or so
[11:00:36] <seb_kuzminsky> i'm helping a friend bring up a new CNC machine with that vfd on the spindle
[11:01:04] <mhaberler> anything else?
[11:03:48] <mhaberler> but I didnt think of the mass of output the hostmot2 driver generates with the pin lists, and that all happens pretty fast
[11:04:05] <skunkworks> not at the moment.. mhaberler I did get your 7i80 branch working - it ended up being the pro/100 card I was using
[11:04:07] <mhaberler> skunksworks: did you see by any chance on shutdown in the log a line like this:
[11:04:25] <mhaberler> "msgd:%d: message ring stats: full=%d locked=%d " and some int instead of %d ?
[11:04:35] <mhaberler> oh, excellent
[11:04:59] <mhaberler> what was unclear to me is if the rtnet patches leave the normal PCI hm2 working ok or not
[11:05:21] <skunkworks> mhaberler, this is what I was getting..
[11:05:22] <skunkworks> http://pastebin.com/Z1iuvW8W
[11:05:24] <mhaberler> in a cursory attempt, that branch failed for me with a 5i25, so it looked like either-or
[11:05:47] <mhaberler> nothing more thereafter?
[11:06:03] <skunkworks> nope
[11:06:08] <mhaberler> that message is a canary at shutdown only
[11:07:03] <mhaberler> ok, I guess we need to prod micges or some other heroic coder with a 7i80 into making it coexist with hm2 pci
[11:07:13] <skunkworks> jepler, make clean did seem to fix that..
[11:07:24] <jepler> skunkworks: ugh, so now we know, or think we know, there's a dependency analysis problem :(
[11:07:25] <skunkworks> mhaberler, I think micges is working on it now.
[11:07:30] <mhaberler> ah, super
[11:08:24] <mhaberler> it is a pity that there's no good portable way of userland ethernet i/o which works without extra stacks like rtnet
[11:08:28] <jepler> $DAY_JOB calls, bbl.
[11:08:32] <mhaberler> cu
[11:09:19] <pcw_home> Preemt-RT might be OK
[11:09:36] <mhaberler> hm, just UDP I/O?
[11:09:57] <mhaberler> is there any way you can do interpacket arrival timings on the 7i80?
[11:10:04] <pcw_home> Yep OASDL specs seem promising
[11:10:14] <pcw_home> Yes
[11:10:58] <pcw_home> current (R14) firmware has timestamps,waituS, and wait for DPLL
[11:11:10] <mhaberler> OSADL.. btw I got a paper on the Portable RTAPI in into the OSADL conference in Lugano CH end of october
[11:11:30] <mhaberler> paper/paper accepted/
[11:12:02] <mhaberler> are these pin values?
[11:12:20] <pcw_home> if Preemt-RT is good enough it solves the "only works with these three MACs" problem
[11:12:29] <mhaberler> right
[11:13:02] <mhaberler> it would be interesting to see the difference between rtnet and just plain udp i/o on the timestamps
[11:13:08] <pcw_home> the timers are lower level but easily accesible
[11:13:14] <skunkworks> So - this is with the message_ring_size to 1024*1024
[11:13:17] <skunkworks> MESSAGE_RING_SIZ
[11:13:33] <skunkworks> http://pastebin.com/deAQNxC9
[11:14:13] <pcw_home> also R14 firmware drives TP0 with RXPKT and TP1 with TXPKT for timing checks
[11:14:15] <mhaberler> looks much better
[11:15:07] <skunkworks> but missing this type of info
http://pastebin.com/E2KzNmWc
[11:15:43] <mhaberler> type info.. example line being?
[11:15:45] <skunkworks> (non linuxcnc.log system)
[11:16:02] <skunkworks> hm2/hm2_7i80.0: IO Pin 002 (P1-05): Muxed Encoder #0, pin Muxed B (Input)
[11:16:06] <mhaberler> ok
[11:16:19] <mhaberler> let me see what he's using
[11:19:40] <skunkworks> mhaberler, this is my test hal file
[11:19:41] <skunkworks> http://pastebin.com/sgNwEGvv
[11:19:53] <skunkworks> (so you can also see the debug flags)
[11:19:57] <mhaberler> aja
[11:21:36] <skunkworks> and I envoke the hal file DEBUG=5 halrun -I -f save.hal
[11:30:14] <mhaberler> I dont see how the buffer size has anything to do with what was being printed before and after the change
[11:30:22] <mhaberler> anything else changed here?
[11:33:24] <mhaberler> are you talking about stderr output or what is in /var/log/linuxcnc.log ?
[11:33:40] <skunkworks> I don't think the increasing the buffer size effected anything
[11:33:49] <skunkworks> where is stderror going? to terminal?
[11:34:00] <mhaberler> well unless you redirect, yes
[11:34:29] <skunkworks> then the pin designations are missing there also/too
[11:34:41] <mhaberler> what did you mean by '(non linuxcnc.log system)' ?
[11:34:57] <mhaberler> you meant logging isnt set up?
[11:35:21] <skunkworks> correct - and it seems to output the info to stderr (terminal output_
[11:35:33] <skunkworks> as you can see here
http://pastebin.com/E2KzNmWc
[11:36:00] <mhaberler> right, but only for messages tagged with RTAPI_MSG_ERR
[11:36:04] <mhaberler> everything else should show up in linuxcnc.log
[11:36:39] <mhaberler> now if those messages are generated with less than RTAPI_MSG_ERR that is just normal they dont show up on the console
[11:36:56] <mhaberler> does the linuxcnc.log file also lack those lines?
[11:37:01] <skunkworks> this is what I get out of terminal currently
http://pastebin.ca/2434246?srch=7i80
[11:37:26] <skunkworks> correct
[11:38:09] <skunkworks> log ->
http://pastebin.com/deAQNxC9
[11:38:21] <skunkworks> terminal ->
http://pastebin.ca/2434246?srch=7i80
[11:39:10] <mhaberler> sorry, I'm lost. give me an example which is in the terminal output but not in the log
[11:40:21] <skunkworks> if I run this setup
[11:40:23] <skunkworks> $ git branch --track rtos-master-v0 origin/rtos-master-v0
[11:40:23] <skunkworks> $ git checkout rtos-master-v0
[11:40:40] <skunkworks> without the linuxcnc.log setup
[11:40:52] <skunkworks> I get this output in terminal
[11:40:53] <skunkworks> http://pastebin.com/E2KzNmWc
[11:41:16] <skunkworks> this is missing from the linuxcnc.log or terminal when logging is setup
[11:41:27] <skunkworks> (if that make sense)
[11:41:58] <mhaberler> (yes, but thats a rather old branch)
[11:42:02] <skunkworks> *this type of info
[11:42:03] <skunkworks> hm2/hm2_7i80.0: IO Pin 011 (P1-23): PWMGen #0, pin Out0 (PWM or Up) (Output)
[11:42:03] <skunkworks> hm2/hm2_7i80.0: IO Pin 012 (P1-25): PWMGen #0, pin Out1 (Dir or Down) (Output)
[11:42:03] <skunkworks> hm2/hm2_7i80.0: IO Pin 013 (P1-27): PWMGen #1, pin Out0 (PWM or Up) (Output)
[11:42:25] <mhaberler> need to see where that's output in hm2 and how
[11:43:10] <skunkworks> biab
[11:47:09] <skunkworks> mhaberler, welcome back! :)
[11:49:32] <mhaberler> oh. I have a suspicion
[11:50:08] <mhaberler> need a test module to verify - it's probably just broken mapping of rtapi to syslog log level
[11:52:29] <mhaberler> ok, I rebased that branch onto ubc3 - it is now called ubc3-7i80-rtnet ; let me look into that log issue first but you can build from that fine
[12:03:06] <mhaberler> skunkworks: your issue is this:
[12:03:37] <mhaberler> if you start realtime like so: 'DEBUG=5 realtime start' everything gets logged
[12:03:53] <mhaberler> you just used halrun, right?
[12:05:00] <mhaberler> need to check whether halrun does export DEBUG, I think yes - at least it should
[12:08:15] <mhaberler> if you run the file like so: 'DEBUG=5 halrun -I -f save.hal' all messages should go to the logfile, could you verify?
[12:20:26] <mhaberler> bbl
[12:24:07] <skunkworks> mhaberler,
http://pastebin.com/aFcM126S
[12:24:17] <skunkworks> (debug=5)
[12:24:26] <skunkworks> and
http://pastebin.com/GcpaVBDp
[12:33:22] <skunkworks> mhaberler, this is what I get if I do DEBUG=5 realtime start
[12:33:37] <skunkworks> Then halcmd -k -f save.hal
[12:33:41] <skunkworks> http://pastebin.com/4t2QqaU9
[12:35:15] <mhaberler> well hm2 is using rtapi_print for those output macros, and I just verified the output does show up in the log if realtime is started with DEBUG=5
[12:36:04] <mhaberler> I currently dont have a 7i80 setup at hand, but I need to reassemble one once micges is done
[12:44:54] <skunkworks> mhaberler, can you see if your 5i25 and see if you get pin information?
[12:45:35] <mhaberler> I think so, but will take a bit
[12:49:59] <skunkworks> (to see if it is a messaging problelm or a mesa driver problem..)
[12:51:51] <mhaberler> sure
[12:53:41] <skunkworks> I have some 5i20's but they are in a working system right now... :)
[12:55:28] <mhaberler> hm, wiki search window gone? on all of: firefox safari chrome
[12:56:16] <skunkworks> heh - I had the same problem - it is at the bottom now.
[12:56:28] <skunkworks> or was always - but the top one is gone
[12:56:51] <mhaberler> ah. confuse the spammers
[12:57:17] <skunkworks> sure
[13:08:45] <mhaberler> ok - ubc3, 5i25.ini, run with 'DEBUG=5 linuxcnc' I get:
[13:08:48] <mhaberler> http://static.mah.priv.at/public/console.txt
[13:09:46] <mhaberler> and this:
http://static.mah.priv.at/public/linuxcnc.log
[13:09:59] <mhaberler> looks like that type dump aint there
[13:10:56] <skunkworks> ok - so it isn't just the 7i80
[13:11:12] <mhaberler> yes, looks like me :-/
[13:11:38] <skunkworks> heh - thats ok. I am just happy that the rtnet seems to be coming along - Pretty darn cool.
[13:12:56] <skunkworks> I have been running a blinking led on the 7i80 for quite a while with no watchdog bites
[13:13:30] <skunkworks> (really - no watchdog bites since I replaced the NIC)
[13:21:44] <mhaberler> yep, found it - the mapping of rtapi to syslog log levels is off - nothing serious, all userland
[13:21:52] <mhaberler> thanks!
[13:24:38] <skunkworks> Awesome!
[13:27:39] <andypugh> Do new standalone HAL components get pushed to master or 2.5 at the moment?
[13:28:14] <cradek> comp based, or more complicated?
[13:28:21] <andypugh> comp
[13:28:37] <cradek> you can add that to 2.5 if you like
[13:28:48] <andypugh> Somebody asked for a gray-code to binary convertor.
[13:29:34] <cradek> cool, that kind of thing is no problem, especially because it gets packaged automatically
[13:33:03] <andypugh> I can't see any use for a binary to gray converter. Can anyone else?
[13:33:20] <alex_joni> mhaberler: the top search box was a hack to our wiki, which got lost during a recent upgrade
[13:33:28] <andypugh> Maybe sending data on a parallel bus made of relays?
[13:34:05] <cradek> mhaberler: what was/is your intent regarding the adoption/merge of jog-while-paused-preview1?
[13:35:12] <mhaberler> give me a bit of time
[13:35:37] <cradek> oh are you responding on list already?
[13:37:17] <mhaberler> no, that was just in response to the forum post - folks have asked repeatedly for this feature and I think they should say if they want it
[13:37:32] <pcw_home> gray to binary I can see (parallel absolute encoders in tool changers and what not)
[13:37:33] <mhaberler> still wading the backlog
[13:37:34] <pcw_home> cant see why you would want a bin to gray either
[13:38:16] <pcw_home> except maybe to test the gray to bin :-)
[13:38:22] <cradek> it's been added to the agenda and there's a post in emc-users about it
[13:38:35] <mhaberler> right, I suggested that
[13:39:54] <cradek> I'm not sure what the agenda item is proposing exactly, which is partly why I asked for your thoughts
[13:41:02] <cradek> I forgot to freeze the agenda yesterday
[13:41:06] <cradek> wonder if I should do it now
[13:41:28] <cradek> this is a good example of why - it's too late to reasonably discuss things that are added
[14:03:40] <KGB-linuxcnc> 03git 05unified-build-candidate-3 92d1c6e 06linuxcnc 04src/rtapi/xeno_math/.e_acos.o.d * xeno_math: remove spurious build artefact
[14:03:41] <KGB-linuxcnc> 03git 05unified-build-candidate-3 a2080d1 06linuxcnc 10src/rtapi/rtapi_msgd.c * rtapi_msgd: fix logging
[14:03:43] <KGB-linuxcnc> 03git 05unified-build-candidate-3 d70e81f 06linuxcnc 10src/rtapi/rtapi_global.h * rtapi_msgd: enlagre message buffer
[14:07:24] <mhaberler> skunkworks: logging is now fixed in ubc3 and ubc3-7i80-rtnet
[14:08:02] <skunkworks> mhaberler, ok - I will give it a try
[14:08:48] <mhaberler> it show up in syslog
[14:09:06] <mhaberler> misread the man page :-/
[14:09:39] <skunkworks> mhaberler, as of now? I looked in the syslog when I was goofing around
[14:10:27] <mhaberler> you want to pull the ubc3-7i80-rtnet branchm or unified-build-candidate-3 which is the base of the former
[14:13:11] <skunkworks> ok - hey - did you see
http://pastebin.com/0kg1jRgC
[14:14:07] <awallin_> does anyone know if "make menuconfig" for a linux kernel autodetects hardware and disables/enables menu-choices depending on the hardware detected? I am not seeing parallel port related stuff, but my current motherboard doesn't have a parport...
[14:14:27] <cradek> no I'm sure it doesn't
[14:15:18] <cradek> there are dependencies though - one menu option can control the appearance of others
[14:17:35] <awallin_> "depends on PARPORT && BROKEN" is not maybe so great :|
[14:17:53] <cradek> hmm
[14:18:14] <linuxcnc-build> build #1343 of hardy-amd64-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1343 blamelist: Michael Haberler <git@mah.priv.at>
[14:18:23] <linuxcnc-build> build #1339 of hardy-i386-realtime-rip is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-realtime-rip/builds/1339 blamelist: Michael Haberler <git@mah.priv.at>
[14:18:39] <linuxcnc-build> build #1341 of hardy-i386-sim is complete: Failure [4failed install-missing-build-dependencies] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1341 blamelist: Michael Haberler <git@mah.priv.at>
[14:19:42] <awallin_> somebody marked pps_gen_parport.c as BROKEN in 2011, in the same e-mail saying "there is an easy fix", but in the latest kernel it is still marked BROKEN
[14:20:08] <awallin_> er "no easy fix" :(
[14:21:00] <seb_kuzminsky> reminds me of the .sig joke, "i've written a patch that fixes the problem, but this .sig is too small to include it"
[14:25:08] <mhaberler> cradek: at the time I did it to explore the result of the discussion on the list - this is largely based on a Ken Lerman idea. At the time you said you werent interested. It worked fine for several people, and they repeatedly bug me about it, so I suggested to them to make it a meeting issue
[14:26:50] <mhaberler> I'm not sure anybody else has taken a closer look at the code though
[14:26:54] <cradek> mhaberler: history aside, I wonder if you think it should be merged and used long-term
[14:27:11] <mhaberler> oh, me - well yes, I find it useful
[14:28:02] <mhaberler> beyond that, I think the principle of multiple switchable motion queues is the way to do these 'things during pause'
[14:29:04] <cradek> mhaberler: to me, it seems like a useful way for people to get around a limitation for now, but I'd like to see a better approach that allows all the existing jog styles instead of making a new style -- I agree multiple motion queues may be part of that -- and it should ideally be part of ja3
[14:29:41] <mhaberler> good point - have a minute to discuss jog styles?
[14:29:42] <cradek> (keeping in mind that ja3 world mode wheel jog is not there currently, but I see recently that micges is planning to do it)
[14:30:14] <micges> yes I do!
[14:30:29] <cradek> micges: that makes me happy, thanks
[14:31:44] <cradek> mhaberler: I am in and out...
[14:31:49] <mhaberler> I see several ways to address jog styles - one way which occurred to me is that by switching kins (optionally masking joints) one could do this in a single planner
[14:32:28] <mhaberler> once you're paused and synced, that'd be safe
[14:32:53] <mhaberler> there is currently no support for multiple kins, but that be the most elegant solution imo
[14:33:12] <mhaberler> the idea would be like this:
[14:34:02] * alex_joni listens
[14:34:23] <eliezer> quien habla español
[14:34:26] <mhaberler> it's always the coord mode planner being active; however, it might act with different kins; for instance a trivkins (with possibly just one joint being active) be fine for joint jogging - and you get the vel/acc limit handling of the coord mode planner for free
[14:34:59] <mhaberler> but maybe I am overlooking a good reason why the joint mode planner is actually needed
[14:35:34] <mhaberler> this is btw exactly what deltatau does in the motion controllers, they call the switchable kins 'coordinate systems' but thats the same idea
[14:36:39] <mhaberler> if the condition is: paused and synced, one should be able to switch kins back and forth, even back with the return move
[14:36:53] <cradek> I don't understand what you mean by switching kins
[14:37:12] <mhaberler> right now kinematics is a singleton, setup time
[14:37:13] <cradek> by jog styles, I meant: continuous, incremental, wheel
[14:37:27] <mhaberler> assume say a puma robot, which is non-trivkins
[14:37:37] <mhaberler> joint jogging is defacto trivkins
[14:37:55] <mhaberler> ahso, thats something completely different then
[14:37:58] <cradek> well joint jogging does not use kins at all
[14:38:08] <mhaberler> right, identity
[14:38:20] <eliezer> Spanish speaking channel
[14:38:32] <alex_joni> cradek: I think mhaberler is talking principle (not current implementation)
[14:38:38] <mhaberler> right
[14:38:47] <alex_joni> if you would have a trivkins setup on a puma robot
[14:38:52] <alex_joni> and you do world joggin
[14:39:05] <alex_joni> it's basicly like a regular joint jogging on a non-trivkins machine
[14:39:09] <mhaberler> right
[14:39:13] <eliezer> and you do world joggin
[14:39:13] <micges> eliezer: this is english channel
[14:39:40] <mhaberler> but then that was a different theme, so lets look at current jog modes
[14:39:54] <eliezer> yes but want a channel on cnc Spanish speaking
[14:39:55] <alex_joni> mhaberler: but still you have some issues to take care of
[14:40:05] <alex_joni> eliezer: ask in #linuxcnc
[14:40:06] <mhaberler> I do assume so, yes ;)
[14:40:13] <alex_joni> scaling and whatnot
[14:40:43] <eliezer> thanks :D
[14:40:56] <mhaberler> now I assume cradeks point was to integrated the jogging functions of this patch with the motion jog commands being passed down, right?
[14:41:34] <cradek> yes, my interest is in getting continuous, incremental, and wheel jogs while paused, in a way that doesn't require a new kind of jogging through a special vcp panel or whatnot
[14:41:36] <mhaberler> right now this is a hal-only affair
[14:42:16] <cradek> the motion part you've done is useful. remaining are probably the task parts and all the UIs' parts :-/
[14:42:45] <cradek> and stirring it together with ja3 -- I don't know how much extra difficulty that makes
[14:42:49] <mhaberler> hm. lets see - otoh it doesnt look all that wild to integrate the motcommands
[14:43:55] <cradek> if you never switch out of world mode, you don't have to worry about resyncing kins (beware that joint mode jog while paused is totally impossible in a inverse-kins-only setup)
[14:44:10] <cradek> so is it your intent that this would be world mode only?
[14:44:22] <mhaberler> I guess so
[14:44:55] <alex_joni> I think the way around this is to be able to save a canon state
[14:45:05] <mhaberler> I would think jog commands can be applied only a) if paused b) this coord mode jogger is enabled
[14:45:06] <alex_joni> so you can do an abort, and resume with the same state
[14:45:26] <alex_joni> than during the "pause" (really program abort) you can do whatever
[14:45:43] <cradek> well that's another question
[14:45:58] <mhaberler> in which case the jog commands from 'above' would drive the target position of the jogger
[14:46:03] <cradek> right now you expect the machine to go back to the original coordinates, then you swap back to the original planner, then resume -- right?
[14:46:21] <mhaberler> yes
[14:46:30] <cradek> people sure do want to change offsets, which breaks all those assumptions
[14:46:31] <mhaberler> there is an automatic return move
[14:47:05] <cradek> yes I understand the return move is what makes it possible to restore (make true again) the old planner's state
[14:47:14] <mhaberler> I dont think that can be realistically done with the current locus of offset application
[14:47:18] <cradek> I agree with you
[14:47:35] <mhaberler> that be serious mission creep
[14:47:49] <cradek> well nobody's really stated a mission :-)
[14:48:06] <andypugh> We are too fond of the queue. It isn't saced and can be recalculated at the drop of a hat.
[14:48:10] <mhaberler> we can likely do that once offset application has moved to motion
[14:48:14] <cradek> "fix the jog-while-paused things people complain about over the years" haha
[14:48:29] <alex_joni> andypugh: not that easily (imagine loops and whatnot)
[14:48:35] <cradek> yeah I agree with you - I think that's the only way to proceed
[14:48:57] <cradek> unfortunately (because it's big)
[14:49:39] <cradek> but I wonder if andypugh is on to a different approach
[14:50:04] <mhaberler> what he's up to ?
[14:50:13] <mhaberler> a, there he is
[14:50:14] <cradek> I haven't thought it through (yes you have to back up program execution but so what - keep the state around)
[14:51:20] <mhaberler> an idea which came out of the messaging work:
[14:52:22] <andypugh> Don't look at me. I just imagine inserting a synthetic point into the motion planner somewhere and carrying on. Loops are tricky, but if you kept the variables and state wouldn't it just work?
[14:53:34] <alex_joni> andypugh: unless you change offsets during the pause
[14:53:41] <cradek> or diameter
[14:53:44] <alex_joni> right
[14:53:51] <cradek> that's another "over the years" type problem
[14:53:55] <mhaberler> note there is no good reason that an RT comp must exclusively exist of RT thread functions; there are several examples of what I'd call 'cooperative components' which have a userland and a RT part (sampler, streamer - but without decent hal support); I would think moving the command handler to a bona-fide userland comp (even python is thinkable) would enable such stunts - like recalculating on the fly without being confined to the
[14:53:57] <mhaberler> environment
[14:54:33] <mhaberler> but that is blue sky
[14:54:36] <alex_joni> then the question is: do you rerun the previous program part with the new diameter and end up with a new endpoint? or do you just apply the new diameter/whatever from now on
[14:54:53] <cradek> but you'd still need something like motion that accepts something like moves and plans them
[14:55:54] <cradek> if we move offsetting and even diameter, motion might have simpler/fewer/more messages but you still need something a lot like motion
[14:56:03] <mhaberler> I would think a realistic goal is to integrate jogging commands into this branch; and it addresses some needs
[14:56:23] <andypugh> You store the pose at the instant that the button is pressed. Than add a G0 XYZABCUVW to the interpreter, then re-start the interpreter?
[14:56:45] <mhaberler> guess what you need for that: switchable motion queues
[14:56:47] <cradek> and then you continue your arc how?
[14:57:12] <mhaberler> this isnt a realistic goal in this context
[14:57:14] <linuxcnc-build> build #1337 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1337 blamelist: Michael Haberler <git@mah.priv.at>
[14:57:41] <mhaberler> integrate with jog commands is
[14:57:54] <andypugh> cradek: Well, it serves you right if you insist on relative centre arcs. It's no problem with absolute or R format arcs. :-)
[14:58:29] <mhaberler> cradek: nml jog commands.. do they pass target position only or are there velocity variants?
[14:58:47] <cradek> depends on whether you're talking about ja3 or not
[14:58:50] <mhaberler> afaict its joint and distance, or joint and direction, right?
[14:59:12] <mhaberler> what will change?
[14:59:28] <cradek> non-ja3 in kins mode uses velocity vector, but that is going away
[15:00:15] <mhaberler> ok, assuming ja3 happens we better plan for that then
[15:00:40] <mhaberler> meaning: target pose and vel?
[15:00:42] <cradek> I believe ja3 uses (joint OR axis number) AND (continuous direction OR target position)
[15:01:06] <cradek> spread into various message types in various modes etc, of course
[15:01:26] <cradek> uh ... OR wheel increment
[15:01:27] <andypugh> cradek: The glib answer is that you would need to store the arc centre too if you paused in an arc, and then modify the command to suit. Which makes arcs a special case. And then it is anyone's guess how many more special cases there are.
[15:01:38] <mhaberler> wheel increment is a pose
[15:02:01] <cradek> yes it's very much like the new target position type of jog
[15:02:11] <cradek> (like incremental)
[15:02:45] <mhaberler> so question 1: do we need joint mode jogging at all during pause
[15:03:10] <cradek> I hope that answer is no, since inverse-kins-only machines will not be able to do it
[15:03:37] <mhaberler> excellent excuse to drop the idea
[15:03:43] <cradek> heh I like that approach
[15:04:19] <cradek> (I am not sure how well IKO works in ja3 - I have not tested it)
[15:04:32] <cradek> in theory it's supported, but it might currently be buggy
[15:04:33] <cradek> an aside
[15:05:23] <mhaberler> I'm not afraid feeding jog commands into this code, but UI mode hell makes me hesitant..
[15:06:07] <cradek> yes I think UI and task modes are the hard part of this -- well that and not requiring the move back to the original position
[15:07:04] <mhaberler> that would suggest these jog commands can be honored in what is currently teleop mode, right?
[15:07:21] <cradek> yes I think so
[15:07:43] <mhaberler> now lets see what that does to a UI
[15:07:46] <mhaberler> pause
[15:07:57] <mhaberler> that would mean teleop jogging now be enabled
[15:08:13] <mhaberler> or really coord mode moves posing as teleop
[15:08:57] <cradek> I think that's pretty much how world mode jogs currently work in ja3
[15:09:15] <cradek> just issue a line move
[15:09:35] <cradek> (with the target the edge of world space)
[15:09:47] <cradek> and you might abort it later
[15:09:58] <mhaberler> or scale the target
[15:10:13] <cradek> ?
[15:10:37] <mhaberler> well if the target is outside world space, prune the vector to the intersection point
[15:10:47] <mhaberler> so it'd stop there
[15:10:48] <cradek> sure
[15:11:02] <cradek> world limits are a cube, so it's trivial
[15:11:23] <cradek> well a 9d "cube" haha
[15:11:37] <alex_joni> although for nontriv machines the cube is pretty moot
[15:11:45] <alex_joni> even if it's 9d
[15:11:56] <mhaberler> making the code react to incrementals isnt hard, but testing without goint through the whole task mode mess is going to be a challenge
[15:11:57] <cradek> well world limits are currently a 9d cube for all machines
[15:12:21] <alex_joni> cradek: I know.. was just saying that for nontrivkins that is incorrect and/or limiting
[15:12:27] <cradek> sure
[15:12:37] <alex_joni> so it's not something to use for jogging
[15:12:47] <cradek> sure it is :-)
[15:12:52] <alex_joni> the infinity end sounds safer
[15:13:06] <cradek> this is a separate issue!
[15:13:13] <mhaberler> question 2: how do we communicate at pause time to the UI (&task) that coord mode jogging is now possible
[15:13:31] <alex_joni> UI assumes it?
[15:13:39] <cradek> you "just" change the UIs to let the user jog when it's paused
[15:13:53] <cradek> and then you change task to not give an error when they do that
[15:13:57] <mhaberler> in the current scheme I would think a field in emcstat be on order
[15:14:13] <cradek> you don't have to communicate things that are always the same
[15:14:29] <cradek> what case are you picturing where it's not allowed?
[15:14:39] <mhaberler> point taken
[15:15:01] <mhaberler> there's this gazillion overrides..
[15:15:27] <mhaberler> thats what made me think of it - assuming its safe might be stretching it a bit
[15:16:05] <cradek> brb
[15:16:33] <mhaberler> re testing: with the linuxcnc module it should be possible, provided task wont trample on the command, but that can be fixed
[15:16:33] <alex_joni> mhaberler: lets first say it's always safe, and limit it later if needed
[15:17:01] <mhaberler> two fingers less later, community opinion converges on the view it wasnt ;)
[15:18:22] <alex_joni> :D
[15:21:23] <alex_joni> so back to possible approaches:
[15:21:28] <alex_joni> 1. switchable queues
[15:21:34] <mhaberler> next question: is this a 'mode' or is it just 'coord and paused' (and why dont we world jog in coord - it seems to me because of coord mode being married to auto)
[15:21:55] <alex_joni> 2. when pausing: remember state, abort, permit mostly anything, resume state, resume
[15:22:19] <alex_joni> I think in ja3 we only world jog
[15:22:44] <mhaberler> more or less; currently restrained to coord mode because mode switching is heavy handed, I think flushes queue
[15:23:00] <alex_joni> except when switching to joint mode, which isnt possible on a trivkins machine
[15:23:13] <mhaberler> a mode switch is pretty much like an abort
[15:23:49] <mhaberler> but a mode switch may not be needed, its just that jogging is restrained to coord mode
[15:24:22] <mhaberler> right, 2) is what the patch does
[15:24:38] <mhaberler> plus switch to alternate queue
[15:24:56] <mhaberler> resume switches back to primary queue after reentry move
[15:25:16] <KGB-linuxcnc> 03andy 05v2.5_branch 25f1203 06linuxcnc 10src/hal/components/ 03bin2gray.comp 03gray2bin.comp
[15:25:16] <KGB-linuxcnc> Add a couple of HAL components to convert to and from Gray code
[15:25:16] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[15:26:10] <mhaberler> the cleaner solution would be have switchable queues go back all the way to switchable interps, but then this is a dog to do in the current setup, all singletons
[15:27:07] <mhaberler> I would think the experiment boils down to: make coord mode jog react to jog commands and provide a path for UI's to 'get them through'
[15:27:38] <alex_joni> but that still leaves wheel jogs out
[15:27:50] <alex_joni> as those are directly in motion
[15:27:54] <alex_joni> hmm.. or maybe not
[15:27:59] <mhaberler> I never looked at those, how do they differ?
[15:28:05] <JT-Shop> wheel jog as in MPG?
[15:29:11] <mhaberler> well that be easy to tack onto provided axis==joints
[15:29:19] <mhaberler> strike out condition, this one is easy
[15:29:42] <mhaberler> it mutates into generating vectors
[15:29:59] <mhaberler> actually that be the low hanging fruit
[15:30:36] <mhaberler> the commanded jogs are more involved
[15:31:10] <mhaberler> vel-mode needs thinking
[15:31:27] <mhaberler> jog-vel-mode I meant
[15:31:48] <linuxcnc-build> build #1340 of lucid-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-i386-sim/builds/1340 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:33:03] <mhaberler> now the $100 question: which jog mode is wheel jog in?
[15:33:15] <mhaberler> joint or world?
[15:33:59] <alex_joni> currently world
[15:34:14] <alex_joni> errr.. currently it only works in non-ja3
[15:34:25] <alex_joni> where it should be world, but acts on joints
[15:34:27] <mhaberler> oh.
[15:34:28] <linuxcnc-build> build #1341 of precise-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-i386-sim/builds/1341 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:34:37] <cradek> alex_joni: no, it's currently joint
[15:34:41] <cradek> it should work in both modes
[15:34:49] <cradek> that is what micges is going to fix (yay)
[15:34:57] <linuxcnc-build> build #1343 of precise-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim/builds/1343 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:35:03] <alex_joni> yeah, I meant joint.. sorry
[15:35:06] <andypugh> What the hell?
[15:35:13] <jepler> it looks like andy's good deed is not going unpunished
[15:35:22] <andypugh> That was 23 lines of .comp that compiles for me.
[15:35:24] <jepler> hal/components/gray2bin.comp:9:1: error: unknown type name ‘u32’
[15:35:39] <jepler> oh it's the good old "nobody knows what to call the fixed-width types" problem
[15:35:50] <jepler> in which the kernel provides one set of attractive names that userspace does not
[15:35:51] <alex_joni> mhaberler: those get only fed via HAL into motion
[15:35:59] <andypugh> Ah, being compiled for sim..
[15:36:04] <andypugh> I can fix that.
[15:36:07] <mhaberler> sure, thats why it would be easy
[15:36:14] <mhaberler> for world mode
[15:36:32] <mhaberler> but since above we decided to drop joint jog.. well here goes
[15:36:33] <andypugh> I forgot to switch to a sim config to check it still compiled :-(
[15:36:43] <linuxcnc-build> build #1343 of lucid-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1343 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:36:48] <cradek> you mean drop the idea of joint jog while paused, right?
[15:36:53] <linuxcnc-build> build #1344 of hardy-amd64-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-amd64-sim/builds/1344 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:36:55] <mhaberler> right
[15:37:17] <cradek> (I'm sure itching to merge ja3)
[15:37:39] <mhaberler> is there sufficient cracking the whip on micges?
[15:37:41] <linuxcnc-build> build #1342 of hardy-i386-sim is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/hardy-i386-sim/builds/1342 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:38:19] <mhaberler> so step #1 would be to get jog wheel to work in world mode while paused
[15:38:52] <cradek> did we decide whether it's ok to require a return move? I'd sure prefer not
[15:39:11] <mhaberler> step#2 is to coerce UI/task/upper motion half to pass down jog commands
[15:39:22] <cradek> if we build in that requirement/assumption we tie our hands about offsets
[15:39:28] <mhaberler> well what you do if you resume and not inpos?
[15:39:38] <cradek> I agree that's the question
[15:40:03] <cradek> I see answering it as step #1
[15:40:17] <mhaberler> it might be dependent on where the resume comes from
[15:40:22] <cradek> assuming our real long-term goal is to allow changing offsets and diameter while paused, and I think it ought to be
[15:40:24] <mhaberler> right now its hal only
[15:40:40] <cradek> well at least offsets, maybe not diameter
[15:40:43] <mhaberler> (postpone for a sec)
[15:40:48] <cradek> offsets are the critical one
[15:40:59] <andypugh> I see it as the operators job to ensure that a rapid to the point where pause was pressed is safe. And I will be buying shares in the Isreli carbide mines.
[15:41:02] <mhaberler> in the future you would have resume from 'above' and from hal
[15:41:19] <cradek> I don't understand what you mean by resume from hal
[15:41:30] <mhaberler> hm
[15:41:31] <cradek> pause and resume are UI idioms
[15:41:43] <mhaberler> right, this was nonsense
[15:42:23] <mhaberler> what you can do is parcel out a 'return to paused pos' command
[15:42:41] <linuxcnc-build> build #1139 of precise-amd64-sim-clang is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/precise-amd64-sim-clang/builds/1139 blamelist: Andy Pugh <andy@bodgesoc.org>
[15:43:02] <mhaberler> then it'd be explicit from the ui or task for that matter
[15:43:28] <mhaberler> right now this is implicit in resume, but need not be
[15:43:41] <cradek> yes return to pause position might be a very useful ability to have BUT I think it would be wrong to require it for resume
[15:43:58] <cradek> welllll
[15:44:05] <cradek> let me be more precise
[15:44:14] <cradek> you don't want to have to restore the original axis positions
[15:44:39] <cradek> you might be able to always restore the original tooltip vs workpiece position (i.e. axis positions could change because an offset changed)
[15:44:56] <mhaberler> ah, I see
[15:45:03] <cradek> yes I think that's really the ticket
[15:45:18] <cradek> then you can continue your arc or whatever it was
[15:45:19] <mhaberler> well then the resume move has to move 'up' towards task/UI
[15:45:46] <cradek> and/or all offsets have to move??
[15:45:52] <cradek> grind grind grind
[15:46:14] <mhaberler> that is one step too early, offsets in motion first
[15:46:27] <KGB-linuxcnc> 03andy 05v2.5_branch b1ec930 06linuxcnc 10src/hal/components/gray2bin.comp
[15:46:27] <KGB-linuxcnc> I forgot that sim has no idea what an unsigned int is.
[15:46:27] <KGB-linuxcnc> Luckily I don't actually care if I end up with 64 bits.
[15:46:27] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[15:47:31] <mhaberler> but splitting into primitives certainly makes sense
[15:48:06] <cradek> I'm struggling to see how offsets can work in our brave new world
[15:48:37] <cradek> remember position must not jump - offsets aren't applied all at once
[15:48:51] <mhaberler> they have to be static during a run on the interp side, and be applied only in motion
[15:49:05] <alex_joni> cradek: but what you had left of the queue is surely not ok anymore, that needs to get recomputed
[15:49:18] <mhaberler> not if the queue is relative
[15:49:25] <mhaberler> to offset
[15:49:34] <alex_joni> right, if it's relative then it shouldn't
[15:49:35] <mhaberler> (doesnt apply to crc)
[15:50:00] <mhaberler> thats what I'm saying, somebody take on moving offset application to motion
[15:50:13] <mhaberler> and queue all be relative to current offset
[15:50:21] <alex_joni> that complicates some bits
[15:50:24] <mhaberler> (including tool)
[15:50:26] <cradek> (another aside: I think the crc thing is easy: don't queue past G41/42 and always reread the tool table when you hit them)
[15:50:45] <alex_joni> (like check extents and such)
[15:51:05] <mhaberler> yes, limits check has to move too
[15:51:22] <alex_joni> but you can't check limits in realtime
[15:51:33] <alex_joni> you have to do it in advance (before issuing a mdi for example)
[15:51:34] <mhaberler> thats what I referred to by cooperative comps
[15:51:43] <cradek> mhaberler: consider g92 x3 y3 (no motion occurs) / g0 x0 (only X moves, -3 units) / g0 y0 (now only Y moves, and only now have you fully applied the offset)
[15:52:05] <cradek> I don't think the queue can be relative to the offsets for this reason
[15:52:23] <mhaberler> well retaining these types of commands will render it impossible, you'll need to tick a box eventually
[15:53:06] <cradek> if that was in response to me, I don't understand
[15:53:07] <mhaberler> freezing offsets at start of run except tool?
[15:53:23] <mhaberler> maybe current system
[15:53:26] <andypugh> pcw_home: Do you think it seems reasonable to limit BiSS to 96 bits until someone complains that they need more?
[15:54:03] <cradek> tool offsets don't apply all at once either. it is no different, I think
[15:55:19] <mhaberler> anyway, realistically I think we can prepare for postponed offset application, but doing this within the context of this patch is out of what I consider its scope
[15:55:22] <cradek> maybe it's just that the queue needs to also contain what axes should move
[15:55:44] <mhaberler> reacting to UI and wheel jog commands is in scope imo
[15:56:28] <mhaberler> (that is why I have to pose types in the protobuf scheme - classic and with null values; i.e. dont move)
[15:57:11] <mhaberler> we need to nail a doable scope for this - doable being within release timeframe and without rocking the boar
[15:57:13] <mhaberler> boat
[15:57:18] <cradek> yes I think if you can have NULL axis position commands, you can have a relative-to-offset queue ..... I think
[15:57:31] <mhaberler> boar.. possibly applicable too ;)
[15:58:13] <cradek> this feels way too big to also hope to get in 2.6 but I would love to be proved wrong
[15:58:26] <cradek> 2.6 is such a lofty goal already
[15:58:42] <mhaberler> well maybe you're too ambitious - some folks are happy with what is there
[15:59:03] <mhaberler> as long as it doesnt block further developments, an incremental step is fine
[15:59:04] <alex_joni> I'd love 2.6 to be ready for 14.04
[15:59:18] <alex_joni> so we can get a new livecd maybe with xenomai
[15:59:26] <cradek> they can certainly continue to use it!
[16:00:19] <mhaberler> I would suggest to prune the goal down to a) integrate with wheel jog b) commanded teleop jogs
[16:00:50] <mhaberler> that is already lots more than the folks ask
[16:01:05] <cradek> well to be fair, I don't know what they're asking
[16:01:14] <cradek> I know what people have asked for over the years
[16:01:50] <mhaberler> do _anything_ user driven during pause instead of being locked inpos is an improvement, but it is a valid question to ask them
[16:02:12] <cradek> and they have that, by running your branch
[16:02:31] <mhaberler> right, a few seem to actually do that
[16:02:48] <cradek> putting that and ja3 together is another story
[16:02:52] <mhaberler> which explains my uneasy feeling
[16:03:20] <cradek> explain please?
[16:03:59] <mhaberler> well I dont like folks running machines off some unmerged branch (now 13 months old)
[16:04:26] <mhaberler> I dont want to be dragged into supporting something with unclear future
[16:04:37] <cradek> understandable (I feel that way about ja3 but it's more like 5 years)
[16:04:52] <cradek> yes also understandable
[16:05:31] <mhaberler> smoke test #0 could be to rebase that branch on ja3
[16:05:38] <cradek> also if it's a false start that is not in the ultimate direction we need, it can be harmful to merge it -- and I feel that way about it for the reasons I explained
[16:05:55] <cradek> the swapping-planners part might end up being useful, but that seems like a tiny part of it
[16:06:35] <mhaberler> no, thats way out, I misunderstood your intent
[16:07:05] <cradek> what's way out?
[16:07:31] <mhaberler> well switchable kins in a single planner - that affects all the modal hell in task/UI
[16:07:58] <mhaberler> and for that particular issue theres no upside
[16:08:51] <cradek> I was talking about switchable planners, my understanding of how your current branch works (which is only a fancy way of having a one-deep stack of saved planner state)
[16:09:05] <mhaberler> right
[16:09:29] <cradek> that idea may be valuable for part of solving the big problem
[16:09:31] <mhaberler> thinking about generalizing a moment:
[16:09:51] <mhaberler> (note I will not touch this as long as nml is here)
[16:10:21] <mhaberler> there should be a way to address separate queues, and tie them to different sources (maybe interps)
[16:10:48] <mhaberler> but you cant to separate interp instances without butchering task thanks to the _setup static
[16:10:58] <mhaberler> besides the separate queue work
[16:11:03] <linuxcnc-build> build #1338 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1338 blamelist: Andy Pugh <andy@bodgesoc.org>
[16:11:08] <mhaberler> so it doesnt make much sense right now
[16:11:39] <cradek> sorry, I think this is too general for me to see how it applies to the goals we're discussing
[16:11:48] <mhaberler> absolutel
[16:11:53] <mhaberler> y
[16:12:27] <mhaberler> all I'm saying is the single alternate mini-queue is a concept generalizing - eventually, not now
[16:13:21] <mhaberler> but to make full use of such a capability you run into other issues like the one interp instance per process issue, thats all
[16:13:35] <mhaberler> lets agree this is blue sky
[16:14:05] <cradek> I'm too nearsighted to see the sky in its full glory
[16:14:27] <mhaberler> but I wouldnt be overambitious on that jog-while-paused request, I think decent jog support will find use without offsets changing
[16:14:36] <cradek> I think we've got a problem of modal assumptions, and offsets being in the wrong places
[16:14:51] <cradek> possibly you are right
[16:15:17] <cradek> if we have continuous/incremental/wheel jogs allowed while paused WITH the [axis position] return move requirement still in place, that might be something mergable in the short term
[16:15:42] <cradek> I think it's pretty limited usefulness though, without the ability to change offsets
[16:16:06] <mhaberler> its a realistic step
[16:16:07] <cradek> I think the long term goal would be to have a [perhaps newly-offset world position] return move be the required thing
[16:16:57] <mhaberler> well if we move the 'return move requirement' 'upwards' (into task/UI) this is going to have much more immediate impact
[16:17:17] <cradek> yes it's a big step to get all that modal and UI stuff sorted out AND that is required for the big goal
[16:17:26] <cradek> so it's totally a useful and realistic step
[16:17:37] <mhaberler> I agree it should, but I dont want to empty the bugtracker post factum
[16:17:55] <cradek> I'm really with you as far as seeing it as two separate projects now
[16:18:56] <mhaberler> fine, well in that case I'll look into the jogwheel/jog command issue, and it'd be great if you could give it second pair of eyes
[16:19:24] <mhaberler> would you think rebasing on ja3 is first?
[16:19:54] <cradek> yes it would be crazy to work with pre-ja3 teleop's velocity vector garbage
[16:20:18] <mhaberler> ok, so I'll make that step 1, then jog wheel, then commanded jogs
[16:20:27] <cradek> awesome
[16:20:35] <mhaberler> excellent, very good result
[16:20:36] <cradek> maybe micges will make progress on world mode wheel jogging too
[16:20:59] <mhaberler> ah, prodding micges, favorite pastime
[16:21:01] <cradek> seems like you'll have to depend on that
[16:21:20] <mhaberler> yes, it seems
[16:21:24] <cradek> I have to run
[16:21:26] <cradek> thanks mhaberler
[16:21:32] <mhaberler> fair enough, excellent!
[16:21:34] <mhaberler> cu
[16:22:27] <mhaberler> I'll summarize for the list if thats ok for you
[16:22:40] <mhaberler> since they are banging the gates
[23:36:04] <KGB-linuxcnc> 03nieson 05master bd446ad 06linuxcnc 04configs/sim/gmoccapy/gmoccapy.glade.h * gmoccapy h file gelöscht
[23:36:04] <KGB-linuxcnc> 03chrisinnanaimo 05master 43cbab2 06linuxcnc 10share/ 10(11 files in 7 dirs) * gmoccapy_0_9_7_4 - modified some locale and release notes