hm, I wonder why jon concluded there's no fabs
it's already used in existing drivers
src/hal/drivers/mesa-hostmot2/pwmgen.c: abs_duty_cycle = fabs(scaled_value);
his new code isn't equivalent to the old (when negative scales are involved)
I see that now, too
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
jthornton_ is now known as jthornton
* cpresser finished his patch for halui, which allows named mdi-commands. now, where should I put it for code review?
JT-Work_ is now known as JT-Work
ries_ is now known as ries
* cpresser did upload his patch here: http://ca.rstenpresser.de/~cpresser/tmp/emc2.5pre_lenny/patches/
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
there is an issue with O<file> calls with M66, probing and other commands resulting in INTERP_EXECUTE_FINISH return value
i'm trying to minimize patch that implements continuation of interrupted mdi calls
unfortunately it's quiet intrusive now
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..
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..
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
+ named_mdi_commands_names[num_named_mdi_commands] = strdup(mc1);
+ named_mdi_commands[num_named_mdi_commands] = strdup(mc2);
patch for review: improving homing error messages: http://codepad.org/8piHJGaK
it's for master but I wonder if it fits 2.4
[16:31:08] <psha> http://pastebin.com/6Bi8KWUt
patch for src/emc/rs274 subtree adding flag to check interrupted calls
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
i've tested it a bit and at a first glance it seem working )
micges: I'm sure you know that it doesn't apply as-is to 2.4 since there are no _() there..
do you frequently run into homing problems where it's not clear what joint is the problem?
it's not problem for me
but customer will read me messages that will mean soemthing
frequently no, but messages about active or inactive switch or hitting limit on state 5 are frequent (due switches problems)
psha: I've read your patch but I don't grasp how it fixes the problem.. (I am familiar with the problem, though)
it's one of two patches
second is based on it and implements readahead_reading-like function in emc/task/emctaskmain.cc
second, pretty dirty
afk for ~10 minutes
jepler: it's ok I'll aplly it to 2.4 and then someone (me) merge 2.4 to master?
psha: I'm excited that someone is digging into the problem
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
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
but since your solution is looking at whether an O-sub is in progress, I'm not sure it will fix this case
jepler: i'm back
second patch may be improved to handle such cases
only needed thing is to queue commands and not interpret them
problem you described is src/emc/task local
psha: I see.
also as i see now my patch may cause some funny effects when two commands are queued
i'll take a cup of tea and try to fix it
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
EMC: 03jepler 07master * r8597c320e6f8 10/src/po/pl.po: Update polish translation
EMC: 03jepler 07master * r4e73474ae112 10/src/emc/usr_intf/axis/scripts/emctop.py: emctop: make it translatable
EMC: 03jepler 07master * ra245338c5976 10/src/emc/rs274ngc/interp_convert.cc: Fix incorrectly scaling ABC tool lengths by 25.4
EMC: 03jepler 07master * r81a0feffaca3 10/src/rtapi/rtapi_math.h: provide isnan in realtime
EMC: 03jepler 07master * rcf709e3bb5ea 10/ (VERSION debian/changelog): release v2.4.4
EMC: 03jepler 07master * r2c7d59c009f1 10/src/emc/rs274ngc/ (tool_parse.cc tool_parse.h): add missing copyright notices
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.
EMC: 03jepler 07master * r4d0975ce7bda 10/ (7 files in 5 dirs): Merge remote branch 'origin/v2.4_branch'
micges: thank you
jepler: what needed for G38.2 Z-10 commands? it complains about it
jepler: "cannot probe with zero feed rate"
psha: then specify a feedrate? G38.2 Z-10 F10
and how may i simulate probing?
i'm working with emc-sim
link pyvcp checkbox to motion.probe-in
psha: the config configs/sim/servo_sim.ini has a simulated probe
also mdi mode refuses to eat second command from me
complaining about "Queue is not empty after probing"
i have to disable this check?
I think that's part of the bug
emctaskmain.cc is C++ code? is std::queue suitable for that file?
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
does that last post make any sense about /etc/emc2/Makefile.Modinc
jepler: at least this file is working fine when called with O<probe> call
$ cat probe.ngc
G38.2 Z-1 F10
jthornton: does he install 10.04 from livecd or install rt kernel on desktop 10.04?
micges: I dont' know but I'll ask
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
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
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
but the problem report seemed to indicate it was a 10.04 system (because of the -122 in the kernel version)...
is it possible to issue empty MDI command? with command == 0?
jthornton__ is now known as jthornton
jepler: i've posted patches on the list for review
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
bb, going to sleep
hm, I've now gotten this twice .. I suspect it's the 64-bit version of that crash some users have reported in axis
[637032.596386] axis: segfault at 1 ip 00007ff7097c535e sp 00007fff597e77c0 error 4 in libc-2.11.1.so[7ff70977c000+17a000]
[637193.435621] axis: segfault at 1 ip 00007fa1d7fed35e sp 00007fffeaf78e40 error 4 in libc-2.11.1.so[7fa1d7fa4000+17a000]
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 -
actually, it's much easier than that. Run configs/sim/axis.ini. press F1 F2 end -
yuck, I'm the fool who introduced it, too. trying to improve an error message...
EMC: 03jepler 07v2.4_branch * r7c72911256d7 10/src/emc/rs274ngc/rs274ngc_pre.cc: axis: fix rs274 bug that led to crash in touch off
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