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?
it is not super complex - maybe 30-40 rungs
but that's an interesting idea - I'm not sure what a delay after pid and before the write would do
I could easily move the ladder update after the write - but I'm not sure that wouldn't break something
more work on extracting the preview/backplot code from axis: http://emergent.unpy.net/files/sandbox/gremlin2.png
preview, backplot, and basic navigation (rotate/pan) in a <500 line pygtk program
259 lines actually
I know of another pygtk program I might eventually want that in...
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
that's ok, I'm not the slightest bit ready
I'm disappointed that gtk.gdkgl.font_use_pango_font doesn't give an antialiased font
it uses the same low-level glXUseXFont API as AXIS
which is based on old core X fonts
yay, the sheet for the front panel has shipped
funny - it's too big to cut out on the bridgeport - first time I've run into that problem.
alex_joni: case EMCMOT_JOINT_ENABLE_AMPLIFIER:
/* enable the amplifier directly, but don't enable calculations */
have you idea what was that used for?
I don't expect it's called from anywhere?
yes it's called from emcJointEnable()
when going to ESTOP
sorry, when going to EMC_TASK_STATE_ON
i think it's historical mess
the communication infrastructure allows for enable/disable on a per joint basis
although I am not sure that task knows how many joints there are (probably it should)
and there is no case when you can enable/disable only one
in ja3 task know joint count
yes there is no case
motion also enable/diable all at once only
I'm still pondering if there is any advantage to have per joint enable/disable
I cant imagine that so I've asked you ;)
here after discuss we didn't find any sane advantage
EMC: 03micges 07joints_axes3 * r6f210d81fc9e 10/src/emc/motion/ (control.c motion.h): Remove unused obsolete varables
whee, got antialiased fonts working in gremlin. what a total detour that was. http://emergent.unpy.net/files/sandbox/gremlin-aa-font.png
still don't have the position quite right :/
jepler: nice fonts
I should go to work :(
neat! can we have it in AXIS?
only if you want the numbers in the wrong place
I think at least one thing I'm using in there is neither in stock ubuntu nor already a dependency of emc2 (pangocairo)
jepler: what's the goal for gremlin?
alex_joni: proof of concept for the refactored opengl display code
if AXIS (tkinter) and gremlin (gtk) can use the same underlying code, the new structure must be OK
yep that seems pretty promising
but - but - but - what about qt? ;)
eventually I'd like python + glade + gremlin = new gtk user interface that looks a lot like axis does today
SWPadnos: in all seriousness, I assume that this code would work on whatever gl-capable qt widget is exposed to python
and it is build from pyvcp widgets
(well, cool anyway, but even more cool)
SWPadnos: you like qt?
I don't really have an opinion on it
that was more of a tweak/joke than a real request
it's merely pragmatic to use tk or gtk and not qt when developing for emc, since those are already dependencies of emc.
I see. Seems like a lot of people think qt is the cat's meow. I've used gtkmm some, but not qt
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.
compared to tk, gtk is a feast
huh, I haven't used tk either.
don't, unless you're starting a project 20 years ago
:) I have too much else to learn/do anyhow
damn. forgot to eat again. bbiab
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
(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)
depending on your intent, writing custom widgets for any of the three is a royal PITA
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
glade has a generic "custom" widget
as long as your widget can be constructed based on a name and two arbitrary arguments, you're in luck
but the appearance in the screen designer is useless
at least that was my (very limited) experience with qt
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
(truthfully, I didn't do most of the component writing either)
if you've used qt and nml before, I have to imagine it should not take long to combine the two
whee.. having qt widgets talking NML would be fun ;)
(not connected to emc2, I mean)
Lerman_ is now known as Lerman
* jepler ♥ git
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