Back
[01:16:41] <skunkworks> cradek: is the ladder for jr more complicated than for the lathe? Could the amount of time needed to run through the ladder what is causing the clunk?
[02:00:30] <cradek> it is not super complex - maybe 30-40 rungs
[02:01:06] <cradek> but that's an interesting idea - I'm not sure what a delay after pid and before the write would do
[02:01:48] <cradek> I could easily move the ladder update after the write - but I'm not sure that wouldn't break something
[02:14:42] <jepler> more work on extracting the preview/backplot code from axis:
http://emergent.unpy.net/files/sandbox/gremlin2.png
[02:14:58] <jepler> preview, backplot, and basic navigation (rotate/pan) in a <500 line pygtk program
[02:14:59] <cradek> cool!
[02:15:34] <jepler> 259 lines actually
[02:15:34] <cradek> I know of another pygtk program I might eventually want that in...
[02:16:21] <jepler> i've pushed the code out to the glrefactor branch of
http://git.unpythonic.net/view/emc2-jepler.git but be aware that I'll be freely rebasing it
[02:16:47] <cradek> that's ok, I'm not the slightest bit ready
[02:20:21] <jepler> I'm disappointed that gtk.gdkgl.font_use_pango_font doesn't give an antialiased font
[02:21:28] <cradek> yeah, ick
[02:21:53] <jepler> it uses the same low-level glXUseXFont API as AXIS
[02:22:01] <jepler> which is based on old core X fonts
[02:38:07] <cradek> yay, the sheet for the front panel has shipped
[02:38:40] <cradek> funny - it's too big to cut out on the bridgeport - first time I've run into that problem.
[07:54:27] <micges_work> hello
[07:54:50] <alex_joni> hi
[08:45:17] <micges_work> alex_joni: case EMCMOT_JOINT_ENABLE_AMPLIFIER:
[08:45:17] <micges_work> /* enable the amplifier directly, but don't enable calculations */
[08:45:41] <micges_work> have you idea what was that used for?
[08:49:14] <alex_joni> hmm.. no
[08:49:29] <alex_joni> I don't expect it's called from anywhere?
[08:50:57] <micges_work> yes it's called from emcJointEnable()
[08:51:18] <micges_work> when going to ESTOP
[08:51:38] <micges_work> sorry, when going to EMC_TASK_STATE_ON
[08:53:07] <micges_work> i think it's historical mess
[08:53:09] <micges_work> only
[08:55:02] <micges_work> brb
[09:05:12] <alex_joni> hmm..
[09:05:28] <alex_joni> the communication infrastructure allows for enable/disable on a per joint basis
[09:05:48] <alex_joni> although I am not sure that task knows how many joints there are (probably it should)
[09:06:00] <alex_joni> and there is no case when you can enable/disable only one
[09:06:25] <micges_work> in ja3 task know joint count
[09:06:57] <micges_work> yes there is no case
[09:07:55] <micges_work> motion also enable/diable all at once only
[09:47:05] <alex_joni> I'm still pondering if there is any advantage to have per joint enable/disable
[09:48:55] <micges_work> I cant imagine that so I've asked you ;)
[10:41:22] <micges_work> here after discuss we didn't find any sane advantage
[10:47:12] <CIA-8> EMC: 03micges 07joints_axes3 * r6f210d81fc9e 10/src/emc/motion/ (control.c motion.h): Remove unused obsolete varables
[12:27:30] <jepler> whee, got antialiased fonts working in gremlin. what a total detour that was.
http://emergent.unpy.net/files/sandbox/gremlin-aa-font.png
[12:27:40] <jepler> still don't have the position quite right :/
[12:28:56] <micges_work> jepler: nice fonts
[12:29:19] <jepler> I should go to work :(
[12:59:08] <cradek> neat! can we have it in AXIS?
[13:00:29] <SWPadnos> only if you want the numbers in the wrong place
[13:03:00] <cradek> whiner
[13:04:37] <SWPadnos> heh
[13:05:42] <jepler> I think at least one thing I'm using in there is neither in stock ubuntu nor already a dependency of emc2 (pangocairo)
[13:28:05] <alex_joni> jepler: what's the goal for gremlin?
[13:29:46] <skunkworks321> screen editor!!!
[13:29:48] <skunkworks321> ;)
[13:30:09] <skunkworks321> hi alex
[13:36:50] <jthornton> hi alex_joni
[13:37:56] <jepler> alex_joni: proof of concept for the refactored opengl display code
[13:38:58] <jepler> if AXIS (tkinter) and gremlin (gtk) can use the same underlying code, the new structure must be OK
[13:39:24] <cradek> yep that seems pretty promising
[13:39:29] <SWPadnos> but - but - but - what about qt? ;)
[13:39:31] <jepler> eventually I'd like python + glade + gremlin = new gtk user interface that looks a lot like axis does today
[13:40:19] <jepler> SWPadnos: in all seriousness, I assume that this code would work on whatever gl-capable qt widget is exposed to python
[13:40:30] <SWPadnos> cool
[13:40:35] <micges_work> and it is build from pyvcp widgets
[13:40:37] <SWPadnos> (well, cool anyway, but even more cool)
[18:31:29] <mozmck> SWPadnos: you like qt?
[18:31:53] <SWPadnos> I don't really have an opinion on it
[18:32:11] <SWPadnos> that was more of a tweak/joke than a real request
[18:32:57] <jepler> it's merely pragmatic to use tk or gtk and not qt when developing for emc, since those are already dependencies of emc.
[18:33:48] <mozmck> I see. Seems like a lot of people think qt is the cat's meow. I've used gtkmm some, but not qt
[18:34:47] <mozmck> a number of years ago when I first did some stuff with gtk it was seriously lacking in areas, but I think it's much better now.
[18:35:18] <jepler> compared to tk, gtk is a feast
[18:35:42] <mozmck> huh, I haven't used tk either.
[18:36:23] <cradek> don't
[18:36:29] <SWPadnos> heh
[18:36:42] <SWPadnos> don't, unless you're starting a project 20 years ago
[18:36:53] <mozmck> :) I have too much else to learn/do anyhow
[18:37:10] <SWPadnos> damn. forgot to eat again. bbiab
[18:42:11] <jepler> three main problems with Tk: poor widget selection--for instance, there was no standard combobox widget until tk8.5 released in 2007 (ubuntu hardy is based on 8.4 still). Second, while 8.5 has limited themability, it can't match standard gnome/kde apps' appearance. Third, it's more difficult to write custom widgets types than in other systems
[18:42:54] <jepler> (you have a choice between writing the custom widget in C (or maybe C++) or in duplicating all of the standard behaviors of a widget from scratch in your preferred language)
[18:45:16] <SWPadnos> depending on your intent, writing custom widgets for any of the three is a royal PITA
[18:45:53] <SWPadnos> if you want the widget to be usable in a screen designer, it's a lot more complicated than making something you just use in a program you wrote
[18:45:57] <SWPadnos> or write
[18:45:59] <SWPadnos> or something
[18:46:30] <jepler> glade has a generic "custom" widget
[18:46:44] <jepler> as long as your widget can be constructed based on a name and two arbitrary arguments, you're in luck
[18:47:01] <jepler> but the appearance in the screen designer is useless
[18:47:30] <jepler> but, yeah
[18:48:16] <SWPadnos> at least that was my (very limited) experience with qt
[18:48:52] <SWPadnos> it was relatively easy to make a dro that attached to EMC via NML, but I never figured out how to make it so someone else could drop that in a Designer window
[18:49:08] <SWPadnos> (truthfully, I didn't do most of the component writing either)
[18:53:10] <jepler> yeah
[18:53:53] <jepler> if you've used qt and nml before, I have to imagine it should not take long to combine the two
[19:08:33] <alex_joni> whee.. having qt widgets talking NML would be fun ;)
[19:08:50] <alex_joni> (not connected to emc2, I mean)
[20:54:03] <Lerman_> Lerman_ is now known as Lerman
[23:34:03] <jepler> * jepler ♥ git
[23:34:41] <jepler> I'd put a whole bunch of stuff in one commit because I was lazy, then I used git rebase --interactive + git gui to split it into about a half dozen logical steps
