Back
[00:00:17] <BJT-Hardy> yes the path seems correct if the Y move is at least the tool radius but totally wrong if less
[00:01:25] <jepler> it looks OK to me for Y as small as 0.21
[00:01:41] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/133136-0.21.png
[00:02:01] <BJT-Hardy> I might not have tested it that much
[00:02:23] <BJT-Hardy> yep looks correct
[00:10:07] <jepler> it's dependent on the angle
[00:10:35] <jepler> for a certain value, the AXIS preview is wrong and gives an error, but the sim run is OK and completes
[00:10:55] <jepler> (sim/axis moves to 0,0,2 for tool changes)
[00:11:08] <BJT-Hardy> the angle from start to finish on the lead in move?
[00:11:32] <BJT-Hardy> related to the next move?
[00:12:10] <jepler> yes
[00:12:51] <jepler> in the preview the entry move is from X1Y0 to X2Y.5. in the actual run on sim/axis it's from X0Y0.
[00:14:42] <BJT-Hardy> * BJT-Hardy hears the dinner bell upstairs
[00:14:49] <BJT-Hardy> talk to you later
[00:15:57] <jepler> see you
[01:16:49] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/configs/plasma-thc/ (24 files): Updated plasma configs, added a simulated plasma config, added a sample plasma nc file, added reset ability to updown component
[01:16:50] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/configs/plasma-thc-sim/axis_manualtoolchange.hal: Updated plasma configs, added a simulated plasma config, added a sample plasma nc file, added reset ability to updown component
[01:16:50] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/configs/plasma-thc/SheetCam/ (SheetCamEMCPlasma.post SheetCamEMCPlasma.scpost): Updated plasma configs, added a simulated plasma config, added a sample plasma nc file, added reset ability to updown component
[01:16:52] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/configs/plasma-thc-sim/SheetCam/ (SheetCamEMCPlasma.post SheetCamEMCPlasma.scpost): Updated plasma configs, added a simulated plasma config, added a sample plasma nc file, added reset ability to updown component
[01:17:02] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/nc_files/plasmatest.ngc: Updated plasma configs, added a simulated plasma config, added a sample plasma nc file, added reset ability to updown component
[01:17:02] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/src/hal/components/updown.comp: Updated plasma configs, added a simulated plasma config, added a sample plasma nc file, added reset ability to updown component
[01:40:38] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/Makefile: instead of including additional copies of emc.nml, copy from the common directory
[02:45:13] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/configs/plasma-thc/ (5 files): And now I know not to add subfolders before populating parent folders in cvs
[02:45:14] <CIA-2> EMC: 03jarl.stefansson 07TRUNK * 10emc2/configs/plasma-thc-sim/ (10 files): And now I know not to add subfolders before populating parent folders in cvs
[03:21:45] <CIA-2> EMC: 03fenn 07TRUNK * 10emc2/lib/python/vismach.py: fix slight angular misalignment in Track() caused by using the wrong formula
[03:22:42] <jepler> fenn: yay, glad you and chris go the key problem solved
[03:30:51] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/configs/plasma-thc-sim/ (5 files): allow it to work with --enable-simulator
[04:08:35] <cradek> strange - tonight axis, classicladder, and halvcp are all segfaulting right and left
[04:08:44] <cradek> on hardy, compiled for sim, I tried clean/rebuild
[04:13:03] <SWPadnos> memtest
[04:14:44] <cradek> axis is segfaulting on exit
[04:14:55] <cradek> classicladder won't run at all
[04:16:27] <SWPadnos> presumably you haven't rebooted, just recompiled and re-ran EMC?
[04:16:37] <cradek> I did reboot just now
[04:16:45] <SWPadnos> any better?
[04:16:48] <cradek> nope
[04:16:51] <SWPadnos> memtest :)
[04:19:47] <cradek> hm, everything but classicladder healed
[04:20:02] <SWPadnos> that's not very reassuring
[04:20:51] <cradek> CL is crashing in a recently-touched area
[04:22:38] <cradek> maybe its crashing porked up everything else somehow
[04:24:12] <cradek> yeah, this code is wrong
[04:25:53] <SWPadnos> I don't see any recent substantive changes to ladder
[04:26:16] <SWPadnos> unless it's the one from 1/31 (or earlier)
[04:27:37] <cradek> Nov 23 I guess
[04:27:39] <cradek> puzzling
[04:28:10] <SWPadnos> yeah. I assumed that you had used this PC/config more recently than that
[04:28:20] <cradek> oh I had
[04:28:28] <SWPadnos> hence my puzzlement :)
[04:28:35] <cradek> not just you
[04:30:29] <cradek> yep that was it
[04:30:32] <cradek> very puzzling
[04:30:50] <cradek> I wonder if that's why it wouldn't start on the ppc the other day
[04:30:50] <cradek> it=CL
[04:32:00] <SWPadnos> I don't see the problem by looking at the commit message, but I trust you on this
[04:32:38] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/hal/classicladder/spy_vars_gtk.c: buffer overruns
[04:33:37] <cradek> wtf, now just halvcp is segfaulting at test_and_set_bit
[04:34:06] <SWPadnos> err
[04:34:49] <SWPadnos> you mean the intrinsic function test_and_set_bit?
[04:34:54] <cradek> for some reason I've got an smp kernel but one cpu
[04:35:11] <SWPadnos> did you intentionally change kernels?
[04:35:13] <cradek> the inline thing in rtapi_bitops.h
[04:35:37] <cradek> Program received signal SIGSEGV, Segmentation fault.
[04:35:37] <cradek> 0xb7fb3d85 in test_and_set_bit (nr=0, addr=0xb7101004) at rtapi/rtapi_bitops.h:91
[04:35:38] <cradek> an update might have happened
[04:35:46] <cradek> but I doubt it changed from UP to SMP
[04:36:14] <SWPadnos> wait, is this RT or sim?
[04:36:26] <cradek> oh I'm inside hal_exit / rtapi_mutex_get / test_and_set_bit
[04:36:26] <cradek> sim
[04:36:35] <cradek> I bet something is still screwy from the CL crashes
[04:36:41] <cradek> I'll go reboot again
[04:38:00] <SWPadnos> it's strange to see you say that
[04:39:18] <cradek> too much magic in sim mode (dlopen, shared memory blocks) for me to be sure
[04:39:42] <cradek> nope
[04:39:43] <cradek> [ 68.587221] halvcp[5870]: segfault at b709b004 eip b7f4dd85 esp bfce36d8 error 6
[04:39:45] <SWPadnos> though theoretically some killall usage should fix it up perfectly
[04:41:04] <cradek> #0 0xb7f67d85 in test_and_set_bit (nr=0, addr=0xb70b5004) at rtapi/rtapi_bitops.h:91
[04:41:19] <cradek> (gdb) p *(char *)addr
[04:41:19] <cradek> Cannot access memory at address 0xb70b5004
[04:42:50] <SWPadnos> from hal_exit?
[04:42:53] <cradek> yes
[04:43:02] <cradek> on line 292 that hal_data is bogus
[04:43:49] <SWPadnos> 292 of which file?
[04:43:55] <cradek> hal_lib.c sorry
[04:43:59] <SWPadnos> heh, ok
[04:46:29] <cradek> maybe something's just wrong with halvcp...
[04:47:36] <SWPadnos> hmmm
[04:48:08] <cradek> yeah when I run halui_halvcp (no CL) it still segfaults at exit
[04:48:09] <SWPadnos> CopySizesInfosFromModuleParams is declared as extern in the file in which it's actually defined
[04:48:17] <SWPadnos> is that an error?
[04:48:32] <cradek> IDontKnowButIdOntThinkSo
[04:48:43] <SWPadnos> IExpectedYouToKnow
[04:48:54] <cradek> SorryImNotActuallyAProgrammer
[04:48:55] <SWPadnos> ButNeitherOfUsIsHungarian
[04:48:59] <SWPadnos> Excellent
[04:49:11] <SWPadnos> ItsHardToNotUseTheSpaceBar
[04:49:37] <cradek> I don't see any reason remaining to implicate CL now
[04:49:49] <cradek> well maybe halui_halvcp runs it - checking
[04:49:58] <cradek> no
[04:50:09] <SWPadnos> the only reason I have is that I'm looking at some suspicious-looking code
[04:50:22] <SWPadnos> lines 287-295, for example
[04:50:23] <cradek> CL is entirely made of suspicious-looking code
[04:50:33] <SWPadnos> ok, then I'll stop before my head explodes
[04:50:42] <cradek> oh, more new stuff?
[04:50:56] <SWPadnos> this is from a very recent check-in
[04:51:02] <SWPadnos> module_hal.c
[04:51:41] <cradek> the indentation makes me think he intended that to be in the if, but dunno.
[04:51:56] <SWPadnos> it looks that way, but the code probably shouldn't be in the if
[04:52:03] <cradek> I think I agree
[04:52:33] <SWPadnos> it looks like it's possible to get through the if on lines 294/295 without setting the number of symbols though
[04:52:52] <cradek> I wonder if line 294 is what he meant
[04:53:38] <SWPadnos> hard to tell
[04:53:43] <cradek> oh, maybe
[04:53:51] <SWPadnos> it seems there should be an else clause with an error/abort in it
[04:53:54] <cradek> cap the GPM... at a define
[04:54:18] <SWPadnos> in theory
[04:54:24] <SWPadnos> but what if you asked for more?
[04:54:47] <cradek> I wish people would write that kind of logic as a = MIN(a, b) so it's explicit
[04:55:01] <SWPadnos> the nbr_symbols doesn't get set, and how does the other code know that there is no valid data for the stuff that "overflowed"?
[04:55:05] <SWPadnos> yeah
[04:55:10] <SWPadnos> and maybe put in an error message too
[04:55:21] <SWPadnos> I'd change it, but I don't know that I know what it's supposed to do
[04:55:23] <cradek> yeah it seems incomplete
[04:55:25] <cradek> same
[04:55:34] <SWPadnos> (and I really don't want to read the whole CL codebase to find out)
[04:55:45] <cradek> maybe halvcp has always segfaulted when exiting. who would notice?
[04:56:05] <SWPadnos> anyone who runs from a terminal?
[04:56:47] <cradek> it doesn't show there
[04:56:50] <cradek> I'm seeing it in dmesg
[04:56:56] <SWPadnos> oh, in that case maybe nobody :)
[04:57:03] <SWPadnos> else
[05:04:26] <cradek> I think halvcp calls hal_exit twice
[05:05:35] <SWPadnos> halvcp or pyvcp?
[05:05:41] <cradek> halvcp
[05:06:52] <cradek> http://pastebin.ca/raw/1333630
[05:07:07] <cradek> but I don't get the second one - how can libc's exit() call exit_from_hal?
[05:07:38] <SWPadnos> g_atexit calls exit_from_hal, as does quit
[05:07:48] <cradek> ahhhh
[05:07:51] <SWPadnos> so sigint may cause both
[05:07:51] <cradek> I see that now too
[05:09:21] <cradek> yep that fixes it
[05:10:50] <cradek> man
[05:10:57] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/hal/user_comps/vcp/vcp_main.c:
[05:10:57] <CIA-2> EMC: g_atexit() already causes hal_exit() to be called. this was calling
[05:10:57] <CIA-2> EMC: it a second time, causing a segfault when exiting.
[05:11:04] <cradek> I'm the canary in the mine
[05:11:18] <SWPadnos> hmmm
[05:12:24] <SWPadnos> what happens if you ctrl-c or kill halvcp though?
[05:12:28] <cradek> ok, now I can run demo_sim_cl and exit, and nothing segfaults
[05:12:39] <SWPadnos> does the g_atexit functionality duplicate signal?
[05:12:42] <cradek> I think that's how it gets killed normally. I was just exiting AXIS.
[05:12:52] <SWPadnos> should be SIGTERM then
[05:14:11] <cradek> ah heck, you're right
[05:14:44] <SWPadnos> I'm not sure if you need both paths, but I suspect you do
[05:15:27] <SWPadnos> hmmm
[05:15:34] <cradek> http://euler.aero.iitb.ac.in/docs/Graphics/GTK-1.2/glib/glib-miscellaneous-utility-functions.html#G-ATEXIT
[05:15:43] <cradek> "normal"
[05:15:55] <cradek> whatever that means
[05:16:21] <SWPadnos> quit calls "gtk_main_quit", which may tell gtk that it's exiting "normally"
[05:16:49] <cradek> I need to get to bed. can you fix it right? or should I revert my change?
[05:16:55] <cradek> should we just delete halvcp?
[05:17:02] <SWPadnos> I can't fix it right tonight
[05:17:03] <SWPadnos> heh
[05:17:07] <SWPadnos> I think it's been deprecated for a while
[05:17:14] <SWPadnos> since pyvcp is now a superset
[05:17:18] <SWPadnos> (AFAIK)
[05:17:32] <cradek> vcp will probably be removed in version 2.2
[05:17:33] <cradek> ha
[05:17:47] <SWPadnos> I wonder if g_atexit(quit) would solve the problem
[05:17:51] <SWPadnos> or create a new one
[05:17:52] <cradek> it prints a warning that it will be removed a year ago
[05:18:09] <SWPadnos> then I guess I wouldn't worry about it much, and would probably delete it
[05:18:37] <cradek> I'll mail -devel
[05:18:44] <SWPadnos> good plan
[05:23:29] <cradek> well, WFM now anyway (normal exit)
[05:23:52] <SWPadnos> no matter how you close it?
[05:24:15] <SWPadnos> (kill, exit EMC/AXIS, ctrl-C in vcp, clise button on window border ...)
[05:24:16] <cradek> I think killing it (with kill) doesn't cause hal_exit to be called
[05:24:26] <SWPadnos> oh, that could be a problem
[05:24:52] <cradek> I shouldn't have committed that - if jmk doesn't want to delete it tomorrow, I'll undo it
[05:25:47] <SWPadnos> static vars to track whether the functions have been called would certainly fix it
[05:26:30] <SWPadnos> it might also work to call quit with g_atexit, but that might loop in some cases
[05:27:35] <cradek> maybe hal_exit could not crash the second time
[05:27:52] <SWPadnos> that would be another option
[05:28:06] <cradek> if hal_exit() would set hal_data=0, it would not crash subsequently, it would give an error
[05:28:16] <SWPadnos> true
[05:28:17] <cradek> I have no idea if that's possible to do
[05:28:30] <cradek> not my area of expertise to say the least
[05:32:17] <cradek> goodnight, thanks for your help
[05:32:22] <SWPadnos> night
[05:50:25] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: minor changes, polishing the docs
[05:50:35] <CIA-2> EMC: 03seb 07TRUNK * 10emc2/docs/man/man9/hostmot2.9: minor changes, polishing the docs
[08:33:41] <micges> good morning
[08:34:42] <micges> it would be nice that in
http://www.linuxcnc.org/docs/devel/html/gcode_main.html#sec:Order-of-Execution will be inserted new gcodes added to 2.3
[08:35:04] <micges> this is very helpfull all the time
[08:47:28] <alex_joni> I think the documentation is really a big step forward from 2.2.x
[08:49:47] <micges> yes of course it is :)
[08:50:17] <micges> but I don't actually know if G43 execute first or M61 Qn?
[08:51:21] <alex_joni> M61 shouldn't be run from a program
[08:51:42] <micges> its just example
[08:52:17] <micges> but they can be in ini file
[08:54:24] <alex_joni> G43 is not really usefull in the ini file ;)
[08:56:05] <micges> heh
[08:58:45] <alex_joni> micges: no clue, I would have to look it up ...
[08:59:01] <alex_joni> but since you can use G43.1 it doesn't really matter
[08:59:04] <alex_joni> or G43 Hxx
[08:59:19] <alex_joni> having things overconstrained is sometimes better :)
[09:00:31] <micges> yes
[12:38:51] <BigJohnT> morning alex_joni
[12:51:04] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/images/ (touchoff.png axis-currentandselected.png): add image
[12:54:00] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/ (axis.lyx touchoff.png): moved to images directory and updated
[12:57:32] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/images/manualtoolchange.png: add updated image
[12:58:59] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gui/ (axis.lyx manualtoolchange.png): update image and move to images directory
[13:35:57] <micges> alex_joni: for very costom install of emc+axis the integrator could want to disable preview/dro tabs completely and create pyvcp panel who take care of deleted tabs.
[13:36:32] <micges> it is impossible to delete/disable those tabs from axis now
[13:37:42] <micges> (its too deep coded it)
[13:52:22] <jepler> that's not going to be added as an option in 2.3.
[13:56:12] <jepler> on a related note, we need a keystroke to switch to the BFDRO. I considered making this one of the things that "v" switches to, but I don't like that idea much. F4 isn't used; it could be made a toggle. other thoughts?
[13:59:14] <cradek_> cradek_ is now known as cradek
[14:01:33] <BigJohnT_> should I remove the vcp chapter from the integrators manual in 2.3?
[14:02:09] <jepler> BigJohnT_: sure
[14:02:11] <cradek> it would be a mistake for anyone to start using it today
[14:02:21] <jepler> if we change course on this, we can retrieve it from 2.2 or CVS history
[14:02:28] <BigJohnT_> ok, that is what I thought
[14:05:39] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/rs274ngc/interp_queue.cc: fix silly problem with debug messages
[14:09:46] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/lib/python/bwidget.py: raise_page can be used to determine the current page
[14:10:02] <cradek> jepler: neat, that fixed ladder on the mac too.
[14:10:54] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/shcom.cc: allow sendMdiCmd to be called with a const argument, like std::string::c_str()
[14:11:14] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/shcom.hh: allow sendMdiCmd to be called with a const argument, like std::string::c_str()
[14:11:15] <jepler> cradek: which "that"?
[14:11:23] <cradek> my buffer overrun commit last night
[14:11:27] <jepler> ah
[14:11:33] <jepler> good
[14:12:07] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: keystroke shortcut to toggle between preview and dro
[14:12:11] <cradek> for the BFDRO we could use \
[14:12:17] <cradek> oh hey, too late to worry about that
[14:12:30] <jepler> if you think \ is better, change it right away
[14:12:37] <cradek> what did you use?
[14:12:39] <jepler> F4
[14:12:55] <cradek> mmmmm
[14:46:06] <jepler> cradek: decided whether you have a strong opinion yet?
[14:47:51] <cradek> I think it's fine
[14:48:18] <cradek> I wonder about putting [F4] on the tabs for symmetry (but, it's a toggle, so it might look strange)
[14:56:30] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/src/hal/halmodule.cc: fix halmodule.0 test failures on 64-bit machines
[14:56:49] <jepler> I could make "[F4]" move around, but that seems icky too
[14:57:01] <cradek> yeah
[15:01:44] <jepler> If I could figure out the way to correctly place it:
http://emergent.unpy.net/files/sandbox/show-shortcut.png
[15:03:11] <cradek> it's not important. so many things don't have the key shortcut showing.
[15:04:46] <jepler> nobody uses keyboard shortcuts anyway
[15:08:37] <skunkworks> that is what mice are for..
[15:11:26] <skunkworks> why do I feel bad when I have to use a via? Just one. Damn it - let it go!
[15:15:42] <alex_joni> F4 might be confusing, on all the other GUIs it's for Auto
[15:23:05] <jepler> sounds like a bug to me
[15:23:07] <jepler> :-P
[15:24:04] <cradek> I thought that too, but after I tried it I didn't care, because it's actually pretty cohesive how F3/F4/F5 change those main tabs around
[15:28:32] <jepler> hmm .. so G62/G63 does nothing?
[15:29:21] <CIA-2> EMC: 03cmorley 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: Add halrun.close() to fix error when openning pyvcp panel multiple times
[15:29:41] <alex_joni> jepler: it does the wrong thing
[15:29:51] <alex_joni> G62/63 do the same thing as 64/65
[15:30:29] <jepler> er, "m"
[15:30:39] <alex_joni> err.. yeah
[15:31:20] <jepler> anyway, motion.digital-out-00 doesn't change when I issue g62p0 or g63p0
[15:31:35] <alex_joni> huh? but it should
[15:31:52] <alex_joni> cradek: see.. it's broken
[15:32:34] <skunkworks> isn't there a code to turn digital i/o on? (boy do I sound stupid)
[15:32:53] <alex_joni> jepler: did you mean M62?
[15:33:03] <alex_joni> skunkworks: M62/M63 does that
[15:33:33] <skunkworks> I don't think i am thinking strait - ignore me.
[15:34:00] <alex_joni> /ignore skunkworks
[15:34:36] <skunkworks> I think I was thinking of adaptive feed - where you have to enable it for the pin to work.
[15:34:51] <alex_joni> ah, no.. this should be always on
[15:38:23] <jepler> alex_joni: yes, I keep meaning m when I say g
[15:38:34] <jepler> "meaninm"
[15:38:40] <alex_joni> jepler: M62/M63 call tpSetDout()
[15:39:10] <alex_joni> int tpSetDout(TP_STRUCT *tp, int index, unsigned char start, unsigned char end) {
[15:39:14] <alex_joni> return 0;
[15:39:16] <alex_joni> }
[15:39:27] <alex_joni> jepler: does fixing that count as a bugfix?
[15:40:50] <alex_joni> cradek: can I bounce some ideas off you?
[15:41:02] <jepler> alex_joni: depends how invasive it gets
[15:41:29] <alex_joni> jepler: I'll try to see.. basicly I need a way to add the IO number to the TC list, attached to the next motion command
[15:42:08] <cradek> you mean an arbitrary number of IO numbers to turn on and off
[15:42:20] <alex_joni> then trigger it by calling a emcmotDioWrite()
[15:42:34] <alex_joni> cradek: currently only one is supported at a time
[15:42:44] <alex_joni> increasing that should be for 2.4
[15:42:45] <cradek> but ... currently it's unimplemented
[15:42:57] <alex_joni> I mean between task and motion
[15:43:18] <cradek> I don't understand
[15:43:30] <alex_joni> let me start over
[15:43:35] <cradek> doesn't each M6x cause a EMCMOT_SOMETHING to be sent?
[15:43:40] <alex_joni> yes
[15:43:48] <alex_joni> EMCMOT_SET_DOUT
[15:43:52] <cradek> what is limiting about that?
[15:44:02] <alex_joni> nothing there,
[15:44:40] <alex_joni> but: "// we put in on the TP queue, warning: only room for one in there, any new ones will overwrite"
[15:44:48] <cradek> so you can get EMCMOT_SETLINE, EMCMOT_DOUT, EMCMOT_DOUT, EMCMOT_DOUT, EMCMOT_SETLINE
[15:44:51] <alex_joni> (that's how it's documented in the code :D)
[15:44:58] <cradek> well the comment is wrong then
[15:45:16] <alex_joni> heh, might be
[15:45:23] <cradek> is there any actual code that limits it in this way?
[15:45:28] <alex_joni> no
[15:45:37] <cradek> ok then
[15:45:48] <alex_joni> I think the actual code that limited it this way was discarded
[15:45:48] <cradek> I see no reason for you to write a new wrong implementation because of a comment
[15:46:23] <cradek> ok, so fortunately the old wrong implementation is already discarded :-)
[15:46:41] <alex_joni> ok, so basicly tpSetDout() should put them to a small queue
[15:47:06] <alex_joni> and on the next tpAddLine or AddCircular or whatever there is, it should attach the queue to the move if it's != NULL
[15:47:55] <cradek> maybe: douts_to_be_turned_on[num_douts], douts_to_be_turned_off[num_douts]
[15:48:12] <cradek> don't need a queue, just two 'masks'
[15:48:16] <alex_joni> then in tpRunCycle()? when it gets to the halfway blending, it just calls emcmotSetDout() with the proper params
[15:48:26] <cradek> yes I think so
[15:48:33] <alex_joni> yeah, but num_douts is pretty big I think 16 or so
[15:49:03] <alex_joni> hmm.. no, 64
[15:50:00] <alex_joni> isn't 2 x array[64] pretty big to put on each move?
[15:50:08] <cradek> I don't know
[15:50:12] <SWPadnos> 64 bits
[15:50:16] <SWPadnos> not bytes
[15:50:25] <alex_joni> SWPadnos: does the compiler do that properly?
[15:50:26] <cradek> 64x2 at least
[15:50:39] <SWPadnos> I don't know
[15:50:51] <alex_joni> sizeof(hal_bit_t)
[15:50:53] <SWPadnos> a single long long would do it
[15:50:59] <SWPadnos> no, not that
[15:51:05] <cradek> I don't know if there are even long longs in kernel space
[15:51:10] <alex_joni> I don't want to foo&(i<<x)
[15:51:15] <SWPadnos> hal_bit_t is either 8 or 32 bits
[15:51:41] <alex_joni> I'd rather write it as hal_bit_t dio_on[64], dio_off[64]
[15:51:45] <SWPadnos> but that's an artifact of the atomic access method
[15:51:57] <SWPadnos> that would be bad to attach to every move :)
[15:52:05] <alex_joni> that's why I asked
[15:52:08] <SWPadnos> (IMO, but I've only read back about 20 lines :) )
[15:52:17] <alex_joni> maybe have a pointer to point to such an array
[15:52:33] <alex_joni> and only malloc it when needed
[15:52:39] <SWPadnos> ewwwwwwwww
[15:52:42] <cradek> oh god
[15:53:10] <alex_joni> why ewww?
[15:53:11] <SWPadnos> for (i=0;i<63;i++,masm>>=1) is a very fast loop
[15:53:20] <SWPadnos> mask>>=1
[15:53:38] <alex_joni> well.. the code only goes from 0 to max_dio
[15:53:52] <SWPadnos> even faster then
[15:53:54] <alex_joni> that's a loadrt param for motmod
[15:54:05] <alex_joni> currently it's #define EMCMOT_MAX_DIO 64
[15:54:16] <alex_joni> but if someone decides they need 128.. then it won't work anymore
[15:54:19] <alex_joni> or even 65
[15:54:53] <SWPadnos> the amount of CPU time spent "extracting" bits from a single mask is nearly zero. 64 bits will probably be 500 cycles (plus cache load time)
[15:55:06] <SWPadnos> that's a microsecond on a very very very slow PC
[15:55:31] <alex_joni> I'm not worried about execution time
[15:56:05] <cradek> default tc queue size is 2000
[15:56:11] <SWPadnos> I think the code is just about identically complex with a bitmask vs. an array of hal_bit_t
[15:56:12] <alex_joni> bytes?
[15:56:21] <alex_joni> SWPadnos: ok, might be
[15:56:21] <cradek> write the most obvious, bugfree, human-readable implementation possible
[15:56:30] <alex_joni> but what about 65 DIO's ?
[15:56:32] <cradek> if there is a size problem, change the 2000 to 1500 or 1000
[15:57:39] <cradek> if you use bitmasks, you have to have enough bits no matter what that define, which probably means using the right number of chars
[15:57:57] <alex_joni> what if the define is 65535?
[15:57:58] <SWPadnos> for 65 DIOs (nad maybe 64, if you want to use 32-bit data types), you need to use more than one base data element
[15:58:16] <SWPadnos> then you have a problem, but less of one than if you use an array ;)
[15:58:46] <alex_joni> not if it's a pointer to an array in the TC queue
[15:59:25] <alex_joni> cradek: didn't hear why you don't like that
[16:00:05] <SWPadnos> manual pointer management is the most common source of bugs in C code
[16:00:09] <SWPadnos> IMO
[16:00:31] <alex_joni> that's probably true..
[16:00:36] <SWPadnos> unless there's exactly one mask set in existence at any given time
[16:01:07] <alex_joni> * alex_joni tries some code .. brb
[16:01:09] <jepler> I think cradek is suggesting that simply having an array of EMCMOT_MAX_DIO items is the right thing to do.
[16:01:59] <SWPadnos> ok, the tc queue is 2000 "queue entries", which cradek was suggesting be reduced if the element size gets too big
[16:02:00] <jepler> the right thing to do initially, anyway
[16:03:47] <cradek> yes, my advice is to do the simplest possible, bugfree, human-readable implementation
[16:03:48] <jepler> if you think there's more than a trivial chance that you'll end up having to use a better-packed data structure, then use the simple implementation initially but hide it behind macros like fd_set (see the select(2) manpage) so you can separate "initial implementation" from "grovel around with individual bits for greater speed"
[16:06:03] <SWPadnos> change it to c++ and use a bit vector
[16:06:09] <SWPadnos> * SWPadnos ducks
[16:06:22] <cradek> in tpTurnOn(dio): array[dio] = 1; in tpTurnOff(dio): array[dio] = -1; in TP: foreach a in array[max_dio]: if a==1 turn_on(a); else if a==-1 turn_off(a)
[16:06:56] <cradek> in tpAddLineWhatever: make sure the array is zeroed
[16:07:43] <SWPadnos> now about: in tpTurnOn(dio): array[dio] = 1; in tpTurnOff(dio): array[dio] = -0 in TP: foreach a in array[max_dio]: set_dio(turn_on[a]*turn_off[a])
[16:07:56] <SWPadnos> uh, 0 - not -0
[16:08:28] <SWPadnos> oh, that won't work without a "current state" variable.
[16:08:32] <SWPadnos> nevermind
[16:10:07] <cradek> (gdb) p sizeof(TC_STRUCT)
[16:10:07] <cradek> $1 = 720
[16:10:14] <cradek> add 64 bytes to it, who cares
[16:10:50] <SWPadnos> 128
[16:11:00] <cradek> why?
[16:11:00] <SWPadnos> but nobody really cares still
[16:11:04] <SWPadnos> 64+64
[16:11:19] <cradek> bytes can have more than one value, so you don't need twice NUM_DIO
[16:11:35] <SWPadnos> ah, hence the reason for +1/-1
[16:11:41] <alex_joni> yup
[16:12:02] <cradek> even I wouldn't go so far as to call that premature optimization
[16:12:35] <alex_joni> cradek: the "in TP" should happen in tpRunCycle() right?
[16:12:44] <alex_joni> * alex_joni tries to figure out where blending is halfway
[16:12:48] <SWPadnos> what if you get tuen on and turn off codes for the same I/O?
[16:12:48] <cradek> alex_joni: yes I think so
[16:12:52] <SWPadnos> turn
[16:13:16] <alex_joni> SWPadnos: then you run them in a predefined order
[16:13:22] <alex_joni> first turn on, then turn off
[16:13:28] <cradek> alex_joni: line 956
[16:13:35] <alex_joni> I was at 963
[16:13:42] <SWPadnos> is it possible to turn the same DIO on and off on a single line?
[16:13:50] <SWPadnos> (or during a single move)
[16:14:03] <alex_joni> yes, but you won't notice anything
[16:14:16] <alex_joni> it will happen instantly
[16:14:17] <cradek> SWPadnos: interesting question. the user probably wants a short pulse
[16:14:31] <alex_joni> then they should output a long pulse, and use a timedelay
[16:14:39] <SWPadnos> well, you will notice something if the output gets set at the start of one move and only gets changed at the end
[16:14:54] <SWPadnos> or reset at the start then changed at the end of the move
[16:15:01] <alex_joni> SWPadnos: nah, they get set/reset at the start of a move
[16:15:12] <alex_joni> start==end of previous move
[16:15:15] <SWPadnos> yes, and then not changed again until the start of the next move
[16:15:17] <alex_joni> since we are blending
[16:16:00] <SWPadnos> so I guess I'd document that if you turn the same I/O on and off during a move, that it will be turned off preferentially (and do it that way)
[16:16:17] <alex_joni> cradek: am I reading it right, that it should happen the very first time it goes in the else at line 963 ?
[16:17:01] <SWPadnos> so tpTurnOn(dio) becomes if (array[dio]>=0) array[dio]=1
[16:17:06] <alex_joni> tc->currentvel should be decreasing, nexttc->currentvel should be increasing
[16:17:44] <alex_joni> the moment they are equal we are halfway through blending
[16:18:13] <alex_joni> (which caused by quantisation can be missed, and exact tc->currentvel == nexttc->currentvel)
[16:18:46] <SWPadnos> if (nexttc->currentvel >= tc->currentvel) {process_IO()}
[16:19:11] <SWPadnos> it shouldn't be off by much
[16:22:51] <alex_joni> that's what the else does ;)
[16:23:26] <alex_joni> I wonder if M62/63 break blending
[16:23:40] <alex_joni> they shouldn't .. not sure how it's done in canon atm
[16:27:10] <cradek> SWPadnos: I would prefer 'last setting wins' to 'off wins'
[16:28:06] <alex_joni> cradek: that's how I'm coding it
[16:28:09] <cradek> alex_joni: be careful of the cases where there is no blending, line 1005
[16:28:15] <alex_joni> cradek: another short question
[16:28:18] <SWPadnos> in the unlikely event that someone programs "on" and "off" on the same line, is there a guarantee that the order of execution won't change
[16:28:33] <cradek> I'm pretty sure you can't program them on the same line
[16:28:55] <SWPadnos> ok, if that's the case then "last man standing" is OK
[16:29:25] <alex_joni> you can't have more than one gcode from the same modal group on the same line
[16:29:28] <alex_joni> (in the same block)
[16:29:31] <cradek> right
[16:29:50] <alex_joni> cradek: I have 2 choices in adding this to the tc queue
[16:29:57] <alex_joni> either touch/change all the tpAdd*
[16:30:09] <alex_joni> or put the code in tcqPut()
[16:30:34] <alex_joni> I think the second attempt is uglier, but touches less code
[16:31:36] <cradek> are you planning to put the dio changes with the move whose end, or whose start, should trigger the change?
[16:31:42] <alex_joni> start
[16:32:07] <alex_joni> I think they always need to change on the start of the next move
[16:32:14] <cradek> g1x1, m62p0, g4p1, s300m3, g1x2
[16:32:24] <alex_joni> the g1x2 there
[16:32:27] <cradek> both approaches are broken for some gcode
[16:32:43] <cradek> this makes me wonder if they shoudl be a separate item on the tp queue
[16:32:59] <alex_joni> on the tc queue?
[16:33:03] <cradek> yes
[16:33:33] <alex_joni> that would be even better.. but I'm not sure I can do that easily
[16:33:37] <cradek> I'm not sure how to write it, actually
[16:33:44] <alex_joni> right
[16:33:52] <alex_joni> it would be a totally different structure
[16:33:59] <cradek> yeah, it's not so straightforward
[16:34:20] <alex_joni> I was thinking to do it this way: then tpSetDIO is called, things get written to a temporary location
[16:34:40] <alex_joni> then on the next move (whatever it is) if the temporary location is changed, it gets copied, and cleared out
[16:37:27] <cradek> that sounds fine to me
[16:37:38] <alex_joni> if no move comes, that be it
[16:37:46] <cradek> even if it's a separate queue entry, bunching them up together is probably what you want
[16:55:42] <cradek> hm, don't forget analog outs
[16:55:54] <alex_joni> we don't have g-code for that
[16:56:03] <cradek> oh? I thought we did.
[16:56:12] <cradek> shows what I know about gcode
[16:56:16] <alex_joni> I don't think we do.. only for inputs
[16:56:18] <alex_joni> M66
[16:56:20] <cradek> (but I bet that's what laser folks want)
[16:56:25] <alex_joni> Sxx
[16:56:48] <alex_joni> hmm.. it's actually tougher than what I thought
[16:58:34] <alex_joni> seems there is a start/end value possible
[16:58:40] <alex_joni> but only between task and motion
[16:58:51] <alex_joni> canon doesn't know about it, and probably TP won't know about it
[16:59:01] <alex_joni> we'll fix that for 2.4 properly
[16:59:23] <cradek> those are remnants of the old implementation
[16:59:30] <cradek> I don't think they were ever reflected in gcode
[17:00:21] <alex_joni> right, there's no way to specify that in gcode atm
[17:00:28] <alex_joni> that could be done though..
[17:00:42] <alex_joni> M62 P0 Q0 (or something like that)
[17:00:52] <alex_joni> Qxx specifies the value at the end of the move
[17:01:04] <alex_joni> not for 2.3.0
[17:39:29] <alex_joni> wheee...
[17:40:10] <alex_joni> http://imagebin.org/38187
[17:41:51] <SWPadnos> do outputs get set to some specific value at program end?
[17:43:18] <alex_joni> nope
[17:43:26] <SWPadnos> I wonder if they should
[17:43:51] <alex_joni> that gets into a debate what value they should have
[17:43:56] <SWPadnos> yes
[17:43:57] <alex_joni> (also at startup..)
[17:44:00] <SWPadnos> yep
[17:44:05] <alex_joni> not gonna happen :)
[17:44:17] <SWPadnos> there could be default value inputs, but that's a PITA
[17:44:34] <SWPadnos> same problems occur with HAL drivers anyway
[17:44:38] <SWPadnos> s/occur/exist/
[17:44:56] <alex_joni> right
[17:52:41] <alex_joni> http://www.pastebin.ca/1334231
[18:00:47] <alex_joni> some more testing says it's gotta be right
[18:01:25] <SWPadnos> don't assume char is signed :)
[18:01:30] <SWPadnos> (use signed chars)
[18:02:59] <alex_joni> changed.. thx for spotting that
[18:03:04] <SWPadnos> sure
[18:03:19] <SWPadnos> sorry, but I stopped reading jus after that - doing other stuff: :
[18:03:21] <SWPadnos> :)
[18:03:31] <alex_joni> tc.syncdio = syncdio;
[18:03:44] <alex_joni> I hope that's ok for all platforms/compilers/whatever
[18:03:49] <alex_joni> both are structs
[18:04:04] <SWPadnos> hmm
[18:04:04] <seb_kuzminsky> C says that's a memcopy of sizeof(your_struct)
[18:04:35] <alex_joni> sounds about right then :)
[18:09:28] <skunkworks> very nice... Couldn't you use 8 bits of Di/o then to set the laser power.. muxed in hal.. ;)
[18:09:58] <alex_joni> skunkworks: you can in theory
[18:10:05] <alex_joni> but I wouldn't want to debug that g-code
[18:10:08] <alex_joni> * alex_joni shudders
[18:10:10] <skunkworks> heh
[18:10:18] <alex_joni> maybe using O-calls
[18:10:22] <alex_joni> but still.. brrr
[18:10:38] <seb_kuzminsky> z seems like such a good fit for laser power to me now
[18:10:57] <alex_joni> seb_kuzminsky: it even does blending (laser power ramping)
[18:11:29] <alex_joni> and you can set MAX_VEL/MAX_ACCEL for power ramping
[18:11:40] <seb_kuzminsky> good stuff
[18:23:41] <alex_joni> guess we can always revert it if it breaks something I didn't find so far
[18:24:47] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/kinematics/ (tc.h tp.c tp.h): make M62/63 work
[18:26:59] <seb_kuzminsky> it's ok, the tree's still slushy, not really frozen yet ;-)
[18:27:11] <alex_joni> don't let jepler hear you though
[18:34:16] <CIA-2> EMC: 03alex_joni 07TRUNK * 10emc2/debian/changelog: mention M62/63 fix
[18:45:48] <cradek> that was fast
[18:55:43] <cradek> hm, so far none of the gui programs will run under efence, but the core of emc+hal does
[18:56:24] <cradek> (halmeter, halvcp, axis, classicladder) all fail
[18:56:34] <cradek> usually freeing something that didn't come from malloc
[21:20:47] <BigJohnT_> BigJohnT_ is now known as BigJohnT
[21:37:18] <seb_kuzminsky> "i dont have time to learn how it works, i just need you to fix it for me fast"
[21:37:23] <SWPadnos> heh
[21:38:32] <skunkworks> I think motioncontrol is probably going to get spindle/c axis working.. He seems to not give up. :)
[21:57:06] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/User_Concepts.lyx: note that cutter comp only looks ahead one move
[22:11:18] <BigJohnT> I don't see where /configs/sim/test.vcp is used anywhere so is it safe to delete from trunk?
[23:23:02] <cradek> BigJohnT: I'm not sure it's true that there is "one segment lookahead". To be precise, to determine whether the tool can get to a programmed move without gouging, three moves are relevant: that one, the one before it, and the one after it
[23:23:32] <SWPadnos> one-segment look-ahead-behind
[23:23:33] <cradek> but, it's just academic I think
[23:24:03] <cradek> well it considers two "corners" and corners are formed by adjacent moves
[23:24:31] <cradek> also, it might "look ahead" arbitrarily far in some programs
[23:24:51] <SWPadnos> really?
[23:24:57] <cradek> move into an XY corner and then move up and down a zillion times: a zillion segment "lookahead"
[23:25:02] <SWPadnos> ah, right
[23:25:08] <SWPadnos> teo "plane corners"
[23:25:10] <SWPadnos> two
[23:25:12] <cradek> because that corner isn't determined until 1zillion+1 moves
[23:25:30] <cradek> so I dunno
[23:25:55] <SWPadnos> I know I asked this before, but are peck cycles allowed with comp on?
[23:25:58] <cradek> I'd hate for people to compare "number of lookaheads" in a simplistic way and assume one system is better than another
[23:26:03] <SWPadnos> yeah
[23:26:14] <cradek> they all have big tradeoffs
[23:26:27] <cradek> (of course, I made the best tradeoffs)
[23:26:36] <cradek> no, canned cycles are not allowed with comp
[23:27:12] <SWPadnos> ok
[23:27:19] <SWPadnos> oh, and "yeah, right" :)
[23:27:32] <cradek> :-)
[23:29:23] <BigJohnT> cradek: I kind of simplified it :)
[23:33:13] <cradek> one could defend calling it "one segment lookahead" and one could also defend calling it "infinite lookahead"
[23:33:18] <cradek> maybe, also 2
[23:33:24] <cradek> but, the other numbers are right out
[23:33:38] <cradek> off to help with dinner, bbl
[23:33:43] <BigJohnT> I was just trying to give the user a little heads up
[23:33:49] <BigJohnT> what's cooking?
[23:33:51] <cradek> I understand
[23:33:56] <cradek> not sure, I think potatoes are involved
[23:34:01] <BigJohnT> yumm
[23:34:28] <cradek> instead of describing the implementation (lookahead etc) maybe you could describe the behavior: what kinds of paths work and what don't, that kind of thing
[23:35:45] <BigJohnT> that is a better idea :)
[23:35:48] <cradek> something like: the tool must be able to touch somewhere along each programmed move without gouging the two adjacent moves for it to work
[23:36:04] <cradek> if that's not possible for some particular programmed move, you get an error
[23:36:05] <BigJohnT> can I quote that?
[23:36:17] <cradek> if you switch to a smaller tool, the error might go away!
[23:36:23] <cradek> yes definitely
[23:36:56] <cradek> it's the geometry of the path that's important
[23:37:02] <cradek> ok, really going now :-)
[23:37:05] <cradek> thanks again
[23:37:20] <BigJohnT> ok enjoy dinner
[23:48:28] <CIA-2> EMC: 03jepler 07TRUNK * 10emc2/docs/src/Submakefile: vcp.lyx has been removed
[23:49:29] <jmkasunich> hal_vcp can (and should) go away IMO
[23:49:42] <jmkasunich> we just need to convert those things that use it over to pyvcp
[23:59:15] <BigJohnT> jmkasunich: /configs/sim/test.vcp does not seem to be used anyplace can I just delete it?
