Back
[00:00:04] <andypugh> And I guess you have considered the possibility that you are already the world expert in rtnet?
[00:02:42] <micges> hah
[00:02:49] -!- Nick001-shop has quit [Quit: ChatZilla 0.9.90.1 [Firefox 23.0.1/20130814063812]]
[00:03:39] <micges> only if it were little more pleasant to dig in into rtai :)
[00:04:43] -!- koopee has quit [Ping timeout: 260 seconds]
[00:05:29] <andypugh> I think you need to get some interaction with PCW. It is entirely possible that the 7i80 is sending garbage.
[00:05:58] <micges> no
[00:06:13] <micges> INIT led indicated that garbage is sended into 7i80
[00:06:48] <micges> under rtai, even if it work under xenomai
[00:09:11] <andypugh> Well, hopefully running a Xenomai config won't be a problem in the next release
[00:10:09] <micges> seems so, ub is working quite well
[00:14:16] <andypugh> I winder when we will reach the cut-off for 2.6?
[00:15:34] <micges> there is no plan
[00:15:58] <andypugh> I think there is possibly a bit of a plan.
[00:16:14] <micges> and I also need fix ja3 teleop wheel jogging
[00:16:58] <andypugh> I have decided that my tooltable stuff is 2.7.
[00:17:31] <andypugh> But I have also decided that your ja3 jogging is 2.6. SOrry you couldn't make the meeting. :-)
[00:18:18] <andypugh> (More seriously, it would be nice to have wheel jogging if Ja3 is going mainline)
[00:19:03] <micges> it will
[00:19:04] <andypugh> And I do already have a branch that supports infinite tools, perhaps I ought to see if I can make a stabe half-ay-house
[00:19:24] <micges> ja3 is going into master
[00:20:23] <micges> what is your tooltable work?
[00:30:25] -!- joebog has quit [Ping timeout: 250 seconds]
[00:34:45] <andypugh> The tool table as a database. Rather than being inside an NML message, anything that wants to know about a tool queries a database.
[00:35:49] <andypugh> We need a lot more queue-busting, but frankly the current code is far too unwilling to throw away the motion queue.
[00:38:08] <andypugh> It is an idea that grew in scope, but the current structure supports a whole-factory database, with machines aware of what tools they have available, and they might choose any of a dozen 8mm end mills that exist in the database. (and will use the wear offset that was applied by the operator when it was on a completely different machine)
[00:38:37] <micges> nice
[00:39:38] <andypugh> it does mean that I end up moving nearly all of iocontrol into user-configurable userspace HAL modules.
[00:40:17] <andypugh> So, there is a lot of work to be done to create a robust default system that emulates the status-quo.
[00:42:17] <andypugh> I had a few months off actually working with machines, and then reconfigured my build-environment (git repo on the Mac, not the DN2800) and decided to take on a simple HAL module job to get back in to coding and to iron out the environment bugs. But the HAL module (serial encoders) has grown and grown.
[00:43:12] <micges> hah, simple :)
[00:43:47] <micges> what hardware do you have to test?
[00:43:50] <andypugh> Tonight I have been working on the Phase-locked-loop that Pete invented to pre-trigger the serial encoders so that the data is as current as possible when read.
[00:44:14] <andypugh> I have an SSI laser rangefinder. :-)
[00:45:02] <andypugh> 140m range, 1mm resolution. But it was the cheapest SSI device on eBay that day (£50)
[00:45:45] <andypugh> I can't think of any use for it when I have finshed, though.
[00:48:04] <micges> sell on ebay :)
[00:48:17] <micges> for 45
[00:48:44] <micges> btw I've setup 7i76E board
[00:49:11] <micges> minor changes to mesaflash and driver (names only)
[00:49:34] <micges> can't wait for 7i77E :)
[00:54:22] -!- asdfasd has quit [Ping timeout: 256 seconds]
[00:56:38] -!- sumpfralle has quit [Ping timeout: 240 seconds]
[01:03:23] -!- syyl-- has quit [Ping timeout: 248 seconds]
[01:03:42] -!- sirdancealot has quit [Ping timeout: 264 seconds]
[01:06:35] -!- theorbtwo has quit [Ping timeout: 248 seconds]
[01:14:22] -!- Cylly has quit [Read error: Connection reset by peer]
[01:17:59] -!- jfire1 has quit [Client Quit]
[01:19:17] -!- c-bob has quit [Read error: Operation timed out]
[01:20:51] -!- jfire has quit [Ping timeout: 260 seconds]
[01:23:54] -!- geografa has quit [Quit: Computer has gone to sleep.]
[01:31:04] -!- c-bob has quit [Ping timeout: 264 seconds]
[01:31:46] -!- syyl has quit [Ping timeout: 256 seconds]
[01:38:46] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[01:48:10] toastydeath is now known as monoprizzle
[02:30:37] -!- AR_ has quit [Ping timeout: 240 seconds]
[02:56:40] -!- geografa has quit [Quit: Computer has gone to sleep.]
[02:57:23] -!- Valen has quit [Quit: Leaving.]
[02:58:44] -!- louis__ has quit [Ping timeout: 256 seconds]
[03:25:31] -!- micges has quit [Quit: Leaving]
[03:26:14] -!- jfire has quit [Quit: Leaving.]
[03:26:37] -!- geografa has quit [Quit: Textual IRC Client: www.textualapp.com]
[03:34:00] -!- andypugh has quit [Quit: andypugh]
[03:47:12] -!- FinboySlick has quit [Quit: Leaving.]
[03:53:32] -!- krusty_ar_ has quit [Ping timeout: 268 seconds]
[04:08:19] -!- krusty_ar has quit [Ping timeout: 260 seconds]
[04:16:22] -!- flippyhead has quit [Quit: flippyhead]
[04:19:56] -!- jfire has quit [Quit: Leaving.]
[04:20:40] -!- ve7it has quit [Remote host closed the connection]
[04:23:08] -!- krusty_ar has quit [Ping timeout: 240 seconds]
[04:36:52] -!- ries has quit [Ping timeout: 246 seconds]
[05:03:06] -!- Fox_Muldr has quit [Ping timeout: 264 seconds]
[05:18:38] -!- tjtr33 has quit [Quit: Leaving]
[05:22:56] monoprizzle is now known as toastydeath
[05:28:19] -!- krusty_ar has quit [Ping timeout: 246 seconds]
[05:43:35] -!- krusty_ar has quit [Ping timeout: 260 seconds]
[05:49:34] -!- JT-Shop has quit [Read error: Connection reset by peer]
[05:49:34] -!- jthornton has quit [Read error: Connection reset by peer]
[05:50:58] -!- JT-Shop [JT-Shop!~John@198.45.190.160] has joined #linuxcnc-devel
[05:51:00] -!- jthornton [jthornton!~john@198.45.190.160] has joined #linuxcnc-devel
[05:55:58] -!- mariusl [mariusl!mariusl@105-208-129-10.access.mtnbusiness.co.za] has joined #linuxcnc-devel
[05:56:33] -!- mariusl has quit [Client Quit]
[05:58:35] -!- kwallace2 [kwallace2!~kwallace@smb-223.sonnet.com] has parted #linuxcnc-devel
[05:59:40] c-bob| is now known as c-bob
[06:15:06] -!- toxx has quit [Ping timeout: 264 seconds]
[06:15:42] -!- Laremere has quit [Ping timeout: 264 seconds]
[06:48:46] -!- uw has quit [Ping timeout: 245 seconds]
[06:52:43] -!- krusty_ar_ has quit [Ping timeout: 248 seconds]
[07:02:06] -!- krusty_ar has quit [Ping timeout: 245 seconds]
[07:33:03] -!- pjm has quit [Read error: Connection reset by peer]
[08:08:32] -!- stsydow has quit [Remote host closed the connection]
[08:11:49] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[08:18:31] -!- Jymmm has quit [Read error: Operation timed out]
[08:32:31] -!- false8 has quit [Ping timeout: 245 seconds]
[09:16:26] -!- sweeney has quit [Ping timeout: 264 seconds]
[09:34:36] -!- MacGalempsy has quit [Remote host closed the connection]
[09:36:30] -!- Thetawaves_ has quit [Quit: This computer has gone to sleep]
[09:41:35] Fox_Muldr is now known as Fox_M|afk
[09:55:30] -!- Fox_M|afk has quit [Ping timeout: 240 seconds]
[10:08:47] Fox_M|afk is now known as Fox_Muldr
[10:33:50] -!- skunkworks has quit [Remote host closed the connection]
[10:39:55] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[10:44:52] -!- maximilian_h [maximilian_h!~bonsai@130.255.104.21] has joined #linuxcnc-devel
[11:05:10] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:27:04] -!- false has quit [Ping timeout: 246 seconds]
[11:42:55] -!- KGB-linuxcnc [KGB-linuxcnc!~kgb-linux@git.linuxcnc.org] has joined #linuxcnc-devel
[11:50:35] -!- wangee has quit [Read error: Connection reset by peer]
[11:52:40] Drigo is now known as drigo
[11:53:54] -!- sirdancealot has quit [Remote host closed the connection]
[12:02:32] -!- wangee has quit [Read error: Connection reset by peer]
[12:21:39] -!- md-2 has quit [Remote host closed the connection]
[12:28:20] -!- kjoller has quit [Quit: Nettalk6 - www.ntalk.de]
[12:33:30] -!- wangee has quit [Read error: Connection reset by peer]
[12:38:14] -!- koopee has quit [Ping timeout: 240 seconds]
[12:41:59] -!- wangee has quit [Read error: Connection reset by peer]
[12:47:22] -!- odogono has quit [Quit: odogono]
[13:06:24] <skunkworks> so this is what I should get with ub
http://pastebin.com/E2KzNmWc
[13:06:29] <skunkworks> I assume
[13:07:00] <skunkworks> I forgot I had a rtnet 10.04 hd setup
[13:07:05] -!- archivist_herron has quit [Ping timeout: 245 seconds]
[13:10:35] <skunkworks> (without the new linuxcnc.log setup)
[13:12:21] <skunkworks> but the newer nic did fix my comunication issues..
[13:19:56] -!- automata_ has quit [Ping timeout: 240 seconds]
[13:24:40] -!- syyl- has quit [Ping timeout: 246 seconds]
[13:28:03] -!- skorasaurus has quit [Ping timeout: 256 seconds]
[13:28:16] -!- eric_unterhausen has quit [Ping timeout: 268 seconds]
[13:33:27] -!- kwallace [kwallace!~kwallace@smb-129.sonnet.com] has joined #linuxcnc-devel
[13:47:04] -!- theorbtwo has quit [Remote host closed the connection]
[13:47:04] -!- wangee has quit [Read error: Connection reset by peer]
[13:58:34] -!- wangee_ has quit [Read error: Connection reset by peer]
[14:03:11] -!- NickParker has quit [Ping timeout: 256 seconds]
[14:04:19] -!- AR_ has quit [Ping timeout: 256 seconds]
[14:10:45] <skunkworks> doesn't stderr just ouput in the terminal?
[14:14:51] drigo is now known as drigo_
[14:15:32] drigo_ is now known as drigo
[14:18:56] -!- jthornton has quit [Read error: Connection reset by peer]
[14:18:57] -!- JT-Shop has quit [Read error: Connection reset by peer]
[14:20:24] -!- JT-Shop [JT-Shop!~John@198.45.190.160] has joined #linuxcnc-devel
[14:20:29] -!- jthornton [jthornton!~john@198.45.190.160] has joined #linuxcnc-devel
[14:24:20] <archivist_> skunkworks, unless you put it somewhere else, yes
[14:25:36] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[14:27:16] <skunkworks> hmm
[14:27:36] <skunkworks> then it does't output the data that I can see anywhere
[14:29:21] <archivist_> you can use the pipe to put stderr some other place
[14:30:06] -!- nots has quit [Ping timeout: 264 seconds]
[14:30:39] <archivist_> tricks like grep da * 2> grep-errors.txt
[14:30:51] <archivist_> http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO-3.html
[14:36:28] -!- AR_ has quit [Ping timeout: 264 seconds]
[14:39:27] -!- Simooon has quit [Remote host closed the connection]
[14:41:35] -!- radicalbiscuit has quit [Quit: Juggling geese.]
[14:43:24] -!- kb8wmc [kb8wmc!~chatzilla@64.25.194.29] has joined #linuxcnc-devel
[14:53:28] -!- stsydow has quit [Remote host closed the connection]
[15:01:26] <skunkworks> This is what I get out of terminal
http://pastebin.ca/2434246?srch=7i80
[15:02:51] <jepler> I think the problem is that it was creating too much debug output from a realtime context
[15:03:00] <jepler> that buffer of only 32768 bytes got full
[15:03:08] <jepler> but you tried increasing the size and it flaked out, so I dunno what to do
[15:03:14] <skunkworks> heh
[15:03:25] <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
[15:03:34] <skunkworks> I will try
[15:18:04] <skunkworks> http://pastebin.com/yyKd0MPN
[15:18:05] -!- cevad has quit [Quit: Leaving]
[15:18:29] <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
[15:18:47] <skunkworks> can I increase the shm size?
[15:20:26] * skunkworks starts down the rabit hole
[15:28:25] <KGB-linuxcnc> 03seb 05vfd-b-2 c25ed82 06linuxcnc 10docs/man/man1/vfdb_vfd.1 * vfd-b: improve manpage (still have a ways to go)
[15:35:33] <cradek> is that a new driver?
[15:38:21] -!- Laremere has quit [Ping timeout: 245 seconds]
[15:40:39] <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..
[15:40:50] <skunkworks> oh - I can do that
[15:40:51] -!- mhaberler [mhaberler!~mhaberler@macbook.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[15:41:27] <mhaberler> hi.. back in coverage
[15:41:34] <jepler> mhaberler: welcome
[15:41:41] -!- b_b has quit [Changing host]
[15:41:52] <skunkworks> mhaberler, Good vacation?
[15:41:57] <mhaberler> mountain time, julian alps
[15:42:28] <skunkworks> nice
[15:42:43] <mhaberler> anyway.. where were we.. licensing methinks..
[15:43:20] <skunkworks> mhaberler, I have a couple of questions...
[15:43:24] <skunkworks> :)
[15:43:34] <mhaberler> uh.. go ahead
[15:43:42] <skunkworks> I am missing output it seems going to linuxcnc.log
[15:44:14] <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
[15:44:27] <mhaberler> you can resize it to any power of 2
[15:44:31] <KGB-linuxcnc> 03seb 05vfd-b-2 e4dc088 06linuxcnc 10docs/man/man1/vfdb_vfd.1 * vfd-b: add a quick-start section to the manpage
[15:45:02] <skunkworks> oh - ok - let me try that.
[15:45:02] <mhaberler> actually I made it small so I could test the adaptive rate polling.. well.
[15:45:05] <seb_kuzminsky> cradek: that's the driver that yishin li wrote to talk to the Delta VFD-B
[15:45:28] <mhaberler> just make it (1024*1024) or so
[15:45:29] <seb_kuzminsky> i'm helping a friend bring up a new CNC machine with that vfd on the spindle
[15:45:57] <mhaberler> anything else?
[15:48:23] -!- syyl-- has quit [Ping timeout: 260 seconds]
[15:48:41] <mhaberler> but I didnt think of the mass of output the hostmot2 driver generates with the pin lists, and that all happens pretty fast
[15:48:58] <skunkworks> not at the moment.. mhaberler I did get your 7i80 branch working - it ended up being the pro/100 card I was using
[15:49:00] <mhaberler> skunksworks: did you see by any chance on shutdown in the log a line like this:
[15:49:18] <mhaberler> "msgd:%d: message ring stats: full=%d locked=%d " and some int instead of %d ?
[15:49:28] <mhaberler> oh, excellent
[15:49:52] <mhaberler> what was unclear to me is if the rtnet patches leave the normal PCI hm2 working ok or not
[15:50:14] <skunkworks> mhaberler, this is what I was getting..
[15:50:15] <skunkworks> http://pastebin.com/Z1iuvW8W
[15:50:17] <mhaberler> in a cursory attempt, that branch failed for me with a 5i25, so it looked like either-or
[15:50:38] -!- Daeron has quit [Ping timeout: 264 seconds]
[15:50:40] <mhaberler> nothing more thereafter?
[15:50:56] <skunkworks> nope
[15:51:01] <mhaberler> that message is a canary at shutdown only
[15:51:56] <mhaberler> ok, I guess we need to prod micges or some other heroic coder with a 7i80 into making it coexist with hm2 pci
[15:52:06] <skunkworks> jepler, make clean did seem to fix that..
[15:52:17] <jepler> skunkworks: ugh, so now we know, or think we know, there's a dependency analysis problem :(
[15:52:18] <skunkworks> mhaberler, I think micges is working on it now.
[15:52:23] <mhaberler> ah, super
[15:53:17] <mhaberler> it is a pity that there's no good portable way of userland ethernet i/o which works without extra stacks like rtnet
[15:53:21] <jepler> $DAY_JOB calls, bbl.
[15:53:25] <mhaberler> cu
[15:54:12] <pcw_home> Preemt-RT might be OK
[15:54:29] <mhaberler> hm, just UDP I/O?
[15:54:50] <mhaberler> is there any way you can do interpacket arrival timings on the 7i80?
[15:54:57] <pcw_home> Yep OASDL specs seem promising
[15:55:07] <pcw_home> Yes
[15:55:51] <pcw_home> current (R14) firmware has timestamps,waituS, and wait for DPLL
[15:56:03] <mhaberler> OSADL.. btw I got a paper on the Portable RTAPI in into the OSADL conference in Lugano CH end of october
[15:56:23] <mhaberler> paper/paper accepted/
[15:56:55] <mhaberler> are these pin values?
[15:57:13] <pcw_home> if Preemt-RT is good enough it solves the "only works with these three MACs" problem
[15:57:20] -!- b_b has quit [Changing host]
[15:57:21] <mhaberler> right
[15:57:31] -!- thomaslindstr_m has quit [Remote host closed the connection]
[15:57:55] <mhaberler> it would be interesting to see the difference between rtnet and just plain udp i/o on the timestamps
[15:58:01] <pcw_home> the timers are lower level but easily accesible
[15:58:07] <skunkworks> So - this is with the message_ring_size to 1024*1024
[15:58:10] <skunkworks> MESSAGE_RING_SIZ
[16:05:57] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[16:06:29] <skunkworks> and I envoke the hal file DEBUG=5 halrun -I -f save.hal
[16:09:28] -!- Laremere has quit [Ping timeout: 240 seconds]
[16:13:25] -!- ries has quit [Ping timeout: 248 seconds]
[16:15:07] <mhaberler> I dont see how the buffer size has anything to do with what was being printed before and after the change
[16:15:15] <mhaberler> anything else changed here?
[16:15:42] -!- DaViruz has quit [Ping timeout: 264 seconds]
[16:16:18] -!- jp_mill has quit [Ping timeout: 264 seconds]
[16:18:17] <mhaberler> are you talking about stderr output or what is in /var/log/linuxcnc.log ?
[16:18:33] <skunkworks> I don't think the increasing the buffer size effected anything
[16:18:42] <skunkworks> where is stderror going? to terminal?
[16:18:53] <mhaberler> well unless you redirect, yes
[16:19:22] <skunkworks> then the pin designations are missing there also/too
[16:19:34] <mhaberler> what did you mean by '(non linuxcnc.log system)' ?
[16:19:39] -!- ries has quit [Ping timeout: 248 seconds]
[16:19:50] <mhaberler> you meant logging isnt set up?
[16:20:14] <skunkworks> correct - and it seems to output the info to stderr (terminal output_
[16:20:26] <skunkworks> as you can see here
http://pastebin.com/E2KzNmWc
[16:20:53] <mhaberler> right, but only for messages tagged with RTAPI_MSG_ERR
[16:20:57] <mhaberler> everything else should show up in linuxcnc.log
[16:21:32] <mhaberler> now if those messages are generated with less than RTAPI_MSG_ERR that is just normal they dont show up on the console
[16:21:50] <mhaberler> does the linuxcnc.log file also lack those lines?
[16:21:54] <skunkworks> this is what I get out of terminal currently
http://pastebin.ca/2434246?srch=7i80
[16:22:19] <skunkworks> correct
[16:23:02] <skunkworks> log ->
http://pastebin.com/deAQNxC9
[16:23:14] <skunkworks> terminal ->
http://pastebin.ca/2434246?srch=7i80
[16:23:34] -!- jfire has quit [Quit: Leaving.]
[16:24:04] <mhaberler> sorry, I'm lost. give me an example which is in the terminal output but not in the log
[16:25:14] <skunkworks> if I run this setup
[16:25:16] <skunkworks> $ git branch --track rtos-master-v0 origin/rtos-master-v0
[16:25:16] <skunkworks> $ git checkout rtos-master-v0
[16:25:33] <skunkworks> without the linuxcnc.log setup
[16:25:46] <skunkworks> I get this output in terminal
[16:25:46] <skunkworks> http://pastebin.com/E2KzNmWc
[16:26:09] <skunkworks> this is missing from the linuxcnc.log or terminal when logging is setup
[16:26:20] <skunkworks> (if that make sense)
[16:26:44] -!- syyl_tb has quit [Read error: Connection reset by peer]
[16:26:51] <mhaberler> (yes, but thats a rather old branch)
[16:26:55] <skunkworks> *this type of info
[16:26:56] <skunkworks> hm2/hm2_7i80.0: IO Pin 011 (P1-23): PWMGen #0, pin Out0 (PWM or Up) (Output)
[16:26:57] <skunkworks> hm2/hm2_7i80.0: IO Pin 012 (P1-25): PWMGen #0, pin Out1 (Dir or Down) (Output)
[16:26:57] <skunkworks> hm2/hm2_7i80.0: IO Pin 013 (P1-27): PWMGen #1, pin Out0 (PWM or Up) (Output)
[16:27:19] <mhaberler> need to see where that's output in hm2 and how
[16:28:03] <skunkworks> biab
[16:28:21] -!- ries has quit [Ping timeout: 248 seconds]
[16:29:14] -!- mackerski has quit [Quit: mackerski]
[16:32:02] <skunkworks> mhaberler, welcome back! :)
[16:34:25] <mhaberler> oh. I have a suspicion
[16:35:01] <mhaberler> need a test module to verify - it's probably just broken mapping of rtapi to syslog log level
[16:37:22] <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
[16:47:59] <mhaberler> skunkworks: your issue is this:
[16:48:30] <mhaberler> if you start realtime like so: 'DEBUG=5 realtime start' everything gets logged
[16:48:46] <mhaberler> you just used halrun, right?
[16:49:53] <mhaberler> need to check whether halrun does export DEBUG, I think yes - at least it should
[16:53:08] <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?
[16:58:29] -!- tmcw has quit [Remote host closed the connection]
[17:03:08] -!- tmcw has quit [Read error: Connection reset by peer]
[17:05:19] <mhaberler> bbl
[17:05:42] -!- tmcw_ has quit [Remote host closed the connection]
[17:09:00] <skunkworks> mhaberler,
http://pastebin.com/aFcM126S
[17:09:10] <skunkworks> (debug=5)
[17:09:18] -!- mackerski has quit [Ping timeout: 256 seconds]
[17:09:19] <skunkworks> and
http://pastebin.com/GcpaVBDp
[17:10:10] -!- md-2 has quit [Remote host closed the connection]
[17:10:54] -!- tmcw has quit [Ping timeout: 264 seconds]
[17:15:04] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[17:18:15] <skunkworks> mhaberler, this is what I get if I do DEBUG=5 realtime start
[17:18:30] <skunkworks> Then halcmd -k -f save.hal
[17:18:34] <skunkworks> http://pastebin.com/4t2QqaU9
[17:20:08] <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
[17:20:57] <mhaberler> I currently dont have a 7i80 setup at hand, but I need to reassemble one once micges is done
[17:29:47] <skunkworks> mhaberler, can you see if your 5i25 and see if you get pin information?
[17:30:28] <mhaberler> I think so, but will take a bit
[17:34:52] <skunkworks> (to see if it is a messaging problelm or a mesa driver problem..)
[17:36:45] <mhaberler> sure
[17:38:34] <skunkworks> I have some 5i20's but they are in a working system right now... :)
[17:39:59] -!- malcom2073 has quit [Read error: Operation timed out]
[17:40:21] <mhaberler> hm, wiki search window gone? on all of: firefox safari chrome
[17:41:09] <skunkworks> heh - I had the same problem - it is at the bottom now.
[17:41:21] <skunkworks> or was always - but the top one is gone
[17:41:45] <mhaberler> ah. confuse the spammers
[17:42:10] <skunkworks> sure
[17:53:38] <mhaberler> ok - ubc3, 5i25.ini, run with 'DEBUG=5 linuxcnc' I get:
[17:53:42] <mhaberler> http://static.mah.priv.at/public/console.txt
[17:54:39] <mhaberler> and this:
http://static.mah.priv.at/public/linuxcnc.log
[17:54:52] <mhaberler> looks like that type dump aint there
[17:55:49] <skunkworks> ok - so it isn't just the 7i80
[17:56:05] <mhaberler> yes, looks like me :-/
[17:56:31] <skunkworks> heh - thats ok. I am just happy that the rtnet seems to be coming along - Pretty darn cool.
[17:57:49] <skunkworks> I have been running a blinking led on the 7i80 for quite a while with no watchdog bites
[17:58:23] <skunkworks> (really - no watchdog bites since I replaced the NIC)
[18:06:37] <mhaberler> yep, found it - the mapping of rtapi to syslog log levels is off - nothing serious, all userland
[18:06:45] <mhaberler> thanks!
[18:09:13] -!- syyl_tb has quit [Ping timeout: 246 seconds]
[18:09:31] <skunkworks> Awesome!
[18:11:33] -!- micges [micges!~micges@deh77.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:12:32] <andypugh> Do new standalone HAL components get pushed to master or 2.5 at the moment?
[18:13:07] <cradek> comp based, or more complicated?
[18:13:14] <andypugh> comp
[18:13:30] <cradek> you can add that to 2.5 if you like
[18:13:41] <andypugh> Somebody asked for a gray-code to binary convertor.
[18:14:08] -!- syyl_tb- has quit [Ping timeout: 240 seconds]
[18:14:27] <cradek> cool, that kind of thing is no problem, especially because it gets packaged automatically
[18:16:12] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[18:17:57] <andypugh> I can't see any use for a binary to gray converter. Can anyone else?
[18:18:14] <alex_joni> mhaberler: the top search box was a hack to our wiki, which got lost during a recent upgrade
[18:18:21] <andypugh> Maybe sending data on a parallel bus made of relays?
[18:18:58] <cradek> mhaberler: what was/is your intent regarding the adoption/merge of jog-while-paused-preview1?
[18:20:05] <mhaberler> give me a bit of time
[18:20:30] <cradek> oh are you responding on list already?
[18:22:10] <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
[18:22:25] <pcw_home> gray to binary I can see (parallel absolute encoders in tool changers and what not)
[18:22:26] <mhaberler> still wading the backlog
[18:22:27] <pcw_home> cant see why you would want a bin to gray either
[18:23:09] <pcw_home> except maybe to test the gray to bin :-)
[18:23:15] <cradek> it's been added to the agenda and there's a post in emc-users about it
[18:23:28] <mhaberler> right, I suggested that
[18:24:47] <cradek> I'm not sure what the agenda item is proposing exactly, which is partly why I asked for your thoughts
[18:25:55] <cradek> I forgot to freeze the agenda yesterday
[18:25:59] <cradek> wonder if I should do it now
[18:26:21] <cradek> this is a good example of why - it's too late to reasonably discuss things that are added
[18:29:33] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[18:34:18] -!- koopee has quit [Ping timeout: 256 seconds]
[18:35:46] -!- Loetmichel has quit [Ping timeout: 240 seconds]
[18:35:59] -!- flippyhead has quit [Quit: flippyhead]
[18:40:54] -!- syyl_tb-- has quit [Ping timeout: 264 seconds]
[18:41:28] -!- syyl_tb- has quit [Ping timeout: 240 seconds]
[18:48:33] <KGB-linuxcnc> 03git 05unified-build-candidate-3 92d1c6e 06linuxcnc 04src/rtapi/xeno_math/.e_acos.o.d * xeno_math: remove spurious build artefact
[18:48:33] krusty_ar_ is now known as krusty_ar
[18:48:33] <KGB-linuxcnc> 03git 05unified-build-candidate-3 a2080d1 06linuxcnc 10src/rtapi/rtapi_msgd.c * rtapi_msgd: fix logging
[18:48:36] <KGB-linuxcnc> 03git 05unified-build-candidate-3 d70e81f 06linuxcnc 10src/rtapi/rtapi_global.h * rtapi_msgd: enlagre message buffer
[18:50:23] -!- AR_ has quit [Ping timeout: 260 seconds]
[18:50:33] -!- ds3 has quit [Ping timeout: 245 seconds]
[18:52:17] <mhaberler> skunkworks: logging is now fixed in ubc3 and ubc3-7i80-rtnet
[18:52:55] <skunkworks> mhaberler, ok - I will give it a try
[18:53:41] <mhaberler> it show up in syslog
[18:53:59] <mhaberler> misread the man page :-/
[18:54:32] <skunkworks> mhaberler, as of now? I looked in the syslog when I was goofing around
[18:55:20] <mhaberler> you want to pull the ubc3-7i80-rtnet branchm or unified-build-candidate-3 which is the base of the former
[18:58:04] <skunkworks> ok - hey - did you see
http://pastebin.com/0kg1jRgC
[18:59:00] <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...
[18:59:20] <cradek> no I'm sure it doesn't
[19:00:11] <cradek> there are dependencies though - one menu option can control the appearance of others
[19:02:28] <awallin_> "depends on PARPORT && BROKEN" is not maybe so great :|
[19:02:46] <cradek> hmm
[19:03:07] <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>
[19:03:16] <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>
[19:03:32] <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>
[19:04:35] <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
[19:05:01] <awallin_> er "no easy fix" :(
[19:05:53] <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"
[19:07:12] -!- psha has quit [Quit: Lost terminal]
[19:09:00] -!- radicalbiscuit has quit [Quit: Page closed]
[19:10:01] <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
[19:11:43] <mhaberler> I'm not sure anybody else has taken a closer look at the code though
[19:11:47] <cradek> mhaberler: history aside, I wonder if you think it should be merged and used long-term
[19:12:04] <mhaberler> oh, me - well yes, I find it useful
[19:12:56] <mhaberler> beyond that, I think the principle of multiple switchable motion queues is the way to do these 'things during pause'
[19:13:57] <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
[19:14:27] -!- sirdancealo2 has quit [Ping timeout: 240 seconds]
[19:14:34] <mhaberler> good point - have a minute to discuss jog styles?
[19:14:35] <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)
[19:15:07] <micges> yes I do!
[19:15:22] <cradek> micges: that makes me happy, thanks
[19:16:37] <cradek> mhaberler: I am in and out...
[19:16:42] <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
[19:17:21] <mhaberler> once you're paused and synced, that'd be safe
[19:17:43] -!- voxadam has quit [Quit: quit]
[19:17:46] <mhaberler> there is currently no support for multiple kins, but that be the most elegant solution imo
[19:18:06] <mhaberler> the idea would be like this:
[19:18:41] -!- eliezer [eliezer!~eliezer@190.77.16.10] has joined #linuxcnc-devel
[19:18:55] * alex_joni listens
[19:19:16] <eliezer> quien habla español
[19:19:19] <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
[19:19:52] <mhaberler> but maybe I am overlooking a good reason why the joint mode planner is actually needed
[19:20:27] <mhaberler> this is btw exactly what deltatau does in the motion controllers, they call the switchable kins 'coordinate systems' but thats the same idea
[19:21:31] <mhaberler> if the condition is: paused and synced, one should be able to switch kins back and forth, even back with the return move
[19:21:46] <cradek> I don't understand what you mean by switching kins
[19:22:05] <mhaberler> right now kinematics is a singleton, setup time
[19:22:06] <cradek> by jog styles, I meant: continuous, incremental, wheel
[19:22:20] <mhaberler> assume say a puma robot, which is non-trivkins
[19:22:30] <mhaberler> joint jogging is defacto trivkins
[19:22:48] <mhaberler> ahso, thats something completely different then
[19:22:51] <cradek> well joint jogging does not use kins at all
[19:23:01] <mhaberler> right, identity
[19:23:13] <eliezer> Spanish speaking channel
[19:23:25] <alex_joni> cradek: I think mhaberler is talking principle (not current implementation)
[19:23:31] <mhaberler> right
[19:23:40] <alex_joni> if you would have a trivkins setup on a puma robot
[19:23:45] <alex_joni> and you do world joggin
[19:23:58] <alex_joni> it's basicly like a regular joint jogging on a non-trivkins machine
[19:24:02] <mhaberler> right
[19:24:06] <eliezer> and you do world joggin
[19:24:06] <micges> eliezer: this is english channel
[19:24:33] <mhaberler> but then that was a different theme, so lets look at current jog modes
[19:24:47] <eliezer> yes but want a channel on cnc Spanish speaking
[19:24:49] <alex_joni> mhaberler: but still you have some issues to take care of
[19:24:58] <alex_joni> eliezer: ask in #linuxcnc
[19:24:59] <mhaberler> I do assume so, yes ;)
[19:25:06] <alex_joni> scaling and whatnot
[19:25:36] <eliezer> thanks :D
[19:25:49] <mhaberler> now I assume cradeks point was to integrated the jogging functions of this patch with the motion jog commands being passed down, right?
[19:26:27] <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
[19:26:29] <mhaberler> right now this is a hal-only affair
[19:27:09] <cradek> the motion part you've done is useful. remaining are probably the task parts and all the UIs' parts :-/
[19:27:38] <cradek> and stirring it together with ja3 -- I don't know how much extra difficulty that makes
[19:27:42] <mhaberler> hm. lets see - otoh it doesnt look all that wild to integrate the motcommands
[19:28:48] <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)
[19:29:03] <cradek> so is it your intent that this would be world mode only?
[19:29:16] <mhaberler> I guess so
[19:29:48] <alex_joni> I think the way around this is to be able to save a canon state
[19:29:58] <mhaberler> I would think jog commands can be applied only a) if paused b) this coord mode jogger is enabled
[19:29:59] <alex_joni> so you can do an abort, and resume with the same state
[19:30:15] <alex_joni> than during the "pause" (really program abort) you can do whatever
[19:30:36] <cradek> well that's another question
[19:30:38] -!- voxadam has quit [Ping timeout: 240 seconds]
[19:30:52] <mhaberler> in which case the jog commands from 'above' would drive the target position of the jogger
[19:30:56] <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?
[19:31:14] <mhaberler> yes
[19:31:24] <cradek> people sure do want to change offsets, which breaks all those assumptions
[19:31:24] <mhaberler> there is an automatic return move
[19:31:59] <cradek> yes I understand the return move is what makes it possible to restore (make true again) the old planner's state
[19:32:01] <mhaberler> I dont think that can be realistically done with the current locus of offset application
[19:32:11] <cradek> I agree with you
[19:32:28] <mhaberler> that be serious mission creep
[19:32:42] <cradek> well nobody's really stated a mission :-)
[19:33:00] <andypugh> We are too fond of the queue. It isn't saced and can be recalculated at the drop of a hat.
[19:33:03] <mhaberler> we can likely do that once offset application has moved to motion
[19:33:07] <cradek> "fix the jog-while-paused things people complain about over the years" haha
[19:33:22] <alex_joni> andypugh: not that easily (imagine loops and whatnot)
[19:33:27] -!- kb8wmc has quit [Quit: ChatZilla 0.9.90.1 [Firefox 20.0/20130329043827]]
[19:33:28] <cradek> yeah I agree with you - I think that's the only way to proceed
[19:33:51] <cradek> unfortunately (because it's big)
[19:34:32] <cradek> but I wonder if andypugh is on to a different approach
[19:34:57] <mhaberler> what he's up to ?
[19:35:06] <mhaberler> a, there he is
[19:35:08] <cradek> I haven't thought it through (yes you have to back up program execution but so what - keep the state around)
[19:36:13] <mhaberler> an idea which came out of the messaging work:
[19:37:15] <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?
[19:38:27] <alex_joni> andypugh: unless you change offsets during the pause
[19:38:34] <cradek> or diameter
[19:38:37] <alex_joni> right
[19:38:44] <cradek> that's another "over the years" type problem
[19:38:48] <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
[19:38:48] <mhaberler> environment
[19:39:27] <mhaberler> but that is blue sky
[19:39:29] <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
[19:39:46] <cradek> but you'd still need something like motion that accepts something like moves and plans them
[19:40:07] -!- ve7it has quit [Remote host closed the connection]
[19:40:47] <cradek> if we move offsetting and even diameter, motion might have simpler/fewer/more messages but you still need something a lot like motion
[19:40:56] <mhaberler> I would think a realistic goal is to integrate jogging commands into this branch; and it addresses some needs
[19:41:16] <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?
[19:41:38] <mhaberler> guess what you need for that: switchable motion queues
[19:41:40] <cradek> and then you continue your arc how?
[19:42:05] <mhaberler> this isnt a realistic goal in this context
[19:42:07] <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>
[19:42:34] <mhaberler> integrate with jog commands is
[19:42:47] <andypugh> cradek: Well, it serves you right if you insist on relative centre arcs. It's no problem with absolute or R format arcs. :-)
[19:43:22] <mhaberler> cradek: nml jog commands.. do they pass target position only or are there velocity variants?
[19:43:40] <cradek> depends on whether you're talking about ja3 or not
[19:43:43] <mhaberler> afaict its joint and distance, or joint and direction, right?
[19:44:05] <mhaberler> what will change?
[19:44:21] <cradek> non-ja3 in kins mode uses velocity vector, but that is going away
[19:45:08] <mhaberler> ok, assuming ja3 happens we better plan for that then
[19:45:33] <mhaberler> meaning: target pose and vel?
[19:45:35] <cradek> I believe ja3 uses (joint OR axis number) AND (continuous direction OR target position)
[19:45:59] <cradek> spread into various message types in various modes etc, of course
[19:46:19] <cradek> uh ... OR wheel increment
[19:46:20] <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.
[19:46:31] <mhaberler> wheel increment is a pose
[19:46:55] <cradek> yes it's very much like the new target position type of jog
[19:47:04] <cradek> (like incremental)
[19:47:38] <mhaberler> so question 1: do we need joint mode jogging at all during pause
[19:48:03] <cradek> I hope that answer is no, since inverse-kins-only machines will not be able to do it
[19:48:29] <mhaberler> excellent excuse to drop the idea
[19:48:36] <cradek> heh I like that approach
[19:49:12] <cradek> (I am not sure how well IKO works in ja3 - I have not tested it)
[19:49:25] <cradek> in theory it's supported, but it might currently be buggy
[19:49:26] <cradek> an aside
[19:50:16] <mhaberler> I'm not afraid feeding jog commands into this code, but UI mode hell makes me hesitant..
[19:51:00] <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
[19:51:57] <mhaberler> that would suggest these jog commands can be honored in what is currently teleop mode, right?
[19:52:14] <cradek> yes I think so
[19:52:36] <mhaberler> now lets see what that does to a UI
[19:52:39] <mhaberler> pause
[19:52:50] <mhaberler> that would mean teleop jogging now be enabled
[19:53:06] <mhaberler> or really coord mode moves posing as teleop
[19:53:50] <cradek> I think that's pretty much how world mode jogs currently work in ja3
[19:54:08] <cradek> just issue a line move
[19:54:28] <cradek> (with the target the edge of world space)
[19:54:30] -!- syyl- has quit [Quit: Leaving]
[19:54:40] <cradek> and you might abort it later
[19:54:52] <mhaberler> or scale the target
[19:55:06] <cradek> ?
[19:55:30] <mhaberler> well if the target is outside world space, prune the vector to the intersection point
[19:55:40] <mhaberler> so it'd stop there
[19:55:41] <cradek> sure
[19:55:55] <cradek> world limits are a cube, so it's trivial
[19:55:58] -!- adb_ [adb_!~IonMoldom@47-122.1-85.cust.bluewin.ch] has joined #linuxcnc-devel
[19:56:16] <cradek> well a 9d "cube" haha
[19:56:30] <alex_joni> although for nontriv machines the cube is pretty moot
[19:56:39] <alex_joni> even if it's 9d
[19:56:49] <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
[19:56:50] <cradek> well world limits are currently a 9d cube for all machines
[19:57:00] -!- eFuchs_firefly has quit [Quit: ping timeout]
[19:57:14] <alex_joni> cradek: I know.. was just saying that for nontrivkins that is incorrect and/or limiting
[19:57:20] <cradek> sure
[19:57:30] <alex_joni> so it's not something to use for jogging
[19:57:40] <cradek> sure it is :-)
[19:57:44] -!- gimps_ has quit [Ping timeout: 246 seconds]
[19:57:45] <alex_joni> the infinity end sounds safer
[19:57:59] <cradek> this is a separate issue!
[19:58:06] <mhaberler> question 2: how do we communicate at pause time to the UI (&task) that coord mode jogging is now possible
[19:58:24] <alex_joni> UI assumes it?
[19:58:33] <cradek> you "just" change the UIs to let the user jog when it's paused
[19:58:46] <cradek> and then you change task to not give an error when they do that
[19:58:50] <mhaberler> in the current scheme I would think a field in emcstat be on order
[19:59:06] <cradek> you don't have to communicate things that are always the same
[19:59:21] adb_ is now known as adb
[19:59:22] <cradek> what case are you picturing where it's not allowed?
[19:59:32] <mhaberler> point taken
[19:59:54] <mhaberler> there's this gazillion overrides..
[20:00:21] <mhaberler> thats what made me think of it - assuming its safe might be stretching it a bit
[20:00:58] <cradek> brb
[20:01:26] <mhaberler> re testing: with the linuxcnc module it should be possible, provided task wont trample on the command, but that can be fixed
[20:01:26] <alex_joni> mhaberler: lets first say it's always safe, and limit it later if needed
[20:01:54] <mhaberler> two fingers less later, community opinion converges on the view it wasnt ;)
[20:02:18] -!- skunkworks has quit [Quit: Leaving]
[20:03:15] <alex_joni> :D
[20:03:16] -!- grummund has quit [Ping timeout: 256 seconds]
[20:05:30] -!- mozmck has quit [Ping timeout: 252 seconds]
[20:06:16] <alex_joni> so back to possible approaches:
[20:06:21] <alex_joni> 1. switchable queues
[20:06:27] <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)
[20:06:48] <alex_joni> 2. when pausing: remember state, abort, permit mostly anything, resume state, resume
[20:07:12] <alex_joni> I think in ja3 we only world jog
[20:07:25] -!- eliezer has quit [Quit: Saliendo]
[20:07:37] <mhaberler> more or less; currently restrained to coord mode because mode switching is heavy handed, I think flushes queue
[20:07:54] <alex_joni> except when switching to joint mode, which isnt possible on a trivkins machine
[20:08:06] <mhaberler> a mode switch is pretty much like an abort
[20:08:42] <mhaberler> but a mode switch may not be needed, its just that jogging is restrained to coord mode
[20:09:15] <mhaberler> right, 2) is what the patch does
[20:09:31] <mhaberler> plus switch to alternate queue
[20:09:49] <mhaberler> resume switches back to primary queue after reentry move
[20:10:09] <KGB-linuxcnc> 03andy 05v2.5_branch 25f1203 06linuxcnc 10src/hal/components/ 03bin2gray.comp 03gray2bin.comp
[20:10:09] <KGB-linuxcnc> Add a couple of HAL components to convert to and from Gray code
[20:10:09] <KGB-linuxcnc> Signed-off-by: Andy Pugh <andy@bodgesoc.org>
[20:11:03] <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
[20:12:00] <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'
[20:12:31] <alex_joni> but that still leaves wheel jogs out
[20:12:43] <alex_joni> as those are directly in motion
[20:12:47] <alex_joni> hmm.. or maybe not
[20:12:52] <mhaberler> I never looked at those, how do they differ?
[20:12:58] <JT-Shop> wheel jog as in MPG?
[20:13:58] <mhaberler> well that be easy to tack onto provided axis==joints
[20:14:12] <mhaberler> strike out condition, this one is easy
[20:14:35] <mhaberler> it mutates into generating vectors
[20:14:52] <mhaberler> actually that be the low hanging fruit
[20:15:29] <mhaberler> the commanded jogs are more involved
[20:16:03] <mhaberler> vel-mode needs thinking
[20:16:20] <mhaberler> jog-vel-mode I meant
[20:16:41] <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>
[20:17:56] <mhaberler> now the $100 question: which jog mode is wheel jog in?
[20:18:08] <mhaberler> joint or world?
[20:18:52] <alex_joni> currently world
[20:19:07] <alex_joni> errr.. currently it only works in non-ja3
[20:19:18] <alex_joni> where it should be world, but acts on joints
[20:19:20] <mhaberler> oh.
[20:19:21] <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>
[20:19:30] <cradek> alex_joni: no, it's currently joint
[20:19:34] <cradek> it should work in both modes
[20:19:42] <cradek> that is what micges is going to fix (yay)
[20:19:50] <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>
[20:19:56] <alex_joni> yeah, I meant joint.. sorry
[20:19:59] <andypugh> What the hell?
[20:20:06] <jepler> it looks like andy's good deed is not going unpunished
[20:20:16] <andypugh> That was 23 lines of .comp that compiles for me.
[20:20:17] <jepler> hal/components/gray2bin.comp:9:1: error: unknown type name ‘u32’
[20:20:32] <jepler> oh it's the good old "nobody knows what to call the fixed-width types" problem
[20:20:43] <jepler> in which the kernel provides one set of attractive names that userspace does not
[20:20:44] <alex_joni> mhaberler: those get only fed via HAL into motion
[20:20:52] <andypugh> Ah, being compiled for sim..
[20:20:57] <andypugh> I can fix that.
[20:21:00] <mhaberler> sure, thats why it would be easy
[20:21:07] <mhaberler> for world mode
[20:21:25] <mhaberler> but since above we decided to drop joint jog.. well here goes
[20:21:27] <andypugh> I forgot to switch to a sim config to check it still compiled :-(
[20:21:37] <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>
[20:21:41] <cradek> you mean drop the idea of joint jog while paused, right?
[20:21:46] <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>
[20:21:49] <mhaberler> right
[20:22:10] <cradek> (I'm sure itching to merge ja3)
[20:22:32] <mhaberler> is there sufficient cracking the whip on micges?
[20:22:34] <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>
[20:22:35] -!- flippyhead has quit [Quit: flippyhead]
[20:50:33] -!- logger[psha] [logger[psha]!~loggerpsh@195.135.238.205] has joined #linuxcnc-devel
[20:50:35] -!- c60 has quit [Quit: leaving]
[20:50:48] <cradek> the swapping-planners part might end up being useful, but that seems like a tiny part of it
[20:51:28] <mhaberler> no, thats way out, I misunderstood your intent
[20:51:58] <cradek> what's way out?
[20:52:24] <mhaberler> well switchable kins in a single planner - that affects all the modal hell in task/UI
[20:52:50] <mhaberler> and for that particular issue theres no upside
[20:53:44] <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)
[20:53:58] <mhaberler> right
[20:54:22] <cradek> that idea may be valuable for part of solving the big problem
[20:54:24] <mhaberler> thinking about generalizing a moment:
[20:54:44] <mhaberler> (note I will not touch this as long as nml is here)
[20:54:46] -!- jfire has quit [Quit: Leaving.]
[20:55:13] <mhaberler> there should be a way to address separate queues, and tie them to different sources (maybe interps)
[20:55:39] -!- rob_h [rob_h!~rob_h@94.8.112.107] has joined #linuxcnc-devel
[20:55:41] <mhaberler> but you cant to separate interp instances without butchering task thanks to the _setup static
[20:55:51] <mhaberler> besides the separate queue work
[20:55:56] <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>
[20:56:01] <mhaberler> so it doesnt make much sense right now
[20:56:32] <cradek> sorry, I think this is too general for me to see how it applies to the goals we're discussing
[20:56:41] <mhaberler> absolutel
[20:56:46] <mhaberler> y
[20:57:20] <mhaberler> all I'm saying is the single alternate mini-queue is a concept generalizing - eventually, not now
[20:58:14] <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
[20:58:28] <mhaberler> lets agree this is blue sky
[20:58:57] <cradek> I'm too nearsighted to see the sky in its full glory
[20:59:20] <mhaberler> but I wouldnt be overambitious on that jog-while-paused request, I think decent jog support will find use without offsets changing
[20:59:29] <cradek> I think we've got a problem of modal assumptions, and offsets being in the wrong places
[20:59:44] <cradek> possibly you are right
[21:00:09] <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
[21:00:35] <cradek> I think it's pretty limited usefulness though, without the ability to change offsets
[21:00:59] <mhaberler> its a realistic step
[21:01:00] <cradek> I think the long term goal would be to have a [perhaps newly-offset world position] return move be the required thing
[21:01:50] <mhaberler> well if we move the 'return move requirement' 'upwards' (into task/UI) this is going to have much more immediate impact
[21:02:10] <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
[21:02:19] <cradek> so it's totally a useful and realistic step
[21:02:30] <mhaberler> I agree it should, but I dont want to empty the bugtracker post factum
[21:02:37] -!- stsydow has quit [Quit: Leaving]
[21:02:48] <cradek> I'm really with you as far as seeing it as two separate projects now
[21:03:49] <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
[21:04:17] <mhaberler> would you think rebasing on ja3 is first?
[21:04:47] <cradek> yes it would be crazy to work with pre-ja3 teleop's velocity vector garbage
[21:05:11] <mhaberler> ok, so I'll make that step 1, then jog wheel, then commanded jogs
[21:05:20] <cradek> awesome
[21:05:28] <mhaberler> excellent, very good result
[21:05:29] <cradek> maybe micges will make progress on world mode wheel jogging too
[21:05:52] <mhaberler> ah, prodding micges, favorite pastime
[21:05:54] <cradek> seems like you'll have to depend on that
[21:06:13] <mhaberler> yes, it seems
[21:06:16] <cradek> I have to run
[21:06:19] <cradek> thanks mhaberler
[21:06:25] <mhaberler> fair enough, excellent!
[21:06:27] <mhaberler> cu
[21:07:20] <mhaberler> I'll summarize for the list if thats ok for you
[21:07:33] <mhaberler> since they are banging the gates
[21:07:45] -!- djcoin has quit [Quit: WeeChat 0.4.1]
[21:10:41] -!- tmcw has quit [Remote host closed the connection]
[21:15:39] -!- tmcw has quit [Ping timeout: 248 seconds]
[21:28:01] _BJFreeman is now known as BJfreeman
[21:30:52] -!- FinboySlick has quit [Quit: Leaving.]
[21:31:54] -!- mhaberler has quit [Quit: mhaberler]
[21:33:55] -!- chillly has quit [Quit: Leaving]
[21:37:31] -!- mhaberler [mhaberler!~mhaberler@extern-177.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[21:40:10] -!- AR_ has quit [Ping timeout: 256 seconds]
[21:43:58] -!- flippyhead has quit [Quit: flippyhead]
[21:46:58] -!- micges has quit [Quit: Leaving]
[21:50:38] -!- stsydow has quit [Quit: Leaving]
[22:00:38] -!- maximilian_h has quit [Ping timeout: 240 seconds]
[22:00:39] -!- Brandonian has quit [Quit: Brandonian]
[22:01:08] -!- JesusAlos has quit [Quit: ChatZilla 0.9.90.1 [Firefox 20.0/20130329043827]]
[22:05:52] -!- `Nerobro has quit [Ping timeout: 240 seconds]
[22:07:06] -!- adb has quit [Ping timeout: 245 seconds]
[22:07:12] -!- skorasaurus has quit [Quit: Elvis has left the building.]
[22:12:35] -!- flippyhead has quit [Quit: flippyhead]
[22:16:20] -!- stsydow has quit [Remote host closed the connection]
[22:16:55] -!- maximilian_h [maximilian_h!~bonsai@46.246.45.24] has joined #linuxcnc-devel
[22:22:43] -!- afiber__ has quit [Quit: Konversation terminated!]
[22:26:27] -!- tmcw has quit [Ping timeout: 260 seconds]
[22:36:46] -!- stsydow has quit [Client Quit]
[22:41:11] -!- maximilian_h [maximilian_h!~bonsai@46.246.45.24] has parted #linuxcnc-devel
[22:42:50] -!- AR_ has quit [Ping timeout: 264 seconds]
[22:48:21] -!- Laremere has quit [Ping timeout: 245 seconds]
[23:04:42] -!- andypugh_ [andypugh_!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[23:04:43] -!- andypugh has quit [Ping timeout: 260 seconds]
[23:04:44] andypugh_ is now known as andypugh
[23:07:44] -!- rob__H [rob__H!~rob_h@94.8.112.107] has joined #linuxcnc-devel
[23:07:44] -!- rob_h has quit [Read error: Connection reset by peer]
[23:13:54] -!- toner has quit [Ping timeout: 264 seconds]
[23:58:51] -!- rob__H has quit [Ping timeout: 260 seconds]