Back
[01:09:48] <jmkasunich> jepler (or maybe someone else?) I'm trying to figure out some install stuff
[01:10:31] <jmkasunich> 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
[01:11:13] <jepler> those files need to get listed in several places to make it into an installed version / .deb package
[01:12:11] <jepler> src/emc/usr_intf/Submakefile and (in 2.2 at any rate) debian/emc2.files.in
[01:12:22] <jmkasunich> I wonder if src/emc/usr_intf/axis/scripts is even the right place for vismach models?
[01:12:29] <jepler> oh probably not so much
[01:12:56] <jmkasunich> dunno why the first one wound up there, the others just followed
[01:13:00] <jepler> yeah
[01:13:07] <jmkasunich> and I added another one yesterday
[01:13:07] <jepler> bad decision on my part, I bet
[01:13:30] <jmkasunich> should we fix it before 2.3.0?
[01:13:49] <jepler> looks like none of the xxxgui programs are listed in emc2.files.in, hmm
[01:14:05] <jmkasunich> vismach is very limited in 2.2.x
[01:14:38] <jmkasunich> the configs/vismach directory is in 2.3.pre only
[01:14:56] <jepler> looks like they need to be listed in src/Makefile and debian/emc2.files.in to get in the final package
[01:15:02] <jmkasunich> 2.2 has only puma, hexa, and scaragui.py
[01:17:50] <jmkasunich> where do we want to put them in the final package?
[01:18:22] <jepler> /usr/bin
[01:18:43] <jepler> $(DESTDIR)$(bindir) in makefilespeak
[01:20:07] <jmkasunich> part of the "install-kernel-indep" rule maybe?
[01:20:31] <jepler> probably part of install-python -- I think we still pay lip service to not requiring it
[01:20:47] <jmkasunich> yeah, just found that target
[01:21:01] <jepler> looking closer it looks like the most modern way is to put it on a $(EXE) line ..
[01:21:07] <jepler> instead of referring to $(DESTDIR)$(bindir) that is
[01:21:22] <jmkasunich> so, do we want to keep the ___gui.py "sources" where they are?
[01:21:35] <jepler> on third thought .. you still have to say $(DESTDIR)$(bindir) I guess .. just at the end
[01:21:39] <jmkasunich> moving them will lose some history, keeping them there will result in more accumulating
[01:22:16] <jepler> the sooner the better, if we are going to move them
[01:22:35] <jepler> but you have to decide where
[01:22:39] <jepler> or, one does
[01:22:57] <jepler> they aren't emc user interfaces, strictly speaking
[01:23:06] <jepler> they're technically hal userspace components, I suppose
[01:23:12] <jmkasunich> yeah
[01:24:23] <jmkasunich> 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
[01:24:27] <jmkasunich> its in lib/python
[01:24:50] <jmkasunich> along with a pyc - that is a "compiled" version?
[01:24:58] <jepler> yeah that's an autogenerated, byte-compiled version
[01:25:34] <jmkasunich> I imagine there are good reasons for vismach.py(c) to remain in lib/?
[01:26:26] <jepler> yes
[01:26:49] <jepler> when you . scripts/emc-environment, that lib/python directory is added to python's search path
[01:27:01] <jepler> easiest to just have a single directory structure for that, rather than multiple ones spread out in the source tree
[01:27:07] <jmkasunich> vismach doesn't seem to get explicitly installed by install_python, does "$(FILE) ../lib/python/*.py ../lib/python/*.so $(DESTDIR)$(SITEPY)" pick it up?
[01:27:11] <jepler> and little value in, say, copying the files around as part of the 'make' process
[01:27:20] <jepler> yes, I think so -- that wildcard should match it
[01:27:25] <jepler> the *.py
[01:27:31] <jmkasunich> what about the pyc?
[01:28:02] <jepler> it's OK for the pyc not to exist -- it's like a cache
[01:28:12] <jepler> (at one point the debian install stuff created them, but I'm not sure it does now)
[01:28:21] <jmkasunich> oh, ok - I thought it was generated by make
[01:28:38] <jepler> no, python makes it when the module is imported, if it doesn't exist or is out of date, and the location is writable
[01:28:51] <jmkasunich> handy ;-)
[01:29:26] <jepler> yes it's a very convenient scheme in most cases
[01:30:00] <jepler> (there's a case where it's not; I should check whether I got around to fixing that or not)
[01:30:12] <jmkasunich> so, the actual GUI's.... src/hal/user_comps (where pyvcp.py is) or a new dir src/hal/user_comps/vismach
[01:30:26] <jepler> (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)
[01:30:35] <jmkasunich> or leave them where they are to preserve CVS history?
[01:30:45] <jepler> (at least at the time, the .deb package contained only the .pyc files, and not the .py files)
[01:31:10] <jepler> (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)
[01:31:46] <jepler> if we're moving them, I think it's reasonable to give them a directory of their own
[01:31:59] <jmkasunich> so the question is do we move them
[01:32:15] <jepler> (nope, looks like I haven't fixed that yet... hmm... I forget why the package gets the .pyc only)
[01:32:30] <jmkasunich> I tend to be biased in favor of logical locations vs. history, so I'd like someone elses opinion
[01:33:27] <jepler> 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.
[01:34:02] <jmkasunich> 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
[01:34:13] <jmkasunich> I thought you owned unpy.com?
[01:34:17] <jepler> no, just .net
[01:34:23] <jmkasunich> ah, ok
[01:34:31] <jmkasunich> (got a domain for sale thing at ,com)
[01:34:37] <jepler> ah
[01:34:38] <jepler> that's not me
[01:35:48] <jmkasunich> the "record a video of an X program" posting (
http://emergent.unpy.net/01196105360) can only capture a single window, right?
[01:35:55] <jepler> 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
[01:36:27] <jmkasunich> maybe thats why so many people have trouble following those instructions
[01:36:37] <jepler> no, it records all the programs you run in the vncserver display
[01:36:47] <jmkasunich> oh good
[01:37:03] <jepler> (in the video you can see the splash screen, then the axis window, then the vismach window, then the fullscreen vismach window)
[01:37:10] <jmkasunich> I want to run a vismach model that is controlled by sliders on a pyvcp panel
[01:37:34] <jepler> I think that should work
[01:37:53] <jepler> 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..
[01:38:15] <jepler> you'll have to go through the pain that I only alluded to there, of compiling a software, client-side opengl library
[01:38:31] <jmkasunich> you mean vncrec?
[01:39:03] <jepler> no, mesa
[01:39:34] <jmkasunich> you didn't even allude to that ;-)
[01:39:59] <jepler> 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.
[01:41:05] <jmkasunich> oh, the very end
[01:41:08] <jmkasunich> I didn't get that far
[01:41:50] <jmkasunich> 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
[01:43:02] <jmkasunich> I wish my fingers would remember how to spell recipe
[01:47:33] <skunkworks> spelling is overrated
[01:47:37] <skunkworks> ;)
[01:47:41] <jepler> hi skunkworks
[01:47:46] <skunkworks> Hi jepler
[01:49:40] <skunkworks> 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.
[01:50:05] <skunkworks> (before emc successfully loads again)
[01:51:30] <skunkworks> but it seems to take a lickin and keeps on tickin
[01:53:00] <jepler> huh
[01:53:05] <jepler> it's repeatable?
[01:55:03] <skunkworks> 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)
[01:55:40] <jepler> huh
[01:56:15] <skunkworks> yeh. like I say - still working good
[01:57:06] <skunkworks> the poor thing.
[01:57:20] <jepler> I hope someday you'll just burn it out and then buy a mesa card to replace it
[01:57:28] <jepler> seb needs you to be a hostmot2 tester
[01:57:32] <skunkworks> I have 2 mesa cards..
[01:57:47] <skunkworks> but they are a little more expensive to just 'play' with.
[01:57:51] <skunkworks> :)
[01:58:07] <jmkasunich> I've been thinking about hostmot2 - I might tackle converting the shoptask from software stepping to hm2 over the holidays
[01:58:46] <skunkworks> Cool! Are you glad you didn't have to tackle the stepper firmware?
[01:58:55] <jmkasunich> somewhat
[01:59:06] <jepler> will that give any tangible benefits besides getting rid of base-period?
[01:59:17] <jmkasunich> I actually did write stepper firmware, and a hal driver for it, but never finished the details
[01:59:23] <jepler> details suck
[01:59:27] <skunkworks> jmkasunich: control freak ;)
[01:59:33] <jmkasunich> jepler: it will let me handle higher speeds on the spindle
[01:59:41] <jmkasunich> dunno if it will improve motor performance at all
[01:59:56] <jmkasunich> (spindle speed improvement because of hw encoder counting)
[02:00:11] <jmkasunich> it will also give me enough spare I/O that I can finally hook up my jogwheel
[02:00:51] <jepler> (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)
[02:11:50] <jmkasunich> 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
[02:11:58] <jmkasunich> is that by design?
[02:14:36] <jmkasunich> 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
[02:14:44] <jmkasunich> $(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)
[02:15:33] <jmkasunich> that is the only mention of axis-remote, hal_manualtoolchange, etc
[02:15:34] <jepler> jmkasunich: lintini is pretty useless and should be removed
[02:15:40] <skunkworks> jmkasunich:
http://imagebin.ca/view/6U3eikh.html
[02:15:49] <jepler> not sure if tracking-test is something useful
[02:15:53] <jepler> teach-in probably needs to be added
[02:16:16] <jepler> items listed in PYSCRIPTS in src/emc/usr_intf/axis/Submakefile are copied to ../bin
[02:16:30] <jepler> then the top-level Makefile determines which are copied for 'make install'
[02:16:33] <jmkasunich> ah
[02:17:03] <jmkasunich> still debating whether to move the *gui.py
[02:17:14] <jmkasunich> I was thinking about just installing *.py from that dir
[02:19:47] <jmkasunich> well, unless somebody recommends otherwise, I'm going to move the vismach models to /src/hal/user_comps/vismach tomorrow
[02:20:11] <jmkasunich> and do whatever Makefile and Submakefile tweaking that requires
[02:20:20] <jepler> I'll be happy to help you get it fixed up
[02:20:29] <jmkasunich> I'd appreciate that ;-)
[02:22:04] <jmkasunich> skunkworks: nice ringing
[02:22:05] <jmkasunich> ding
[02:29:49] <skunkworks> thanks :)
[02:30:23] <skunkworks> .2us per division - that was across the sense resistor
[02:30:41] <jmkasunich> what is the vertical scale?
[02:31:56] <skunkworks> damnit - I thought you would ask that. I don't remember - would guess .05 per div
[02:32:21] <skunkworks> it is at every transision of the square wave.
[02:32:38] <jmkasunich> x10 probes? 50mV per div at the scope, or at the probe tip?
[02:32:48] <skunkworks> X1
[02:32:51] <jmkasunich> it is quite possible that you are seeing probe artifacts
[02:33:08] <jmkasunich> make that very possible - 1x probes aren't very suitable for high speed work
[02:33:25] <jmkasunich> how long are the probe ground leads? I bet they are what is ringing
[02:33:46] <skunkworks> ah. Ok.. ground leads are around 3 inches I would guess.
[02:33:49] <jmkasunich> simple test - put the probe ground clip _and_ the probe point both at the bottom of the sense resistor
[02:34:05] <jmkasunich> I bet it will be ringing even with probe and ground at the same place
[02:34:15] <skunkworks> ok - I will test that tomorrow.
[02:34:43] <skunkworks> Thank you.
[02:35:28] <skunkworks> I am getting different trip voltage depending on which direction I am turning the shaft.
[02:35:37] <skunkworks> I need to do some testing.
[02:37:31] <skunkworks> we are talking lets say .08v vs .095 or so. but that is a lot when .08v is around 5a
[02:37:55] <jmkasunich> 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
[02:39:51] <skunkworks> My guess is I have too much stuff after my comparator causing problems
[02:40:10] <jmkasunich> after the comparator?
[02:40:26] <jmkasunich> the critical circuitry is before the comparator
[02:40:46] <skunkworks> I am talking ground and supply
[02:41:05] <skunkworks> for the comparator and voltage reference.
[02:42:00] <jmkasunich> its kind of hard to follow traces....
[02:42:08] <skunkworks> I know.
[02:42:49] <jmkasunich> schem doesn't show power and gnd pins for the comp? (or am I blind?)
[02:44:04] <skunkworks> odd - it isn't labeled. it is the one left of the ic6p
[02:44:12] <skunkworks> pin 4 and 8
[02:44:28] <jmkasunich> thanks
[02:44:40] <jmkasunich> what is R18 for?
[02:45:19] <skunkworks> that was to protect the comparator. It cause too many problems - it is now a jumper.
[02:45:31] <jmkasunich> I was gonna suggest that ;-)
[02:45:34] <skunkworks> that was to protect the comparator. It cause too many problems - it is now a jumper.
[02:45:39] <skunkworks> oops
[02:45:44] <skunkworks> :)
[02:46:24] <jmkasunich> the left hand end of C11 is connected to the resistor sense lead, right?
[02:47:35] <jmkasunich> is the cap immediately above the comp C19?
[02:47:55] <jmkasunich> no, I bet it's one of the power supply bypasses
[02:48:02] <jmkasunich> oh, I see C19
[02:48:47] <skunkworks> I need to open both schem and layout so I can play along
[02:49:02] <jmkasunich> yeah, that pic is nearly unreadable
[02:49:22] <jmkasunich> the blue traces especially - they disappear when they go under things
[02:49:34] <jmkasunich> I keep wanting to zoom in ;-)
[02:50:03] <skunkworks> do you want the files?
[02:50:11] <jmkasunich> not really
[02:50:18] <skunkworks> well - you really don't have to spend time on this
[02:50:20] <skunkworks> :)
[02:50:40] <skunkworks> I am suprised it is working off the bat ;)
[02:51:29] <skunkworks> Did you see the video I posted earlier?
[02:51:40] <jmkasunich> yeah
[02:52:27] <skunkworks> I was running 70vdc today. Snappy
[02:53:48] <skunkworks> 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.
[02:54:48] <skunkworks> there probably should be a bypass cap right across the trimmer
[02:54:52] <jmkasunich> you mean the +12 to the top of the pot?
[02:54:57] <skunkworks> yes
[02:55:08] <jmkasunich> the pot supply is less critical
[02:55:28] <jmkasunich> any noise there is attenuated at least 40:1 by the R15/R16 voltage divider
[02:55:39] <jmkasunich> the critical notes are pins 2 and 3 of the comp
[02:56:00] <jmkasunich> C11 and C19 should be as close to the comp as possible, and grounded to the same point
[02:56:12] <jmkasunich> is the comp in a socket?
[02:56:20] <skunkworks> yes
[02:57:04] <jmkasunich> 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
[02:57:26] <jmkasunich> or, solder a cap directly between pins 2 and 3
[02:57:35] <jmkasunich> its hard to say which approach is better
[02:57:46] <jmkasunich> keep the leads short - 1/2" or less
[03:01:25] <skunkworks> .001uf?
[03:01:40] <jmkasunich> yeah
[03:05:44] <skunkworks> OK - Thanks again :)
[03:08:24] <skunkworks> I can try both ways and see what is better.
[03:12:42] <skunkworks> * skunkworks is still suprised it is working as well as it is.
[03:14:16] <skunkworks> SWPLinux" !
[03:31:35] <skunkworks> Night.
[13:03:35] <skunkworks> TGIF
[13:41:42] <alex_joni> it was :D
[13:46:44] <skunkworks> heh - you and your time zone.
[13:54:25] <cradek> it's unnerving that alex always talks to us from the future
[13:58:54] <skunkworks> heh
[14:27:44] <alex_joni> usually from teh weekend :P
[14:44:34] <skunkworks> cradek: how is the lathe doing? What have you been making?
[16:19:33] <cradek> skunkworks: it works great - only minor problems left
[16:19:43] <cradek> sometimes the part chute doesn't retract - some kind of air solenoid problem
[16:20:18] <cradek> but that's the only problem I've had (that I didn't directly cause by making a mistake...)
[16:22:44] <cradek> right now I'm trying to make some knurled aluminum knobs
[16:24:44] <skunkworks> Neat
[16:25:42] <cradek> 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
[16:27:21] <skunkworks> what are the knobs for?
[16:29:32] <cradek> the control for a thermostat I'm making (encoder) and also I will make extras to eventually use on the cnc machines
[16:30:08] <skunkworks> neat
[16:30:21] <skunkworks> did you try single point knurling?
[16:30:27] <cradek> nope
[16:46:18] <CIA-37> EMC: 03cradek 07TRUNK * 10emc2/src/emc/kinematics/tp.c: allow feed override and pausing for FPR moves
[17:09:08] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in): Try to detect early if tcl and tk development versions conflict
[19:31:04] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/html/gcode_fr.html: french translation update
[19:31:05] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/config/stepper_fr.lyx: french translation update
[19:31:05] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/examples/misc_fr.lyx: french translation update
[19:31:06] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: french translation update
[19:31:06] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/common/integrator_intro_fr.lyx: french translation update
[19:31:07] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gui/axis_fr.lyx: french translation update
[19:31:09] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/hal/components_fr.lyx: french translation update
[19:31:11] <CIA-37> EMC: 03tissf 07TRUNK * 10emc2/docs/src/motion/ (kinematics_fr.lyx tweaking_steppers_fr.lyx): french translation update
[19:32:53] <tissf> hi
[19:34:11] <jepler> hi tissf
[19:34:21] <jepler> thanks for your continuing work on the documentation!
[19:34:39] <tissf> :) thanks to you!
[19:35:27] <tissf> sometime lyx's a pain...
[19:35:43] <jepler> yeah
[19:36:05] <jepler> but converting all the documentation into another format is an even worse pain
[19:36:24] <tissf> yes sure
[19:37:06] <tissf> BigJohnT made a big work for clarify all the mess
[19:38:51] <tissf> Why the Axis error notifications not are translatable?
[19:40:33] <jepler> 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.
[19:41:32] <tissf> ok :(
[19:41:55] <jepler> for "milltask" it is a relatively straightforward matter, just nobody's done it
[19:42:27] <jepler> for "motion" it is much more difficult (because "motion" is realtime and can't use the normal libraries used for translating software on linux)
[19:43:59] <tissf> ok importance is relative, everyone understands but...
[19:44:29] <cradek> jepler: is there somethign tissf could do to help get the interpreter (milltask) error messages translatable?
[19:44:50] <jepler> (probably 80% of untranslated messages are from milltask and other userspace program, 20% from motion and other realtime programs)
[19:45:39] <cradek> 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
[19:46:52] <jepler> the time consuming item is to mark the strings that need to be translated, and then to translate them
[19:48:31] <tissf> If you point me on a file I can do an test
[19:50:03] <tissf> I can try
[19:50:47] <jepler> I'm looking into it, hold on..
[19:50:56] <cradek> jepler: maybe for the interp, marking ERM/ERS/etc in the defines is easy
[19:52:20] <tissf> Can be more prudent to await the V2.4?
[19:54:49] <jepler> it should be fairly safe
[19:55:59] <tissf> OK np
[19:56:57] <tissf> tell me
[19:58:31] <jepler> 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
[19:58:56] <jepler> I need to determine why, and fix it, before suggesting that you start marking and translating more of the strings
[19:59:13] <tissf> OK
[19:59:52] <tissf> fr_rs274_err.po is all translated
[20:00:08] <tissf> without accents
[20:05:46] <jepler> why without accents?
[20:11:24] <tissf> that did the hyeroglyphes in a old version
[20:14:51] <tissf> bbl
[20:46:06] <jepler> 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
[20:46:52] <tissf> wow ! :) you are the better !
[20:47:39] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/ (configure configure.in config.h.in): make translating messages in milltask work
[20:47:44] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: make translating messages in milltask work
[20:48:08] <cradek> woo
[20:49:22] <tissf> The good question is what's EMC_TASK_PLAN_RUN?
[20:49:42] <tissf> debug message ?
[20:51:10] <jepler> yes, there's something in the source code called EMC_TASK_PLAN_RUN
[20:53:51] <tissf> I will test tomorrow at the workshop
[20:54:04] <CIA-37> EMC: 03jepler 07TRUNK * 10emc2/src/emc/task/emctaskmain.cc: permit translated messages to contain non-ascii characters according to user setting
[20:55:54] <jepler> 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
[20:55:54] <tissf> I can re put the accents?
[20:56:28] <jepler> you can try it, at least
[20:56:38] <jepler> I changed the translation to this (not sure if it's right), and it appeared the same in axis:
[20:56:41] <jepler> "La commande (%s) ne peut être executée tant que la machine n'est pas sortie "
[20:56:44] <jepler> "de l'arret d'urgence et mise en marche"
[20:57:02] <tissf> perfect
[20:57:16] <jepler> do you understand how to add _() to source files in C or C++?
[20:57:21] <tissf> arrêt d'urgence
[20:57:23] <jepler> for messages that don't appear in the po file yet?
[20:58:21] <tissf> I dont understand _()
[20:58:48] <jepler> ok, let me try to explain it.
[20:58:53] <tissf> ok
[20:59:42] <jepler> here's some lines from src/emc/task/emctaskmain.cc:
[20:59:42] <jepler> 708 sprintf(errstring, _("can't do that (%s) in manual mode"),
[20:59:45] <jepler> 709 emc_symbol_lookup(type));
[20:59:57] <jepler> because the string "can't do that..." is surrounded by _(), it is put in the po file for you to translated
[21:00:05] <jepler> er, for you to translate
[21:00:39] <jepler> 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
[21:01:21] <alex_joni> it's similar for python and tcl
[21:01:56] <tissf> it seems easy
[21:01:59] <alex_joni> jepler: so this checkin should take care of translating rs274 messages too?
[21:02:16] <alex_joni> interp errors I mean..
[21:02:32] <jepler> alex_joni: yes, it does
[21:02:48] <alex_joni> I somehow vaguely remember that has been disabled cause the LC_* stuff caused problems with . and , during interpreting of g-codes
[21:02:54] <jepler> for now we will use the rs274_err file for both interpreter errors and "milltask" errors
[21:03:08] <tissf> hi Alex
[21:03:20] <jepler> 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
[21:03:34] <jepler> po/rs274_err.pot: emc/task/emctaskmain.cc $(LIBRS274SRCS)
[21:03:36] <alex_joni> ok, sounds good :)
[21:03:48] <alex_joni> wonder why didn't do this sooner .. (not that I'm complaining..)
[21:03:51] <jepler> ^^^ in po/Submakefile, you will need to add new files to this list, next to emctaskmain.cc
[21:04:03] <jepler> for example if you put _() in emccanon.cc you would also liste emccanon.cc on this line
[21:04:27] <alex_joni> maybe renaming the pot file would be appropriate then..
[21:04:30] <alex_joni> hi tissf
[21:04:56] <jepler> alex_joni: yeah probably, but I don't want to do it right this second
[21:05:04] <jepler> I want to leave work, go home, and take the weekend off :-P
[21:05:21] <cradek> wow, what happened to the day?
[21:05:24] <alex_joni> I can relate :P
[21:05:32] <alex_joni> cradek: it vanished..
[21:05:43] <alex_joni> talking to people talking from the future does that
[21:05:59] <tissf> jepler: I try tomorrow, good weekend
[21:06:10] <jepler> tissf: let me know about any problems you encounter
[21:06:19] <jepler> I'll do my best to fix them
[21:06:23] <jepler> bbl
[21:33:56] <tissf> Hi John
[21:34:23] <BigJohnT> hi tissf
[21:34:35] <tissf> How are you ?
[21:34:51] <BigJohnT> good, and you?
[21:34:58] <tissf> fine too
[21:35:22] <BigJohnT> looks like we have both been busy guys :) on the docs
[21:36:03] <tissf> it is you who have done a good job
[21:36:24] <BigJohnT> * BigJohnT head swells up a bit
[21:36:46] <tissf> :)
[21:36:46] <BigJohnT> what do you think of docbook?
[21:37:09] <tissf> docbook?
[21:37:52] <BigJohnT> 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
[21:38:51] <BigJohnT> did you see the message from Jeff on documentation proposals?
[21:40:12] <tissf> a recent proposal?
[21:40:21] <BigJohnT> yes
[21:40:26] <tissf> no
[21:40:34] <BigJohnT> 7 Oct
[21:40:46] <BigJohnT> on the developers list
[21:41:46] <tissf> ah no Irarely on the list
[21:42:00] <BigJohnT> I can forward you a copy
[21:42:09] <tissf> yes ok thanks
[21:42:27] <BigJohnT> he was looking at addressing some of the limitations of lyx
[21:43:12] <BigJohnT> it's flying across the pond as we type
[21:43:33] <tissf> sometime lys's a pain...
[21:43:42] <tissf> er lyx
[21:44:14] <BigJohnT> I dislike the lack of control you have over some things
[21:45:16] <tissf> me too
[21:46:13] <BigJohnT> I'm trying to get a grip on some of the linux open source document publishing software... the seem to run together a bit
[21:46:26] <BigJohnT> asciidoc, docbook etc.
[21:47:28] <tissf> 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!
[21:48:23] <BigJohnT> party machine?
[21:48:52] <tissf> first chapter
[21:49:08] <tissf> before Gcodes chapter
[21:49:09] <BigJohnT> * BigJohnT looks
[21:50:27] <tissf> it's just one problem after translation
[21:51:00] <BigJohnT> I've noticed that some links get "fixed" if you run make more than once
[21:51:48] <BigJohnT> did you get a failed to make makefile msg?
[21:53:02] <tissf> no the compiler stop without message :(
[21:53:26] <BigJohnT> you might try a "make clean" then do "make"
[21:53:58] <tissf> yes I do
[21:54:54] <BigJohnT> if all else fails then a fresh copy is what you need :(
[21:55:15] <tissf> I came back to the old files is good
[21:55:56] <tissf> no real problem :)
[21:56:44] <tissf> just a waste of time
[21:57:17] <BigJohnT> I know what you mean.
[21:57:43] <tissf> sure
[21:58:21] <tissf> John, bed time here
[21:58:43] <BigJohnT> I bet! good talking to you
[21:59:06] <BigJohnT> midnight for you
[21:59:12] <tissf> have a good weekend
[21:59:35] <tissf> yes 23h59
[22:00:18] <BigJohnT> you too
[22:00:31] <tissf> nice for me too
[22:00:40] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/src/rtapi/rtai_rtapi.c: expanded the rtapi error message a bit :)
[22:01:07] <tissf> :)
[22:01:44] <alex_joni> good night all
[22:03:35] <BigJohnT> good night alex
[22:07:26] <CIA-37> EMC: 03bigjohnt 07v2_2_branch * 10emc2/src/rtapi/rtai_rtapi.c: expanded the rtapi error message a bit :)
[22:09:58] <jepler> BigJohnT: make sure that full message actually displays
[22:10:05] <jepler> I remember that it goes into some buffer which is not really all that large...
[22:10:06] <BigJohnT> I did :)
[22:10:13] <jepler> ok alright
[22:10:32] <BigJohnT> took about three tries to get it to look good
[22:12:53] <BigJohnT> I knew jepler would be watching :)
[22:14:20] <jepler> I try to keep an eye on you
[22:15:22] <jepler> bbl
[22:16:53] <BigJohnT> :)
[22:16:58] <BigJohnT> me too
[22:18:09] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: some minor edits
[22:21:07] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/ (Stepper_Diagnostics.lyx Diagnostics.lyx): changed the name to be more specific to the contents
[22:26:29] <CIA-37> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Master_User.lyx): add section
[22:30:07] <CIA-37> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/hal/pyvcp.lyx: minor edits
[22:38:38] <skunkworks> 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
[22:40:02] <jmkasunich> I'm having trouble parsing what you just wrote
[22:40:27] <jmkasunich> sentences 1 and 3 are related? and 2 and 4 are related?
[22:40:46] <jmkasunich> * jmkasunich brain not at full power
[22:44:14] <skunkworks> I didn't get a chance to see if removing the caps would stop the drivers from being taken out.
[22:44:23] <skunkworks> (the caps on the comparator)
[22:44:48] <jmkasunich> I'd be somewhat astonished if the caps on the comparator have any effect on the driver ICs
[22:45:11] <skunkworks> I agree
[22:45:50] <skunkworks> crap - I have to leave. BBL
[22:47:16] <skunkworks> adding the larger bootstrap cap back in held off the failing of the driver ic - but it would still get taken out.
[22:52:44] <skunkworks> 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.
[22:53:01] <jmkasunich> stops and the drivers are dead?
[22:53:21] <skunkworks> yes - it just acts like the power was removed.
[22:53:38] <jmkasunich> and cycling power doesn't help, you have to replace the driver chip(s)?
[22:54:29] <skunkworks> It might handle it 1 or 2 times but after that it will stop working
[22:54:51] <skunkworks> (gone tru about 4 ic so far.)
[22:55:22] <jmkasunich> might be L*dI/dT undershoots
[22:55:39] <jmkasunich> this is the kind of thing that is very hard to troubleshoot without being there
[22:55:46] <skunkworks> heh - I am sure
[22:56:29] <skunkworks> plus it isn't here.
[23:09:51] <skunkworks> bbl
