Back
[01:15:39] <tom3p> alex_joni: i still have probs with comp. i renamed the entire tree (emc2-dev -> emc2-dev-001) and now am re-gitting the whole thing. will this resolve it? (git clone git://git.linuxcnc.org/git/emc2.git emc2-dev)
[01:21:14] <tom3p> argh, the README in the git src says to exec cd src then ./configure --enable-run-in-place does it really mean ./autogen.sh?
[01:23:27] <tom3p> apparently it should read ./autogen.sh then ./configure --enable-run-in-place
[01:46:57] <tom3p> ok, i git a whole new directory, built it and get the same error. i touched no permissions. i just followed instructions from the README and the wiki. the terminal wont scroll back thru all of this, what to do?
[01:48:50] <tom3p> tomp@stepperBox:~/emc2-dev$ sudo comp --install src/hal/components/mux2bit.comp
[01:48:50] <tom3p> sudo: comp: command not found
[01:49:26] <tom3p> tomp@stepperBox:~/emc2-dev$ ls -la rtlib
[01:49:26] <tom3p> total 1772
[01:49:26] <tom3p> drwxrwxrwx 2 tomp tomp 4096 2010-01-03 16:26 .
[01:49:26] <tom3p> drwxrwxrwx 17 tomp tomp 4096 2009-12-02 21:49 ..
[01:49:59] <tom3p> this is after cd , cd src, . scripts/emc-environment
[01:59:11] <tom3p> the new mux2bit file >is< written to the rtlib directory , it has the same owners and perms that all the other files in the dir have.
[01:59:35] <tom3p> the wiki page
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?HowToWriteNewHalComponent must be wrong, because dropping 'sudo' from the command 'worked'
[01:59:41] <tom3p> even tho emc2 still reports " Can't find module 'mux2bin' in /home/tomp/emc2-dev/rtlib" tho ls can.
[02:00:35] <SWPadnos> run-in-place is default in 2.4~pre, and sudo isn't necessary for run-in-place
[02:00:42] <SWPadnos> maybe the readme should be updated
[02:01:19] <tom3p> ok, thx, do you have an idea why the .ko file exists but is reported 'cant find' ?
[02:01:53] <tom3p> i couldnt take the liberty of chging the readme or the wiki while things didnt work for me
[02:01:54] <SWPadnos> well, you do still need sudo make setuid for RIP RT builds
[02:02:01] <tom3p> did that
[02:02:05] <SWPadnos> sure, and I'm not sure my explanation is correct :)
[02:02:37] <SWPadnos> well, if you did all the comp work after sourcing emc-environment, then I don't know why it wouldn't have worked
[02:02:51] <tom3p> id like to see any comp actually work, i'll try renaming one to fred.comp and test
[02:03:20] <SWPadnos> but if you're on an RT system, that leads me to believe that you have a systemwide install of EMC2, so comp might work before the source command, since there's the installed version available
[02:04:33] <tom3p> i dont understand RT system? RealTime?
[02:04:36] <SWPadnos> yes
[02:04:58] <tom3p> uh, yes, if you mean NOT a sim, then yes
[02:05:03] <SWPadnos> I don't think you'd get a .ko unless you were building kernel modules, and that only happens on RT systems. sim is userspace only
[02:05:06] <tom3p> never did sim
[02:05:10] <SWPadnos> ok
[02:05:38] <tom3p> and shouldnt be systemwide if i said --enable-run-in-place to ./configure
[02:06:16] <SWPadnos> is mux2bit part of emc2, or something you put in the src/hal/components directory?
[02:06:30] <SWPadnos> (you don't need to put it there when you're building with comp)
[02:06:39] <tom3p> something i wrote ( just chgd float to bit 3x in mux2.comp)
[02:07:11] <tom3p> uh, is it a problem that i put it into src/hal/somponents?
[02:07:14] <tom3p> c
[02:07:14] <SWPadnos> ok, so configure makes it so that the emc2 build will be run-in-place, but it doesn't cause the shell to use the run-in-place programs
[02:07:25] <SWPadnos> I don't think that should be a problem
[02:07:56] <SWPadnos> but you still need to source scripts/emc-environment, after the make and before using comp
[02:08:12] <tom3p> i cd build dir . scripts/emc-environment, now shell should use rip programs (i think)
[02:08:30] <SWPadnos> and also in every terminal/window where you want to use the RIP programs
[02:08:38] <SWPadnos> yes, but that has to be done after the build
[02:08:38] <tom3p> all in same terminal
[02:09:07] <SWPadnos> make actually creates the emc-environment script with the correct paths in it
[02:10:54] <tom3p> maybe it is out of sequence, i'll do it again cd builddir . scripts/emc-environment comp src/hal/components/mux2bit.comp emc (the hal file including mux2bit is on the emc2 gui already)
[02:11:20] <tom3p> is there a wasy to un-emc-environment?
[02:11:23] <tom3p> way
[02:11:32] <SWPadnos> and incidentally, emc-environment will only run once, it looks for some environment vars and exits with a message if it sees them
[02:11:47] <SWPadnos> I think all you need to do is unset all the EMC* vars
[02:12:01] <tom3p> in env?
[02:12:03] <SWPadnos> or you could open a new tab in the terminal (ctrl-shift-t)
[02:12:28] <tom3p> hmm, will try new terminal
[02:12:29] <SWPadnos> env | grep EMC2 | xargs unset
[02:12:30] <SWPadnos> I think
[02:12:50] <SWPadnos> you may need a ${} or something in there, I'm not an xargs expert
[02:13:01] <SWPadnos> yeah, ctrl-shift-t is definitely easier :)
[02:17:29] <tom3p> new terminal by ^shift-t same result, terminal saved to pastebin
http://pastebin.ca/1736959 will be rebooting now
[02:27:48] <SWPadnos> you have a typo in your hal files
[02:28:05] <SWPadnos> the component is called mix2bit, the hal files try to load mux2bin
[02:28:55] <tom3p> !
[02:32:26] <tom3p> "the component is called mix2bit, the hal files try to load mux2bin" sorta you're right! the component is called mux2bit, & the hal files try to load mux2bin
[02:32:38] <tom3p> i need the reader digest version of gedit
[02:32:39] <tom3p> thx
[02:32:47] <SWPadnos> heh
[02:36:05] <jepler> looks like my ISP is done bouncing my DSL every 2 minutes like they did for the previous 7 hours ..
[02:36:13] <jepler> * jepler crosses his fingers
[02:38:54] <SWPadnos> yay
[02:39:03] <SWPadnos> (relatively speaking)
[04:31:38] <CIA-62> EMC: 03cradek 07master * r83fa31b7e42d 10/src/emc/usr_intf/touchy/touchy.py: Set the initial max velocity correctly
[04:31:38] <CIA-62> EMC: 03cradek 07master * rf886dd3f4363 10/src/emc/usr_intf/touchy/ (mdi.py touchy.glade): Show status of mdi words in a less confusing way?
[04:32:42] <Dave911> When is the var file loaded or accessed by the Gcode interpreter? I'm thinking of writing a Python program to alter the var file for various parameters in a lengthy Gcode program and I am wondering how/when the var file is accessed. I can't see much mention of it in the integrator manual.
[04:44:28] <SWPadnos> there's no specified access time other than that the file is guaranteed to be read at EMC2 startup and guaranteed to be written at (normal) shutdown
[04:46:05] <SWPadnos> once read, the file on disk is no longer the most up-to-date information, that's internal to the interpreter (in RAM), and is written out "from time to time
[05:00:31] <cradek> Dave911: reading/rewriting the var file directly is a bad idea
[05:00:43] <cradek> tell us more about your problem and maybe we can help you find a good solution
[05:05:03] <Dave911> OK, I have an existing multiaxis machine that has an existing roughly 3000 line motion program. I think I can write a generic Gcode program with vars to do what they want to move the machine in sequence.
[05:05:05] <Dave911> I need a front end to configure the machine and alter the vars or the Gcode to suit a particular part. The setup must be menu driven, fill in the blank, etc. I don't need to alter the var file while the Gcode runs - I just need to know things like - is the var file loaded when the config is opened or is it reloaded when the Gcode is loaded etc.
[05:06:26] <cradek> maybe your front end program should send MDI commands to the running EMC. the MDI commands could be of the form #1234=567.89
[05:07:18] <cradek> if it's python it's trivially easy to send the mdi commands. see the 'mdi' python program in the distribution
[05:07:42] <Dave911> OK, so EMC2 would load the var file via the MDI lines .... is that what you mean?
[05:07:43] <Dave911> A PyVCP panel would be fine for an operator interface to monitor the machine.
[05:08:02] <cradek> don't worry about the var file. let emc take care of it.
[05:08:12] <cradek> I suggest telling emc what you want using mdi
[05:08:38] <Dave911> So the file is just called MDI.py ?
[05:08:43] <cradek> no, mdi.py
[05:09:44] <cradek> http://git.linuxcnc.org/gitweb?p=emc2.git;a=blob;f=src/emc/usr_intf/axis/scripts/mdi.py;h=f5b4f23eb9a56deb14f54ac4f45fd2c9438c0ac8;hb=master
[05:11:08] <Dave911> ok, I'll look for it. That would avoid any possible var file conflicts for sure...
[05:11:10] <Dave911> Why would it be bad to directly alter the var file? Would I have an ownership read/write access issue with Linux?
[05:12:37] <cradek> its whole purpose is to let emc save and reload its state -- so emc reads and writes it willy-nilly. if you mess with it too, you'll eventually get your ass bitten because you'll clash with emc in various ways
[05:14:12] <cradek> another good approach would be to use AXIS's input filter feature to edit your input gcode on the fly
[05:15:31] <cradek> I've used that to load files written in an incompatible gcode dialect
[05:15:43] <cradek> the filter program just tweaks it
[05:16:02] <cradek> I'm off, goodnight
[05:16:37] <Dave911> Ok, yep I can't plan anything around willy nilly ;-)
[05:16:39] <Dave911> I seriously thought about the filter concept and I think that would be more viable if the amount of motion code wasn't so great. I really don't want to have thousands of lines of print commands to gen the Gcode, I'd rather just work directly with the gcode. I think debugging would be faster....
[05:16:41] <Dave911> Thanks for the ideas! Good night!
[05:18:01] <Dave911> The filter concept is very cool though... I'm sure I'll be using that eventually also.
[05:18:30] <cradek> you wouldn't need thousands of prints - you could use something like sed to substitute some things in the file
[05:18:47] <cradek> #1234=@MY_FIRST_VARIABLE@
[05:19:10] <cradek> then you'd use a filter program like sed 's/@MY_FIRST_VARIABLE@/1.234/'
[05:19:21] <Dave911> Hmmmm...... ok
[05:19:28] <cradek> goodnight, hope you find a good answer
[05:20:02] <Dave911> I'm sure I will... I'll consider the sed's Thanks again!
[05:24:12] <Dave911> SWPadnos: Sorry I didn't mean to ignore you.. I didn't see your response until I scrolled up again.. I don't want to have to shutdown EMC to write to the var file so that is definitely a no-go.
[05:24:14] <Dave911> Thanks!
[06:18:56] <tom3p> I can now switch between position stepgen and velocity stepgen while running emc2 and Axis.
[06:18:56] <tom3p> As long as i return the axis to the position stepgen's rawcount value, i get no jerk or change in f-error.
[06:18:56] <tom3p> I'd like to move in velocity mode until a limiting position was arrived at, but..
[06:18:56] <tom3p> Axis doesn't show the position changes when i move in velocity mode.
[06:18:56] <tom3p> The only things I see tracking position are the velocity stepgen's rawcounts, and the position stepgen's f-error.
[06:18:57] <tom3p> Do I need to track position myself? (position stepgen's rawcounts + velocity stepgen's rawcounts scaled by sizeof1rawcount)?
[06:21:42] <SWPadnos> you can do that, but EMC will be surprised when the position changes due to the (not controlled by emc) velocity stepgen
[06:21:49] <SWPadnos> and will stop with a following error
[06:23:10] <SWPadnos> nigth
[06:23:13] <SWPadnos> night
[06:25:38] <tom3p> night
[06:27:33] <tom3p> thx
[17:10:03] <CIA-62> EMC: 03micges 07master * rbc7dfee0cdba 10/ (2 files in 2 dirs): Speed up generating opengl preview
[17:15:12] <Guest284> Guest284 is now known as skunkworks_
[18:29:34] <SWPadnos> micges, how much time did converting that preview function to C save?
[18:43:47] <micges> here in 9.04 in sim that function execution time dropped from 30 sec to 5
[18:44:17] <micges> on hardy rt on faster pc function run at least 2.5x faster
[18:48:55] <micges> SWPadnos: why?
[18:53:37] <SWPadnos> I was just curious
[18:55:56] <micges> mostly it improve speed on systems with poor gpu acceleration
[19:16:25] <cradek> do you have lots of dwells?
[19:16:37] <jepler> SWPadnos: when I measured on my own system I didn't see the original load times being anywhere near that high, and the percentage impact on total load time was also small
[19:16:55] <jepler> it doesn't seem like this can be accelerated vs software rendering, because the eliminated work is all Python interpreted code
[19:17:16] <SWPadnos> ok - I figured the savings would be minimal - I was actually (quite) surprised at the 6x improvement
[19:17:56] <SWPadnos> I'd bet that disk caching would have a bigger impact
[19:17:59] <jepler> If I understand the figures from micges, it was that step of the load that was improved from 30 to 5 secnonds .. but that's only one phase of loading a part program
[19:18:34] <SWPadnos> you'd expect the interpreter to take about the same amount of time
[19:18:38] <SWPadnos> or I would anyway
[19:19:26] <jepler> the change moves the loop "for each dwell: do several opengl calls to add the dwell to the display list" into C code
[19:20:05] <SWPadnos> right - I noticed that the C code did the exact same thing, I didn't look closely enough to see if it had any optimizations in it
[19:20:19] <SWPadnos> ie, the exact same set of glblahblah calls
[19:21:15] <jepler> so it removes probably a dozen Python bytecodes and 4 Python function calls for each dwell.
[19:22:05] <SWPadnos> and dives into a large mass of openGL code for the 16 or so function calls
[19:22:19] <micges> I think all opengl generation code could be moved to c
[19:22:22] <SWPadnos> oh, 8 calls
[19:22:43] <jepler> A Python function call is actually fairly time-consuming -- calling a do-nothing function takes 7x as long as doing nothing inlined in the loop, for instance.
[19:22:45] <jepler> $ python -mtimeit -s'def f(): pass' 'pass' # test an empty loop
[19:22:48] <jepler> 10000000 loops, best of 3: 0.0803 usec per loop
[19:22:50] <jepler> $ python -mtimeit -s'def f(): pass' 'f()' # test a loop that calls a function
[19:22:51] <SWPadnos> micges, I'd want to see a real statistical sampling of run times before bothering with that
[19:22:54] <jepler> 1000000 loops, best of 3: 0.59 usec per loop
[19:23:24] <SWPadnos> do that with two function calls
[19:23:33] <SWPadnos> please :)
[19:24:54] <jepler> anyway, in my mind the question is why one step of the load takes 30 seconds on micges machine (2.4GHz Celeron) while the whole load process takes under 10 seconds on my system (2.2GHz Core 2 Duo) -- is the Core 2 so much faster per MHz than Celeron that it makes sense, or is something else wrong in Micges case?
[19:28:13] <SWPadnos> it may be a little of both
[19:28:23] <SWPadnos> the celeron sucks on a "work-per-cycle" basis
[19:28:34] <SWPadnos> unless it's a celeron version of the P4
[19:28:49] <SWPadnos> which it could be, since it's 2.4GHz
[19:29:46] <jepler> I sure can't keep Intel processor families straight
[19:29:58] <SWPadnos> celeron = shit, more or less across the board
[19:30:57] <SWPadnos> it probably has 1/4 the L2 cache size (512k instead of 2M), and likely much smaller L1 too
[19:31:25] <micges> you all don't want me to mess with that part any more?
[19:31:43] <SWPadnos> I'd like to see more data before saying that for sure
[19:32:37] <SWPadnos> unless you did several time tests with each version, I'm inclined to believe that the 30 vs. 6 second difference was mostly not due to this code change
[19:32:40] <SWPadnos> just a hunch
[19:33:17] <micges> ok
[19:35:24] <jepler> from Wikipedia's List of Intel Celeron processors a 2.4GHz Celeron could be Northwood-128 (NetBurst, 128KiB L2 cache), Celeron-D Prescott-256 (NetBurst, 256KiB), Celeron E3200 Wolfdale-3M (Core, 1MiB)
[19:36:11] <micges> jepler: 2.8GHz, low end mainboard
[19:36:21] <jepler> oh, 2.8GHz? Curse my flawed memory.
[19:37:09] <jepler> could still be Northwood-128, Prescott-256. There isn't a Wolfdale-3M 2.8GHz listed
[19:37:28] <jepler> so it is several chip designs older than the system I was testing on..
[23:20:22] <SWPadnos> hmmm. that's no good, since -1 is a valid value for analog inputs
[23:24:53] <jepler> What's no good?
[23:25:11] <SWPadnos> returning -1 for timeout from M66
[23:25:23] <SWPadnos> in the same var that gets the input result otherwise
[23:26:17] <jepler> "Mode 0 [immediate] is the only one permitted for an analog input" so it can never time out
[23:26:27] <SWPadnos> ah, ok
[23:26:37] <SWPadnos> in that case it's fine :)
[23:27:01] <SWPadnos> I guess that makes sense, until there's an option to "wait for threshold crossing"
[23:27:03] <SWPadnos> :)
[23:31:27] <skunkworks> bldc servo question.. I have one hooked to a amc drive. When power is applied - and I spin the shaft by hand or command a low rpm - I hear ticking. (2 servos do this so far) could the ticking be the comutation changing from the hal sensors?
[23:31:54] <skunkworks> hall
[23:56:41] <jepler> hi dgarr
[23:57:07] <jepler> dgarr: do I owe you any patch reviews at the moment?
[23:57:15] <jepler> it seems like there was something but I have no idea what anymore