Back
[00:00:38] <BigJohnT> you about to get all the bugs out of hostmod2?
[00:00:58] <seb_kuzminsky> then i would have no job security ;-)
[00:01:09] <BigJohnT> LOL
[00:01:30] <seb_kuzminsky> gotta go, dinner time here, seeya later
[00:01:37] <BigJohnT> ok see ya
[00:29:04] <CIA-42> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/images/ (4 files): add ladder images
[00:32:19] <CIA-42> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ladder/classic_ladder.lyx: add assign compare example
[01:01:11] <cradek> whee, I have a jog wheel
[01:01:43] <BigJohnT> cool
[01:02:59] <SWPadnos> yay
[01:03:08] <SWPadnos> does the VFD work? :)
[01:03:28] <SWPadnos> (using modbus, on something other than /dev/ttyS0 :) )
[01:10:35] <cradek> sorry, I haven't messed with that yet
[01:14:52] <jepler> it would be interesting to see how well it works in css mode
[01:15:24] <jepler> if it updates the speed infrequently (e.g., 10Hz) I bet you would notice it
[01:16:20] <cradek> I bet you're right
[01:16:37] <jepler> on the other hand it seems like you could avoid carefully measuring the RPM/v relationship since it becomes a digital command
[01:19:02] <cradek> wow, jog wheel + CSS is extremely cool
[01:19:13] <jepler> I bet it is
[01:19:28] <jepler> now figure out how to do jog wheel + fpr
[01:19:52] <cradek> um
[01:20:27] <jepler> well it sucks that you have to spin the wheel faster the smaller X gets ..
[01:20:30] <jepler> right?
[01:20:57] <cradek> I guess - it's true the fpr goes down, but it doesn't really matter unless you're doing something hairy
[01:31:48] <cradek> hm, my computer's clock must be wrong, it says it's December
[01:37:37] <skunkworks> heh. don't blink...
[03:03:05] <cradek> I wonder if a lower accel for the jogwheel would be useful. it's pretty jerky at low speed since this machine is so fast.
[03:03:34] <cradek> I mean, when I am turning the knob slowly, no matter the increment setting
[03:03:52] <jepler> that's part of what ilowpass is for
[03:04:12] <SWPadnos> unfortunately, emc only knows that you've turned the wheel when you hit an encoder edge
[03:04:14] <cradek> oh...
[03:04:49] <cradek> well maybe I should try that!
[03:04:57] <jepler> it's not really an acceleration limit but it "kinda smooths things out"
[03:05:04] <cradek> thanks for the reminder
[03:05:11] <SWPadnos> err - doesn't jogging use the counts output of encoder?
[03:05:17] <cradek> it could use some smoothing.
[03:05:49] <cradek> does it still maintain position with ilowpass?
[03:05:50] <jepler> NAME
[03:05:50] <jepler> ilowpass - Low-pass filter with integer inputs and outputs
[03:06:12] <SWPadnos> yes, but the count changes by one increment
[03:06:27] <SWPadnos> so would ilowpass just delay that transition from N to N+1?
[03:06:28] <jepler> cradek: yes and no. in the steady-state position the output is a multiple of the input
[03:06:52] <cradek> ok so it will stop at the right place. that's what couts.
[03:06:55] <cradek> n
[03:06:58] <jepler> but if you switch the axis-to-jog before it's settled, you could end up getting half the jog on the new axis
[03:07:06] <jepler> SWPadnos: it scales up by a selectable amount
[03:07:12] <cradek> ok, I will play with it
[03:07:15] <cradek> ... later
[03:07:16] <cradek> brb
[03:07:17] <SWPadnos> ah ok - I'm seeing that now. thanks
[03:07:17] <jepler> SWPadnos: so 1 input count could become 100 output counts, or whatever you want
[03:07:20] <jepler> see you cradek
[03:07:41] <jepler> jon elson apparently really liked it after playing with the two tuning parameters (named, confusingly, scale and gain :-P)
[03:07:43] <SWPadnos> so the jog increments would need to be suitably altered
[03:07:46] <SWPadnos> heh
[03:07:51] <jepler> SWPadnos: yeah
[03:08:15] <SWPadnos> do you know how it works in velocity jog mode?
[03:08:24] <jepler> SWPadnos: no
[03:08:33] <SWPadnos> hmm
[03:08:48] <SWPadnos> that sounds like a simple problem, but I think it isn't
[03:54:14] <jmkasunich> hmm, it might be interesting to set jog increments by changing the scale (or gain) in the lowpass
[03:54:37] <jmkasunich> if you are taking tiny tiny steps, then every input "tick" will move you 0.0001 with no filtering or delays
[03:54:51] <jmkasunich> if you are taking bigger steps, then a tick will move you 0.01 with filtering
[03:55:39] <SWPadnos> at that point, the jog input should probably just be changed to a position that the motion controller moves toward within constraints
[03:55:52] <SWPadnos> more or less as though you ran the position into a stepgen
[03:56:06] <jmkasunich> that's what it is now, sort of
[03:56:18] <jmkasunich> what you propose wouldn't work well with other jog sources
[03:56:23] <SWPadnos> well, not quite (AFAIK)
[03:56:24] <SWPadnos> right
[03:56:41] <jmkasunich> the input isn't a position to move to, it's an amount to move the position to move to
[03:57:10] <jmkasunich> and EMC does head toward the final position while obeying constraints
[03:57:11] <SWPadnos> sort of
[03:57:15] <SWPadnos> sure
[03:57:28] <jmkasunich> basically there is a "jog target"
[03:57:32] <SWPadnos> but it's a unitless number, with the unit being internally set
[03:57:43] <jmkasunich> keyboard jogs move it, wheel jogs move it, EMC chases it while obeying limits
[03:58:07] <SWPadnos> setting the scale on ilowpass is like making the number have a unit of length
[03:58:25] <jmkasunich> "he number" = what?
[03:58:30] <jmkasunich> the counts input?
[03:58:33] <SWPadnos> yes
[03:58:40] <jmkasunich> it already has a unit of length
[03:58:50] <jmkasunich> jogwheel.n.scale or something like that
[03:59:23] <SWPadnos> uh, then what do the selections in the GUIs do?
[03:59:31] <SWPadnos> they don't change that HAL pin do they?
[03:59:47] <SWPadnos> oh duh - nevermind that
[03:59:49] <cradek> wow, ilowpass works great
[03:59:49] <jmkasunich> the guis directlky change the size of any jogs they issue
[04:00:05] <SWPadnos> different jog sources = different units
[04:00:14] <SWPadnos> (potentially)
[04:00:18] <jmkasunich> I think axis exports pins so you can also change jogwheel units
[04:00:34] <jmkasunich> not just potentially - almost always
[04:00:37] <SWPadnos> well, it works, so yay! :)
[04:01:03] <cradek> yes AXIS gives you the increment and selected axis
[04:01:04] <jmkasunich> one click on a keyboard is probably gonna be bigger than on click on a wheel, just because you can conveniently issue scads of wheel clicks
[04:01:43] <SWPadnos> "one step" on the keyboard is useful for testing stepper drives though :)
[04:04:39] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/ (Makefile mk_vhdl_deps.py): starting on a makefile for the Mesa bitfiles - work in progress
[04:05:57] <jmkasunich> goodnight
[04:06:04] <SWPadnos> see you later
[04:06:06] <cradek> goodnight
[04:44:42] <CIA-42> EMC: 03jmkasunich 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/Makefile: remember: test, THEN commit
[04:45:03] <jmkasunich> I always seem to remember stuff I forgot while I'm walking the dog...
[04:46:14] <SWPadnos> heh. I take it something didn't work
[06:31:40] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/TODO: logging is ok now
[13:04:37] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/ladder/classic_ladder.lyx: update the vars images
[13:31:18] <CIA-42> EMC: 03bigjohnt 07v2_2_branch * 10emc2/docs/src/gcode/main.lyx: add info on M0
[13:33:22] <CIA-42> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/gcode/main.lyx: add info on M0
[13:53:39] <alex_joni> hi skunkworks
[13:54:11] <Guest931> good morning :)
[13:54:20] <Guest931> Guest931 is now known as skunkworks_
[15:31:37] <cradek> http://www.youtube.com/watch?v=DrdC9-gPTk0&NR=1
[15:31:40] <cradek> interesting
[16:01:08] <jepler> "Enchaged"
[16:01:23] <cradek> yeah I noticed that too - close.
[16:01:37] <cradek> it has a lot of complex work-holding stuff on it
[16:04:25] <jepler> suppose those are axes or just solenoids?
[16:04:38] <cradek> I think they are air solenoids
[16:24:45] <cradek> neat, I can ask hm2 for another encoder, and it shows up on some of the 7i37 input pins
[16:25:47] <jepler> how fortunate
[16:26:16] <cradek> and ... they are some of the ones I haven't used yet
[16:28:25] <seb_kuzminsky> good morning
[16:28:35] <cradek> hi seb
[16:28:43] <cradek> hm2 is cool
[16:28:46] <seb_kuzminsky> :-)
[16:29:06] <cradek> I can add a second jog wheel (fifth encoder) without using a base thread
[16:31:02] <cradek> looks like I can get 15kHz through the optos, so it will work fine
[16:31:35] <seb_kuzminsky> the base thread is in the fpga :-)
[16:31:50] <cradek> and a good place for it that is
[16:35:03] <cradek> I know index mask has a bit to enable it, so even though those GPIs also hook to the encoder internally, I don't have to worry, and I can still use them as GPIs. Am I correct that this is not true for the Index inputs?
[16:51:48] <seb_kuzminsky> cradek: any pin used by a module instance as an *input* is also visible and available in HAL as a GPIO input at all time
[16:52:01] <seb_kuzminsky> that's totally independent of what the module instance is doing with it
[16:56:22] <cradek> ok I understand that, but if I have other stuff driving that input as I'm using it as a GPI, it will mess up my encoder count
[16:56:31] <cradek> or not, if I never assert index-enable
[16:56:42] <cradek> sorry, I had a stupid moment
[16:57:57] <seb_kuzminsky> oh i see waht you mean
[16:58:38] <seb_kuzminsky> yes i think it should work as you describe, if you dont tell the encoder to look at its index input, you should be totally free to use that input pin for something else
[16:59:46] <seb_kuzminsky> one thing i want for the hm2 driver is a better configuration mechanism, it'd be nice if you could say "encoder #4 should run without index", and get the index and index-mask pins as full GPIOs, totally disconnected from the encoder module instance
[17:00:24] <cradek> I see there is sure a complexity/configurability tradeoff
[17:00:33] <seb_kuzminsky> elsewhere in the news, paul_c got his buildslave to work
[17:00:33] <cradek> you have already made huge advances
[17:01:05] <seb_kuzminsky> thanks chris :-)
[17:01:10] <seb_kuzminsky> http://emc2-buildbot.colorado.edu/buildbot/builders/sid-2.6.27-trunk-realtime-rip/builds/2
[17:01:32] <seb_kuzminsky> paul's running 2.6.27, and hal_5i2x doesnt compile
[17:02:27] <cradek> oh, did some pci api change? icky.
[17:02:45] <seb_kuzminsky> i dont think so cradek, the function is still there, still marked as __deprecated
[17:02:57] <seb_kuzminsky> maybe paul's turned off deprecated features or something....
[17:03:39] <cradek> so now is when we have to start guessing whether he's breaking the build on purpose?
[17:03:44] <seb_kuzminsky> i've told him he's gotta do some of the debugging work on his chosen platform, we'll see if he follows through
[17:04:52] <cradek> there are a lot of other warnings I haven't seen before.
[17:06:25] <seb_kuzminsky> he's running Debian Sid's GCC 4.3, which *may* have FORTIFY_SOURCE enabled by default
[17:06:37] <seb_kuzminsky> that does a bunch of static checking at compile time
[17:06:43] <seb_kuzminsky> good stuff for finding bugs
[17:08:26] <cradek> emc/usr_intf/xemc.cc:222: warning: array subscript is above array bounds
[17:08:30] <seb_kuzminsky> coverity flagged some of the array out of bounds bugs in the nml code, but it's pretty hairy in there
[17:08:38] <cradek> this first one I checked is a real error
[17:08:51] <seb_kuzminsky> xemc is another place that's dense with coverity issues
[17:09:35] <cradek> emc/usr_intf/xemc.cc:1034: warning: suggest parentheses around comparison in operand of !=
[17:09:41] <cradek> and this one...
[17:13:08] <cradek> http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc8/2.6.26-rc8-mm1/broken-out/undeprecate-pci_find_device.patch
[17:13:45] <cradek> (I bet he built without CONFIG_PCI_LEGACY)
[17:13:59] <seb_kuzminsky> i bet you're right
[17:18:10] <cradek> apparently other drivers still use it - he must not have any that do in his system.
[17:18:29] <cradek> well maybe he will update the pci stuff so it does not require that option.
[17:22:28] <seb_kuzminsky> dont hold your breath...
[17:23:01] <cradek> does anyone know how (other than the obvious way) I could see the default kernel config file for sid?
[17:23:53] <jepler> looks like svn maybe
http://wiki.debian.org/DebianKernel
[17:25:30] <jepler> http://svn.debian.org/wsvn/kernel/dists/sid/linux-2.6/debian/config/config?op=file&rev=0&sc=0 has CONFIG_PCI_LEGACY=y
[17:25:43] <seb_kuzminsky> he compiled his own kernel with the rtai patches
[17:26:01] <cradek> sure, I just wondered what the default is
[17:26:06] <seb_kuzminsky> ok
[17:26:09] <jepler> which isn't overridden by i386/config or i386/config.686
[17:26:36] <jepler> so as far as I can guess, the kernel shipped with sid has CONFIG_PCI_LEGACY
[17:26:42] <cradek> I agree
[17:26:43] <cradek> thanks
[17:29:47] <jepler> looks like unstable (that's sid, right?) isn't on 2.6.27 yet
[17:29:54] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/libnml/cms/cms.cc: fix a gcc 4.3 fortify warning
[17:29:57] <seb_kuzminsky> sid is unstable yes
[17:30:16] <seb_kuzminsky> there are two things here i think
[17:30:30] <seb_kuzminsky> one is he turned off PCI_LEGACY, so our legacy pci code doesnt compile
[17:30:54] <seb_kuzminsky> the other is the new gcc has a bunch of static checking enabled that warns about actual bugs in our code
[17:31:12] <seb_kuzminsky> to fix 1: re-enable PCI LEGACY or update the drivers
[17:31:16] <seb_kuzminsky> that's paul's job
[17:31:28] <seb_kuzminsky> to fix 2 is all our jobs i think - they're our bugs
[17:31:51] <jepler> what's "2"?
[17:32:09] <cradek> heh, if they're in NML and xemc none of us wrote them, but sure, it's not specific to paul's setup.
[17:32:20] <seb_kuzminsky> the static-checker warnings from gcc 4.3
[17:32:25] <cradek> jepler: some new warnings in his build output that are real problems
[17:32:25] <seb_kuzminsky> "the other" above
[17:32:49] <seb_kuzminsky> many of the gcc-found problems were already known from coverity
[17:35:07] <cradek> nice that gcc finds them now
[17:37:18] <seb_kuzminsky> super nice :-)
[17:37:21] <seb_kuzminsky> thanks gcc guys!!
[17:37:36] <seb_kuzminsky> coverity still finds a bunch more stuff than gcc does though
[17:38:59] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/libnml/cms/ (cms_aup.cc cms_dup.cc tcp_srv.cc): fix some gcc fortify warnings
[17:44:38] <jepler> ummmmm so this rtwas person insists that in 2.2.2, during an m0 pause, he could jog and touch off
[17:45:18] <cradek> mistaken
[18:02:54] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/emcsh.cc: fix an array overrun bug
[18:22:31] <seb_kuzminsky> sometimes we use LINELEN and sometimes NML_TEXT_LEN, NML_DISPLAY_LEN, etc, and they're all different
[18:22:48] <seb_kuzminsky> (for the size of arrays of characters to hold lines of text)
[18:22:55] <SWPadnos> well, that's why they have different names :)
[18:23:20] <seb_kuzminsky> but they're not used consistently so we have bugs
[18:23:35] <SWPadnos> yeah, that's probably true
[18:23:58] <SWPadnos> I'd have to look at the code to see why there are so many constants to choose from
[18:25:47] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/shcom.cc: fix more pedantic warnings
[18:26:28] <SWPadnos> that one wasn't pedantic :)
[18:26:47] <SWPadnos> oh, maybe it was
[18:27:01] <SWPadnos> have I mentioned recently how little coffee I've had this morning? :)
[18:27:46] <seb_kuzminsky> SWPadnos: get juiced up man! it's morning!
[18:27:55] <SWPadnos> working on it
[18:28:02] <SWPadnos> amd it's afternoon here ;)
[18:28:06] <SWPadnos> s/m/n/
[18:28:07] <skunkworks_> morning? I just went for the after lunch walk..
[18:28:20] <SWPadnos> some people are on Mountain time
[18:28:31] <SWPadnos> or worse
[18:29:07] <seb_kuzminsky> mountain time rocks what you talking about!
[18:29:20] <SWPadnos> mountain time rockies
[18:29:21] <skunkworks_> :)
[18:33:24] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/emclcd.cc: fix some array overruns
[18:33:52] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/halui.cc: fix some operator precedence pedantry
[18:34:15] <skunkworks_> I am confused..
[18:34:20] <skunkworks_> http://www.electronicsam.com/schalt.pdf
[18:35:29] <SWPadnos> by what?
[18:35:47] <skunkworks_> * skunkworks_ wonders how that works.. The h-bridge drives are run by ic10d - the pwm gets sent to one driver ic and the other is run by the inverted of the same signal..
[18:36:51] <skunkworks_> how do you get both directions from that?
[18:36:58] <skunkworks_> I must not be seeing it.
[18:37:10] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/keystick.cc: fix some operator precedence pedantry
[18:37:33] <skunkworks_> one driver chip is pwm and the other is pwmnot
[18:37:36] <SWPadnos> you always have one half on, and the direction changes depending on whether the input to IC10D is high or low
[18:37:57] <SWPadnos> err - one bridge on
[18:38:05] <SWPadnos> is /SD the disable?
[18:38:09] <skunkworks_> yes
[18:38:45] <SWPadnos> ok, so you control whether it's powered by fiddling with /SD, and you control whether the average push is in one direction or the other by varying the IN value
[18:38:52] <SWPadnos> "0" is 50% PWM duty cycle
[18:39:00] <SWPadnos> half one way, half the other
[18:41:02] <SWPadnos> oh interesting
[18:41:08] <SWPadnos> that's actually not how he's doing it
[18:41:19] <skunkworks_> oh - so at 50% pwm it is 0 output
[18:41:31] <SWPadnos> the PWM also clocks the flip-flop (IC8b)
[18:42:00] <skunkworks_> I thought that was for reseting the overcurrent on the next upswing
[18:42:02] <SWPadnos> so the drivers are only enabled half the time
[18:42:19] <SWPadnos> could be, I'd haveto look at the software
[18:42:26] <SWPadnos> (and I don't want to do that right now ;) )
[18:42:34] <skunkworks_> which I think is closed source anyways.. ;)
[18:42:39] <SWPadnos> oh, lovely
[18:42:59] <skunkworks_> wait - though he is disabling both drivers at the same time..
[18:43:06] <SWPadnos> yes, that's for overcurrent
[18:43:10] <skunkworks_> ok
[18:43:20] <SWPadnos> but you can also change the PWM duty cycle at the same time
[18:43:31] <SWPadnos> you can load up different values for the two sides
[18:43:55] <SWPadnos> (the AVR will use the new value on the next PWM cycle, so there's no lag from a software update
[18:43:57] <SWPadnos> _
[18:43:59] <SWPadnos> )
[18:45:01] <SWPadnos> oh right, you output what you want the next cycle to look like, both on PB4 (goes to the D input of IC8b) and in the PWM duty cycle
[19:02:53] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/usr_intf/emcrsh.cc: fix an array overflow bug
[19:08:12] <seb_kuzminsky> alex_joni: you around?
[19:12:30] <seb_kuzminsky> check out xemc.cc:1034 <
http://bazaar.launchpad.net/~vcs-imports/emc/trunk/annotate/5949?file_id=srcemcusr_intfxemc.c-20081125191054-fc003aqe3q28809p-794>
[19:13:07] <alex_joni> seb_kuzminsky: around now
[19:13:17] <seb_kuzminsky> lookss like it calls sendAuto() each time, no matter what emcStatus->task.mode is
[19:13:29] <seb_kuzminsky> i gotta go, but i think that line is wrong
[19:13:39] <seb_kuzminsky> == and != have equal precedence, and evaluate left-to-right
[19:13:43] <alex_joni> what line number?
[19:13:47] <SWPadnos> if (0 == (emcStatus->task.mode != EMC_TASK_MODE_AUTO)) {
[19:13:48] <alex_joni> that link only opens the file
[19:13:51] <SWPadnos> added parens
[19:13:58] <SWPadnos> 1034
[19:14:19] <SWPadnos> or get rid of the 0== altogether (which would be more readable)
[19:14:21] <alex_joni> the == 0 is bogus
[19:14:52] <alex_joni> to be completely ok I'd write:
[19:15:10] <SWPadnos> to fit that line to the convention of constant then variable, it would be
[19:15:10] <alex_joni> if (EMC_TASK_MODE_AUTO != emcStatus->task.mode) {
[19:15:24] <SWPadnos> right, that :)
[19:15:32] <alex_joni> although for != it doesn't matter which is first
[19:15:49] <SWPadnos> it only matters as protection from accidentally leaving off the !
[19:15:53] <cradek> or always sendAuto, who cares
[19:16:05] <alex_joni> (and the constant first is imo a remnant from old days when compilers wouldn't cause warnings on if (foo=bar) {}
[19:16:31] <SWPadnos> there's a lot of output during a build - warnings like that can easily be lost
[19:16:32] <alex_joni> like cradek says, sending auto everytime a program gets opened is also no issue
[19:16:45] <alex_joni> SWPadnos: they are red on the buildbot pages :D
[19:16:48] <SWPadnos> heh
[19:16:51] <SWPadnos> warnings?
[19:17:40] <alex_joni> http://emc2-buildbot.colorado.edu/buildbot/builders/sid-2.6.27-trunk-realtime-rip/builds/2/steps/compile/logs/stdio
[19:17:51] <SWPadnos> yep, looking at it now
[19:18:20] <alex_joni> btw, paolo warned that he wasn't able to run 2.6.26 and .27 with rtai
[19:18:29] <alex_joni> it's caused him some problems
[19:19:00] <SWPadnos> there sure are a lot of warnings in the rtai_shm.h and rtai_lxrt.h files
[19:19:38] <alex_joni> "2.6.26 and 2.6.27 patches alone (RTAI not implied) seems to have
[19:19:38] <alex_joni> problem, as reported by a few people now. So I would not care for them
[19:19:38] <alex_joni> till the patches alone do work.
[19:19:39] <alex_joni> Paolo."
[19:19:55] <SWPadnos> huh. seb didn't fix xemc.cc :)
[19:20:18] <SWPadnos> oh right - he was looking at that when he had to leave. duh
[19:20:34] <alex_joni> you may
[19:20:39] <alex_joni> * alex_joni grabs a bite
[19:21:04] <SWPadnos> I will
[19:24:06] <jepler> SWPadnos: yeah those are bugs in the rtai header
[19:24:07] <jepler> http://groups.google.com/group/comp.std.c/browse_thread/thread/8118ae4c53a4de60
[19:24:17] <jepler> apparently c99 actually forbids this, but I can't see what the problem is
[19:26:05] <SWPadnos> bar could be used from an external file, where foo shouldn't be visible (?)
[19:26:38] <SWPadnos> I think inline isn't a command, it's a suggestion
[19:26:38] <jepler> I can't figure out what the motivation is for that constraint
[19:27:58] <SWPadnos> hmmm. I'm not sure either
[19:30:02] <SWPadnos> I wonder if it's something like this: since bar is inline, the contents need to be available to any user of bar (since there's really no function "bar"), which is not true of foo for externally linked calls to bar
[19:30:05] <SWPadnos> or something like that :)
[19:30:34] <jepler> but if it's an external call to bar, then it's calling some out-of-line'd version of bar, which can with no difficulty access the static thing
[19:33:21] <SWPadnos> err, true
[19:33:49] <SWPadnos> no, not necessarily true
[19:34:22] <SWPadnos> unless it's guaranteed that an inline function can't be inlined unless all calls within it are also inline-able (which would make no sense)
[19:35:16] <SWPadnos> I guess it doesn't make a lot of sense anyway since anything that knows about bar (likely from a header) must also know about foo (likely also from a header)
[19:35:28] <SWPadnos> oh wait. that's not true
[19:35:45] <SWPadnos> argh. I need more coffee!
[19:35:59] <SWPadnos> or I need to stop thinking about this problem. yeah, that's the ticket :)
[19:43:19] <jepler> http://www.greenend.org.uk/rjk/2003/03/inline.html
[19:44:24] <jepler> sounds like the "fix" is to 'static inline' those functions that are presently just 'inline' (c99 inline rules say this is like gnu c inline rules)
[20:00:56] <SWPadnos> hmmm. the "almost the same but not quite" #defines are an annoying problem
[20:05:51] <SWPadnos> though in the xemc and keystick cases, the proper fix is to just increase the size of the string buffer
[20:10:32] <CIA-42> EMC: 03swpadnos 07TRUNK * 10emc2/src/emc/usr_intf/ (xemc.cc keystick.cc): Fix some buffer length warnings and an incorrect comparison
[20:46:25] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/emc/rs274ngc/interp_convert.cc: fix some gcc fortify warnings
[20:47:10] <SWPadnos> have you figured out how to get those warnings on a local build?
[20:47:31] <seb_kuzminsky> the warnings are from FORTIFY_SOURCE, a feature of gcc 4.3
[20:47:35] <SWPadnos> I jsut can't seem to find where to add -D_FORTIFY=2 in the makefiles/Submakefiles ...
[20:47:55] <SWPadnos> oh, so there I go :)
[20:47:55] <seb_kuzminsky> it's enabled by default on Ubuntu Intrepid, and (i guess) Debian Sid
[20:48:37] <seb_kuzminsky> paul just disconnected his buildslave, hopefully to reboot to a kernel with CONFIG_PCI_LEGACY enabled
[20:48:48] <SWPadnos> ok, I'll try on the other machine then. now I can go to the coffee shop :)
[20:49:07] <seb_kuzminsky> mmm coffee
[20:51:17] <seb_kuzminsky> brb coffee
[21:02:07] <seb_kuzminsky> * seb_kuzminsky slurrrrrrps
[21:16:08] <seb_kuzminsky> what's up with the CHP macro and friends in emc/rs274ngc/interp_internal.hh?
[21:16:16] <seb_kuzminsky> they all have a dangling "else"
[21:16:57] <seb_kuzminsky> with no { }, so the following line in the code is the else clause?
[21:16:59] <seb_kuzminsky> very strange to me
[21:39:10] <cradek> else ;
[21:43:16] <seb_kuzminsky> right, duh
[21:43:24] <cradek> but still, it's odd
[21:43:38] <seb_kuzminsky> that whole pile of macros is problematic in other ways
[21:43:38] <cradek> I don't think the code uses the else for anything; it could be left off I think
[21:43:51] <seb_kuzminsky> some of them return, leaking memory
[21:44:29] <cradek> do you know an example offhand?
[21:48:14] <cradek> oh, with O words do we have some mallocs in the interp now?
[21:48:38] <cradek> yeah I guess so (strdup)
[21:49:07] <seb_kuzminsky> emc/rs274ngc/rs274ngc_pre.cc:1026 or so
[21:49:34] <seb_kuzminsky> CHK calls return, but the fopen on 1014 is still current
[21:49:41] <seb_kuzminsky> (so it leaks a filedescriptor, not ram, sorry)
[21:50:58] <cradek> true, but that never happens - it would be fairly fatal anyway
[21:51:26] <seb_kuzminsky> then let's exit ;-)
[21:52:21] <cradek> or discard the line
[21:53:33] <SWPadnos> seb_kuzminsky, I think those defines should use the form do { } while (0);
[21:53:58] <SWPadnos> I believe they're just trying to insure that all the statements in the define are treated as a single block
[21:54:02] <cradek> I agree that is more customary, but is it a functional change?
[21:54:08] <SWPadnos> it shouldn't be
[21:54:14] <cradek> most of them are based on a big if() anyway
[21:54:17] <SWPadnos> the only place it's used is in interp_convert
[21:54:20] <seb_kuzminsky> SWPadnos: what does that idiom do? I mean i understand what it does, but why not use { }?
[21:54:42] <cradek> seb_kuzminsky: if(MACRO(...))
[21:54:48] <SWPadnos> I don't recall the reason for that - it may have to do with extraneous semicolons or something
[21:55:20] <seb_kuzminsky> cradek: if ( do { } while(0); ) { ... } ??
[21:56:17] <cradek> nope I'm on drugs
[21:56:30] <seb_kuzminsky> anything good? ;-)
[21:56:40] <cradek> http://www.rtems.com/ml/rtems-users/2001/august/msg00086.html
[21:57:19] <cradek> I should ask the internet first, type second
[21:57:51] <SWPadnos> oh,
http://kernelnewbies.org/FAQ/DoWhile0
[21:58:51] <seb_kuzminsky> you guys are better than google
[21:59:04] <cradek> more entertaining anyway, I'm sure
[21:59:14] <SWPadnos> especially when searching for answers
[21:59:22] <SWPadnos> the intermediate results are often hilarious
[22:00:10] <seb_kuzminsky> heh
[22:03:11] <BigJohnT> for a comp to have the value of the commanded velocity do I need a "pin cmd-vel in float" and have to connect to that in my hal file with a net line?
[22:03:38] <SWPadnos> what?
[22:04:11] <SWPadnos> are you asking how to write a .comp that can have a float input?
[22:04:17] <BigJohnT> LOL, ok I want to use the commanded velocity Fnn in a function of a comp
[22:04:57] <BigJohnT> or is there a way inside of the comp to know the Fnn?
[22:05:09] <SWPadnos> ok, then what you wrote is correct, unless the order of the words was wrong :)
[22:05:15] <SWPadnos> no, you need to use a pin
[22:05:30] <cradek> the F word is not directly available to anything outside the interpreter
[22:05:35] <BigJohnT> ok, so a comp is like inside it's own bubble except for the pins
[22:05:39] <SWPadnos> yes
[22:05:45] <SWPadnos> pins, params, and functions
[22:05:46] <cradek> the velocity the machine is currently moving is available from HAL
[22:05:51] <cradek> those are not even remotely the same thing :-)
[22:06:08] <SWPadnos> those are the interface between each hal component and everything else
[22:06:15] <BigJohnT> what I'm looking for is the commanded velocity and the actual velocity
[22:06:29] <BigJohnT> of X and Y axis
[22:06:38] <cradek> you just don't have that at the HAL level
[22:06:54] <BigJohnT> crumb
[22:07:01] <SWPadnos> I don't know that those are available except by using ddt on the x-pos-cmn and y-pos-cmd outputs
[22:07:02] <cradek> what do you want to do?
[22:07:10] <BigJohnT> corner lock for THC
[22:07:11] <SWPadnos> s/cmn/cmd/
[22:07:17] <cradek> SWPadnos: that's not anything like the commanded velocity though
[22:07:23] <SWPadnos> no
[22:07:29] <SWPadnos> it's only actual
[22:08:03] <cradek> BigJohnT: I don't know exactly what that means, but I bet it would need to be coded in C in the trajector planner
[22:08:40] <SWPadnos> it "should be easy" to add a net commanded velocity output
[22:08:41] <BigJohnT> it would be if the actual velocity is within a settable percent of commaned velocity then turn on an enable bit
[22:08:46] <cradek> at that stage you do know the 'desired' velocity which is still not the same as the F word
[22:09:13] <BigJohnT> the enable would allow the THC to do it's thing
[22:09:49] <BigJohnT> as soon as you slow down for a corner etc. the enable goes off blocking the THC from moving the Z
[22:09:52] <cradek> depending exactly what 'commanded velocity' means exactly, that might be fairly easy
[22:09:55] <SWPadnos> is it tp_run_cycle that calculates the new pose every cycle?
[22:10:13] <cradek> yes
[22:10:20] <cradek> depending exactly exactly
[22:11:00] <cradek> imagine a machine with max vels X=2ips and Y=1ips. You're moving diagonally in XY. You programmed F200. what's commanded velocity?
[22:11:08] <SWPadnos> well, there are at most 3 velocities (I think): F word, modified F word (with FO/AF included), and net vel (after TP limits)
[22:11:32] <cradek> if your answer is 200, you don't know that at the TP level
[22:11:57] <BigJohnT> if I program in 100 IPM and my tolerance is 10% when ever the combined velocity of X and Y is 90 IPM to 100 IPM allow the THC to work...
[22:12:49] <SWPadnos> hmmm. is FO done at a higher level, or is that just from the axis vel limits?
[22:13:06] <cradek> if you program numbers your machine can move (in any direction) it's possible to generate that output I think
[22:13:24] <BigJohnT> cool
[22:13:38] <SWPadnos> hmmm. are you quite sure the 200 wouldn't be available to the TP in that example?
[22:13:40] <cradek> SWPadnos: FO comes from several places and the TP honors them as appropriate at each cycle
[22:13:54] <cradek> SWPadnos: yes quite
[22:14:18] <cradek> the TP gets vels adjusted so they make sense according to axis constraints
[22:14:24] <cradek> F200 on that move makes no sense
[22:14:39] <cradek> (see emccanon.cc)
[22:14:46] <cradek> unfortunately I have to run, 15 minutes ago
[22:14:53] <BigJohnT> thanks cradek
[22:14:59] <cradek> I'll read back later
[22:15:07] <SWPadnos> ok, thanks
[22:18:57] <BigJohnT> SWPadnos: on line 188 of emccanon.cc is "static double currentLinearFeedRate = 0.0;" and "static double currentAngularFeedRate = 0.0;"
[22:19:26] <SWPadnos> yep, those are the variables all right :)
[22:19:37] <BigJohnT> do they help?
[22:19:40] <BigJohnT> :)
[22:21:02] <SWPadnos> what version of emccanon are you looking at?
[22:21:12] <BigJohnT> 2.2.x
[22:21:37] <SWPadnos> oh no wonder. I'm looking at trunk :)
[22:21:49] <SWPadnos> it's about 200 lines further down in my file
[22:23:25] <BigJohnT> yep :)
[22:30:40] <SWPadnos> ok, I think this is non-simple :)
[22:31:05] <BigJohnT> !simple... darn
[22:31:06] <SWPadnos> you're looking for the difference between actual feed rate and the programmed feed rate (modified by FO and AF I assume)
[22:31:09] <SWPadnos> yes
[22:31:20] <BigJohnT> what is FO and AF
[22:31:30] <SWPadnos> deed override and adaptive feed override
[22:31:35] <SWPadnos> s/deed/feed/
[22:31:51] <BigJohnT> yes but just on the X and Y axis
[22:31:59] <SWPadnos> it makes no difference
[22:32:04] <SWPadnos> (well, slight difference)
[22:32:16] <BigJohnT> to include the Z?
[22:32:38] <SWPadnos> the trouble is that the requested feed rate doesn't exist in the RT code as far as I can tell
[22:32:53] <BigJohnT> hmmm
[22:33:16] <SWPadnos> the velocity that the TP gets is already modified based on some limits, like "must decelerate now or we might overshoot"
[22:33:32] <BigJohnT> ok, I understand that
[22:33:37] <SWPadnos> so the realtime code has an already reduced "command" rate
[22:33:55] <BigJohnT> where does the velocity come from that the TP gets?
[22:33:55] <SWPadnos> so the next idea is to add pins to the userspace interp
[22:33:59] <SWPadnos> canon
[22:34:23] <SWPadnos> say canon sees a command to move in a straight line at F200, but the distance is too small to accel/decel to that reate
[22:34:25] <SWPadnos> rat
[22:34:26] <SWPadnos> e
[22:34:35] <SWPadnos> it reduces the command rate to fit the segment length
[22:34:42] <SWPadnos> commanded rate, that is
[22:34:49] <BigJohnT> so would canon "knows" that it can't do the commaned rate
[22:34:53] <SWPadnos> yes
[22:35:23] <SWPadnos> but here's the problem, canon can have a HAL pin or three that give us F word, accel limited feed rate, etc
[22:35:28] <BigJohnT> could it set a flag or something that that segement is below "tolerance"
[22:35:48] <SWPadnos> but the interp is busy working on lines that haven't been run yet
[22:36:02] <SWPadnos> so the interp and TP rates are from different places
[22:36:22] <SWPadnos> I believe the interp has no HAL interface at the moment, so there's no easy way to add that output
[22:36:54] <BigJohnT> but the TP plans when to slow down for a direction change right?
[22:36:57] <SWPadnos> and it wouldn't be synchronized with the execution of the segment (vs. the interpretation of the g-code) unless the canon messages are changed to add the flag
[22:37:20] <SWPadnos> I don't know how much of that is done in canon and how much is done in the TP
[22:37:35] <SWPadnos> canon is where the G64P- tolerances are taken into account, for example
[22:37:40] <BigJohnT> I know even less :)
[22:37:50] <SWPadnos> heh, it's easy isn't it? :)
[22:37:54] <BigJohnT> ok
[22:37:56] <SWPadnos> (to not know much about this)
[22:37:57] <BigJohnT> yep
[22:38:48] <SWPadnos> so I take back my statement that "it should be easy". I don't think that's true any more
[22:39:42] <BigJohnT> maybe cradek will have time to look at it...
[22:39:53] <SWPadnos> could be
[22:40:07] <SWPadnos> in the mean time, could you hook up your GS2 and tell me if the driver works for you? :)
[22:40:45] <BigJohnT> I've not ordered it yet but I'll get on the stick and get it coming
[22:41:04] <SWPadnos> oh. I thought you had it already. nevermind
[22:41:58] <BigJohnT> I've got it picked out but I keep getting dragged off to the customers to sit down and press the send me one key
[22:42:11] <BigJohnT> to have time to sit down
[22:42:17] <SWPadnos> ah
[22:42:26] <SWPadnos> I can email Ray anyway - I know he has one :)
[22:42:33] <SWPadnos> (should even be configured correctly)
[22:42:35] <BigJohnT> does it use the parallel port for the interface
[22:43:39] <SWPadnos> no, modbus
[22:43:55] <BigJohnT> ok that would be cool to test out
[22:44:25] <fenn_> fenn_ is now known as fenn
[22:46:27] <BigJohnT> SWPadnos: dumb question but what port is modbus on?
[22:46:36] <SWPadnos> serial
[22:46:40] <BigJohnT> ok
[22:46:47] <SWPadnos> or TCP/IP, but not this driver
[22:47:13] <BigJohnT> so the modbus takes over the serial port?
[22:48:01] <SWPadnos> well, generally serial ports are point-to-point connections, so yes, you need to have a serial port dedicated to modbus
[22:48:26] <SWPadnos> it is possible to have multiple devices on a single port though, if you have RS485 (or some other multi-drop protocol)
[22:54:21] <BigJohnT> ok lazy streak is over it will be here in a couple of days
[22:55:28] <SWPadnos> cool
[22:55:30] <BigJohnT> actually it was something I planned on ordering before the end of the year... but why rush things
[22:55:46] <BigJohnT> you know spend the money before you pay taxes on it
[22:55:57] <SWPadnos> I suppose I could get a smaller one for my bandsaw. they're relatively cheap
[22:57:31] <BigJohnT> the 3hp is $100 per hp by the time you add shipping so that is cost effective
[22:57:48] <SWPadnos> oh. I'd only need 1/2-1HP for the saw
[22:58:47] <BigJohnT> 1/2 is $160 and 1hp is $175
[22:59:25] <BigJohnT> * BigJohnT needs to go see what the dog is trying to tell me
[22:59:40] <SWPadnos> time to go off with the wife here. bbl
[23:18:18] <skunkworks> jmkasunich: are you around?
[23:23:29] <skunkworks> or square
[23:27:20] <fenn> askew perhaps
[23:28:24] <jmkasunich> skunkworks: for a bit
[23:30:53] <skunkworks> heh
[23:32:07] <skunkworks> I was just going to say - the 21844 driver chip - 14pin dip has a separate logic and motor ground
[23:32:35] <skunkworks> and can handle +/-5 volts difference
[23:32:47] <jmkasunich> that whole grounding thing is complex enough that I'm not even going to try to discuss it over the interwebs
[23:33:14] <skunkworks> no problem
[23:33:25] <jmkasunich> all you can do is hook it up, and scope it carefully to see if you ever get spikes between the two grounds that are "significant"
[23:34:28] <jmkasunich> I say scope "carefully" because it isn't uncommon to see 1V spikes in this kind of system, when you have the scope probe touching its own ground clip
[23:34:40] <jmkasunich> that isn't real - the problem is figuring out what is real
[23:34:45] <skunkworks> right
[23:35:18] <skunkworks> I was thinking the 14 dip package would separate hv pins from the lv ones. It doesn't
[23:35:24] <skunkworks> odd
[23:36:37] <skunkworks> this is the 14 pin version of the driver I am using now.
[23:37:17] <jmkasunich> sorry, gotta go
[23:37:33] <skunkworks> take it easy
[23:49:39] <seb_kuzminsky> hi john
[23:49:56] <seb_kuzminsky> i mean, hi jmkasunich