Back
[05:35:54] <jthornton> cool
[05:56:45] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15nicokid commented on issue #33: Hi Jeff,... 02
https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-226149199
[06:41:02] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #33: @nicokid, Thank you for giving it a try. I agree, some parts of git take time to learn. But I think you'll become comfortable with it with time.... 02
https://github.com/LinuxCNC/linuxcnc/pull/33#issuecomment-226157889
[07:03:31] <skunkworks> heh - andys replay is hilarious..
[07:10:02] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf be1995e 06linuxcnc 10(14 files) Remove some comments * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=be1995e
[07:10:02] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf ac6f6c7 06linuxcnc 10src/emc/usr_intf/stepconf/main_page.glade 10src/emc/usr_intf/stepconf/pages.py Remove unused button * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=ac6f6c7
[07:10:02] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf 2e1d703 06linuxcnc 03lib/python/multifilebuilder_gtk3.py Create multifilebuilder_gtk3.py * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2e1d703
[07:10:04] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf fdb4f52 06linuxcnc 10src/emc/usr_intf/stepconf/stepconf.py Add label when append_page on notebook1 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fdb4f52
[07:10:08] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf b5e0adb 06linuxcnc 10(7 files) Add halui page tab * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b5e0adb
[07:10:12] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf c35d60d 06linuxcnc 10src/emc/usr_intf/stepconf/halui_page.glade Move halui page from gtk 3.12 to 3.2 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c35d60d
[07:10:16] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf a75419a 06linuxcnc 10src/emc/usr_intf/stepconf/options.glade Update options.glade * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a75419a
[07:10:20] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf a6b1eab 06linuxcnc 10src/emc/usr_intf/stepconf/pages.py Update pages.py to correct typo * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a6b1eab
[07:10:24] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf f36c2b5 06linuxcnc 10src/emc/usr_intf/stepconf/start.glade Update start.glade * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f36c2b5
[07:10:28] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf 9a5cd32 06linuxcnc 10src/emc/usr_intf/stepconf/options.glade Update again option.glade * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a5cd32
[07:10:32] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf a3a3037 06linuxcnc 10src/emc/usr_intf/stepconf/options.glade Update again option.glade * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a3a3037
[07:10:36] <KGB-linuxcnc> 03Nicola Quargentan 05jepler/master/nikokid-stepconf 0b3ec8c 06linuxcnc 10src/emc/usr_intf/pncconf/build_HAL.py 10src/emc/usr_intf/stepconf/build_HAL.py 10src/emc/usr_intf/stepconf/build_INI.py 10src/emc/usr_intf/stepconf/stepconf.py custom_postgui.hal will not be overwritten * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b3ec8c
[07:40:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 7058bf6 06linuxcnc 10src/configure.in configure: check if clock_nanosleep is available * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7058bf6
[07:40:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 7154eb8 06linuxcnc 10src/rtapi/uspace_common.h rtapi_delay: respect rtapi_delay_max, per documentation * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7154eb8
[07:40:19] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 9a0581e 06linuxcnc 10src/rtapi/rtai_ulapi.c 10src/rtapi/rtapi.h 10src/rtapi/uspace_common.h rtapi: add rtapi_delay{,_max} to ULAPI * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9a0581e
[07:40:22] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep e80319e 06linuxcnc 10src/hal/hal_lib.c hal: Use rtapi_delay in stream wait ops * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e80319e
[07:40:27] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 17b002d 06linuxcnc 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc uspace: introduce, use rtapi_clock_nanosleep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=17b002d
[07:43:32] <KGB-linuxcnc> 05jepler/master/nicokid-stepconf 0b3ec8c 06linuxcnc branch created * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0b3ec8c
[08:01:35] <skunkworks> cool!
[08:17:34] <jepler> skunkworks: if you have the time, it would be awesome if you could test stepconf in the branch jepler/master/nicokid-stepconf
[08:17:45] <jepler> I am not a very good stepconf user, I just click "next" until it lets me go
[08:18:04] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #71: Jepler/master/nicokid stepconf (06master...06jepler/master/nicokid-stepconf) 02
https://github.com/LinuxCNC/linuxcnc/pull/71
[08:41:30] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #72: Jepler/master/missing clock nanosleep (06master...06jepler/master/missing_clock_nanosleep) 02
https://github.com/LinuxCNC/linuxcnc/pull/72
[08:41:56] <skunkworks> jepler, I will try it when I get a chance. (I don't use it either - but know atleast how it should work)
[12:19:57] <andypugh> Do any of the tests run in different locales? I am trying to figure out why PnCConf doesn’t work in French:
https://forum.linuxcnc.org/forum/39-pncconf/31103-how-to-link-inputs-outputs-for-mesa-5i25-7i76?limitstart=0#76101
[12:29:25] <jepler> andypugh: no, we don't routinely test in other locales
[12:31:36] <andypugh> I am not about to volunteer, but it would probably be a good idea.
[13:22:49] <jepler> that is bumper sticker material, you just need to shorten it up a bit
[13:37:59] <andypugh> “I have a great idea for you” ?
[13:49:41] <jepler> not bad
[13:58:00] <seb_kuzminsky> jepler: i left some comments on your nanosleep PR, and was surprised that we didn't get a ping here
[13:58:06] <seb_kuzminsky> did you get notified by github about it?
[14:04:08] <jepler> seb_kuzminsky: huh
[14:04:15] <jepler> let me look
[14:04:45] <jepler> > (typo) The max delay is 999,999,999ns, not microseconds like it says in the commit message.
[14:05:06] <jepler> I think commenting on a PR is different than commenting on a diff
[14:05:31] <seb_kuzminsky> hmm yeah
[14:08:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep cb3bdc3 06linuxcnc 10src/rtapi/rtai_ulapi.c 10src/rtapi/rtapi.h 10src/rtapi/uspace_common.h rtapi: add rtapi_delay{,_max} to ULAPI * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cb3bdc3
[14:08:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep def227e 06linuxcnc 10src/hal/hal_lib.c hal: Use rtapi_delay in stream wait ops * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=def227e
[14:08:01] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/missing_clock_nanosleep 7e20ab1 06linuxcnc 10src/rtapi/uspace_common.h 10src/rtapi/uspace_rtapi_app.cc uspace: introduce, use rtapi_clock_nanosleep * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7e20ab1
[14:08:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #72: .. I fixed the typo in one of the commit messages. 02
https://github.com/LinuxCNC/linuxcnc/pull/72#issuecomment-226281149
[14:11:55] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #72: .. in case the force-push makes the other comments disappear, the reason I forward-declare the static rtapi_clock_nanosleep is because uspace_common.h is not included until later, and I didn't care to decypher and correct why that happened to be the case. 02
https://github.com/LinuxCNC/linuxcnc/pull/72#issuecomment-226282126
[14:14:10] <andypugh> Does anyone kow offhand what emcsched.cc is for?
[14:14:47] <jepler> andypugh: it is something that should be deleted
[14:15:04] <andypugh> Is it used?
[14:15:07] <jepler> I believe it is a piece of software that is supposed to schedule when to run part programs
[14:15:35] <seb_kuzminsky> yeah, looks like an old coprolite
[14:15:35] <andypugh> That sort-of fits. It seems good at files, but also knows about spindles and tools but not axes
[14:16:09] <andypugh> Right, I will fix it to compile and not care about making it work (ie, assume spindle 0 is the only spindle)
[14:39:17] <seb_kuzminsky> jepler: looks good, thanks
[14:55:12] <jepler> I'm not convinced that trying to emulate clock_nanosleep with nanosleep is really a good idea, but I don't know what other sleep-type primitive there might be on freebsd that is closer to t
[14:55:18] <jepler> s/t$/it/
[18:35:38] <andypugh> You know, we don’t seem 100% sure whether the number of joints is passed to motion as a modparam, or read by components from the INI
[18:40:57] <andypugh> And if they don’t match, it is bad.
[18:41:24] <andypugh> This sort of bad:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.64.6357&rep=rep1&type=pdf
[18:41:39] <andypugh> No, ignore that. Wrong paste
[18:41:51] <andypugh> That’s a paper about NML.
[18:43:15] <andypugh> This sort of bad: [17641.802816] BUG: unable to handle kernel paging request at 68a8a76d
[18:44:33] <jepler> *whispers* uspace
[18:45:03] <jepler> unless you're developing a hardware driver, it is pretty hard for uspace to wedge the system so hard a reboot is needed before you can run linuxcnc again
[18:45:26] <jepler> but I think that's typically the case with rtai kernel-based realtime once you get that kind of bad
[18:45:58] <seb_kuzminsky> it'd be great to use uspace and gdb and things to find the cause of the wedge, and fix it for both
[18:46:21] <andypugh> The machine didn’t crash.
[18:46:45] <andypugh> I think I pasted a secondary problem
[18:46:54] <andypugh> There is also [17637.494674] BUG: unable to handle kernel NULL pointer dereference at (null)
[18:52:02] <andypugh> Has anyone got a non-JA config to play with easily? I got this by telling motion that num_joints was 5 and having [KINS] JOINTS = 6 in the INI. I rather expect that the same problem is there in normal LinuxCNC if you use a num_joints < [TRAJ]AXES
[18:53:00] <jepler> in master branch, no [KINS]JOINTS in inifiles as far as I see
[18:53:22] <andypugh> Basically the num_joints passed to motion doesn’t propagate as widely as you might expect. But as lots of code assumes 9, it has tended to work
[18:54:34] <andypugh> I only noticed this because I was trying to clone code with num_spindles and noticed how many versions of such data there is.
[18:55:33] <andypugh> jepler: No, [KINS}JOINTS is JA-only. Closest equivalent in Master is [TRAJ]AXES
[18:56:23] <andypugh> Nearly every config has num_joints=[TRAJ]AXES so this issue isn’t seen.
[18:58:57] <andypugh> I don’t know the answer. If you want to be able to loadrt motmod in standalone sessions without an INI file then you need the modparam option.
[18:59:23] <andypugh> Of course, that assumes that such a thing is possible. <experiment>
[19:09:01] <jepler> of course motion can't directly obtain inifile items
[19:09:28] <jepler> presently, it does obtain some inifile items indirectly from task, but this is unfortunate (for a reason I'll explain in a moment) so I wouldn't want to add to the list of problems
[19:09:31] <andypugh> Ah, no, realtime = no file access
[19:10:04] <jepler> the linuxcnc script is complicated, and it would be nice if it could be replaced by something simpler
[19:10:25] <jepler> for instance, it would say to loadusr task
[19:11:00] <jepler> but it can't in its present form, and it has something to do with how motion and task both have to talk to each other before they can finish creating all their pins
[19:11:09] <jepler> (dangit I thought I had recorded the details of this :-P)
[19:11:16] <andypugh> Maybe we need to propogate num_joints upstream to a point that it can be compared to [TRAJ]AXES and / or [KINS}JOINTS and give a nice clear error messag if they fail to match.
[19:11:39] <jepler> if instead you could loadusr the one and loadrt the other, but you had to say foo=[TRAJ]AXES to motion or your configuration is broken, that would be better to me
[19:11:59] <jepler> and yes, you can add "compare the value here and there" in the right spot and catch this, instead of crashing in kernel space
[19:12:04] <jepler> that's always for the better
[19:12:33] <andypugh> I am curious if this is a purely JA problem or can be seen in Master
[19:12:56] <jepler> I wouldn't sweat it toooo much, it's a blatant misconfiguration to begin with
[19:14:46] <andypugh> It’s a nasty one though. It will confuse users. Even if they fix the problem LinuxCNC will still “crash” because the null pointer issue leaves RTAI modules in an unrecoverable tangle.
[19:17:30] <andypugh> <ponder> Should the next default release be Uspace, with a clear suggestion that a higher-performance but much more flaky option is available for parallel-port fondling Morlocks?
[19:18:12] <cradek> you mean next iso?
[19:18:36] <cradek> I hadn't considered that and you're right we should consider it
[19:18:56] <andypugh> Yes, I mean the ISO
[19:23:54] <jepler> andypugh: fwiw I can cause the crash in ja e.g., by changing core_sim.hal to num_joints=3 and axis.ini to [KINS]JOINTS=9
[19:24:03] <andypugh> Alex put a rather swanky HAL FIELDS #define in halui.cc, but it isn’t used by the pin creation code, which seems a shame.
[19:24:19] <jepler> /* output joint info to HAL for scoping, etc */
[19:24:19] <jepler> for (joint_num = 0; joint_num < emcmotConfig->numJoints; joint_num++) {
[19:24:23] <skunkworks> I don't know... I think most people initially use the printer port...
[19:25:09] <andypugh> skunkworks: That will still work, and can probably keep up with some hardware.
[19:25:56] <jepler> /* export joint pins and parameters */
[19:25:56] <jepler> for (n = 0; n < num_joints; n++) {
[19:26:15] <andypugh> skunkworks: But you have a point, if we have a reputation for higher performance than Mach on parport then the change will kill that. But perhaps a reputation of beig easy to get going is worth it?
[19:26:17] <jepler> so emcmotConfig->numJoints is the inifile value via task, and num_joints is the loadrt value
[19:27:08] <andypugh> jepler: You figured that out by inspection or debugging the numbers?
[19:27:20] <skunkworks> andypugh, maybe - I might seriously consider 2 iso's... But I can't say that because I don't know the work involved...
[19:27:21] <jepler> andypugh: with uspace I could stop right at the segfault
[19:27:25] <jepler> Program received signal SIGSEGV, Segmentation fault.
[19:27:26] <jepler> [Switching to Thread 0x7ffff7f86700 (LWP 6536)]
[19:27:26] <jepler> output_to_hal () at emc/motion/control.c:1794
[19:27:26] <jepler> 1794 *(joint_data->motor_offset) = joint->motor_offset;
[19:27:32] <jepler> then I grepped around for where the pin was created
[19:28:53] <andypugh> My plan was to propagate num_spindles from motion upwards.
[19:29:59] <andypugh> My feeling is that we ought to do the same for num_joints. ie, motion can get it from the INI via the halfile if wanted, but the num_joints modparam is the definitive number and no other code should look anywhere else.
[19:31:47] <andypugh> But I am fairly sure that Master and friends are just as confused here, and this is a niggle to settle after the merge I am hoping for ;-)
[19:37:53] <jepler> andypugh:
https://emergent.unpythonic.net/files/sandbox/0001-motion-show-a-diagnostic-for-joints-misconfiguration.patch
[19:38:37] <jepler> so now I start linuxcnc and get: "Cannot set number of joints to 9, motion was loaded with max joints 3. Normal configuration has loadrt motion ... joints=[KINS]JOINTS
[19:38:40] <jepler> "
[19:40:35] <andypugh> Hmm. My Wifi just died.
[19:40:52] <andypugh> Luckily I could plug in a lump of copper
[19:41:23] <jepler> andypugh:
https://emergent.unpythonic.net/files/sandbox/0001-motion-show-a-diagnostic-for-joints-misconfiguration.patch
[19:44:08] <andypugh> Should it be != rather than > in the test?
[19:44:44] <jepler> maybe
[19:45:07] <jepler> the message would also need a slight tweak in that case
[19:45:14] <jepler> if you want to decide and change it, please be my guest.
[19:46:15] <andypugh> I see that you chose to just crop the numJoints rather than exit with an error.
[19:46:28] <andypugh> I can see an argument both ways.
[19:48:42] <andypugh> Having followed all too many support threads, I think I like “start linuxCNC with a warning” best. Users tend to just see the error report as a “Crash!” don’t read it, and come whining to the forum.
[19:49:06] <andypugh> noobs! When it was me I came whining to the IRC :-)
[19:51:25] <andypugh> On reflection, your patch is adequate and catches an unusual misconfiguration. Misconfiguring the other way is just untidy, rather than problematic.
[19:52:22] <andypugh> Also, I am so deep in something else that backtracking to somewhere to fix this would confuse me.
[20:09:35] <andypugh> I think this guy is being grateful and friendly. So how does he manage to come over condescending?
http://codepad.org/ykuWz1tj
[20:10:42] <cradek> it does feel odd, but I agree he's probably a nice guy
[20:12:38] <andypugh> I think it is the tacit assumption that he knows more about machines and metallurgy than me.
[20:15:14] <andypugh> There again, whilst I know that lots of people know more about those two subjects than me, I am not sure I actually believe it. :-)
[20:18:21] <andypugh> I can watch someone doing any kind of making-things job and be sure I could do it better. It’s probably a pathology.
[20:21:22] <skunkworks> I think it is human nature.. some hide it better than others.
[20:21:56] <andypugh> However, I do know know that you guys are all better coders than me, and if jepler thinks that patch does the trick, it should be pushed.
[20:24:22] <jepler> you're very kind
[20:24:27] <jepler> I am abrasive jerk but I'm working on it
[20:25:49] <skunkworks> http://electronicsam.com/images/house/sully.jpg
[20:25:54] <skunkworks> unrelated...
[20:26:03] <skunkworks> Just really cute if I do say so my self..
[20:27:01] <jepler> darn I was hoping for a cat pic. I mean, cute -- how old now?
[20:27:10] <jepler> is the number written there in some way a clue?
[20:27:44] <andypugh> the 19 dots probably arent’
[20:29:43] <skunkworks> one in april
[20:33:12] <jepler> http://www.printing-machine.org/notes/2016/6/4/printing-cliches
[20:33:58] <jepler> any blog which includes melting "type metal" on a kitchen stove is probably a good one
[20:34:24] <skunkworks> http://electronicsam.com/images/house/squirts.jpg
[20:35:42] <andypugh> jepler: Fascinating
[20:36:43] <andypugh> skunkworks: I don’t know how much hair is traditonal at that age but ?
[20:37:23] <andypugh> Is he destined for a career as a swimmer?
[20:37:57] <skunkworks> it is not uncommon.. stella took a long time to get her hair too.
[20:38:12] <skunkworks> just not this long ;)
[20:40:43] <andypugh> There is a famous (in the UK) Olympic gold-medal winning swimmer (Duncan Goodhew) who had no hair at all. There was speculation that it was an unfair advantage.
[20:43:05] <jepler> an unf-hair advantage
[20:46:43] <skunkworks> he does have really short fine blond hair.. so he looks balled
[20:48:49] <andypugh> Eep! look at the time! Time to sleep
