#emc-devel | Logs for 2010-06-08

Back
[08:12:37] <micges_work> 2.4.1 package doesn't work on 8.04
[08:14:03] <micges_work> http://pastebin.com/D4pTEiYw
[12:00:16] <jepler> micges: looks like that's due to a change Chris made. I e-mailed him with the info.
[12:11:51] <dgarr> jepler: some work on tcl pkg Emc http://www.panix.com/~dgarrett/stuff/emc_pkg_update.mbox
[12:41:12] <jepler> % package require Emc; emc_mdi {}
[12:41:12] <jepler> Segmentation fault
[12:41:16] <jepler> yuck, I didn't know about this :-/
[13:20:46] <JT-Work> I tried to do a git pull this morning and the connection failed
[13:25:20] <JT-Work> will it fail if I have too much uploading/downloading going on?
[13:28:35] <JT-Work> bbl
[13:52:42] <jepler> JT-Work: there's some sort of connectivity problem to the server
[13:53:33] <alex_jon1> gitweb works
[13:54:21] <jepler> ah, it may be back now
[13:54:25] <jepler> it was down for a few hours though
[14:28:14] <alex_jon1> alex_jon1 is now known as alex_joni
[14:39:20] <jepler> dgarr: as usual I can't avoid tinkering.. http://emergent.unpy.net/files/sandbox/emc_pkg_update_v3.mbox
[14:43:21] <Jymmm> Um, why is everything named 'emc_blah'? Like emc_rel_act_pos
[14:43:41] <JT-Work> jepler: thanks
[14:45:58] <jepler> Jymmm: because we love to hear the name of the software over and over again
[14:46:18] <Jymmm> jepler: no other reason?
[14:51:09] <SWPadnos> well you wouldn't want to confuse it with BP_rel_act_pos now, would you?
[14:51:30] <Jymmm> Does such a thing exist?
[14:51:52] <SWPadnos> no idea, but at least we wouldn't confuse it! :)
[14:51:58] <Jymmm> lol
[14:52:40] <dgarr> jepler: your patch v3 looks fine to me
[14:52:49] <Jymmm> I'm just wondering how much smaller emc would be without the prefix everywhere
[14:53:19] <SWPadnos> Jymmm, not enough smaller to bother changing it
[14:53:58] <Jymmm> Well, size is no biggy, but the typing seems annoying =)
[14:54:17] <JT-Work_> JT-Work_ is now known as JT-Work
[14:54:29] <SWPadnos> note that it is possible to write a program (though none exists that I'm aware of) that could talk to both EMC2 and something else via NML
[14:55:09] <Jymmm> And NML being what exactly? I've heard the term a few times.
[14:55:11] <SWPadnos> and you don't want name clashes if you import multiple modules that have variables like "status"
[14:55:19] <SWPadnos> you'll have to read about it :)
[14:55:33] <Jymmm> in a nutshell
[14:55:55] <jepler> nml is the library emc uses for RPC and non-realtime shared memory.
[14:56:09] <SWPadnos> very very briefly, it's the communications protocol that emc uses for communication between various parts
[14:56:16] <jepler> it's also one of the top four things people say they want to get rid of in emc
[14:56:29] <Jymmm> Ah, ok. Why get rid of it?
[14:56:31] <SWPadnos> then they read about the alternatives, and decide it's not worth it :)
[14:57:26] <SWPadnos> the protocol itself is a bit like XML, in that it doesn't actually say anything about the contents of the messages, only how they get passed around
[14:58:10] <SWPadnos> but of course, all the modules need to know the contents of the messages, which leads to annoyingly long constructs in the code, which are there to "decode" the messages
[14:58:26] <jepler> Jymmm: I don't really want to get rid of it
[14:59:03] <SWPadnos> I think people look at the steps you have to go through to change anything, and assume there must be something way better
[14:59:11] <SWPadnos> then when you look at it, there isn't really
[14:59:19] <jepler> Jymmm: though there are a few problems emc has that center around the way command submission/acknowledgement happens and which make multiple UIs sometimes act flaky
[14:59:46] <SWPadnos> which I think Alex pointed out are addressed in later versions of RCS
[15:00:11] <Jymmm> jepler: ah
[15:00:41] <jepler> (a command has a "sequence number", and you check to see if it's been received or completed by looking for that number in the status buffer. but how do you choose a sequence number that doesn't conflict with another UI, and if you see the "last command completed" ID is not from your process how do you know if your command is completed or not?)
[15:01:43] <Jymmm> Do SOAP and COBRA have the same limitations?
[15:02:19] <jepler> I doubt this is an inherent limitation of NML but probably a problem with how emc uses it
[15:18:14] <SWPadnos> I think there's a problem with NML that makes it difficult to do things "right", which is that you don't know for sure that all consumers get all messages
[15:18:44] <SWPadnos> which is fixed in a later version (there's some multi-receiver queue, which delivers all messages to all receivers)
[15:19:06] <SWPadnos> without that guarantee, it's hard to know who's going to get your command complete status first
[15:19:08] <Jymmm> * Jymmm passes the token to SWPadnos
[15:19:09] <SWPadnos> (or something like that :) )
[16:33:37] <micges> jepler: what changes?
[17:01:50] <micges> (about cradek' changes caused 2.4.1 packages donesn't work)
[17:06:28] <cradek> can you be more specific
[17:07:05] <SWPadnos> [08:03:33]<jepler>micges: looks like that's due to a change Chris made. I e-mailed him with the info.
[17:07:08] <jepler> commit e66c1f9661d21a64242cc102044177548aa553cf
[17:07:08] <jepler> Author: Chris Radek <[email protected]>
[17:07:08] <jepler> Date: Tue May 25 09:32:28 2010 -0500
[17:07:08] <jepler> These need separate var files.
[17:07:16] <cradek> yes I got that email
[17:07:18] <jepler> I think this is what causes sim_mm.ini to not work, but I haven't looked into it
[17:07:21] <jepler> bbl
[17:07:46] <cradek> sim/axis_mm doesn't work but sim/axis does?
[17:09:31] <micges> cradek: don't know, I've just take a fast look before journey, I can check more tomorrow
[17:09:42] <cradek> the var files are not in git - make does not create them - debian/rules does not create them
[17:09:56] <cradek> so I have no idea how it previously worked
[17:10:30] <cradek> configure does not create them
[17:11:13] <micges> maybe path permitions?
[17:11:24] <cradek> chris@max:~$ dpkg -L emc2|grep var
[17:11:24] <cradek> /usr/bin/inivar
[17:11:24] <cradek> /usr/share/doc/emc2/examples/sample-configs/classicladder/cl-estop/emc.var
[17:11:24] <cradek> /usr/share/doc/emc2/examples/sample-configs/smithy/emc.var
[17:11:46] <cradek> the package does not have any sim var files in it
[17:13:33] <micges> yes but here I can't create files at /usr/share/doc/emc2/examples/ from normal user
[17:13:54] <cradek> oh you tried to run it in place without letting it copy the config to your home directory?
[17:14:37] <cradek> this has nothing to do with my change then, and the backtrace you showed in pastebin is not the first problem
[17:15:10] <micges> yes
[17:15:32] <micges> in trace there are path from which config is emc run
[17:15:56] <cradek> the interp must fail silently if it can't create the var file
[17:16:52] <cradek> it works if I answer Yes to the copying question (the default)
[17:18:16] <cradek> what fix do you suggest, if any?
[17:22:19] <micges> some warning should be enough
[17:23:54] <cradek> "WARNING: Here is a dialog. If you answer No it won't work. If you answer Yes it will."?
[17:24:35] <cradek> if that's what you mean, I don't care for it
[17:24:53] <SWPadnos> heh
[17:25:08] <SWPadnos> "WE HAVE PRE-SELECTED THE CORRECT ANSWER"
[17:25:18] <micges> adding " If you answer No it won't work" to config chooser should be ok
[17:25:34] <cradek> no, that's awful
[17:25:49] <cradek> if we want to allow sample configs to run without copying we must fix them
[17:26:02] <cradek> if we don't want to do that, we should remove the dialog that asks a useless question
[17:26:43] <cradek> the only other option I see, and it's a positively terrible idea, is to make /usr/share/doc/... writable by everyone
[17:27:38] <SWPadnos> ick
[17:27:43] <cradek> which?
[17:27:52] <SWPadnos> making the samples writable
[17:28:04] <cradek> yeah, afaic, that's right out
[17:28:15] <SWPadnos> IMO, emc should run, but not save the var file
[17:28:40] <cradek> well AXIS pukes if there's no var file
[17:28:49] <cradek> and many things don't work right if there's not a writable var file
[17:28:50] <SWPadnos> well that's a problem then :)
[17:29:06] <cradek> (for instance, touch off doesn't work)
[17:29:44] <cradek> I think #2 (remove the useless dialog that only gives you an option that makes it not work right) is the only correct fix
[17:29:57] <cradek> I don't know whether it's appropriate to do #2 in 2.4
[17:30:09] <SWPadnos> dunno
[17:30:15] <cradek> (I want jepler's opinion)
[17:30:19] <SWPadnos> yeah
[17:31:05] <cradek> #1 (make it work right if you don't copy) is possible if we install writable var files (only)
[17:34:21] <dgarr> the inifile could have: [RS274NGC] PARAMETER_FILE = /tmp/sim.var and the copy script could s/\/tmp\///
[17:36:23] <cradek> interesting idea
[17:37:25] <micges> I agree
[17:38:08] <cradek> that messes up the user who copies an example or part of an example manually
[17:40:17] <SWPadnos> if any program that needs the var file just goes to /tmp/varfile if it's not writable, does that fix the problem?
[17:40:33] <SWPadnos> assuming you don't run multiple instances at once (like several sim configs)
[18:05:18] <jepler> cradek: I'm sorry I jumped to conclusions about your change causing the problem.
[18:13:16] <jepler> not tested, but if the problem is declining to copy the config: http://emergent.unpy.net/files/sandbox/0001-Don-t-let-users-sabotage-themselves.patch
[18:35:04] <cradek> jepler: I like it
[21:14:42] <andypugh> I can just tell this is going to be painful to debug, because the only way I know to unload rtai in this condition is to restart: http://www.pastebin.ca/1879306
[21:15:39] <jepler> yes, some sorts of crashing bugs are that way :(
[21:18:38] <andypugh> To make it more fun, the EMC machine is in the garage, so restarts frequently entail a walk.
[21:20:57] <alex_joni> does it freeze?
[21:24:23] <andypugh> No, but it sticks partway through shutdown quite often when RTAI hasn't unloaded
[21:25:09] <jepler> if you can get around needing to talk to hardware, build with --enable-simulator
[21:25:31] <jepler> then crashes won't kill your system, and you may even be able to figure out how to use a debugger on the "real time" code
[21:25:33] <andypugh> I am writing a hardware driver...
[21:25:44] <jepler> oh :(
[21:25:49] <jepler> I thought 3ppwm was finished
[21:25:58] <jepler> the mesa part of it at any rate
[21:26:18] <andypugh> Yes, now I think about it, I am writing a driver for the driver.
[21:26:31] <alex_joni> andypugh: small project then
[21:26:45] <alex_joni> an ethernet connected micro with a relay on the PC's reset line
[21:26:50] <andypugh> Though the interaction with the servo and encoder might be more trouble than it is worth to simulate
[21:27:52] <andypugh> alex_joni: I might have exagerrated the difficulty, the short walk is generally only to the breaker board where I can turn off the garage power.
[21:31:28] <andypugh> hmm, something to do with libnml, but it gets scrolled off the top and out of the history by waiting for s.axes before I can read it.
[21:33:16] <jepler> if realtime crashes you get a whole cascade of errors .. task won't start, because it can't talk to motion. axis won't start, because it can't talk to task..
[21:34:39] <andypugh> I made a change that might be a solution, but I have also just pulled down 2.5~pre
[21:35:02] <andypugh> I _think_ this is the nml-file-in-the-ini issue now, but dinner is ready
[21:35:16] <jepler> that could be too
[21:35:57] <jepler> if you decide to go the --enable-simulator route, a wiki page says how to run gdb on the code that's normally realtime .. http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?DebuggingRtapi
[21:36:26] <andypugh> Looks useful, thanks
[21:58:34] <andypugh> Hmm, easier than I thought to fix. It turns out that option extra_setup ; really does need a yes or no parameter. Quite the over-reaction, if yiou ask me :-)
[22:08:30] <andypugh> When does f-error checking get turned on?
[22:09:02] <micges> after machine on
[22:09:31] <andypugh> I am looking for somewhere in HAL to insert the motor alignment block
[22:11:52] <andypugh> It looks like (as was discussed with cradek last night) the only real option is when e-stop is cleared. ie iocontrol.0.user-enable-out => bldc_sine.init and then bldc_sine.init-done => iocontrol.0.emc-enable-in. I am just a bit unhappy with wobbling axes when the machine is technically still off.
[22:13:27] <andypugh> I guess anyone who doesn't like that can create a dedicated motor homing button, though.
[22:14:49] <andypugh> Ah, no, wait. Does that stop the machine turning off?