#emc-devel | Logs for 2010-11-01

Back
[00:18:20] <ries_> ries_ is now known as ries
[00:50:44] <skunkworks> logger_dev: bookmark
[00:50:44] <skunkworks> Just this once .. here's the log: http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2010-11-01.txt
[01:45:05] <jepler> Returned Value: int
[01:45:05] <jepler> If any of the following errors occur, this returns the error code shown.
[01:45:05] <jepler> Otherwise, it returns INTERP_OK.
[01:45:05] <jepler> 1. An A-axis value is given with a canned cycle (g80 to g89):
[01:45:05] <jepler> NCE_CANNOT_PUT_AN_A_IN_CANNED_CYCLE
[01:45:23] <jepler> if (block->a_flag != OFF) {
[01:45:23] <jepler> CHKS(((block->g_modes[1] > G_80) && (block->g_modes[1] < G_90)),
[01:45:23] <jepler> NCE_CANNOT_PUT_AN_A_IN_CANNED_CYCLE);
[01:45:23] <jepler> }
[01:45:54] <jepler> the code to reject it's there, it's just not working for some reason
[01:50:35] <jepler> .. because using block->g_modes[1] is the wrong thing?
[01:50:49] <jepler> "g81 a90" is rejected, "g81" ... "a90" is accepted
[01:53:38] <jepler> cradek: what's the state of uvw in canned cycles? should they be rejected just like abc?
[02:06:05] <cradek> they work correctly when in uvw-related planes (g17.1 .. g19.1)
[02:06:39] <cradek> when in xyz-related planes, they should probably be rejected? not sure what sane behavior you would expect in that case.
[02:13:20] <jepler> It looks like down inside the canned cycle code there are only 3 axes, so you can't move the other 3
[02:13:41] <jepler> so g17/18/19 reject UVW and in g17.1/18.1/19.1 reject XYZ?
[02:13:47] <cradek> yes
[02:13:57] <cradek> and always reject abc, I guess
[02:21:09] <cradek> jepler:
[02:21:12] <cradek> http://timeguy.com/cradek-files/emc/2010-10-31_17-51-40_109.jpg
[02:21:13] <cradek> http://timeguy.com/cradek-files/emc/2010-10-31_17-51-57_353.jpg
[02:21:13] <cradek> http://timeguy.com/cradek-files/emc/2010-10-31_17-52-13_194.jpg
[02:21:13] <cradek> http://timeguy.com/cradek-files/emc/2010-10-31_17-52-29_290.jpg
[02:21:13] <cradek> http://timeguy.com/cradek-files/emc/2010-10-31_17-52-40_898.jpg
[02:26:53] <jepler> the setscrew goes right in the leadscrew? cunning!
[02:27:00] <jepler> or is it a pin?
[02:27:21] <cradek> it's a spring pin
[02:27:38] <cradek> the motor shafts are drilled for them
[02:27:56] <cradek> but yeah - I love the simplicity - much better than making a coupling. it's very concentric.
[02:28:28] <cradek> the tapped hole above the indicator shaft is for a locking screw, so they are adjustable for alignment
[02:28:37] <jepler> you'll put the limit switches on the motor side somehow?
[02:29:06] <cradek> no, I was thinking they'd be on the indicator end, so you can see all the various steps interacting with the switches
[02:29:33] <cradek> I think they should trip in the middle of the indicator travel somewhere
[02:30:27] <jepler> I see your point
[02:30:33] <cradek> oh you said limit switches - I read home switches
[02:30:43] <jepler> I was thinking home switches
[02:30:45] <cradek> I don't think there will be limit switches
[02:31:14] <cradek> looks like it will be done by fest, yay.
[02:31:31] <jepler> yes, yay
[02:35:28] <jepler> gruntle
[02:35:29] <jepler> READ => U0
[02:35:29] <jepler> Bad character 'u' used
[02:35:29] <jepler> U0
[02:35:32] <jepler> I can't test this using SAI
[02:35:47] <cradek> ick
[02:37:31] <jepler> Cannot put a U in a canned cycle in the XY plane
[02:37:35] <jepler> well this looks promising in axis
[02:37:47] <cradek> thanks for fixing it
[02:37:51] <jepler> Cannot put an X in a canned cycle in the UV plane
[02:38:00] <cradek> it's funny the things we don't think to test
[02:39:33] <jepler> it's a tad bit tempting to think that you could drill holes in 8 faces of your gizmo with A motion in the canned cycle.. G81 A[360/8] L8 ...
[02:39:48] <jepler> but I'm *way* too tired to contemplate implementing it
[02:39:57] <cradek> yeah, no kidding
[02:40:21] <cradek> and the next guy would think that should 'drill' a spiral
[02:41:28] <jepler> gee, and we don't even mention angular mode in the gcode quick reference
[02:41:36] <cradek> polar?
[02:41:42] <jepler> yeah, that's what I mean
[02:42:00] <cradek> I think the docs are a lot less ready for 2.5 than the code is
[02:42:14] <jepler> get to work!
[02:42:29] <cradek> what OS do I have to install to write docs?
[02:43:18] <jepler> 8.04
[02:44:11] <cradek> the shop computer is still 8.04. maybe I should take it to fest.
[02:44:47] <cradek> yeah sure, I'll sit and write documentation at fest. really.
[02:49:46] <jepler> aha, the current docs say the thing that chris remembers:
[02:49:48] <jepler> \begin_layout Standard
[02:49:48] <jepler> Rotational axis words are allowed in canned cycles, but it is better to
[02:49:48] <jepler> omit them.
[02:49:48] <jepler> If rotational axis words are used, the numbers must be the same as the
[02:49:50] <jepler> current position numbers so that the rotational axes do not move.
[02:50:00] <jepler> except that's not exactly what the implementation did either
[02:52:36] <jepler> argh, I wish the documentation didn't say that :( now I think I can't change this in 2.4, it's an incompatible change...
[02:53:31] <cradek> I kind of doubt you should touch 2.4's interp at all
[02:53:44] <jepler> you may be right
[02:53:52] <jepler> this is sure a problem that is fixable by "so don't do that..."
[02:54:21] <cradek> exactly
[02:56:14] <cradek> touchy needs different jog increments for rotaries. .0001 degrees sure isn't much.
[03:00:04] <CIA-31> EMC: 03jepler 07master * r10ced449a48a 10/tests/ (9 files in 9 dirs): modernize hal files in testsuite
[03:00:05] <CIA-31> EMC: 03jepler 07master * r584adb26813f 10/src/emc/rs274ngc/interp_check.cc: interp: reject ABC in canned cycles
[03:00:06] <CIA-31> EMC: 03jepler 07master * r15f4a7ed2d2c 10/tests/interp/bad/test: testsuite: fix reversed error message
[03:00:27] <CIA-31> EMC: 03jepler 07master * r417a60e169ec 10/configs/ (52 files in 25 dirs): Modernize hal files in sample configs
[03:00:28] <cradek> hm, ferror checks for gantried joints will be interesting
[03:00:38] <CIA-31> EMC: 03jepler 07master * r487275d7d533 10/docs/html/gcode.html: quickref: all axes apply to these words
[03:00:38] <CIA-31> EMC: 03jepler 07master * ra1653594e44c 10/tests/interp/bad/ (a-in-canned-cycle.ngc a-in-canned-cycle2.ngc): interp: add tests for ABC in canned cycles
[03:00:39] <CIA-31> EMC: 03jepler 07master * rce5c2e30c507 10/src/emc/rs274ngc/interp_cycles.cc: interp: reject more bad axis letters in canned cycles
[03:00:40] <CIA-31> EMC: 03jepler 07master * r8e4537bca7ff 10/docs/html/gcode.html: quickref: not all axes apply to canned cycles
[03:00:41] <CIA-31> EMC: 03jepler 07master * r5c9460de9e83 10/docs/src/gcode/main.lyx: docs: fix discussion of axis letters in canned cycles
[03:04:17] <cradek> jepler: >80 && <90 is no longer a suitable test for canned cycles, since we have 73
[03:06:43] <cradek> int is_a_cycle = (motion == G_73 || ((motion > G_80) && (motion < G_90)));
[03:07:02] <cradek> ^ should be functioned or macroed maybe
[03:07:25] <jepler> cradek: oh potatoes
[03:07:34] <cradek> jepler: pickle juice!
[03:07:42] <jepler> taters
[03:09:37] <jepler> so basically you're suggesting
[03:09:38] <jepler> + bool is_a_cycle = ((motion > G_80) && (motion < G_90)) || (motion == G_73);
[03:09:42] <jepler> if (block->a_flag) {
[03:09:44] <jepler> - CHKS(((motion > G_80) && (motion < G_90)),
[03:09:47] <jepler> - NCE_CANNOT_PUT_AN_A_IN_CANNED_CYCLE);
[03:09:49] <jepler> + CHKS(is_a_cycle, NCE_CANNOT_PUT_AN_A_IN_CANNED_CYCLE);
[03:09:52] <jepler> }
[03:11:08] <cradek> yes I think that's right
[03:12:18] <jepler> emc/rs274ngc/interp_cycles.cc:int Interp::convert_cycle(int motion, //!< a g-code between G_81 and G_89, a canned cycle
[03:12:23] <cradek> actually I meant make a function bool is_a_cycle(int motion) {...} and replace the other occurrence too
[03:12:25] <jepler> I bet at least a few of these comments are wrong too(?)
[03:12:34] <cradek> oh surely so
[03:16:05] <jepler> - CHKS(((motion > G_80) && (motion < G_90)),
[03:16:05] <jepler> - NCE_CANNOT_PUT_A_B_IN_CANNED_CYCLE);
[03:16:05] <jepler> + CHKS(is_a_cycle(motion), NCE_CANNOT_PUT_A_B_IN_CANNED_CYCLE);
[03:17:14] <CIA-31> EMC: 03jepler 07master * rb6b9b0a7317f 10/src/emc/rs274ngc/ (interp_check.cc interp_internal.hh): interp: use correct test for "is a cycle"
[03:17:47] <jepler> 'night
[03:22:14] <CIA-31> EMC: 03cradek 07master * r6bd1cd502b8c 10/src/emc/rs274ngc/interp_convert.cc: no behavior change: use new is_a_cycle test here too
[14:37:19] <jepler> mhaberler: in your comment on SF#3092250 you implied that there's a problem with left-hand tapping. I don't have a real machine at hand, but M4 / G33.1 looks like it works in sim/lathe.ini
[14:37:23] <jepler> M4 S400
[14:37:23] <jepler> G33.1 Z-1 K[1/20]
[14:37:26] <jepler> specifically ^^
[14:41:30] <cradek> jepler: 57c8a38924185f81bf3727aa60b434d73413cb4c
[14:42:01] <jepler> ah, so that's also been fixed comparatively recently
[14:42:17] <jepler> v2.4.2
[14:51:08] <psha> how often builbot builds packages?
[14:51:14] <psha> good evening
[14:51:37] <jepler> psha: it seems buildbot is down right now -- most builders show as "offline".
[14:51:53] <psha> lack of build slaves?
[14:51:57] <jepler> when it is working properly, a package build takes place shortly after a push to linuxcnc.org.
[14:52:07] <jepler> (I'm looking at http://emc2-buildbot.colorado.edu/buildbot/one_box_per_builder )
[14:52:47] <jepler> seb runs the buildslaves as virtual machines. I'm not sure why he hasn't restarted them.
[14:52:54] <jepler> he hasn't been around irc lately either
[14:54:50] <psha> is not virtual machine an overkill for build task?
[14:55:20] <SWPadnos> it's somewhat necessary, since the cuilds are done on multiple OS versions
[14:55:23] <SWPadnos> builds
[14:56:20] <psha> SWPadnos: only reason why to use virtual machine is _running_ rtai kernel
[14:56:48] <SWPadnos> yes, which is somewhat necessary to build the RT components and packages
[14:56:50] <jepler> in fact, the buildslaves are running the rtai kernel so that they can run the testsuite
[14:57:04] <psha> i've built rtai package for ubuntu on debian box using pbuilder chroot with _installed_ rtai kernel
[14:57:11] <jepler> it might be true that if you didn't want to do that, you could use other technologies like pbuilder
[14:57:16] <jepler> but you can't run the testsuite that way
[14:57:22] <psha> i see
[14:57:31] <SWPadnos> an important point :)
[14:57:44] <psha> but even then you only need one machine per kernel?
[14:58:00] <SWPadnos> yes, which is somewhat easier with VMs
[14:58:07] <SWPadnos> since you then only need one machine
[14:58:09] <psha> (hardy + lucid) x (i386 + amd64)?
[14:58:48] <jepler> this list has lenny, hardy, lucid, dapper(!?); it looks like amd64 is only listed with lucid.
[14:59:49] <psha> and what VM is used? kvm?
[15:00:04] <SWPadnos> it might be VMWare player
[15:00:10] <SWPadnos> but I'm not sure
[15:00:14] <psha> even with VM's build task is just like ordinar execution task
[15:00:36] <psha> but I was too lazy to move our build system from pbuilder to vm's :)
[15:00:59] <jepler> I wish seb was here to discuss this. Mostly I'm just pleased to have the buildbot and don't know why he made the specific choices he did.
[15:02:26] <jepler> bbl
[15:38:18] <cradek> what's the modern, good way to do virtual machines in lucid? I keep finding crap like http://www.howtoforge.com/kvm-guest-management-with-virt-manager-on-ubuntu-8.10 which is full of surely-wrong advice
[15:40:10] <jepler> I've tried virt-manager in the past but didn't have much luck.
[15:40:24] <jepler> I build the 8.04 packages with qemu images that I installed manually from cd images, and start and stop manually when I want to use them..
[15:45:19] <psha> i've used hand-made vms too
[15:45:34] <psha> but not manually installed
[15:47:56] <jepler> anyway, if you want to try the libvirt-based approach, this might be the most up to date for ubuntu 10.04 hosts: https://help.ubuntu.com/10.04/serverguide/C/libvirt.html
[15:49:21] <cradek> thanks
[15:55:00] <psha> libvirt looks promising some time ago
[15:59:58] <psha> cradek: if you need script too bootstrap debian (ubuntu) into vm i may look for one
[16:00:03] <psha> s/too/to/
[16:00:35] <jepler>
[16:13:03] <jepler> actually, just now I had success creating and using an ubuntu vm image with virt-install and virt-manager
[16:13:20] <jepler> including virt-manager over ssh
[16:14:28] <psha> great :) mine is segfaulting on creating network interface :)
[16:14:32] <jepler> that's too bad
[16:14:54] <psha> i'm upgrading to current testing from mixed-stable-testing-unstable-experimental
[16:16:03] <psha> and give it another try
[16:17:35] <jepler> UGH! who the HECK thought that hitting ctrl-w should close the virt-viewer application!
[16:17:39] <jepler> that is INSANE
[16:18:11] <SWPadnos> herh
[16:18:14] <SWPadnos> -r
[16:18:36] <SWPadnos> that's the pseudo-standard "close this window" key
[16:19:12] <SWPadnos> which might make it difficult to close a window of something inside the virt-viewer application
[16:20:39] <cradek> or use emacs
[16:21:01] <SWPadnos> clearly ctrl-x, ctrl-k is much safer
[16:21:07] <SWPadnos> or was that meta
[16:22:38] <jepler> apparently I have to make sure the mouse is grabbed before typing things like ctrl-w
[16:25:15] <jepler> and the network isn't working right either (I think I need to set up bridged networking)
[16:25:31] <jepler> but at least this time around the installation and management features seem to work
[16:25:43] <psha> jepler: check bridge interface
[16:25:50] <psha> virbr0 for me
[16:27:00] <jepler> hm .. I have a virbr0
[16:28:57] <jepler> looks like it's my firewall/nat that isn't how I'd like it
[17:27:18] <psha> jepler: is forwarding/masquerading enabled?
[18:02:23] <psha> anybody using HAL_ComboBox?
[18:06:00] <jepler> psha: It is for my normal internal network. The problem is probably simple but I'm remote from that system now so I don't want to go mucking with the firewall rules
[18:06:22] <cradek> the voice of experience speaks
[18:06:29] <jepler> it may be that I need to specify an additional interface or network for SNAT.. I currently have
[18:06:32] <jepler> -A POSTROUTING -s 10.0.0.0/255.0.0.0 -o eth0 -j SNAT --to-source 206.222.212.217
[18:06:51] <jepler> so maybe I need -o vibr or -s 192.x.x.x/255.255.255.0 or something
[18:07:58] <psha> jepler: or change virbr0 address space to 10/8 network :)
[18:22:31] <jepler> psha: stop tempting me to wreck my working machine while I'm not in the same building to fix it
[18:24:53] <psha> sorry :))
[18:36:33] <jepler> argh -- vmbuilder can't build hardy images, and also I just nuked the working lucid I had built
[18:36:58] <jepler> (because by default it outputs to the same directory name every time, and this commandline I was copying includes "-o", "overwrite automatically"
[18:43:21] <psha> you don't need my advices how to wreck something :-P
[18:43:42] <SWPadnos> the voice of experience speaks
[18:43:44] <SWPadnos> :)
[19:06:55] <psha> when i create pin, set some value and only then connect it to signal - value is lost?
[19:08:02] <alex_joni> psha: right
[19:08:38] <micges> hi alex_joni
[19:08:49] <psha> feature? :)
[19:09:49] <psha> i'm playing with gladevcp and found that control values are lost
[19:09:59] <alex_joni> hi micges
[19:10:24] <psha> for example if you have two radio buttons connected to two leds then they are all off
[19:11:18] <psha> not bad but may be a bit disturbing
[19:13:43] <psha> i've solved it with updating control values periodicaly
[19:13:55] <psha> may be not good solution but i see no other
[19:36:27] <psha> may someone take a look on the patch and say if it's definitely trash or maybe not so bad?
[19:37:20] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=gladevcp-modules&id=b1d76695d5388a687f7a1a219dbc46439421731c
[19:52:11] <jepler> argh
[19:52:27] <jepler> psha: I glanced at the patch, but I don't know enough about gladevcp to comment.
[19:52:34] <jepler> it looks pretty much like the whole file's rewritten
[19:55:08] <psha> i've restructured lot of 'if widget_name == 'HAL_widget_name': then do something to two class functions per widget
[19:55:44] <psha> for me it seem resonable to have update/init code sit in class and not soomewhere else
[19:56:14] <psha> i'll try to get review from cmorley but i have a little hope on it...
[19:56:41] <psha> at least now it shows correct led in glade colors designer window :)
[19:56:50] <psha> led colors in glade designer window
[20:17:19] <jepler> bounce bounce
[20:19:12] <psha> another question
[20:19:26] <psha> does it looks reasonable to you to add 'pin' object to python hal bindings?
[20:19:36] <psha> now there is only 'pin dict' object available
[20:19:54] <psha> and if you want to manipulate with one pin you need to remember it's name
[20:20:28] <psha> maybe add something like hal.pin with get/set methods?
[20:20:42] <psha> everything is already implemented in halmodule.cc except type object
[20:22:05] <jepler> that's a patch I'd at least be able to review
[20:22:30] <jepler> .newpin would return the object, and it'd have some methods like value() and set()?
[20:23:10] <psha> yes
[20:23:13] <jepler> (a method is needed since h = newpin(); ... h = 3 doesn't change something about the pin object, it just rebinds h)
[20:23:31] <psha> sure
[20:23:31] <jepler> get() and set() maybe
[20:25:04] <jepler> argh, my batter charger broke
[20:26:03] <jepler> (pulled it out of the socket before swapping out charged batteries, and one of the prongs stayed in the wall!)
[20:31:37] <skunkworks> yeck
[20:31:47] <psha> what is difference between pin and param?
[20:31:56] <psha> from program?
[20:32:04] <psha> not idealogicaly :)
[20:32:58] <skunkworks> pin is read/writable at all times.. param can only be written to at load?
[20:33:31] <psha> for reading - no difference?
[20:33:46] <cradek> pins can be linked to signals
[20:34:16] <cradek> if that's not the answer I don't understand the question
[20:54:12] <SWPadnos> technically, cradeks answer is correct - pins can be connected to signals and params can't be
[20:55:05] <SWPadnos> conceptually, params are not intended to be changed often, and "should" be used for setting modes or the like - things that might require recalculating internal scale factors or the like
[20:57:05] <psha> thanks :)
[21:22:29] <psha> jepler: please take a look at /?
[21:22:33] <psha> oops
[21:22:38] <psha> http://psha.org.ru/cgit/psha/emc2.git/commit/?h=pyhal-pin
[21:23:52] <psha> i've added hal.pin object, modified hal.newpin call to return it and added getpin function to get already added objects
[21:24:27] <psha> but i maybe failed with refcounts/contructor/destructor
[21:30:11] <psha> if patch is ok i'll move gladevcp on top of it tomorrow
[22:03:14] <jepler> it would be nice if the pin object knew its name
[22:03:15] <jepler> +return PyString_FromFormat("<hal param %s>", pin_type2name(self->type));
[23:54:11] <jepler> I wonder whether having only one type and only one method get_pin() is how it should b
[23:54:15] <jepler> e
[23:54:17] <jepler> or should there be two types and two methods