Back
[01:38:18] <jepler> .. didn't immediately get hm2 high-resolution proving to work, unfortunately
[02:01:50] <skunkworks> Few issues?
[02:02:50] <jepler> something's not right in the communication between the driver and the firmware
[02:03:05] <jepler> I haven't figured out just what, yet
[02:05:31] <jepler> in principle it's nice and easy: the driver tells the firmware to store the exact number of counts when the probe makes contact and set a flag. When it sees the flag set, it converts the stored counts into a probed position. the end.
[02:06:16] <jepler> but my modified hostmot2 driver (not yet commited to git.linuxcnc.org) just doesn't work right. sometimes the probed position just keeps changing, other times it doesn't change at all
[02:10:12] <skunkworks> odd
[02:11:06] <jepler> probably something I'm overlooking still
[06:30:03] <micges_work> good morning
[06:38:04] <dgarr> micges_work: do you use emc gcode subroutines?
[06:54:24] <micges_work> dgarr: yes
[07:00:04] <dgarr> i wrote a tcl/tk script as a frontend gui for subroutines: see
http://www.panix.com/~dgarrett/ngcgui/ngcgui.txt
[07:00:43] <dgarr> screenshot:
http://www.panix.com/~dgarrett/ngcgui/ngcgui.png
[07:02:03] <micges_work> dgarr: Cool, I use my own gcode generators ;)
[07:02:40] <dgarr> this gui makes it easy to call up subroutines -- i'm finding it useful for debugging them
[07:02:45] <micges_work> dgarr: I was thinking that you want ask about subroutines ;)
[07:05:25] <dgarr> no -- i'm trying to get someone to try this gui and give me some feedback
[12:41:13] <jt-dev> what is the syntax for a font for touchy?
[12:41:42] <jt-dev> I've tried in the [default] section control_font = sans 16
[12:41:49] <jt-dev> and sans,16
[12:48:09] <jt-dev> I saw this in the terminal when running touchy No option 'control_font' in section: 'DEFAULT'
[12:48:29] <jt-dev> so I added a [DEFAULT] section to the ini
[12:50:40] <jepler> you should edit touchy's font using touchy, not by editing any inifile
[13:04:07] <jepler> cradek:
http://maemo.org/api_refs/4.0/gtk/GtkSettings.html#GtkSettings--gtk-touchscreen-mode
[13:04:34] <jepler> I think if one of us can just figure out how to set that for touchy, it will kill the "last button clicked looks funny" behavior
[13:05:37] <cradek> jepler: hey slick
[13:07:50] <jt-dev> ok, I was just guessing :)
[13:08:34] <cradek> jt-dev: it gives a warning the first time - it's a "feature" of the ini file module - you can just ignore it
[13:08:49] <jt-dev> ok thanks
[13:08:54] <cradek> .touchy_preferences actually gets filled out with the default entries the first time you run touchy
[13:09:23] <cradek> then it uses that to save your fonts, commanded/actual, block delete, etc settings
[13:11:47] <jt-dev> so if you wanted to set touchy up on a normal computer then copy it to another one that had a touch screen you would need .touchy_preferences
[13:14:24] <jt-dev> * jt-dev heads out
[13:54:16] <skunkworks_> logger_dev: bookmark
[13:54:17] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-10-23.txt
[16:28:30] <mhaberler> /msg nickserv identify Mp62i-0003uU-QD
[16:31:57] <cradek> time to change your password
[16:32:08] <mhaberler> uh-oh
[16:32:11] <skunkworks_> wow - I thought I was the only one that did that..
[16:32:29] <mhaberler> btw - we#re on to something, mail coming
[16:36:19] <mhaberler> told ya, MBA...
[16:47:41] <cradek> mhaberler: what is the gcode like? is this a g76?
[16:48:22] <mhaberler> no, g33
[16:48:24] <mhaberler> here's the file I ran:
http://mah.priv.at/cgi-bin/viewvc.cgi/emc-syncmove/threading-mah.ngc?revision=1.3&root=CVS&sortby=date&view=markup
[16:48:54] <cradek> so what I'm seeing is two consecutive passes in that while loop?
[16:49:57] <mhaberler> yes
[16:50:14] <cradek> does it oscillate sometimes, or every other time through, or some other pattern?
[16:51:13] <mhaberler> usually a couple of clean passes, then one or several jerky ones, than clean again - no clear pattern like alternating or so
[16:51:22] <cradek> ok
[16:52:32] <cradek> wait, this must not be the same code I'm running, because sync-accel stays constant
[16:52:42] <cradek> what version is this? 'git describe'
[16:58:33] <mhaberler> I pulled yesterday and did a branch for the debug pins; no other changes
[16:58:37] <alex_joni> cradek:
http://www.linuxcnc.org/docview/devel/html/gui_touchy.html
[16:59:20] <cradek> Error: does not exist
[16:59:27] <alex_joni> cradek: indeed it doesn't :P
[16:59:38] <cradek> haha
[16:59:41] <cradek> this I know
[16:59:52] <alex_joni> where's BJT when you need him :P
[17:01:55] <micges> hi guys
[17:02:18] <JT-Work> right here
[17:03:03] <cradek> mhaberler: are spindle-vel and target-vel zero as well as sync-accel doesn't trigger? something is very wrong there.
[17:03:13] <cradek> if you could get a sim configuration where this happens it would be really nice.
[17:03:40] <cradek> alex_joni: I thought you were going to show me some docs you put together ... imagine my disappointment!
[17:04:03] <JT-Work> I'm working on them :)
[17:04:16] <cradek> our hero as usual :-)
[17:04:19] <alex_joni> cradek: I can imagine :)
[17:04:37] <alex_joni> but my plan was to whine enough so that BJT takes pitty in us
[17:06:16] <micges> I'm retrofittng 85' laser which have mechanical switches and earlier it has switches that slow down homing to about 5 mm/min
[17:07:13] <mhaberler> cradek: yes, looks like thats the case. other environment change is a self-built smp kernel because its a Core2 cpu but I'll revert to the vanilla kernel for now to exclude that
[17:07:25] <micges> Any restrictions for adding support for such thing to emc?
[17:07:47] <cradek> micges: how does it work?
[17:08:11] <micges> as we barely run it
[17:08:29] <micges> it is huge table laser 2.5x2.5m
[17:08:50] <cradek> seems like you could do it with one switch with emc, since it can find the switch fast, then pull back off, then go slow and find it again
[17:08:57] <jepler> cradek:
http://pastebin.ca/1640435
[17:08:58] <cradek> maybe the old control was not smart enough to do that
[17:09:25] <cradek> jepler: cool!!
[17:09:51] <cradek> jepler: the only other thing that might help is to make the pointer disappear
[17:10:12] <micges> cradek: ah yes you right, nm then
[17:10:40] <cradek> micges: :-)
[17:11:14] <cradek> micges: you just have to be sure the switch stays tripped long enough for the machine to decelerate and stop
[17:11:34] <cradek> ideally the home switch cam goes all the way past the limit switch position
[17:12:02] <micges> cradek: at low speed it is possible
[17:20:42] <cradek> jepler: hm, it doesn't change for me - is that because I'm on dapper?
[17:23:04] <jepler> cradek: yes, it looks that way
[17:23:11] <jepler> I tested it on hardy
[17:23:46] <jepler> I have a way to set the cursor invisible but it makes touchy real hard to use without the touchscreen!
[17:25:24] <cradek> hm, yeah I bet
[17:25:42] <cradek> maybe it could be a preference, if we can fit it on the prefs screen somewhere
[18:06:46] <micges> how can one additionally secure(in software) machine if it is some very fast machine for mass production (3d mill, velmax=150, acc=11000. some ideas, thoughts?
[18:08:12] <micges> I've found only some additional soft limits settings
[18:21:17] <cradek> what do you mean secure?
[18:29:45] <micges> hmm
[18:31:06] <micges> dont fully know, I'm only afraid what suddenly position hold after some errors can do with it
[18:31:51] <micges> I think that all stops in emc are with deacc?
[18:32:46] <cradek> all normal stops have full deceleration
[18:33:01] <cradek> estop and following error just disable the amps to stop - if you need braking you should have brakes
[18:33:54] <micges> ah yes brakes
[18:36:44] <alex_joni> micges: on fast machines, e.g. our robots, each motor has a mechanical brake
[18:37:04] <alex_joni> if you take off power from the machine, the brakes engage and the axis stops abruptly
[18:37:17] <alex_joni> this can be pretty scary, but it's safer
[18:37:48] <alex_joni> (imagine a big axis - maybe 2000kg of moving mass - running at 1m/sec and stopping with a brake)
[18:38:51] <micges> uh oh inertia ?;)
[18:41:00] <micges> ok thanks guys
[18:44:46] <cradek> if dc motors, you can get cheap braking by shorting the servo motor leads with a contactor (IF your amps can survive having the motors disconnected for an emergency stop)
[18:50:28] <micges> cradek: I will check this
[18:52:03] <cradek> micges: some amps will blow up if you remove the motor while the amp is on - some have protection because they expect you to do that to brake
[18:52:11] <cradek> <- not an expert
[18:53:04] <micges> ok
[19:01:12] <CIA-82> EMC: 03seb 07master * r7c7714bd83de 10/docs/man/man9/hostmot2.9: clarify hm2 encoder x1 mode
[19:04:46] <CIA-82> EMC: 03seb 07v2_3_branch * r6905a465d120 10/docs/man/man9/hostmot2.9: clarify hm2 encoder x1 mode
[19:42:00] <mhaberler> cradek: simulated config done, see mail
[20:48:13] <CIA-82> EMC: 03cradek 07master * rbb0039c7a71d 10/docs/man/man9/hostmot2.9: Revert "clarify hm2 encoder x1 mode"
[20:49:33] <jepler> :qa
[20:49:53] <CIA-82> EMC: 03cradek 07v2_3_branch * rcbd82b5004fa 10/docs/man/man9/hostmot2.9: Revert "clarify hm2 encoder x1 mode"
[22:10:07] <dgarr> cutter compensation gouge at exit -- not sure why, if i increase k2 to 0.1 it doesn't
[22:10:08] <dgarr> simulator, 2.4-0pre, 0.5 tool diameter
[22:10:21] <dgarr> screenshot:
http://www.panix.com/~dgarrett/stuff/badexit.png
[22:10:37] <dgarr> gcode:
http://www.panix.com/~dgarrett/stuff/badexit.ngc
[23:37:32] <cradek> dgar1: looking ... a little hard to follow the gcode.
[23:39:20] <dgar1> using named parameters makes it hard to follow?
[23:39:56] <cradek> well ... all of it :-)
[23:41:13] <dgar1> i could change it back to #1, #2 everywhere :-/
[23:41:21] <cradek> nah
[23:41:36] <cradek> also baffling is I'm getting old debug output from my build, even though I did a clean and rebuild
[23:41:42] <cradek> and the string it's printing isn't found by grep
[23:42:04] <cradek> and block delete wasn't working, but now it is after the rebuild
[23:42:07] <cradek> so confused
[23:45:19] <cradek> ohhh, that's your output, not mine
[23:45:24] <cradek> jeez, I'm slow tonight
[23:50:19] <cradek> xfinal_a=1.000000 yfinal_a=1.000000
[23:50:19] <cradek> xfinal_b=1.354260 yfinal_b=1.354260
[23:50:49] <cradek> this move is 0.4883 long
[23:55:01] <cradek> ok that doesn't matter
[23:55:07] <cradek> let me show you a picture
[23:55:08] <dgar1> ? .501 = sqrt(2 *.35426) (not including tool radius compensation)
[23:55:23] <dgar1> that too (doesnt matter i think)
[23:56:34] <cradek> len is sqrt( 2 * (.35426)^2 )
[23:57:23] <dgar1> yes on sqrt .501i guess my question is (for k2=0) should there be an error/or warning or is it expected to do that
[23:57:23] <cradek> http://timeguy.com/cradek-files/emc/exit.png
[23:57:45] <cradek> this is the uncompensated path, with a tool of 0.5
[23:57:53] <cradek> I changed the exit rapid so you can see it
[23:58:05] <cradek> see how with these two moves you make a corner where the tool can't fit?
[23:58:35] <cradek> it can't get in there to touch that short line that goes up and right
[23:58:50] <cradek> if you were to continue on and program some more compensated moves, you would see this error
[23:59:05] <cradek> in fact I did that by moving the g40 down under the g0, and I got the error
[23:59:20] <cradek> you are hiding the error by turning off compensation at just the right time
