Back
[01:22:23] <KGB-linuxcnc> 03Kim Kirwan 05dgarr/ja9_updates 61ad880 06linuxcnc 10src/emc/kinematics/gentrivkins.c dgarr/ja9_updates, gentrivkins: fix minor typo. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=61ad880
[11:14:11] <seb_kuzminsky> i wonder how hard it would be to add world-mode wheel jogging in ja9, since it already has incremental world-mode jogging by nml messages
[11:18:34] <mozmck> Isn't teleop mode world-mode?
[11:19:21] <seb_kuzminsky> yeah
[11:19:37] <mozmck> I bet it wouldn't be too hard.
[11:43:42] <cradek> I think it's probably not too hard. you'll end up with wheel inputs on axis.* hal pins as well as the existing joint.* pins
[11:43:57] <cradek> iirc, micges did this already once, but the code ended up lost
[11:47:12] <mozmck> Too bad. I really need to start working with JA soon. I think it would be really good to get it merged for 2.8 (3.0?) as soon as possible.
[11:47:32] <mozmck> cradek: did you see my joint disable pin hack?
https://github.com/mozmck/linuxcnc-mirror/commit/decc049d0f2401a1a621f2b52de6ba6afa4de326
[11:49:00] <cradek> cool, looks like a good start :-)
[11:50:02] <cradek> note #2 hints at the class of problems I was expecting: also (for example) disable Y, crank Y a few inches and reenable it, now program G0 X[anywhere but where X is] and Y will move back to where it was
[11:50:39] <mozmck> No, it doesn't actually do that.
[11:50:44] <cradek> all the layers, way up into the interpreter, need to be massaged, probably at reenable time
[11:51:00] <cradek> huh really? I don't see how not
[11:51:09] <cradek> I must not understand it then
[11:51:40] <cradek> nothing resets the canon or interp positions does it?
[11:51:56] <mozmck> The tpSetPos() takes care of some of it
[11:52:28] <cradek> aha, at reenable time, I see
[11:52:35] <mozmck> I'm not sure about canon and interp - I need to understand them better.
[11:52:37] <mozmck> Yes
[11:53:01] <cradek> but yeah I'm surprised if that syncs the interp
[11:54:13] <mozmck> Maybe that's where my #2 issue is.
[11:54:18] <cradek> I don't see how it knows to leave Y in its new location, in my example - the interpreter always sends a position for all axes
[11:54:42] <cradek> and I think tpSetPos does not tell it Y moved
[11:54:44] <mozmck> It's similar to when the machine is off.
[11:55:28] <cradek> heh, I'll stop pretending I know what the bugs are without trying it
[11:56:00] <cradek> this would be a neat feature. I've heard people want it (or something like it) for locking joints too
[11:56:28] <mozmck> It does in this case because I set the carte_pos_cmd.<joint> after the tpGetPos gets the next point.
[11:56:45] <mozmck> So the cmd follows feedback for the joint
[11:58:25] <mozmck> I'm so far only testing with MDI. I disable Y, g0 y2, enable Y, and Y is still at 0. Then if I do g0 y2 again - it does nothing. But if I do g0 x2 y2, it moves as it should.
[11:58:26] <cradek> ok, got that part, but if you tell the interp GO X3 I figured it would issue CANON_RAPID(3, previous interp Y position, previous interp Z position, ...)
[11:58:51] <cradek> oh! MDI might resync the interpreter after every command.
[11:59:36] <mozmck> Hmm, I hadn't thought of that. I really need to dig more into the interpreter and canon. Is there any documentation on that?
[11:59:47] <cradek> yes I think the g0y2 does not issue any canon call because the interp thinks it's a no-op
[11:59:48] <pcw_home> mozmck: I just looked at UDP-RT, Not sure if automatic retrys at the stack level make sense for periodic motion control messages I suspect they just make things worse, I think for single state changing messages retrys make sense, but thats it
[11:59:57] <mozmck> I've figured out stuff mostly by digging around in the code so far.
[12:00:32] <cradek> the only documentation I can think of (original ngc design of the canon interface) would not really help you I bet, sorry
[12:00:48] <cradek> your digging skills are admirable
[12:00:55] <mozmck> pcw_home: that could be - I didn't take the time to really read the article all the way, but it sounded like he got some pretty good results - 200K messages per sec?
[12:01:31] <mozmck> cradek: thanks! There are notes in the code here and there that help - at least when they are not out of date!
[12:01:43] <mozmck> Plenty of FIXMEs too!
[12:01:46] <pcw_home> I suspect that it was written for financial transactions
[12:01:51] <cradek> heh yeah
[12:02:12] <cradek> I trust the FIXMEs less than I trust the other comments :-/
[12:02:15] <mozmck> pcw_home: that could be
[12:03:02] <mozmck> cradek: some make sense - like doing away with all the macros and bit flags and using variables that we have already.
[12:03:54] <cradek> could your implementation use a M code to disable an axis, and another M code to reenable it? the second M code could block interpretation and resync, and I can see how it would all fit together then
[12:04:43] <cradek> having a hal pin for disable/reenable I don't see how it can "push" an unexpected update back up into the interpreter
[12:05:20] <mozmck> pcw_home: BTW, one can apparently put this line in /etc/network/interfaces under the iface eth(x) inet static line: hardware-irq-coalesce-rx-usecs 0
[12:06:06] <pcw_home> Oooh that neat
[12:06:09] <cradek> brb
[12:06:14] <mozmck> pcw_home: in debian and derivatives that should cause ethtool to set rx_usecs to 0 on every if_up
[12:06:56] <pcw_home> I think I had to install ethtool on most systems
[12:07:19] <mozmck> pcw_home: cat /usr/share/doc/ethtool/README.Debian
[12:07:49] <mozmck> I believe I have to install it on xubuntu 14.04
[12:10:10] <mozmck> cradek: My plan is to do it in HAL, but it will have to only do it if code is not running or is paused. My plan is to use an M66 to wait on a HAL signal to indicate the sync is complete before continuing.
[12:51:12] <skunkworks> http://www.machsupport.com/forum/index.php/topic,31039.0.html
[12:59:16] <seb_kuzminsky> huh, ja9
[12:59:19] <seb_kuzminsky> err
[12:59:31] <seb_kuzminsky> js9's incremental teleop jogs are not implemented in the way i had expected
[12:59:41] <seb_kuzminsky> *ja9's
[13:00:01] <seb_kuzminsky> specifically, they are not EMCMOT messages from Task to Motion, like the free-mode incremental jogs are
[13:00:08] * seb_kuzminsky digs more
[13:00:16] <skunkworks> dig seb dig!
[13:11:06] <seb_kuzminsky> oh wait, no there it is
[13:12:09] <seb_kuzminsky> ok so it *is* by NML message (EMCMOT_JOG_INCR), and Motion's behavior in response to that message depends on if Motion is in Teleop or Free mode
[13:12:14] <seb_kuzminsky> that's all fine then
[13:14:42] <seb_kuzminsky> it's confusing that sometimes "Coord" is the opposite of "Free", and sometimes "Teleop" is the opposite of "Free"
[13:15:23] <seb_kuzminsky> i guess it's wrong to think of them as pairwise, the way our "bit test" macros in Motion do
[13:16:12] <seb_kuzminsky> there's a motion_state enum, which can be Disabled, Free, Teleop, or Coord, and that's the right way to look at it
[13:16:29] * seb_kuzminsky goes back to lurk mode
[15:41:48] <seb_kuzminsky> the snickerdoodle folks just won my heart by using screen as the serial terminal to talk to their board:
https://www.youtube.com/watch?v=_VFqfAGwSEQ
[17:54:09] <skunkworks> pcw_home: making it through the first day back? or did you take it easy?
[20:03:17] <linuxcnc-build> build #1825 of 1405.rip-wheezy-armhf is complete: Failure [4failed garbage-collect git repo] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1825 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:03:18] <linuxcnc-build> build #3649 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3649 blamelist: Dewey Garrett <dgarrett@panix.com>
[20:03:31] <linuxcnc-build> build #1826 of 1405.rip-wheezy-armhf is complete: Failure [4failed garbage-collect git repo] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/1826 blamelist: Kim Kirwan <Kim@KimKirwan.com>
[20:19:22] <pcw_home> I did ok but am pretty tired (I did discover I cannot use the arbor press for pressing in connectors yet)
[20:21:34] <skunkworks> it is a start :)
[22:07:33] <seb_kuzminsky> Linux jessie-i386 3.16.0-9-rtai-686-pae #1 SMP PREEMPT Debian 3.16.7-3linuxcnc (2015-11-18) i686 GNU/Linux
[22:55:12] <mozmck> seb_kuzminsky: sounds neat - what version of rtai?
[23:06:51] <seb_kuzminsky> mozmck: 4.1, the latest from rtai.org
[23:06:57] <seb_kuzminsky> trying to build the userspace now