Back
[08:03:26] <micges> is it allowed to jog that far above soft limits?
http://imagebin.ca/view/723Uhgaz.html
[09:43:43] <alex_joni> nope
[09:43:49] <alex_joni> trivkins?
[09:45:44] <micges> yes
[09:45:52] <micges> sim_mm
[09:46:49] <micges> while jogging it stops after while but I can resume jog in bad direction
[09:54:22] <micges> bbl, lunch
[12:14:38] <CIA-1> EMC: 03micges 07master * r827e58145dba 10/src/emc/task/emctaskmain.cc: Remove unused soft limit check code
[12:20:09] <CIA-1> EMC: 03bigjohnt 07v2_3_branch * r3c54512fe509 10/docs/src/config/ini_homing.lyx: add units used for homing settings
[13:59:00] <mozmck> I'm not sure stepconf does chargepump right
[14:00:02] <jepler> I agree that nobody likes the way it does chargepump
[14:00:07] <jepler> somebody should do something.
[14:00:09] <mozmck> net estop-out charge-pump.enable iocontrol.0.user-enable-out
[14:00:40] <mozmck> the problem with this seems to be that iocontrol.0.user-enable-out never goes TRUE
[14:01:07] <mozmck> so the charge-pump never turns on
[14:01:15] <cradek> really? I thought that meant estop reset.
[14:01:39] <mozmck> I've tried it in 2.2.8, 2.3.x and now on master
[14:01:51] <jepler> if you have an external estop input that is TRUE then you can never make user-enable-out go TRUE by clicking in the GUI
[14:02:45] <mozmck> I have an external estop input, but it can go true and false and user-enable-out stays false
[14:02:45] <cradek> if the external estop is tripped, surely no charge pump is right
[14:02:46] <jepler> (I think what I envisioned was that the external estop input would be FALSE if the charge pump signal was not present, but no actual boards seem to work that way)
[14:02:56] <jepler> cradek: er, I must mean external estop input that is FALSE
[14:03:07] <cradek> so confusing
[14:03:17] <jepler> there's some way to wire it that the GUI estop button is never useful
[14:03:38] <jepler> emc starts directly in the "machine off" state, not "estop"
[14:04:13] <mozmck> That's how this does here.
[14:04:31] <cradek> my estop is rungs and rungs - I don't know how to do the simplest possible estop.
[14:05:12] <mozmck> :) I have a simple input pin
[14:07:27] <mozmck> the only other connection with the estop-out signal is this: net estop-out <= iocontrol.0.user-enable-out, but that seems redundant
[14:09:37] <mozmck> so user-enable-out should be true when the machine is out of estop?
[14:09:55] <jepler> no
[14:10:04] <jepler> user-enable-out should be TRUE when the user requests to take the machine out of estop
[14:10:09] <jepler> using the GUI
[14:10:47] <mozmck> oh. ok, so should the charge-pump.enable really be attached to that at all then?
[14:11:02] <jepler> well that depends
[14:11:20] <jepler> if "charge pump active" is made a part of the external estop chain, then it would make sense
[14:12:23] <mozmck> by external estop chain you mean a classicladder setup?
[14:14:24] <jepler> no, the one in the breakout card or whatever
[14:15:33] <jepler> I assumed the breakout board's estop output to the PC was an AND of a physical estop button and charge-pump-good and any other onboard diagnostics
[14:16:08] <jepler> so when you start emc the estop input from the breakout would be FALSE, so the GUI estop button was pressable and would turn on the charge pump when pressed
[14:16:19] <mozmck> yes except there is no charge-pump-good
[14:16:35] <jepler> charge-pump-good being something derived on the card from the presence of the square wave
[14:16:42] <jepler> I am just explaining what I thought when I made it
[14:16:44] <mozmck> the charge-pump is generated by the computer and ouput on pin 17
[14:16:50] <jepler> right
[14:16:58] <mozmck> by the hal charge-pump module
[14:17:00] <jepler> right
[14:18:10] <mozmck> on our stuff the charge pump is converted to a dc signal which runs the enable pins on the buffers and other chips
[14:18:48] <mozmck> it's absence disables all outputs. but there is no connection back to the estop chain
[14:19:05] <jepler> I am just trying to explain the design I imagined a breakout board using a charge-pump signal would have. It's clear that this doesn't match the real world
[14:19:37] <SWPadnos> mozmck, take a look at the Tormach PCNC-1100 config
[14:20:04] <SWPadnos> the estop setup there is different from the standard stepconf-generated one
[14:20:10] <SWPadnos> but it may still not be what you want :)
[14:20:15] <jepler> if there's a different way that "all" stepper systems use, then by all means let's change stepconf
[14:20:51] <SWPadnos> well, the thing is that there is hardware that causes the estop input to EMC to be asserted if the charge pump output is lost (I think)
[14:21:16] <mozmck> there is not on our stuff.
[14:21:22] <mozmck> I'm not sure about others
[14:21:52] <SWPadnos> the Tormach board may work that way
[14:22:23] <SWPadnos> hmmm. no, maybe not. the input to EMC is probably just the state of the e-stop switch
[14:22:30] <mozmck> basically what I want is for the charge-pump to turn on with "machine on"
[14:23:00] <SWPadnos> and for the machine to go to "estop" state if the external signal is asserted
[14:23:18] <mozmck> yes.
[14:23:35] <SWPadnos> well, take a look at the Tormach config. it might do that
[14:23:43] <SWPadnos> can't remember, been a while since I did it
[14:23:46] <cradek> in order to get to machine on, you have to be able to read the limit switches. I can easily imagine a board where you cannot read these inputs without the charge pump already running.
[14:24:01] <mozmck> I noticed that motion.motion-enabled does toggle with "machine on"
[14:24:07] <cradek> if that's right, then charge pump must run from estop like stepconf currently does (or tries to do)
[14:24:09] <SWPadnos> probably not for inputs, but definitely for outputs
[14:24:24] <mozmck> why do you have to read limit switches? to make sure you're not on one?
[14:24:43] <cradek> yes you cannot go to machine on while on a limit switch (without doing the override)
[14:25:25] <mozmck> I see. our limits are enabled by the charge pump because they are muxed
[14:25:50] <mozmck> the charge pump is the select signal - actually you can read 4 inputs without charge pump
[14:25:54] <cradek> ok, then I propose that you want the charge pump on estop reset, not machine on
[14:26:15] <jepler> your fancy muxing boards won't fit with stepconf without a custom.hal anyway
[14:26:25] <mozmck> That would work too.
[14:26:25] <cradek> there is that
[14:26:30] <jepler> in custom.hal you can re-hook the signals however you please
[14:27:12] <mozmck> jepler: that's true, but I was just trying a standard stepconf config just to get the charge-pump working and never could
[14:27:57] <jepler> you and steve stallings both
[14:28:40] <mozmck> I can get it working by just setting enable to true of course.
[14:29:13] <mozmck> in the idoubler.comp (which you actually wrote for me) I added an enable pin because it just ran all the time.
[14:29:59] <mozmck> the select pin of that comp will do the charge pump instead of the charge-pump hal module
[14:31:15] <jepler> talking just about what stepconf should do: if its use of charge-pump is not compatible with the common m**h-compatible breakout boards, then let's change it
[14:31:24] <mozmck> so for charge-pump on "machine on" can I just connect to motion.motion-enabled, or is there a reason that would not be good (ignoring the muxed inputs for right now)
[14:32:27] <mozmck> I think it's not. who else has breakout boards with charge pump? I'm almost certain Bob Campbells work like ours
[14:32:43] <jepler> steve stallings
[14:32:50] <SWPadnos> G540, PMDX, CNC4PC
[14:32:55] <SWPadnos> probably others
[14:33:55] <jepler> so in that world it's basically used as an "amplifier enable" signal?
[14:33:55] <mozmck> hmm, does G540 have a charge-pump input or just dc enable signal?
[14:34:18] <jepler> amplifiers on when a square wave is present, off otherwise?
[14:34:21] <mozmck> I think so. I don't know much about the amplifier world yet :(
[14:34:39] <jepler> what if the external estop button is pressed, is that AND'ed into the amplifier enable?
[14:34:48] <SWPadnos> G540 is charge pump
[14:35:17] <mozmck> yes, the signal is just run through a cap and resistor to create a DC signal, but will ignore an incoming DC signal or noise
[14:35:27] <mozmck> no, it's separate
[14:35:43] <jepler> that's terrible then
[14:36:26] <jepler> s/that's terrible then/at every turn this is counter to my intuition/
[14:36:34] <cradek> haha
[14:36:58] <mozmck> basically, the external estop tells the software to turn off everything, and the software turns off the charge pump to disable outputs
[14:37:11] <cradek> I'd go with jepler's first statement then -- that's not estop
[14:37:23] <cradek> estop must stop the machine in hardware only or it's not estop
[14:38:01] <SWPadnos> it may optionally inform the software that the machine is e-stopped
[14:38:10] <cradek> yes sure
[14:38:30] <cradek> it may optionally send you a twitter on your facebook iphone
[14:38:39] <jepler> ow my social
[14:38:52] <mozmck> that's true. Our fancy power supply has an estop button which turns off the power several ways, but it also sets the estop line so the software can stop running
[14:39:24] <cradek> yeah, it's good to notify the software - it's wrong to trust the software to do your stopping for you
[14:39:47] <cradek> (not just bad; wrong)
[14:39:55] <mozmck> we don't. the charge-pump is mostly an extra safety.
[14:40:47] <mozmck> it prevents noise from switching relays or something if there is power to the board but the software is not running, or the cable to the parport is not connected
[14:40:48] <cradek> I must have misunderstood then - what else does the hardware estop do to cause the machine to stop?
[14:41:23] <mozmck> or if the board and motors are powered up when the computer is turned on.
[14:41:36] <cradek> I understand - charge pump is good for that.
[14:42:40] <mozmck> on our power supply it breaks power to the main relay coil, sends a signal to the processor which turns of a triac in series with the relay, and pulls the estop line to the computer low
[14:42:53] <mozmck> of = off
[14:43:01] <cradek> gotcha
[14:43:33] <mozmck> then our processor dumps the caps and back emf from the motors to ground to stop the machine faster
[14:45:48] <cradek> ok, so you do have a real hardware estop, sorry I misunderstood.
[14:46:51] <mozmck> heh, not as much as I misunderstand I'm afraid.
[14:53:53] <mozmck> SWPadnos: your right (of course!), here's the link for the G540 doc
http://www.geckodrive.com/upload/G540InitialSetup.pdf Page 2 tells what the charge pump does.
[15:03:40] <jepler> G540 REV1 apparently didn't have chargepump, REV3 does.
http://www.geckodrive.com/upload/G540%20MANUAL%20REV1.pdf http://www.geckodrive.com/upload/G540%20REV3%20MANUAL.pdf
[15:04:54] <jepler> "will not come out of FAULT mode unless there is a charge pump" -- this sounds like it might work with stepconf
[15:05:08] <jepler> CP not present -> fault -> external input to PC will be TRU␂E
[15:05:31] <jepler> so pressing F1 will assert user-enable-out, and complete the "come out of estop" procedure
[15:06:08] <jepler> bbl
[15:07:04] <mozmck> hmm, is there an external input to PC?
[15:07:33] <mozmck> oh, pin 15
[15:08:44] <SWPadnos> jepler, it did work with stepconf
[15:09:06] <SWPadnos> I don't think I had to do anything special except get the polarities and pins right
[15:09:16] <SWPadnos> bbl
[15:37:47] <CIA-1> EMC: 03jepler 07master * r2594ccb2cf73 10/src/po/it.po: update italian translation
[15:58:25] <CIA-1> EMC: 03cradek 07master * r1f28be14d9b4 10/tcl/tkemc.tcl: Make TkEMC show next line to be executed
[15:59:23] <CIA-1> EMC: 03cradek 07v2_3_branch * r5970fc1ec8ef 10/tcl/tkemc.tcl: Make TkEMC show next line to be executed
[16:54:31] <mozmck> so with the current estop setup, say on the G540, if the charge pump turns on with F1 but the fault line is still on due to something else, does the charge pump then turn off?
[17:01:30] <jepler> I don't think there's a timeout
[17:04:57] <mozmck> hmm, so in that case would it be a problem to just have charge pump on all the time?
[17:06:10] <mozmck> In Ma**3 the default is that charge pump toggle off and on with reset (equivalent of machine on), but there is a setting to leave charge pump on all the time.
[17:07:48] <mozmck> just wondering if maybe stepconf could have something similar - default to charge-pump on with machine on, and a check box to use the old (current) method or just leave it on all the time.
[17:08:33] <SWPadnos> I believe that with the G540, if it's in e-stop you won't be able to turn the machine on
[17:09:06] <mozmck> yeah, but if you hit F1 it turns the charge-pump on?
[17:09:13] <SWPadnos> durrr
[17:10:16] <mozmck> then does it stay on?
[17:10:26] <SWPadnos> durrr
[17:10:33] <mozmck> ?
[17:10:58] <SWPadnos> I'm not sure at the moment
[17:11:26] <mozmck> I see. thought it was a typo :)
[17:11:57] <SWPadnos> I think the charge pump output is only turned on when EMC is in the machien on state
[17:12:00] <SWPadnos> machine
[17:12:31] <mozmck> I need to test with our G540. I think it's a REV3...
[17:12:57] <SWPadnos> if it has the switch, it's a REV3 or REV4 (?)
[17:13:16] <mozmck> if the charge pump is part of the estop chain then the machine can't be turned on unless it has charge pump can it?
[17:13:59] <SWPadnos> I don't think the G540 turns its estop output (input to EMC) on when the charge pump signal is lost
[17:14:45] <SWPadnos> hmmm. I probably don't know what I'm talking about any more, and should turn the thing on to check before saying anything more
[17:15:29] <mozmck> :) I'd have to go to Tom's to get ours. Might do that tomorrow.
[17:16:20] <SWPadnos> I think the G540 setup does have the "problem" that the estop state (and AXIS button) only reflect the state of the external estop input
[17:16:57] <SWPadnos> you can stop the machine with F1 like normal, but the estop button/indicator (in AXIS) will stay out
[17:17:45] <mozmck> I see. I can click the button here and it will stop the machine, but the button does stay out
[17:18:58] <SWPadnos> I don't remember if I "fixed" that problem for the Tormach config
[17:19:29] <mozmck> The estop button shows the external estop state, and the machine on button shows the machine on state. is that a problem?
[17:19:46] <SWPadnos> it may be counterintuitive for some people (like me)
[17:20:01] <SWPadnos> that when I hit the "estop" button (F1 or GUI), it doesn't change
[17:20:51] <mozmck> yeah, maybe it should press and come back out when you let off of it.
[17:21:18] <mozmck> don't know how easy that would be though.
[18:23:47] <mozmck> I made a change to configure.in and ran autoconf which made a new configure script. Should I include that in the patch I'm about to send?
[18:25:23] <cradek> I think either way is fine. configure is a generated file but we have it in vc. it's an odd case.
[18:25:42] <cradek> maybe your patch would be less noisy without it I guess
[18:26:06] <mozmck> yeah, but people might not know to run autoconf first
[18:26:57] <mozmck> in this patch I moved Makefile.modinc and the image files from etc to $prefix/share/emc
[18:26:58] <cradek> whoever pushes your change would do it - I agree a reminder in the email would be nice
[18:27:35] <mozmck> jepler thought we should look at moving them from etc and that looks to me like a good place.
[18:28:02] <mozmck> ok, how do I make a patch and exclude one file?
[18:28:03] <cradek> did you also update the deb packing list files?
[18:28:27] <mozmck> I don't know about them - which files do I look for?
[18:28:33] <cradek> um, let me look
[18:28:46] <mozmck> I updated comp.g, makefile, and configure.in
[18:29:10] <cradek> debian/emc2.files.in
[18:29:17] <cradek> there may already be a wildcard that's applicable
[18:31:06] <mozmck> ok, I'll look. how do I exclude configure from git format-patch?
[18:31:45] <cradek> hm, well, I think you'd have to not have that change as part of your commit
[18:31:54] <cradek> maybe I'm just wrong and you should include it :-)
[18:32:13] <cradek> so I'm changing my answer to "just do whichever is easier"
[18:32:15] <cradek> haha
[18:33:41] <mozmck> :) I'll look through the man docs a little. I already commited here
[18:33:47] <jepler> we should get rid of configure and config.h.in from git and require people using source from git to generate it
[18:34:30] <cradek> yeah that's sure the root of the problem
[18:34:57] <cradek> I wish just a make invocation could do it all, but you lose the ability to set the configure options then.
[18:36:45] <mozmck> I believe I've seen setups where the Makefile ran configure first
[18:38:04] <cradek> ours will even do that, using the same configure options you used "previously"
[18:38:20] <cradek> but for a first time, it seems like you can't get around there being several steps
[18:38:43] <cradek> also, this change will add autoconf as a build dependency
[18:39:22] <jepler> autoconf is not a big package
[18:39:23] <mozmck> maybe have a small file with the config args that someone could easily change...
[18:39:49] <mozmck> the Makefile would read that and pass them to configure or something like that...
[18:40:36] <jepler> there's no default that makes sense to put in git
[18:40:51] <jepler> echo "--enable-run-in-place --enable-simulator" > default-configure-args; make
[18:40:54] <jepler> ./configure --enable....; make
[18:41:04] <jepler> I don't think the first variant has much to recommend it
[18:45:29] <jepler> ./autogen.sh; ./configure ...; make
[18:45:29] <jepler> http://emergent.unpy.net/files/sandbox/0001-don-t-keep-autoconf-generated-files-in-git.patch
[18:47:40] <cradek> 15 insertions(+), 12026 deletions(-)
[18:47:47] <cradek> any patch that looks like that must be a good one
[18:48:10] <cradek> I didn't know we used autoheader too
[18:48:16] <jepler> I won't check it in right now, it'd turn all the buildbots red
[18:48:42] <jepler> but I'd also like to do it
[18:48:59] <cradek> one buildbot already needs attention - don't know what its problem is
[18:49:05] <cradek> tests fail on it
[18:49:10] <jepler> yeah I know why that is
[18:49:15] <jepler> its user sometimes leaves emc running on it
[18:49:22] <jepler> so anything else that halruns, fails
[18:49:35] <cradek> doh
[18:49:50] <jepler> s/leaves/has/
[18:52:07] <jepler> mozmck: as for your original question, you have two choices. First, you could do some git hackery to amend your commit to not include the configure change at all. second, you could just not be bothered by the fact that most of the patch from format-patch looks like noise
[18:52:43] <jepler> or third you could wait for my change to get rid of autoconf, rebase your tree on it, and then once you clear up the delete/modify conflict, your new patch won't have the configure change at all
[18:53:09] <cradek> three ... three choices!
[18:53:48] <jepler> manually editing the output of format-patch is probably best not done, but technically it's a fourth choice that you have availabe
[18:54:20] <mozmck> :) I was looking at that one.
[18:55:25] <mozmck> here's the manually modified patch:
http://www.pastebin.ca/1490974
[18:57:26] <cradek> hm, that doesn't apply at all
[18:58:07] <mozmck> to what?
[18:58:35] <mozmck> heh, it still says 4 files changed...
[18:58:39] <cradek> to master
[18:59:18] <mozmck> oh, my patch won't apply... probably because I manually edited it?
[18:59:29] <cradek> I'm not sure - maybe pastebin messed it up
[18:59:45] <cradek> I think the errors are about whitespace
[18:59:57] <jepler> incidentally, I am concerned about the configure.in change
[19:00:07] <cradek> (what is it with git and whitespace? those kinds of style checks don't belong in VC software)
[19:00:56] <mozmck> jepler: what would be better? is that not a good place to put the images?
[19:01:08] <jepler> it should probably be $(eval echo $datadir)/emc
[19:01:25] <jepler> but then the code will still be wrong if someone actually specifies --datadir to configure without more fixes
[19:01:29] <jepler> ugh I hate flexibility
[19:01:57] <jepler> #
[19:01:58] <jepler> + $(FILE) ../*.png ../*.gif $(DESTDIR)$(datadir)/emc
[19:02:14] <jepler> this line specifies where the images will go
[19:02:20] <mozmck> heh, there are still hardcodes references to /usr/local/etc/emc2/config that don't seem to be used anymore
[19:02:32] <mozmck> I see. why the eval echo stuff?
[19:02:33] <jepler> and this specifies where tcl will look for them: EMC2_IMAGE_DIR=${prefix}/share/emc
[19:03:05] <mozmck> I didn't know if the datadir var was available in configure.in
[19:03:09] <jepler> if $(datadir) isn/t ${prefix}/share then it won't work
[19:03:16] <jepler> probably it is but I haven't checked
[19:03:24] <mozmck> I see
[19:04:15] <jepler> if you were to write just ${datadir} in that spot in configure.in, then reconfigure and rebuild, you'd see a wrong path in emc.tcl which contains $-signs
[19:04:26] <jepler> $(eval echo) causes an extra level of expansion of $-substitutions
[19:06:09] <mozmck> ok, I'll try your statement and make sure it works.
[19:07:19] <mozmck> * mozmck needs to figure out how to revert commits...
[19:07:40] <jepler> if you just want to change your most recent commit, "git commit -a --amend"
[19:07:47] <jepler> (or use git add instead of the -a flag to commit)
[19:07:58] <cradek> git reset --hard origin/master, if you want to discard your local changes
[19:08:22] <jepler> I don't think that's what mozmck wants in this case though
[19:08:26] <mozmck> that may be what I want. I'll save my changed files and do that.
[19:09:16] <mozmck> that will get my configure commit out of there and another commit that I made accidentally
[19:14:27] <mozmck> interesting. when I changed configure.in to EMC2_IMAGE_DIR=$(eval echo $datadir)/emc, Makefile.inc has EMC2_IMAGEDIR=${prefix}/share/emc
[19:14:46] <mozmck> I guess that means it works...
[19:16:02] <mozmck> bbl
[20:34:48] <mozmck> grrr, git add seems to do nothing
[20:47:14] <mozmck> io error ^^^
[20:48:36] <mozmck> cradek: see if this will apply:
http://www.pastebin.ca/1491104
[20:52:31] <cradek> aha, it's a cr/lf problem. if I unix2dos it, git doesn't whine
[20:52:54] <cradek> so yes, it does work fine
[20:53:02] <cradek> er dos2unix
[20:53:42] <micges> cradek: what's the difference between tpSetVmax() and tpSetVlimit() ?
[20:53:54] <mozmck> weird, I'm on linux here, I guess pastebin messes it up.
[20:54:03] <jepler> yeah, it's pastebin's fault
[20:54:28] <micges> comments are not clear
[20:55:27] <mozmck> know if pastebin.com is better?
[20:55:41] <jepler> dunno
[20:55:48] <cradek> now that I know the secret, it's fine
[20:56:04] <cradek> micges: I don't know offhand, sorry
[20:56:24] <mozmck> same patch:
http://pastebin.com/d17c8f082
[20:56:58] <cradek> mozmck: so in the deb, this $datadir becomes /usr/share so you get /usr/share/emc/...?
[20:57:45] <cradek> hm, I feel unqualified to say whether this is right
[20:57:59] <mozmck> yes. datadir = datarootdir = $prefix/share
[20:58:45] <cradek> did you build a deb and see if everything installs and runs?
[20:59:06] <mozmck> no, how do I do that? (more ignorance showing...)
[20:59:29] <cradek> well you'd have to be on dapper or hardy
[20:59:31] <jepler> in the top dir, debian/rules binary; dpkg-buildpackage -rfakeroot
[20:59:48] <jepler> no, dapper doesn't build packages on master
[20:59:49] <jepler> lyx too old
[20:59:53] <cradek> oh
[20:59:56] <cradek> only hardy then?
[21:00:16] <jepler> I think it would work on 9.04
[21:00:29] <cradek> oh ok
[21:00:58] <mozmck> I'm on 9.04. let me try it - guess I have to delete it elsewhere...
[21:05:06] <jepler> I'm doing a build on 8.04 now
[21:08:58] <mozmck> in debian there is rules.in, but no rules. how do I generate it?
[21:09:27] <jepler> oops
[21:09:32] <jepler> I told you the wrong thing
[21:09:37] <jepler> debian/configure sim; dpkg-buildpackage -rfakeroot
[21:10:29] <mozmck> will that build sim only?
[21:10:34] <jepler> yes
[21:11:00] <mozmck> ok. how do I get the realtime?
[21:11:47] <jepler> you have a realtime kernel built?
[21:11:59] <jepler> is it the one you've booted at the moment?
[21:12:07] <mozmck> yes.
[21:12:12] <jepler> debian/configure -r; dpkg-buildpackage -rfakeroot
[21:12:33] <jepler> (fakeroot may be a package you need to install, incidentally.. you'll also need the packages required for buildind documentation. I think dpkg-buildpackage will complain if you don't)
[21:12:42] <mozmck> that's all I've run for weeks now - works fine. I'm testing hardware on this computer as well.
[21:16:41] <mozmck> looks like it doesn't like 9.04 - can't find rtai-modules and python-tkinter
[21:20:58] <mozmck> bbl
[21:50:36] <jepler> some of the package names are probably wrong for 9.04 (python-tkinter may be in that category)
[21:50:50] <jepler> it also assumes you built kernel and rtai as debian packages, which probably you didn't
[21:50:53] <jepler> oh well
[22:00:37] <cradek> it's spelled python-tk in my 9.04
[23:04:16] <jepler> I just gave "cppcheck" a try. It finds a number of not very interesting problems in emc2:
http://pastebin.ca/1491247
[23:05:25] <jepler> (sf.net/projects/cppcheck)
[23:17:01] <cradek> that's it?
[23:18:10] <jepler> that's all I got out of it so far
[23:18:21] <cradek> first one is definitely real
[23:21:06] <jepler> I ran it again with some additional flags. it printed more stuff.
http://emergent.unpy.net/files/sandbox/err.txt
[23:21:21] <jepler> hm, this can't be what it means: [../emc2-dev/src/emc/usr_intf/axis/extensions/emcmodule.cc:1]: (style) The function 'while' is never used
[23:21:41] <cradek> no...
[23:22:57] <jepler> it has a limited ability to specify include files or defines; it seems to try to guess what defines it should try compiling a file with
[23:23:21] <jepler> Checking ../emc2-dev/src/objects/hal/components/conv_bit_s32.c...
[23:23:21] <jepler> Checking ../emc2-dev/src/objects/hal/components/conv_bit_s32.c: MODULE_INFO...
[23:23:25] <jepler> Checking ../emc2-dev/src/objects/hal/components/conv_bit_s32.c: 0!=0...
[23:23:27] <jepler> wait, what?
[23:23:29] <jepler> Checking ../emc2-dev/src/objects/hal/components/conv_bit_s32.c: 0!=-1...