Back
[00:26:19] <jepler> hm, I wonder why jon concluded there's no fabs
[00:26:35] <jepler> it's already used in existing drivers
[00:26:35] <jepler> src/hal/drivers/mesa-hostmot2/pwmgen.c: abs_duty_cycle = fabs(scaled_value);
[00:50:59] <cradek> his new code isn't equivalent to the old (when negative scales are involved)
[01:04:09] <jepler> I see that now, too
[03:46:26] <jepler> maybe we need to add to hal some standard functions for converting to/from analog values like the docs claim hal analog I/Os all do. Something like:
http://emergent.unpy.net/files/sandbox/hal_tofrom_analog.c
[11:36:01] <jthornton_> jthornton_ is now known as jthornton
[14:02:55] <cpresser> * cpresser finished his patch for halui, which allows named mdi-commands. now, where should I put it for code review?
[15:08:35] <JT-Work_> JT-Work_ is now known as JT-Work
[15:24:09] <ries_> ries_ is now known as ries
[15:37:01] <cpresser> * cpresser did upload his patch here:
http://ca.rstenpresser.de/~cpresser/tmp/emc2.5pre_lenny/patches/
[16:15:59] <psha> i've digged a bit into g-code execution and it seem that i've found solution for correct exectution of O<file> calls in MDI mode
[16:17:04] <psha> there is an issue with O<file> calls with M66, probing and other commands resulting in INTERP_EXECUTE_FINISH return value
[16:18:12] <psha> i'm trying to minimize patch that implements continuation of interrupted mdi calls
[16:19:05] <micges> interesting
[16:20:04] <psha> unfortunately it's quiet intrusive now
[16:21:04] <jepler> cpresser: halui.cc is a C++ program, so you could use std::string when dealing with the mdi commands and their names. that should help you get rid of the strdup()s and the associated memory leaks..
[16:22:22] <jepler> otherwise, you're right that those strdup()s leak. you could fix it by assigning that return value to some other local variable, then free()ing that at the right time..
[16:22:58] <jepler> these strdup()s are right, in that the memory allocated by the strdup needed right up until the program exits, so there's no point in arranging to free it
[16:23:03] <jepler> + named_mdi_commands_names[num_named_mdi_commands] = strdup(mc1);
[16:23:03] <jepler> + named_mdi_commands[num_named_mdi_commands] = strdup(mc2);
[16:25:57] <micges> jepler: hi
[16:26:18] <jepler> hi micges
[16:26:33] <micges> patch for review: improving homing error messages:
http://codepad.org/8piHJGaK
[16:26:53] <micges> it's for master but I wonder if it fits 2.4
[16:31:08] <psha> http://pastebin.com/6Bi8KWUt
[16:31:44] <psha> patch for src/emc/rs274 subtree adding flag to check interrupted calls
[16:32:47] <psha> if INTERP_EXECUTE_FINISH is returned while processing call mdi_interrupt flag is set and next call to execute(0) continues to process from last command
[16:33:09] <psha> i've tested it a bit and at a first glance it seem working )
[16:35:17] <jepler> micges: I'm sure you know that it doesn't apply as-is to 2.4 since there are no _() there..
[16:35:40] <micges> yes
[16:35:41] <jepler> do you frequently run into homing problems where it's not clear what joint is the problem?
[16:36:21] <micges> it's not problem for me
[16:36:47] <micges> but customer will read me messages that will mean soemthing
[16:38:47] <micges> frequently no, but messages about active or inactive switch or hitting limit on state 5 are frequent (due switches problems)
[16:38:49] <jepler> psha: I've read your patch but I don't grasp how it fixes the problem.. (I am familiar with the problem, though)
[16:39:09] <psha> it's one of two patches
[16:39:29] <psha> second is based on it and implements readahead_reading-like function in emc/task/emctaskmain.cc
[16:40:18] <psha> jepler:
http://pastebin.com/00aGUJAN second, pretty dirty
[16:41:40] <psha> afk for ~10 minutes
[16:42:14] <micges> jepler: it's ok I'll aplly it to 2.4 and then someone (me) merge 2.4 to master?
[16:42:33] <jepler> psha: I'm excited that someone is digging into the problem
[16:48:10] <jepler> psha: you may want to also test the case where there's no subroutine, but two MDI commands issued one after the other, where the first one needs to finish before interpreting the second. Like G38.2 Z-10 / G0 Z[#5063+1] which (unless I wrote it wrong) should probe toward Z-10 then move to 1 inch (or mm) above the probed location
[16:48:41] <jepler> iirc, this will currently move sometimes to the coordinate specified by a *previous* G38.2, and I am guessing that it's related to this problem
[16:48:53] <jepler> but since your solution is looking at whether an O-sub is in progress, I'm not sure it will fix this case
[16:52:14] <psha> jepler: i'm back
[16:54:21] <psha> second patch may be improved to handle such cases
[16:54:48] <psha> only needed thing is to queue commands and not interpret them
[16:56:23] <psha> problem you described is src/emc/task local
[16:59:50] <jepler> psha: I see.
[17:00:34] <psha> also as i see now my patch may cause some funny effects when two commands are queued
[17:01:37] <psha> i'll take a cup of tea and try to fix it
[17:04:25] <jepler> psha: once you're satisfied with your patch I'd be happy to put it on master. Right now it is something I would not put on v2.4, at least until it's seen more testing
[17:07:45] <CIA-5> EMC: 03jepler 07master * r8597c320e6f8 10/src/po/pl.po: Update polish translation
[17:07:48] <CIA-5> EMC: 03jepler 07master * r4e73474ae112 10/src/emc/usr_intf/axis/scripts/emctop.py: emctop: make it translatable
[17:07:49] <CIA-5> EMC: 03jepler 07master * ra245338c5976 10/src/emc/rs274ngc/interp_convert.cc: Fix incorrectly scaling ABC tool lengths by 25.4
[17:07:52] <CIA-5> EMC: 03jepler 07master * r81a0feffaca3 10/src/rtapi/rtapi_math.h: provide isnan in realtime
[17:07:54] <CIA-5> EMC: 03jepler 07master * rcf709e3bb5ea 10/ (VERSION debian/changelog): release v2.4.4
[17:08:03] <CIA-5> EMC: 03jepler 07master * r2c7d59c009f1 10/src/emc/rs274ngc/ (tool_parse.cc tool_parse.h): add missing copyright notices
[17:08:12] <jepler> micges: OK, go ahead with that change on v2.4_branch and take care of the merge to master. There were a few trivial conflicts already, so I did a merge so you didn't have to deal with them.
[17:08:21] <CIA-5> EMC: 03jepler 07master * r4d0975ce7bda 10/ (7 files in 5 dirs): Merge remote branch 'origin/v2.4_branch'
[17:08:32] <jepler> bbl
[17:09:17] <micges> cool
[17:10:05] <jepler> micges: thank you
[17:11:26] <micges> np
[17:11:32] <psha> jepler: what needed for G38.2 Z-10 commands? it complains about it
[17:12:12] <psha> jepler: "cannot probe with zero feed rate"
[17:12:30] <jepler> psha: then specify a feedrate? G38.2 Z-10 F10
[17:12:59] <psha> good
[17:13:27] <psha> and how may i simulate probing?
[17:13:34] <psha> i'm working with emc-sim
[17:15:36] <micges> link pyvcp checkbox to motion.probe-in
[17:15:47] <jepler> psha: the config configs/sim/servo_sim.ini has a simulated probe
[17:16:10] <psha> thanks
[17:16:22] <psha> also mdi mode refuses to eat second command from me
[17:16:40] <psha> complaining about "Queue is not empty after probing"
[17:16:56] <psha> i have to disable this check?
[17:17:06] <jepler> I think that's part of the bug
[17:23:29] <psha> emctaskmain.cc is C++ code? is std::queue suitable for that file?
[17:24:21] <micges> yes
[17:38:32] <psha> jepler: still failing to setup correct fake probing... (
[17:39:49] <jthornton> http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,10/id,3603/limit,6/limitstart,48/lang,english/#4352
[17:41:08] <jthornton> does that last post make any sense about /etc/emc2/Makefile.Modinc
[17:48:15] <psha> jepler: at least this file is working fine when called with O<probe> call
[17:48:22] <psha> $ cat probe.ngc
[17:48:22] <psha> O<probe> sub
[17:48:22] <psha> G38.2 Z-1 F10
[17:48:22] <psha> G0 Z[#5063+1]
[17:48:22] <psha> O<probe> endsub
[17:48:24] <psha> M2
[17:50:17] <micges> jthornton: does he install 10.04 from livecd or install rt kernel on desktop 10.04?
[17:50:44] <jthornton> micges: I dont' know but I'll ask
[17:50:48] <jepler> jthornton: maybe some previous version of emc2 put Makefile.modinc in /etc/emc2, but the current package puts it in /usr/share/emc/Makefile.modinc
[17:51:05] <jthornton> jepler: thanks
[17:51:48] <jepler> if you have /etc/emc2/Makefile.modinc (for instance from an old installation that used that path) then 'comp --print-modinc' will use that in preference to the one in /usr/share .. but if so, your best corrective action is simply to remove that one and use the one in /usr/share
[17:53:35] <jepler> it looks like the modinc file was moved between emc2.3 and emc2.4, so an 8.04 system upgraded from 2.3 to 2.4 might display this symptom
[17:54:03] <jepler> but the problem report seemed to indicate it was a 10.04 system (because of the -122 in the kernel version)...
[18:26:24] <psha> is it possible to issue empty MDI command? with command[0] == 0?
[19:36:55] <jthornton__> jthornton__ is now known as jthornton
[19:47:25] <psha> jepler: i've posted patches on the list for review
[19:47:39] <psha> also queing is very simple on top of these
[19:50:09] <psha> http://pastebin.com/MFDM7Gu1 something like this but with correct handling for resets
[20:06:59] <psha> bb, going to sleep
[20:44:26] <jepler> hm, I've now gotten this twice .. I suspect it's the 64-bit version of that crash some users have reported in axis
[20:44:30] <jepler> [637032.596386] axis[20429]: segfault at 1 ip 00007ff7097c535e sp 00007fff597e77c0 error 4 in libc-2.11.1.so[7ff70977c000+17a000]
[20:44:33] <jepler> [637193.435621] axis[20549]: segfault at 1 ip 00007fa1d7fed35e sp 00007fffeaf78e40 error 4 in libc-2.11.1.so[7fa1d7fa4000+17a000]
[20:45:14] <jepler> both times I had had a program abort with an error (probe move ended without contact), hit end to touch off an axis, then (I think) typed -
[20:46:17] <jepler> actually, it's much easier than that. Run configs/sim/axis.ini. press F1 F2 end -
[20:46:20] <jepler> kaboom!
[20:54:41] <jepler> yuck, I'm the fool who introduced it, too. trying to improve an error message...
[20:55:23] <CIA-5> EMC: 03jepler 07v2.4_branch * r7c72911256d7 10/src/emc/rs274ngc/rs274ngc_pre.cc: axis: fix rs274 bug that led to crash in touch off
[20:58:43] <skunkworks> heh
[21:04:24] <jepler> yuck, I wish I'd found this before 2.4.4. failing that, I wish I'd found it early enough in the weekend to make 2.4.5, because this bug is a real pain in the rear