jepler (or maybe someone else?) I'm trying to figure out some install stuff
specifically, the config in /configs/vismach work fine during RIP, but since the max5gui.py lives in the src tree, I suspect it won't work so well in an installed system
those files need to get listed in several places to make it into an installed version / .deb package
src/emc/usr_intf/Submakefile and (in 2.2 at any rate) debian/emc2.files.in
I wonder if src/emc/usr_intf/axis/scripts is even the right place for vismach models?
oh probably not so much
dunno why the first one wound up there, the others just followed
and I added another one yesterday
bad decision on my part, I bet
should we fix it before 2.3.0?
looks like none of the xxxgui programs are listed in emc2.files.in, hmm
vismach is very limited in 2.2.x
the configs/vismach directory is in 2.3.pre only
looks like they need to be listed in src/Makefile and debian/emc2.files.in to get in the final package
2.2 has only puma, hexa, and scaragui.py
where do we want to put them in the final package?
$(DESTDIR)$(bindir) in makefilespeak
part of the "install-kernel-indep" rule maybe?
probably part of install-python -- I think we still pay lip service to not requiring it
yeah, just found that target
looking closer it looks like the most modern way is to put it on a $(EXE) line ..
instead of referring to $(DESTDIR)$(bindir) that is
so, do we want to keep the ___gui.py "sources" where they are?
on third thought .. you still have to say $(DESTDIR)$(bindir) I guess .. just at the end
moving them will lose some history, keeping them there will result in more accumulating
the sooner the better, if we are going to move them
but you have to decide where
or, one does
they aren't emc user interfaces, strictly speaking
they're technically hal userspace components, I suppose
it would make sense to put vismach.py in the same place (at least to me), but it isn't even in the src/ tree
its in lib/python
along with a pyc - that is a "compiled" version?
yeah that's an autogenerated, byte-compiled version
I imagine there are good reasons for vismach.py(c) to remain in lib/?
when you . scripts/emc-environment, that lib/python directory is added to python's search path
easiest to just have a single directory structure for that, rather than multiple ones spread out in the source tree
vismach doesn't seem to get explicitly installed by install_python, does "$(FILE) ../lib/python/*.py ../lib/python/*.so $(DESTDIR)$(SITEPY)" pick it up?
and little value in, say, copying the files around as part of the 'make' process
yes, I think so -- that wildcard should match it
what about the pyc?
it's OK for the pyc not to exist -- it's like a cache
(at one point the debian install stuff created them, but I'm not sure it does now)
oh, ok - I thought it was generated by make
no, python makes it when the module is imported, if it doesn't exist or is out of date, and the location is writable
yes it's a very convenient scheme in most cases
(there's a case where it's not; I should check whether I got around to fixing that or not)
so, the actual GUI's.... src/hal/user_comps (where pyvcp.py is) or a new dir src/hal/user_comps/vismach
(if there's a .py file and a .pyc file, and they are different, python always uses the contents of the .py file and ignores the .pyc file)
or leave them where they are to preserve CVS history?
(at least at the time, the .deb package contained only the .pyc files, and not the .py files)
(a user who did a "make install" put .py files there. then when you go back to the package version, you get the .py files, not the .pyc file, and you have a version mismatch)
if we're moving them, I think it's reasonable to give them a directory of their own
so the question is do we move them
(nope, looks like I haven't fixed that yet... hmm... I forget why the package gets the .pyc only)
I tend to be biased in favor of logical locations vs. history, so I'd like someone elses opinion
I tend to pay more attention to the "oh no, it loses history" argument, but there's really not that much history. I don't have a problem with moving them, but I wouldn't do it for my own sake.
well, I'm planning to add another config to configs/vismach (the horizontal boring mill) and make sure all the configs in there work for the 2.3.0 release
I thought you owned unpy.com?
no, just .net
(got a domain for sale thing at ,com)
that's not me
the "record a video of an X program" posting (http://emergent.unpy.net/01196105360)
can only capture a single window, right?
hm, the "building emc2 from cvs" skips the step that you have to reboot after installing the realtime kernel, or specify --with-realtime=, or the realtime system isn't picked uip right
maybe thats why so many people have trouble following those instructions
no, it records all the programs you run in the vncserver display
(in the video you can see the splash screen, then the axis window, then the vismach window, then the fullscreen vismach window)
I want to run a vismach model that is controlled by sliders on a pyvcp panel
I think that should work
what you don't see in the video is that I launched all the programs from a terminal running on my regular display, but with DISPLAY=:1 set in the environment..
you'll have to go through the pain that I only alluded to there, of compiling a software, client-side opengl library
you mean vncrec?
you didn't even allude to that ;-)
sure I did: I wanted to record a program that used OpenGL, but the Ubuntu Dapper vncserver doesn't have glx support. To do this, I used a version of Mesa compiled as a client-side library, and set LD_LIBRARY_PATH to point at the directory where This libGL.so.1 resided.
oh, the very end
I didn't get that far
to be honest, I was hoping this was something where I could just follow the recipie and have a nice cookie when I was done
I wish my fingers would remember how to spell recipe
spelling is overrated
I can put the pluto into some odd state.. But as you can see from my testing - I would guess it was static or such. I physically have to unplug the power from the pluto before it starts working again.
(before emc successfully loads again)
but it seems to take a lickin and keeps on tickin
I would have to play with it more.. I have had it happen by unplugging the logic supply from the h-bridge. (twice) but I would have no clue why that should effect it as the pluto is opto-isolated from that. (why I think it is just me and static)
yeh. like I say - still working good
the poor thing.
I hope someday you'll just burn it out and then buy a mesa card to replace it
seb needs you to be a hostmot2 tester
I have 2 mesa cards..
but they are a little more expensive to just 'play' with.
I've been thinking about hostmot2 - I might tackle converting the shoptask from software stepping to hm2 over the holidays
Cool! Are you glad you didn't have to tackle the stepper firmware?
will that give any tangible benefits besides getting rid of base-period?
I actually did write stepper firmware, and a hal driver for it, but never finished the details
jmkasunich: control freak ;)
jepler: it will let me handle higher speeds on the spindle
dunno if it will improve motor performance at all
(spindle speed improvement because of hw encoder counting)
it will also give me enough spare I/O that I can finally hook up my jogwheel
(except for the "have to reboot" step I had to add, the wiki instructions for installing emc on a fresh 8.04 box and then building from scratch for rip work)
jepler: there are several other python files in src/emc/usr_intf/axis/scripts that don't seem to be explicitly installed - lintini.py, teach-in.py, and tracking-test.py
is that by design?
also, files in there that _are_ installed, like axis-remote and axis itself, confuse me, because I don't see anything in the Makefile that points at that dir
$(EXE) ../bin/stepconf ../bin/hal_input ../bin/pyvcp ../bin/axis ../bin/axis-remote ../bin/debuglevel ../bin/emctop ../bin/mdi ../bin/hal_manualtoolchange ../bin/image-to-gcode $(DESTDIR)$(bindir)
that is the only mention of axis-remote, hal_manualtoolchange, etc
jmkasunich: lintini is pretty useless and should be removed
not sure if tracking-test is something useful
teach-in probably needs to be added
items listed in PYSCRIPTS in src/emc/usr_intf/axis/Submakefile are copied to ../bin
then the top-level Makefile determines which are copied for 'make install'
still debating whether to move the *gui.py
I was thinking about just installing *.py from that dir
well, unless somebody recommends otherwise, I'm going to move the vismach models to /src/hal/user_comps/vismach tomorrow
and do whatever Makefile and Submakefile tweaking that requires
I'll be happy to help you get it fixed up
I'd appreciate that ;-)
skunkworks: nice ringing
.2us per division - that was across the sense resistor
what is the vertical scale?
damnit - I thought you would ask that. I don't remember - would guess .05 per div
it is at every transision of the square wave.
x10 probes? 50mV per div at the scope, or at the probe tip?
it is quite possible that you are seeing probe artifacts
make that very possible - 1x probes aren't very suitable for high speed work
how long are the probe ground leads? I bet they are what is ringing
ah. Ok.. ground leads are around 3 inches I would guess.
simple test - put the probe ground clip _and_ the probe point both at the bottom of the sense resistor
I bet it will be ringing even with probe and ground at the same place
ok - I will test that tomorrow.
I am getting different trip voltage depending on which direction I am turning the shaft.
I need to do some testing.
we are talking lets say .08v vs .095 or so. but that is a lot when .08v is around 5a
got links to your schematic and layout handy?
[02:38:59] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/schemagain.png
[02:39:15] <skunkworks> http://www.electronicsam.com/images/KandT/servostart/boardagain.png
My guess is I have too much stuff after my comparator causing problems
after the comparator?
the critical circuitry is before the comparator
I am talking ground and supply
for the comparator and voltage reference.
its kind of hard to follow traces....
schem doesn't show power and gnd pins for the comp? (or am I blind?)
odd - it isn't labeled. it is the one left of the ic6p
pin 4 and 8
what is R18 for?
that was to protect the comparator. It cause too many problems - it is now a jumper.
I was gonna suggest that ;-)
that was to protect the comparator. It cause too many problems - it is now a jumper.
the left hand end of C11 is connected to the resistor sense lead, right?
is the cap immediately above the comp C19?
no, I bet it's one of the power supply bypasses
oh, I see C19
I need to open both schem and layout so I can play along
yeah, that pic is nearly unreadable
the blue traces especially - they disappear when they go under things
I keep wanting to zoom in ;-)
do you want the files?
well - you really don't have to spend time on this
I am suprised it is working off the bat ;)
Did you see the video I posted earlier?
I was running 70vdc today. Snappy
you can see how the + supply for the voltage referenc goes over the hill and thru the woods to get there. I need to do some more probing to see if there is some odd things happening there.
there probably should be a bypass cap right across the trimmer
you mean the +12 to the top of the pot?
the pot supply is less critical
any noise there is attenuated at least 40:1 by the R15/R16 voltage divider
the critical notes are pins 2 and 3 of the comp
C11 and C19 should be as close to the comp as possible, and grounded to the same point
is the comp in a socket?
that makes it a bit tricker, but can you solder a cap between pins 2 and 4, and another one between pins 3 and 4 - solder both directly to the comp pins
or, solder a cap directly between pins 2 and 3
its hard to say which approach is better
keep the leads short - 1/2" or less
OK - Thanks again :)
I can try both ways and see what is better.
* skunkworks is still suprised it is working as well as it is.
it was :D
heh - you and your time zone.
it's unnerving that alex always talks to us from the future
usually from teh weekend :P
cradek: how is the lathe doing? What have you been making?
skunkworks: it works great - only minor problems left
sometimes the part chute doesn't retract - some kind of air solenoid problem
but that's the only problem I've had (that I didn't directly cause by making a mistake...)
right now I'm trying to make some knurled aluminum knobs
I might have to work on my knurling tool mount a little more. It tends to pivot on the turret. I might have to add a dowel pin or something
what are the knobs for?
the control for a thermostat I'm making (encoder) and also I will make extras to eventually use on the cnc machines
did you try single point knurling?
EMC: 03cradek 07TRUNK * 10emc2/src/emc/kinematics/tp.c: allow feed override and pausing for FPR moves
EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in): Try to detect early if tcl and tk development versions conflict
EMC: 03tissf 07TRUNK * 10emc2/docs/html/gcode_fr.html: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/stepper_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/examples/misc_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/integrator_intro_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/components_fr.lyx: french translation update
EMC: 03tissf 07TRUNK * 10emc2/docs/src/motion/ (kinematics_fr.lyx tweaking_steppers_fr.lyx): french translation update
thanks for your continuing work on the documentation!
:) thanks to you!
sometime lyx's a pain...
but converting all the documentation into another format is an even worse pain
BigJohnT made a big work for clarify all the mess
Why the Axis error notifications not are translatable?
some of the messages AXIS shows are produced by different parts of emc (such as "motion" or "milltask"), which are not yet written in a way to allow the messages to be translated.
for "milltask" it is a relatively straightforward matter, just nobody's done it
for "motion" it is much more difficult (because "motion" is realtime and can't use the normal libraries used for translating software on linux)
ok importance is relative, everyone understands but...
jepler: is there somethign tissf could do to help get the interpreter (milltask) error messages translatable?
(probably 80% of untranslated messages are from milltask and other userspace program, 20% from motion and other realtime programs)
I think the task/interpreter messages are the most important - people see them every day - a lot of motion messages only appear when something strange happens
the time consuming item is to mark the strings that need to be translated, and then to translate them
If you point me on a file I can do an test
I can try
I'm looking into it, hold on..
jepler: maybe for the interp, marking ERM/ERS/etc in the defines is easy
Can be more prudent to await the V2.4?
it should be fairly safe
I notice some strings in emctaskmain.cc are already marked to be translated, and are in the rs274_err.po file, but they're not being translated yet
I need to determine why, and fix it, before suggesting that you start marking and translating more of the strings
fr_rs274_err.po is all translated
why without accents?
that did the hyeroglyphes in a old version
well that took far longer than I hoped it would .. but I got it to work
[20:46:08] <jepler> http://emergent.unpy.net/files/sandbox/motion-message-translated.png
wow ! :) you are the better !
EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in config.h.in): make translating messages in milltask work
EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: make translating messages in milltask work
The good question is what's EMC_TASK_PLAN_RUN?
debug message ?
yes, there's something in the source code called EMC_TASK_PLAN_RUN
I will test tomorrow at the workshop
EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: permit translated messages to contain non-ascii characters according to user setting
the string EMC_TASK_PLAN_RUN comes from the function emc_symbol_lookup in emc/nml_intf/emc.cc. I'm not sure what the consequence is of returning a string for humans (e.g., "Run Program") and then translating that string for non-english users
I can re put the accents?
you can try it, at least
I changed the translation to this (not sure if it's right), and it appeared the same in axis:
"La commande (%s) ne peut être executée tant que la machine n'est pas sortie "
"de l'arret d'urgence et mise en marche"
do you understand how to add _() to source files in C or C++?
for messages that don't appear in the po file yet?
I dont understand _()
ok, let me try to explain it.
here's some lines from src/emc/task/emctaskmain.cc:
708 sprintf(errstring, _("can't do that (%s) in manual mode"),
because the string "can't do that..." is surrounded by _(), it is put in the po file for you to translated
er, for you to translate
usually, when something you need to translate does not appear in the po file, you can put it there by adding _() in the .c or .cc file
it's similar for python and tcl
it seems easy
jepler: so this checkin should take care of translating rs274 messages too?
interp errors I mean..
alex_joni: yes, it does
I somehow vaguely remember that has been disabled cause the LC_* stuff caused problems with . and , during interpreting of g-codes
for now we will use the rs274_err file for both interpreter errors and "milltask" errors
alex_joni: in this new code I don't set the LC_NUMERIC -- so "." should maintain its meaning as the fraction separator, no matter the language
po/rs274_err.pot: emc/task/emctaskmain.cc $(LIBRS274SRCS)
ok, sounds good :)
wonder why didn't do this sooner .. (not that I'm complaining..)
^^^ in po/Submakefile, you will need to add new files to this list, next to emctaskmain.cc
for example if you put _() in emccanon.cc you would also liste emccanon.cc on this line
maybe renaming the pot file would be appropriate then..
alex_joni: yeah probably, but I don't want to do it right this second
I want to leave work, go home, and take the weekend off :-P
wow, what happened to the day?
I can relate :P
cradek: it vanished..
talking to people talking from the future does that
jepler: I try tomorrow, good weekend
tissf: let me know about any problems you encounter
I'll do my best to fix them
How are you ?
good, and you?
looks like we have both been busy guys :) on the docs
it is you who have done a good job
* BigJohnT head swells up a bit
what do you think of docbook?
just to change the subject my new bike well new to me it's 10 years old http://i47.photobucket.com/albums/f163/johnplctech/GW1500.jpg
did you see the message from Jeff on documentation proposals?
a recent proposal?
on the developers list
ah no Irarely on the list
I can forward you a copy
yes ok thanks
he was looking at addressing some of the limitations of lyx
it's flying across the pond as we type
sometime lys's a pain...
I dislike the lack of control you have over some things
I'm trying to get a grip on some of the linux open source document publishing software... the seem to run together a bit
asciidoc, docbook etc.
I have not managed to extract the text for the party machine from gcode/main.lyx as you do, there are too many broken links compiler stoped with no message!
before Gcodes chapter
* BigJohnT looks
it's just one problem after translation
I've noticed that some links get "fixed" if you run make more than once
did you get a failed to make makefile msg?
no the compiler stop without message :(
you might try a "make clean" then do "make"
yes I do
if all else fails then a fresh copy is what you need :(
I came back to the old files is good
no real problem :)
just a waste of time
I know what you mean.
John, bed time here
I bet! good talking to you
midnight for you
have a good weekend
nice for me too
EMC: 03bigjohnt 07TRUNK * 10emc2/src/rtapi/rtai_rtapi.c: expanded the rtapi error message a bit :)
good night all
good night alex
EMC: 03bigjohnt 07v2_2_branch * 10emc2/src/rtapi/rtai_rtapi.c: expanded the rtapi error message a bit :)
BigJohnT: make sure that full message actually displays
I remember that it goes into some buffer which is not really all that large...
I did :)
took about three tries to get it to look good
I knew jepler would be watching :)
I try to keep an eye on you
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: some minor edits
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/ (Stepper_Diagnostics.lyx Diagnostics.lyx): changed the name to be more specific to the contents
EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Master_User.lyx): add section
EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/pyvcp.lyx: minor edits
jmkasunich: the adding of the 2 capasitors seemed to make the current limit symetrical. Now though I have issues with the higher supply voltage. It takes out the driver ic when the drive goes into current limit. (I have it set for 75mv and that is where it seems to be tripping.) Now I had removed the 10uf caps for the boot strap - (so there is .1uf was the only one there (had forgotten)) when I was reading the app
I'm having trouble parsing what you just wrote
sentences 1 and 3 are related? and 2 and 4 are related?
* jmkasunich brain not at full power
I didn't get a chance to see if removing the caps would stop the drivers from being taken out.
(the caps on the comparator)
I'd be somewhat astonished if the caps on the comparator have any effect on the driver ICs
crap - I have to leave. BBL
adding the larger bootstrap cap back in held off the failing of the driver ic - but it would still get taken out.
I gave up on it for the day :) at 40v it seems to be able to handle being in over current for ever.. At 70v it stops after a few seconds.
stops and the drivers are dead?
yes - it just acts like the power was removed.
and cycling power doesn't help, you have to replace the driver chip(s)?
It might handle it 1 or 2 times but after that it will stop working
(gone tru about 4 ic so far.)
might be L*dI/dT undershoots
this is the kind of thing that is very hard to troubleshoot without being there
heh - I am sure
plus it isn't here.