Back
[01:07:17] <KGB-linuxcnc> 03Chris Morley 052.7 dbbd343 06linuxcnc 10src/emc/usr_intf/pncconf/build_INI.py pncconf: fix halui cmnds error * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=dbbd343
[01:07:17] <KGB-linuxcnc> 03Chris Morley 052.7 c1883d8 06linuxcnc 10src/emc/usr_intf/pncconf/pncconf.py pncconf: fix user created stepper names error. * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c1883d8
[03:32:23] <skunksleep> cmorley: I can goof around with it tomorrow but it sound
[03:35:22] <skunksleep> Like the issue with not knowing if the segment is the last segment. (So the TP falls back to 1 segment look ahead)
[03:35:22] <skunksleep> Because of que busters
[07:12:26] <skunkworks> zlog
[08:49:52] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15samcoinc opened issue #45: ja: Command isn't tracking feedback in machine-off 02
https://github.com/LinuxCNC/linuxcnc/issues/45
[08:50:10] <jepler> skunkworks: welcome to github
[08:50:27] <skunkworks> :) it was bound to happen
[08:53:04] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes12 e993e7f 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py make sure startup is in joint mode * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e993e7f
[09:28:17] <dgarr> skunkworks:I have a servo/encoder machine (xzc) and cannot reproduce the behavior of issue #45
[09:28:26] <dgarr> i could not follow yesterday's discussion so i made a standalone xyzb sim config that might
[09:28:26] <dgarr> be helpful in constructing your xyzb config:
http://www.panix.com/~dgarrett/stuff/xyzb.tgz
[09:28:34] <dgarr> this config uses gentrivkins, i see there are still problems with trivkins and omitted axis letters
[09:34:57] <dgarr> skunkworks: i also cannot reproduce the "On sim" behavior cited in issue #45 which sim exactly?
[09:37:32] <cradek> dgarr: you're both using ja12? I can try too
[09:38:45] <dgarr> yes ja12 -- there is a commit today 3d5355c that fixes a bug i found making the xyzb.tgz referenced above
[09:38:52] <cradek> ok
[09:39:46] <dgarr> note that the update_ini script does not handle locking_indexers nor wheel teleop jogging -- that is a lot to ask i think, some configs will require human intervention
[09:40:31] <cradek> I agree
[09:40:42] <dgarr> the buildbot seems to be stalled?
[09:41:54] <cradek> yeah ETA 9 hours seems abnormal
[09:42:05] <cradek> it's early for seb - I bet he'll show up soon
[09:43:16] <cradek> actually it is making progress, running tests on wheezy-rtpreempt
[09:43:24] <cradek> it might be fine...?
[09:44:43] <cradek> yeah I think it's working, but it's behind
[09:45:05] <dgarr> ok -- i see some progress with the buildbot now
[09:45:18] <cradek> two builds waiting:
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin
[09:45:33] <cradek> so yours isn't even next :-/
[09:45:47] <cradek> I bet it's having trouble, maybe swapping or something
[09:46:24] <dgarr> cradek: if you or anyone else runs the xyzb.tgz example and sees a problem it would be helpful to describe so i can reproduce and try to fix
[09:46:46] <cradek> understood
[09:46:57] <cradek> I'm trying the "on sim" instructions now
[09:47:15] <dgarr> i'm not in a hurry for the buildbot, just noticed it seemed slow
[09:48:16] <cradek> I agree "on sim" doesn't reproduce it (I added step 2.5: go to machine off state)
[09:48:50] <cradek> um, I should try not adding steps
[09:49:29] <skunkworks> heh
[09:49:45] <dgarr> my xzc servo/encoder machine doesn't show the issue#45 error at all (xzc using gentrivkins)
[09:49:47] <cradek> yeah it still seems right
[09:50:02] <cradek> when I do the setp, it ferrors and turns off, but I can turn it right back on
[09:50:33] <skunkworks> umm - I forgot - 1.5 on the sim instructions should be - toggle machine off.
[09:50:58] <cradek> I tried it with and without step 1.5
[09:51:08] <cradek> it doesn't happen here either
[09:51:18] <cradek> running sim/axis/axis
[09:52:07] <skunkworks> the machine has to be off -> then move the fb -> then try to turn machine back on. (don't recconect feedback to pos)
[09:52:21] <cradek> yep I did that
[09:52:26] <skunkworks> (like an encoder is hooked to feedback)
[09:52:33] <skunkworks> you are not seeing it?
[09:52:33] <cradek> understood
[09:52:44] <cradek> right - it works correctly for me
[09:52:48] <skunkworks> huh
[09:52:58] <dgarr> works correctly for me too
[09:53:06] <cradek> you must be doing something different - can you check your steps again?
[09:53:22] <cradek> skunkworks: you are on joints_axes12, right?
[09:53:33] <skunkworks> sure. I don't have dgarrs latest commit - would that have changed anything?
[09:53:39] <dgarr> no
[09:53:47] <skunkworks> ok - let me try it again
[09:54:52] <skunkworks_> linuxcnc-JA$ git branch* joints_axes12v2.7.4-592-gbd31d87
[09:55:40] <skunkworks_> sim axis - estop out, on
[09:56:08] <skunkworks_> homed
[09:56:10] <skunkworks_> off
[09:58:10] <skunkworks> wow.
[09:58:29] <skunkworks> ok - what was I doing? I was getting it to do it. I swear
[09:58:52] <skunkworks> I did it like 3 times in a row to get the steps
[09:58:55] <skunkworks> hmmm
[09:59:11] <cradek> did you jog to a limit?
[09:59:22] <skunkworks_> no
[09:59:23] <cradek> it seemed like that was involved with the weirdness you saw yesterday
[09:59:38] <skunkworks_> yes - but I reproduced it without that I thought
[09:59:45] <skunkworks_> let me goof around with it
[09:59:46] <seb_kuzminsky> i'm looking at the buildbot now
[09:59:46] <cradek> hmm
[10:00:35] <dgarr> skunkworks: did you see my input above about xyzb.tgz to illustrate a xyzb config?
[10:01:16] <skunkworks_> dgarr: not yet - I think I have the xyzb working ok - just the jog wheel wasn't working for me.
[10:03:21] <dgarr> i (strongly) suggest using gentrivkins coordinates=xyzb like in the example tgz, see it also for hooking up jog wheel for both world and joint jogging
[10:03:52] <skunkworks> Thank you!
[10:05:49] <seb_kuzminsky> i dont see anything obviously wrong to explain why the buildbot is so far behind
[10:06:12] <seb_kuzminsky> dgarr: should we remove trivkins in favor of gentrivkins in ja?
[10:09:30] <seb_kuzminsky> looks like the problem is on the buildmaster VM
[10:10:35] <dgarr> seb_kuzminsky: removing trivkins might be possible but i am not inclined to do it. my take for now is to educate and recommend gentrivkins
[10:11:03] <dgarr> if someone wants to remove and replace trivkins with gentrivkins it will be a lot of work
[10:12:12] <seb_kuzminsky> gotcha
[10:12:27] <dgarr> and testing all the configs is not really much fun
[10:12:45] <seb_kuzminsky> is there any situation where trivkins is preferable over gentrivkins (in terms of user experience, not developer effort)
[10:12:58] <cradek> the vast majority of our users are simple trivkins with consecutive joints and axes, plus XZ lathes also on trivkins
[10:13:12] <seb_kuzminsky> (i really need to upgrade that stupid buildmaster machine...)
[10:13:18] <seb_kuzminsky> off to work, i'll read back later
[10:13:55] <skunkworks> ok...
[10:13:57] <dgarr> i don't think there are situations where trivkins is preferable -- and it is ok IF there are no omitted axis letters and no duplicated axis letters
[10:14:20] <skunkworks> could someone try this? Unlink the joint.0.motor-pos-fb while machine is still on.
[10:14:23] <skunkworks> jog
[10:14:25] <dgarr> ja has an xz sim config examples in configs/axis/gentrivkins/
[10:14:34] <skunkworks> jog X
[10:14:39] <skunkworks> get a following error -
[10:14:46] <skunkworks> then try to turn the machine back on
[10:18:53] <dgarr> skunkworks: tried, yes, it won't turn on then but it will if you re net: net Xpos joint.0.motor-pos-fb
[10:19:41] <skunkworks> Sure - but if the motor-pos-fb is from an encoder - it will stay where it is at.
[10:20:11] <jepler> what we all expect is for the feedback position to be copied to command position while the machine is "off"
[10:20:20] <cradek> that is wrong then - after the ferror, it should copy fb into cmd. then it should turn on fine
[10:20:30] <jepler> so that at the transition to "machine on" the commanded and feedback positions are equal, and there's not an immediate following error
[10:20:57] <cradek> and also not ever a step change commanded in the joint's actual position
[10:25:31] <skunkworks> so - maybe I triggered a following error first? Boy - don't remember that
[10:28:02] <skunkworks> 2.7 you can do the same thing - toggling machine on doesn't cause a FE
[10:30:05] <jepler> https://emergent.unpythonic.net/files/sandbox/ferror-ja2.png
[10:30:23] <jepler> when you try to go back to machine on, motor-pos-cmd jumps back to the previous motor-pos-cmd from before the first ferror
[10:30:30] <jepler> afk
[10:32:21] <seb_kuzminsky> i think the buildbot slowness is due to yet another locking bug in the 0.8.6p1 version of buildbot that's in precise
[10:40:31] <dgarr> skunkworks: so i just went to the shop and tried with my xzc servo/encoder gentrivkins machine and found that by moving the rotary c axis with the machine off i could reproduce the error -- but, surprisingly, it took many tries to reproduce, usually it was ok
[10:41:52] <cradek> dgarr: the original #45, not the after-ferror problem we're talking about later?
[10:42:12] <cradek> oh you said "with the machine off", so yes the original #45
[10:42:23] <dgarr> yes the original #45 servo/encoder -- note i'm not familliar with the code involved so if others want to fix it would be great
[10:42:29] <skunkworks> Could be why it sometimes works...
[10:43:04] <cradek> why on earth
[10:43:26] * skunkworks just breaks things...
[10:47:23] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15samcoinc commented on issue #45: Ok - so the above directions seem to not work 100% of the time. What does seem to work 100% of the time is ... 02
https://github.com/LinuxCNC/linuxcnc/issues/45#issuecomment-194932809
[10:48:37] <skunkworks> does that make sense?
[10:54:33] <dgarr> your added comment makes sense
[10:55:04] <jthornton> when your flashing 5i2x cards in dos do you run env.bat then nmflash file.bit?
[10:57:05] <pcw_home> envd.bat
[10:57:50] <jthornton> hmm I have ENV.BAT, is envd.bat a newer version?
[10:58:06] <pcw_home> well its pretty simple
[10:58:19] <pcw_home> you can recreate it
[10:59:09] <pcw_home> the entire contents are:
[10:59:11] <pcw_home> set interface=PCIMEM
[10:59:12] <pcw_home> set protocol=DIRECT
[11:00:55] <jthornton> ok the one I have is set interface=pcimem set protocol=bus
[11:01:03] <jthornton> I'll make a new one
[11:01:47] <pcw_home> might be that either will work
[11:03:14] <jthornton> lol, I have not used dos for a long time but I remember how
[11:03:58] <pcw_home> just like a terminal window with a lousy shell
[11:05:45] <jthornton> lol, and I keep typing in ls instead of dir
[11:06:09] <pcw_home> I should zip up our DOS 5i25 test directory, it has the latest of those utils (plus the low level init batch files)
[11:06:38] <pcw_home> I use 4dos and have ls aliased to dir
[11:08:58] <jthornton> thanks
[11:09:09] <jthornton> I'm using freedos
[11:10:16] <pcw_home> freedos can use the 4dos shell
[11:14:08] <jthornton> what does 4dos do?
[11:17:54] <jepler> I don't remember particularly, but circa 28 years ago it was much better than COMMAND.COM.
[11:18:00] <pcw_home> it replaces command.com (the shell) and adds many features like command history
[11:18:25] <pcw_home> it has a nicer command history interface than most unix shells
[11:18:44] <pcw_home> and a much smarter copy command
[11:21:27] <jepler> https://en.wikipedia.org/wiki/4DOS#Features
[11:21:37] <jepler> in the waning days of DOS games this one was key: A more sophisticated swapping mechanism, yielding more free conventional memory on most systems
[11:22:07] <jepler> I remember it had some way I could open my text editor on the whole environment, which I could edit and save both to the running shell and for future reboots
[11:22:37] <jepler> > the source code is available under a modified MIT License but it "may not be used in any commercial product without written permission from Rex Conn"[2] and "may not be compiled for use on any operating system other than FreeDOS" so it does not qualify as open source as defined by Open Source Initiative.[3]
[11:22:45] <jepler> too bad
[11:23:27] <pcw_home> yeah thats sort of strange
[11:26:14] <pcw_home> BTW we dug up the source for the macro processor used with our embedded CPUs
[11:26:16] <pcw_home> (It was written by Gilberts son many years ago)
[11:28:01] <jepler> pcw_home: very cool. I did purchase a license to the unmodified assembler at some point, but because I didn't have your mods it was not useful for getting closer to the ideal of rebuilding the embedded firmwares in hostmot2-firmware
[11:30:24] <pcw_home> Ill send it if you want it. I think thats all thats needed to make a working toolchain for linux
[11:32:00] <jepler> I would like to have that, even if I'm not likely to work on it right away
[11:32:32] <pcw_home> BTW we have verified what you saw, that theres a bug in SSLBP where the error status bits are sticky when they should get cleared every doit
[11:33:40] <pcw_home> we should be able to fix it in Version 45 but its fairly subtle (not obvious from the code at all)
[11:34:35] <jepler> pcw_home: OK. If you do have a fixed version with a bumped fw version number, I think the hal driver can check that and change its behavior accordingly
[11:34:57] <pcw_home> Yeah that would be great
[11:35:35] <pcw_home> we did fix the 7I84 encoder bug (also on 7I69)
[12:01:43] <jepler> great
[12:01:57] <jepler> is there anything linuxcnc needs to do, or workarounds that can be removed, when a fixed version is detected?
[12:17:04] <pcw_home> the error response for local com errors will be different
[12:18:38] <pcw_home> I think some of the sserial errors are missed by the filter now also ( "doit not cleared from previous cycle" is not filtered for example)
[12:21:13] <pcw_home> Also filtered out errors _should_ be counted
[12:53:38] <linuxcnc-build> build #3054 of 4006.deb-lucid-rtai-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4006.deb-lucid-rtai-i386/builds/3054 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[13:03:59] <seb_kuzminsky> ruh ro
[13:04:49] <linuxcnc-build> build #3058 of 4003.deb-lucid-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4003.deb-lucid-i386/builds/3058 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[13:05:35] <linuxcnc-build> build #1066 of 4014.deb-wheezy-rtpreempt-i386 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4014.deb-wheezy-rtpreempt-i386/builds/1066 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[13:06:35] <linuxcnc-build> build #3057 of 4004.deb-lucid-amd64 is complete: Failure [4failed shell_3] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4004.deb-lucid-amd64/builds/3057 blamelist: Chris Morley <chrisinnanaimo@hotmail.com>
[13:06:38] <seb_kuzminsky> all the deb builders will fail now beacuse i messed up the buildmaster config
[13:48:34] <seb_kuzminsky> maybe this time
[13:53:19] <skunkworks_> heh - Thank you for keeping the buildbots running
[13:54:00] <seb_kuzminsky> yep
[13:54:03] <seb_kuzminsky> back in a bit
[14:00:38] <jepler> so what I think I am seeing is: when returning to "machine on" after a following error, a previous cartesian position axes[*].teleop_tp.curr_pos is copied into emcmotStatus->carte_pos_cmd, which has kinematicsInverse run on it, and that is what steps the joint command
[14:00:53] <jepler> starting around control.c:1325
[14:00:58] <jepler> case EMCMOT_MOTION_TELEOP
[14:01:19] <jepler> so maybe a spot where teleop_tp.curr_pos gets updated during machine-off state is needed
[14:01:53] <jepler> halcmd: setp joint.0.motor-pos-fb 0
[14:01:53] <jepler> halcmd: setp joint.0.motor-pos-fb 100
[14:02:01] <jepler> also it's a bit surprising that doing this doesn't change the DRO
[14:02:19] <jepler> (DRO showing cartesian coordinates)
[14:02:53] <jepler> config is ../configs/sim/axis/axis.ini
[14:28:17] <skunkworks__> It didn't make sense what the axis was showing when I would set the fb pin. On 2.7 if I set it to 10 - the dro says 10
[14:31:48] <jepler> it may not even be running forward kinematics while the machine is off
[14:31:49] <jepler> ?
[14:33:11] <skunkworks__> maybe? I don;t know - like I setp'ed it to 10 and the dro says 8.984 now
[14:33:16] <skunkworks__> (was zero)
[14:33:32] <jepler> in 2.7?
[14:33:34] <cradek> if you've homed, that might be right
[14:33:38] <skunkworks__> no - JA
[14:33:39] <cradek> I think?
[14:33:54] <jepler> in ja in "machine off" mode it wasn't changing at all for me
[14:34:55] <jepler> if you homed (have motor offsets) the results could be different
[14:36:36] <skunkworks__> well - with it homed I see pos is 1.01535
[14:36:53] <skunkworks__> *Xpos (joint.0.motor....)
[14:37:04] <skunkworks__> why would that be if it was homed with no offsets?
[14:37:33] <skunkworks__> (machine and relative are both 0)
[15:16:06] <cradek> skunkworks__: does it have a simulated index?
[15:17:55] <skunkworks__> NO
[15:17:59] <skunkworks__> sorry
[15:18:00] <skunkworks__> no
[15:22:13] <jepler> offsets?
[15:22:18] <jepler> like g54?
[15:26:13] <skunkworks__> (machine and relative are both 0)
[15:26:21] <jepler> oh I see you said that once already
[15:26:26] <jepler> backlash?
[15:26:37] <skunkworks__> wow - that would be a lot :)
[15:26:39] <skunkworks__> none in the ini
[15:28:13] <skunkworks__> bbl
[15:36:54] <jepler> sedol now 0/2 :-/
[15:41:40] <seb_kuzminsky> jepler: it's interesting how he played so differently in games 1 and 2, and how well alphago handled both those styles
[15:44:54] <jepler> how many games played by alphago are public at this point? Did Sedol have more than the games aganst Fan to study?
[17:16:36] <seb_kuzminsky> linuxcnc-build: force build --branch=master 0000.checkin
[17:16:37] <linuxcnc-build> build #3967 forced
[17:16:37] <linuxcnc-build> I'll give a shout when the build finishes
[18:19:53] <linuxcnc-build> Hey! build 0000.checkin #3967 is complete: Success [3build successful]
[18:19:53] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3967
[18:30:53] <seb_kuzminsky> ~1 hour for a build, that's about right
[18:32:35] <seb_kuzminsky> linuxcnc-build: force build --branch=2.7 0000.checkin
[18:32:39] <linuxcnc-build> build forced [ETA 1h03m15s]
[18:32:39] <linuxcnc-build> I'll give a shout when the build finishes
[18:47:25] <skunkworks> zlog
[20:06:43] <linuxcnc-build> build #1757 of 4017.deb-wheezy-amd64 is complete: Failure [4failed apt-get-update shell_1] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/4017.deb-wheezy-amd64/builds/1757
[20:24:38] <linuxcnc-build> Hey! build 0000.checkin #3968 is complete: Success [3build successful]
[20:24:38] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3968
[21:57:31] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch 0000.checkin
[21:57:32] <linuxcnc-build> build forced [ETA 1h27m36s]
[21:57:32] <linuxcnc-build> I'll give a shout when the build finishes
[23:26:26] <linuxcnc-build> Hey! build 0000.checkin #3969 is complete: Success [3build successful]
[23:26:26] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3969
