Back
[00:25:59] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/hostmot2.c: Add some missing sanity checks of the hostmot2 idrom clock frequencies.
[02:00:12] <CIA-40> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (TODO hostmot2.c):
[02:00:12] <CIA-40> EMC: Fix a minor insanity in my sanity-checking.
[02:00:12] <CIA-40> EMC: Also: more to do
[02:06:25] <SWPadnos> hey jepler, do you recall the name of that internet cafe you went to in Göttingen?
[02:25:08] <cradek> seb is tireless
[02:25:33] <SWPadnos> heh
[02:43:13] <jmkasunich> I just managed to annoy Axis
[02:43:38] <jmkasunich> I mv'ed the g-code file to another directory, then touched off
[02:43:46] <jmkasunich> it must have tried to do a reload
[02:45:25] <SWPadnos> yep - touchoff does a reload
[02:46:13] <SWPadnos> probably because the preview has to change relative to the new origin
[02:47:19] <SWPadnos> hmm. actually, it redraws, then reloads the file
[02:51:57] <jmkasunich> found something else annoying
[02:52:07] <jmkasunich> the pyvcp spinbox widget is aptly named
[02:52:29] <SWPadnos> does it spin from one side right to the other?
[02:52:43] <jmkasunich> although you can click in it and type numbers, the HAL pin isn't updated unless you click on the up/down arrows
[02:52:57] <jmkasunich> you can't just type a number and hit enter or whatever
[02:53:13] <SWPadnos> hmmm. even if you press enter or tab to move out of the edit box?
[02:53:23] <jmkasunich> enter doesn't work, lemme try tab
[02:53:55] <SWPadnos> ok. requiring enter or tab is good - you don't want something changing to 1 then 10 then 100 then 1000 as you type
[02:53:55] <jmkasunich> nope
[02:53:58] <SWPadnos> bummer
[02:54:09] <jmkasunich> agreed about requiring something
[02:54:48] <jmkasunich> as it stands, you can type your number, then hit up-arrow to increase it by one increment and output to hal, then down-arrow to decrease it back to what you typed and output to hal again
[02:55:20] <SWPadnos> I'd file a bug report (or hope someone fixes it while you remember it's there :) )
[02:56:16] <jmkasunich> well, it matches the description in the manual
[02:56:28] <jmkasunich> "Spinbox controls a FLOAT pin. You increase or decrease the value of the pin by 'resolution' by either pressing on the arrows, or pointing at the spinbox and rolling your mouse-wheel."
[02:56:35] <SWPadnos> ah :)
[02:57:22] <jmkasunich> although I think it should either be impossible to type in the box (so it works _exactly_ as described), or you should be able to type in it and then hit enter to accept what you typed
[02:59:23] <SWPadnos> feature request then
[03:03:30] <jmkasunich> bug report actually
[03:03:44] <jmkasunich> the arrow key trick gets interesting when you are out of estop
[03:03:57] <SWPadnos> oh, yes indeed
[03:04:18] <jmkasunich> if the widget has focus, hitting the arrow key increments the number, then it loses focus and you get a jog
[03:04:46] <SWPadnos> does the HAL pin update?
[03:05:24] <jmkasunich> yeah
[03:12:32] <jmkasunich> there....
[03:13:14] <jmkasunich> I think it should update HAL on enter (if it has focus)
[03:13:32] <jmkasunich> I'm not sure about when it loses focus (from hitting tab, or clicking somewhere else on the screen)
[03:14:58] <jmkasunich> not sure what the "right" behavior would be regarding the arrow keys - when the widget has focus, should it own the keyboard, including arrows?
[03:15:08] <SWPadnos> I'd say that if a number is showing, and it's not being edited (ie, the cursor isn't there), then the HAL pin should reflect that number
[03:15:47] <SWPadnos> tough question
[03:15:50] <jmkasunich> yeah, that probably makes sense
[03:16:03] <cradek_> I think a box that's a readout and also an entry is bad UI
[03:16:07] <cradek_> for all these reasons
[03:16:08] <SWPadnos> I'd say it should own the keyboard, but then we end up with problems like F1 and estop
[03:16:17] <jmkasunich> spinbox is not a readout, it is only an entry
[03:16:20] <SWPadnos> it's not a readout (except for the spinbuttons)
[03:16:37] <SWPadnos> it only gets changed by user actions
[03:16:45] <cradek_> oh, ok
[03:16:50] <cradek_> cradek_ is now known as cradek
[03:17:04] <jmkasunich> I'd be perfactly happy if we had a completely different widget for typing in numbers, no "spinbox" behavior at all
[03:17:10] <jmkasunich> however, the real bug would still be present
[03:17:41] <jmkasunich> when the widget has focus, there is a blinking "type text here" cursor in it, and whatever you type appears there
[03:17:47] <jmkasunich> but it is also interpreted by axis
[03:17:54] <jmkasunich> type "R", and axis tries to run the program
[03:18:03] <cradek> ouch
[03:18:08] <cradek> that stuff is a pain
[03:18:39] <jmkasunich> wouldn't be an issue for a standalone pyvcp panel, but when it is an axis side panel....
[03:18:57] <cradek> I guess I have only used buttons and readouts there
[03:19:09] <jmkasunich> ditto for me
[03:19:27] <jmkasunich> but now I want to enter a number
[03:20:00] <jmkasunich> and I can't do it by clicking on the "increment" button and waiting for it to count up to 1.0004 by increments of 0.0001
[03:20:12] <jmkasunich> well, I can.... but I refuse to
[03:21:55] <SWPadnos> I guess you'd be setting spindle speeds or feed override (or selected axis or something) if you were typing with the keyboard numbers vs. the keypad
[03:22:25] <jmkasunich> good question - I don't have a keypad, didn't notice if the feed override was changing while I entered numbers
[03:22:35] <SWPadnos> oh - mini keyboard?
[03:22:44] <jmkasunich> yup, the FO changes as I type
[03:22:51] <jmkasunich> yes, mini rubber keyboard
[03:23:38] <jmkasunich> so, the issue becomes "while this widget has a 'type text here' cursor in it (has focus), typing should go only to the widget
[03:23:57] <jmkasunich> except ESC and F1 (just to make it a challenge)
[03:24:25] <SWPadnos> ESC is necessary. F1 less so IMO
[03:24:31] <jmkasunich> agreed
[03:25:51] <jmkasunich> interesting - clicking on the increment and decrement buttons doesn't give the widget focus (at least, it doesn't put the cursor there)
[03:26:05] <jmkasunich> I don't have a scroll wheel on that mouse (its a touchpad)
[03:26:09] <SWPadnos> no, the buttons have focus when you click them
[03:26:28] <SWPadnos> no scrolly-area on the side?
[03:26:43] <jmkasunich> how does the scrollwheel action work - does the widget need to have focus when you scroll? or does the pointer just need to be over it?
[03:27:11] <SWPadnos> I think scroll events go to the underlying widget, regardlesss of focus
[03:27:34] <jmkasunich> I didn't realise my touchpad had a scrolly area
[03:27:42] <SWPadnos> almost like the old focus-follows-pointer, but not quite
[03:27:44] <SWPadnos> heh
[03:27:53] <jmkasunich> it does work - if the pointer is over the widget, it will scroll, regardless of whether it has focus or not
[03:28:00] <SWPadnos> cool
[03:28:08] <SWPadnos> now all you need is a 6 foot tall touchpad ;)
[03:29:14] <jmkasunich> so it really comes down to the text entry cursor
[03:30:10] <jmkasunich> either the widget should never be able to get that cursor (use only the up/down buttons or the mouse scroll) or when it has the cursor, it should block axis from seeing the keystrokes
[03:31:57] <SWPadnos> yep
[03:32:37] <SWPadnos> I'm not sure how axis tracks what widget has focus, if it does so
[03:32:50] <jmkasunich> I don't even know where to start looking
[03:32:55] <jmkasunich> and its 11:30
[03:32:57] <SWPadnos> it seems that it's mostly unnecessary - if you're typing into MDI, you're not in manual mode
[03:33:04] <SWPadnos> heh - it ain't gettin done tonight
[03:33:17] <jmkasunich> so I;m going to walk the dog, go to bed, and hope jeff sees this conversation
[03:33:18] <SWPadnos> unless jepler has already fixed it and is just waiting to commit the patches
[03:33:30] <SWPadnos> good plan. see you
[03:33:39] <jmkasunich> goodnight
[10:03:54] <micges> Is there possible to split feedoverride to 3 values applying to single axes ?
[10:04:37] <alex_joni> no
[10:05:43] <micges> tp must be rewriten to do this ?
[10:15:39] <alex_joni> I don't understand how you want this to work..
[10:16:16] <micges> simply
[10:16:20] <micges> two fo
[10:16:25] <micges> xfo and yfo
[10:17:22] <micges> we have material that behave differently when milling in x and y direction
[10:19:01] <micges> and when f=100, x_fo = 90% y_fo = 20% => machine move in x dir 90 mm/min and when in y direction 20 mm/min
[10:19:47] <micges> thats all
[10:22:46] <alex_joni> and when you move from (0,0) to (10,10) what happens?
[10:52:14] <micges> calculate ((vel_x + vel_y)/vel_x) * fo_x for axis x
[10:52:35] <micges> for y simmilar
[10:59:05] <alex_joni> then you don't want feed override
[10:59:12] <alex_joni> you want a max feed
[10:59:33] <alex_joni> if you set feed override to 30%, the machine will move with 30% of the set speed
[10:59:49] <alex_joni> if you set x feed override to 30% then the X axis will move with 30% of what it should
[10:59:59] <alex_joni> if Y is set to something else, you won't get the right shape
[11:04:47] <micges> you right
[11:29:52] <alex_joni> so what you want is a max speed on the X and Y aces
[11:29:58] <alex_joni> axes even
[11:30:51] <micges> I see now
[12:53:25] <jepler> I think you'd better calculate the appropriate F-number in your CAM based on the angle of each move. It's not entirely unlike having different feed rates for plunges vs other moves, for instance.
[13:02:00] <jepler> as to the spinbox problem: it's not hard to give the spinbox the same behavior as the mdi entry field (to not pass keystrokes through to the thing that sets override and/or the active axis)
[13:02:23] <jepler> the next problem that arises is that there's no obvious way to give focus back to axis and restore those keys
[13:02:32] <jepler> (tab doesn't do it, clicking on the background doesn't do it)
[13:06:22] <jepler> any of you want to tell me what you would expect as a user?
[13:09:57] <alex_joni> I think clicking inside should popup a "enter value" dialog, and dismissing that should enter the number and update the HAL pin
[13:11:59] <jepler> hm -- yeah. suppose you want to increase it from 100 to 200 by typing. If you click after the "1", press backspace, then press 2, the pin's value was 0 for awhile. that may be unacceptable..
[13:13:11] <jepler> if pyvcp is improved to have this pop-up, it'll work fine -- the pop-up won't have to do anything special to not trigger normal manual-mode actions
[13:13:30] <jepler> (on the other hand, it would have to do something special to make F1 estop...)
[13:13:51] <cradek> ugh
[13:15:10] <jepler> hm again, maybe not. the <Key-F1> binding is on 'all', not on '.' so it should be available in any widget that doesn't go out of its way to override it .. Esc for abort is another story, specifically because it is the standard keystroke to dismiss popups
[13:17:01] <jepler> add this to the confusion: typing in the spinner isn't actually updating the hal value for me
[13:21:56] <alex_joni> jepler: that was jmks original complaint
[13:22:09] <alex_joni> I still think typing in the spinner shouldn't work
[13:43:55] <steves_logging> steves_logging is now known as steve_stallings
[13:45:01] <steve_stallings> using a pop up dialog box is an unambigious indication that you ARE changing the value only when you click on apply or OK
[13:45:17] <cradek> I agree
[13:45:27] <jepler> hi steve_stallings
[13:45:35] <alex_joni> and dismissing it using cancel doesn't update it
[13:45:36] <jepler> alex_joni: ah, I didn't scroll all the way back t osee
[13:45:37] <alex_joni> hi steve_stallings
[13:45:48] <alex_joni> jepler: I read the bugreport first :)
[13:45:52] <jepler> alex_joni: phtpthtoht
[13:46:00] <alex_joni> * alex_joni looks that up
[13:46:15] <alex_joni> Your search - phtpthtoht - did not match any documents.
[13:46:22] <alex_joni> .. not yet at leas
[13:46:23] <alex_joni> t
[13:46:24] <jepler> s/o/p/
[13:46:49] <alex_joni> 2 links :)
[13:46:50] <steve_stallings> the popup approach also has the advantage that the HAL pin is alway set to the value shown in the spin box
[13:47:11] <jepler> CIA-40: are you still constipated?
[13:47:12] <steve_stallings> principal of "least surprise"
[13:47:30] <alex_joni> jepler: seems CIA is back in pain
[13:47:34] <alex_joni> * alex_joni kicks CIA-40
[13:47:34] <CIA-40> ow
[13:47:39] <alex_joni> * alex_joni kills CIA-40
[13:47:40] <CIA-40> * CIA-40 dies
[13:47:41] <jepler> back pain? poor guy
[13:47:48] <jepler> * jepler gives CIA-40 a handful of advil
[13:47:59] <alex_joni> * alex_joni rubs CIA-40's tummy
[13:47:59] <CIA-40> *purr*
[13:48:14] <cradek> I've never seen a multi-day delay in cia before - they must have had an amazing backlog
[13:48:17] <alex_joni> maybe that helps with the constipation
[13:49:22] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/docs/src/gcode/main.lyx: typos
[13:49:56] <alex_joni> cradek: they probably dropped the rest
[13:52:28] <BigJohnT> cradek: what the heck was I thinking? :)
[13:52:43] <BigJohnT> Pete and RePete :)
[13:52:43] <cradek> :-)
[13:52:49] <cradek> thanks for writing it
[13:52:54] <BigJohnT> np
[13:55:40] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py:
[13:55:40] <CIA-40> EMC: partially address the problem of vcp entry and spinbox widgets that take keyboard focus
[13:55:40] <CIA-40> EMC: * apply the same bindings modifications to Spinbox as Entry. This is what causes "1" to not switch to axis 1 or set feed override to 10% when using the mdi entry field.
[13:55:40] <CIA-40> EMC: * make hitting enter in most widgets in the root window focus back on the root window, so that you can get back the normal manual-mode behaviors after typing in a spinbox
[13:55:43] <CIA-40> EMC: this leaves the pyvcp spinbox keyboard bugs which exist in pyvcp whether used in conjunction with axis or not
[13:55:46] <CIA-40> EMC: 03jepler 07TRUNK * 10emc2/share/axis/tcl/axis.tcl:
[13:55:48] <CIA-40> EMC: partially address the problem of vcp entry and spinbox widgets that take keyboard focus
[13:55:50] <CIA-40> EMC: * apply the same bindings modifications to Spinbox as Entry. This is what causes "1" to not switch to axis 1 or set feed override to 10% when using the mdi entry field.
[13:55:53] <CIA-40> EMC: * make hitting enter in most widgets in the root window focus back on the root window, so that you can get back the normal manual-mode behaviors after typing in a spinbox
[13:55:56] <CIA-40> EMC: this leaves the pyvcp spinbox keyboard bugs which exist in pyvcp whether used in conjunction with axis or not
[14:23:13] <cradek> jepler: do you have an idea what causes the incorrect rapids when using tool offsets? if it's hard to fix, could extents and unzoom be made to ignore rapids when their display is turned off?
[14:25:29] <jepler> cradek: I haven't looked into it.
[14:25:49] <jepler> maybe unzoom should always ignore rapids :-P
[14:25:58] <cradek> possibly
[14:27:43] <cradek> I think the problem is that with the machine at tool change position, the tool tip is some arbitrary place. then it takes several moves to get from there to the work. in this program I'm looking at, I always change tool (old tool tip moves somewhere near tool change position), then g43 (tool tip flies somewhere new), then g0 x[radius], then g0 z[safe], then start cutting
[14:28:25] <cradek> so which things don't you show? maybe it's impossible to know.
[14:31:19] <alex_joni> a lot of people are complaining about the default G64
[14:31:42] <alex_joni> and from their compleint it's a change from 2.1.x to 2.2.x (din't bother actually looking in the code if that is so)
[14:31:57] <cradek> I don't think that's the case
[14:32:16] <cradek> I mean, that it changed
[14:33:31] <alex_joni> yeah, I understood what you mean.. it also struck me as odd
[14:36:47] <SWPadnos> I suspect there's a larger user base, specifically of users that don't know that G61 and G64 exist
[14:37:29] <SWPadnos> someone else would have been surprised if their "circle" came out as a 100-gon due to G61 and a stupid post
[14:40:06] <CIA-40> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: after 5 seconds, give up and try to print something useful in the case of misconfigured axes
[14:43:07] <jepler> something else you might consider doing (and mind you I haven't thought this through yet): look at the change in angle between the moves. if the angle is above a threshhold, use exact stop mode. in particular, a 180-degree reversal is something that probably should be exact stop
[14:45:24] <cradek> in a previous version [ahem], I only blended obtuse angles to avoid the adding acceleration on reversal
[15:21:11] <issy> hi all
[15:26:20] <cradek> hi issy
[15:26:34] <issy> haw are you
[15:28:03] <cradek> fine
[16:02:46] <jepler> cradek: do you mean the machine origin has to be within 1" of the top of travel?
[16:02:49] <jepler> or the offset origin?
[16:05:30] <cradek> offset origin
[16:06:23] <cradek> I think that bug report assumes machine Z 0 is the top of travel
[16:36:38] <steve_stallings> steve_stallings is now known as steves_logging
[17:09:39] <alex_joni> seb's comments in the code are fun :)
[17:09:48] <alex_joni> "// oh shit i'm gonna overshoot!"
[17:11:34] <BigJohnT> at least he doesn't try to hide the excitement of overshooting your target :)
[18:19:50] <issy> did somebody ever use the softdmc from mesa
[18:29:51] <jepler> no, and it's not really a good match for emc--hostmot is much better. softdmc does things like generate trapezoidal motion profiles based on endpoints, but emc does that just fine.
[18:30:12] <jepler> (and unlike hostmot I do not believe softdmc is gpl)
[18:59:53] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_INIT
[18:59:54] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_SPINDLE_INIT
[20:26:01] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_HALT
[20:26:02] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_SPINDLE_HALT
[20:27:47] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_ABORT
[20:27:47] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_SPINDLE_ABORT
[20:28:25] <cradek> whee
[20:29:28] <SWPLinux> so how does the spindle get haltede?
[20:29:31] <SWPLinux> halted
[20:30:13] <alex_joni> SPINDLE_STOP ?
[20:30:13] <cradek> it doesn't, it gets stopped
[20:30:30] <alex_joni> and sometimes using SPINDLE_OFF
[20:30:49] <SWPLinux> ok
[20:31:08] <alex_joni> odd to have both.. but who am I to judge
[20:32:28] <SWPLinux> I can see using stop to set the speed to 0, but leave the spindle-on pin active (keeping the VFD energized at velocity 0)
[20:32:40] <SWPLinux> vs. off meaning "no power" or something
[20:33:33] <alex_joni> that should be spindle-enable
[20:33:37] <alex_joni> but there is no such thing
[20:34:00] <SWPLinux> ah
[20:34:12] <alex_joni> should be though, I think
[20:34:15] <SWPLinux> I can see a difference between stopping and powering off - I guess that was my point
[20:34:24] <SWPLinux> I don't know if that's how it's used
[20:40:26] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_FORWARD and _REVERSE
[20:40:26] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_SPINDLE_FORWARD and _REVERSE
[20:40:45] <alex_joni> SWPLinux: it's not used at all
[20:40:54] <alex_joni> and not thought through either
[20:41:05] <alex_joni> hmm.. that's probably too harsh
[20:41:30] <alex_joni> it's made to fit the NIST phylosophy.. multiple controllers which talk NML
[20:41:51] <alex_joni> one task controller with talks to an IO controller which talks to the SPINDLE controller, etc
[20:43:39] <alex_joni> lol, this is funny:
[20:43:45] <SWPLinux> thinking it through, it makes to have separate start, stop, set_speed, and disable (or off) functions
[20:44:20] <SWPLinux> set_speed might also be separable into set_direction and set_rate, but I think I'd favor using a signed speed settings
[20:44:27] <SWPLinux> -a
[20:44:48] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_STOP
[20:44:49] <alex_joni> guess _STOP is not used either :)
[20:44:57] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_SPINDLE_STOP
[20:45:58] <alex_joni> one of the things that make these things fuzzy is that there are multiple data paths that use the same messages
[20:46:14] <alex_joni> GUI talking to task (sends spindle_on, off, brake off, etc..)
[20:46:24] <alex_joni> interp to task (similar messages)
[20:47:59] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_ENABLE
[20:48:43] <SWPLinux> yeah, that's why I only think about it sometimes, and never end up doing anything :)
[20:49:14] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_SPINDLE_DISABLE
[20:49:42] <alex_joni> spindle done, aux next :)
[20:53:03] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_AUX_INIT
[20:53:04] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_AUX_INIT
[20:53:04] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: remove unused EMC_AUX_INIT
[20:55:44] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: remove unused EMC_AUX_HALT
[20:55:44] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_AUX_HALT
[20:55:45] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_AUX_HALT
[21:00:22] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/iotask/ioControl.cc: remove unused EMC_AUX_ABORT
[21:00:23] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_AUX_ABORT
[21:00:23] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/usr_intf/iosh.cc: remove unused EMC_AUX_ABORT
[21:06:25] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/nml_intf/ (emc.cc emc.hh emc_nml.hh): remove unused EMC_AUX_DIO_WRITE
[21:06:25] <CIA-40> EMC: 03alex_joni 07TRUNK * 10emc2/src/emc/task/emccanon.cc: remove unused EMC_AUX_DIO_WRITE
[21:36:52] <CIA-40> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/classic_ladder.lyx: some more editing