Back
[00:41:57] <jepler> it's likely that a gtk program exercises code paths in the X server that Tk doesn't
[00:42:07] <jepler> for instance, gtk is using the render extension for fonts, while Tk uses X core fonts
[00:42:40] <jepler> on the other hand, the panel has things rendering with gtk, so that makes it seem less likely
[00:42:48] <jepler> * jepler doesn't have a good theory
[00:46:44] <jepler> there was an ubuntu kernel update last week or so; I'll probably install it tonight or tomorrow, now that I'm back from my trip. This will make the cvs server unreachable for the short time. I'll give another note on IRC right before the downtime.
[00:50:36] <jepler> (hm, I guess it was longer ago than that -- march 16? well, this is the first I saw it)
[02:19:55] <cradek> jepler: what's wrong?
[02:54:45] <jepler> cradek: that report of good latency test results, but chunky behavior while running stepconf
[02:55:17] <jepler> (assuming it's correct that the cause is bad latency, I suppose)
[02:55:29] <jepler> http://www.linuxcnc.org/component/option,com_kunena/Itemid,0/func,view/catid,16/id,75/lang,en/#75
[02:59:07] <SWPLinux> hmm. is there a way to get irssi to show "tabs" for open windows?
[02:59:41] <SWPLinux> or to change windows/tabs without using the "/window #" command
[03:01:40] <cradek> SWPLinux: alt-1, alt-2 etc
[03:03:23] <SWPLinux> hmm. I guess that would work if I weren't in a gnome-terminal
[03:03:38] <SWPLinux> now to figure out how to make rxvt show me a usable font :)
[03:04:30] <cradek> I'm sure you can fix gnome-terminal somehow
[03:04:38] <cradek> something about meta vs escape
[03:05:43] <SWPLinux> ok, esc-# does work
[03:29:29] <cradek> does anyone remember why the indrescnt>3 test is in the ppmc driver?
[03:30:47] <SWPadnos> is that the number if registers in a "hole" that doesn't need to be read?
[03:30:51] <SWPadnos> s/if/of/
[03:31:01] <cradek> no, it's in the index sensing
[03:31:07] <SWPadnos> oh
[03:31:18] <SWPadnos> no, dunno
[03:31:23] <cradek> has to be at least three? servo cycles since you requested an index for it to be called valid
[03:31:44] <SWPadnos> that makes no sense to me (while I'm not looking at the code ...)
[03:31:59] <cradek> this is so complicated I don't trust it
[03:33:47] <SWPadnos> and the integrated commenting / screwing up of bracket indenting makes it a lot clearer
[03:34:06] <cradek> C-c C-q
[03:34:34] <SWPadnos> I'm sure that does something in vi
[03:34:48] <cradek> emacs (properly indent this whole function)
[03:35:04] <SWPadnos> ah
[03:35:34] <SWPadnos> alt-T C does it in Kate (after you select the function or other text to fix up)
[03:38:35] <SWPadnos> oh interesting
[03:39:12] <cradek> sesms if this was wrong you might get a count reset without an index-enable reset
[03:39:19] <cradek> the user reports the opposite problem
[03:39:43] <SWPadnos> or you would ignore an index reset if it took less than 3 servo cycles to happen
[03:39:58] <SWPadnos> which would be really really unlikely at any speed, since the PPMC can't count that fast
[03:40:02] <cradek> yeah, perhaps
[03:40:10] <SWPadnos> err, since no motor is likely to spin that fast
[03:40:25] <cradek> no, you just have to be suitably close to the upcoming index when you assert index-enable
[03:40:33] <SWPadnos> true
[03:40:33] <cradek> it wouldn't be hard to hit
[03:40:55] <cradek> but as long as the firmware matches, this is ok I think
[03:41:12] <cradek> it's scary if they don't agree
[03:41:36] <SWPadnos> yeah. it's also a bit hard to follow how the indrescnt gets reset (or not)
[03:41:44] <cradek> like I said though, I think you'd get the opposite wrong behavior
[03:42:10] <cradek> I think it gets reset the first cycle when index-enable is true, then counts up after that
[03:42:16] <SWPadnos> it seems to get incremented all the time in read_encoders, reset sometimes in write_encoders, and checked other times later in read_encoders
[03:42:23] <SWPadnos> yes, I'd bet that's true
[03:42:43] <SWPadnos> that seems to be the intent anyway
[03:43:18] <cradek> the user might not recognize a sign extension problem (count changes to some nonzero value)
[03:43:47] <SWPadnos> hmmm
[03:43:53] <cradek> I bet jon e has only ever tested this with the encoder spinning one direction
[03:44:06] <SWPadnos> JonE should see that sooner, since he has higher resolution encoders
[03:44:47] <SWPadnos> I'm pretty sure I tested it in both directions, but I may not have gone to over/underflow
[03:45:01] <SWPadnos> (I ported the encoder code to HAL)
[03:45:37] <SWPadnos> maybe didn't do such a great job of it though :)
[03:46:05] <SWPadnos> I remember being confused by his logic, but I think I decided to keep it, under the assumption that it was proven correct
[03:52:01] <cradek> I know there's still a bug but it might be in firmware - I always look in this source and hope to find a smoking gun, but am always left with only an uneasy feeling.
[03:52:33] <SWPadnos> yeah. there's smoke but no identifiable fire in there
[03:54:18] <cradek> yeah, I don't spot a problem. I think it's firmware or a subtle interaction between driver and firmware (like this count-to-3 thing, whatever it means)
[03:55:05] <cradek> I hope we get plots. "delta" and "index" might be telling. they are wrapped in fewer conditionals and might be a clue.
[03:55:13] <SWPadnos> that count-to-3 thing might not be a problem if the hardware index flag still gets reset (but not the software index)
[03:55:26] <SWPadnos> it would then just wait for the next one (I think)
[03:55:28] <cradek> but you'd get a reset count
[03:55:33] <cradek> they must match
[03:55:49] <SWPadnos> yeah, I didn't see code to do this right :)
[03:55:54] <cradek> since the reset happens in hardware, not here
[03:56:09] <SWPadnos> well, keep the hardware looking, but ignore it if count<3
[03:56:39] <SWPadnos> so the hardware resets twice - big deal, the count is still correct relative to the latest index event
[03:56:43] <SWPadnos> if it did it that way
[03:56:50] <cradek> for a while hm2 set i-e false and reset its count on different but adjacent servo cycles - this was not good :-)
[03:56:59] <SWPadnos> heh
[03:57:10] <cradek> true but you got a following error on the first reset when i-e didn't clear
[03:57:37] <SWPadnos> oh, right
[03:57:38] <cradek> or maybe I'm not understanding what you're saying
[03:57:49] <SWPadnos> no, more likely I'm not understanding the full situation
[04:00:44] <cradek> ack, I should go to bed
[04:01:03] <cradek> goodnight, thanks for helping me puzzle about it
[04:02:05] <SWPadnos> sure, I like puzzling
[04:02:07] <SWPadnos> night
[06:34:27] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[06:37:37] <christel> [Global Notice] Good morning, it would appear we're experiencing some connectivity issues this morning. We're looking into it. Apologies for the inconvenience and have a good day!
[08:42:33] <micges> good morning
[08:43:25] <micges> naive cam detector can be turned off with G64P0.01 remains turn on?
[09:11:35] <alex_joni> micges: that didn't make much sense
[09:16:53] <micges> is all cam detector implemented in emccanon.cc ?
[09:17:31] <micges> after improving it in 2.3 I have huge problems resuming gcode properly :|
[09:18:50] <micges> I'll move resuming code to task soon becouse I have no other option
[09:19:22] <micges> alex_joni: I'm just complaining :)
[09:19:33] <micges> have a nice day :)
[09:19:38] <micges> bbl
[09:25:10] <alex_joni> micges: yeah, I think it's all in emcccanon.cc
[11:43:25] <jepler> alex_joni: sure it does -- it would hypothetically enable tolerance mode in the realtime motion planner, but have task not modify the motions it's presented.
[11:44:06] <alex_joni> jepler: I mean I didn't understand the sentence
[11:44:29] <alex_joni> but I understand your description
[11:44:46] <alex_joni> basicly turning off naive cam detection, but leaving tolerance mode on in the TP
[11:44:56] <jepler> alex_joni: Originally, G64P- modified just the RT planner so that it would follow the programmed path to within P- of the endpoints
[11:45:04] <alex_joni> yes, I understood now
[11:45:07] <jepler> later I added on the naive cam stuff, and used the same code to turn it on and off
[11:45:45] <alex_joni> maybe we can use G64.1 or so, to specifically turn off the naive cam detection if needed
[11:46:37] <jepler> or maybe G64 P- Q- to specify the RT tolerance and the naive cam tolerance separately
[11:48:27] <jepler> I'd consider such a patch, but if it turns out to be complicated I won't want to do it on the 2.3 branch
[11:48:36] <jepler> (it may be; I think it involves adding or changing canon calls..)
[11:52:39] <alex_joni> right
[11:55:32] <micges> yes, main problem is that task modify path
[11:56:25] <alex_joni> task?
[11:57:00] <micges> (13:43:25) jepler: alex_joni: sure it does -- it would hypothetically enable tolerance mode in the realtime motion planner, but have task not modify the motions it's presented.
[12:02:49] <alex_joni> I think jepler meant the canon part that is linked into task..
[12:04:28] <micges> err exactly :P
[12:28:04] <CIA-2> EMC: 03bigjohnt 07v2_3_branch * 10emc2/docs/src/hal/ (basic_hal.lyx pyvcp.lyx): add a link to the hal commands section
[12:30:20] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (basic_hal.lyx pyvcp.lyx): add a link to the hal commands section
[12:58:37] <zhangj> hello every body
[12:59:22] <zhangj> I am happy to meet you all!
[13:00:12] <zhangj> i read through emc tp.c these days
[13:00:52] <zhangj> feel confused by the motion blend math,is there any clear document for this?
[13:01:30] <cradek> yes there is a comment and a corresponding xfig diagram that explains it
[13:01:30] <jepler> zhangj: good morning
[13:01:39] <zhangj> good morning
[13:01:46] <zhangj> jepler
[13:03:12] <zhangj> hi cradek,i have saw the xfig diagram today,but where is the comment?
[13:03:27] <jepler> comments in the source code
[13:04:37] <zhangj> oh,thank you,i have not read it carfully
[13:08:06] <zhangj> another question is I want to watch the program running step by step,what kind of debug tool should i used?the command line GDB is now easy
[13:08:52] <jepler> you can use gdb on all parts of emc if you compile with --enable-simulator. All the "real time" code runs in the process called rtapi_app.
[13:09:59] <jepler> http://mid.gmane.org/20090120172418.GA11149@unpythonic.net
[13:12:00] <zhangj> great advice!
[14:30:40] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: unpack the unused joints.
[14:31:43] <CIA-2> EMC: 03cradek 07v2_3_branch * 10emc2/src/emc/usr_intf/axis/scripts/axis.py: unpack the unused joints.
[14:33:05] <skunkworks_> unpack? sounds like your just got back from a trip.
[14:34:05] <SWPadnos> then it would be "unpack the abused joints"
[14:40:47] <cradek> I wish there was a search on this page:
http://www.linuxcnc.org/docs/devel/html/
[14:41:09] <cradek> * cradek is giddy about a 2.3.0 release
[14:41:12] <SWPadnos> heh
[14:41:37] <SWPadnos> the overall site search would find things there, though I agree, it would be nice to have a "docs search" function there
[15:05:03] <seb_kuzminsky> good morning
[15:07:00] <cradek> hi seb
[15:07:54] <BJT-Work> hi seb
[15:08:51] <seb_kuzminsky> hi alex_joni
[15:15:54] <skunkworks_> seb_kuzminsky: a long long time ago - I saw the issue with stepgen before it was figured out that the stepgen needed accel headroom. It would go too far and reverse afew degrees
[15:16:08] <seb_kuzminsky> hmm
[15:17:04] <seb_kuzminsky> http://highlab.com/~seb/emc2/stepgen/config/broken-5i20.ini
[15:17:33] <seb_kuzminsky> [TRAJ]MAX_ACCEL is higher than [AXIS_?]MAX_ACCEL
[15:17:59] <seb_kuzminsky> they're in the same units, right? so that indicates lack of headroom?
[15:19:28] <seb_kuzminsky> [TRAJ]MAX_VELOCITY is higher than [AXIS_?]MAX_VELOCITY, too
[15:20:04] <skunkworks_> how is the max accelleration in the mesa stepgens set?
[15:20:17] <seb_kuzminsky> it's in the driver, the fpga doesnt know about accel
[15:20:44] <seb_kuzminsky> so in the servo loop, the driver commands the vel for the following servo period, and the fpga steps at that rate until the driver changes the command
[15:43:03] <cradek> seb_kuzminsky: do you have the rest of that config?
[15:43:14] <cradek> ah, yes
[15:43:39] <cradek> setp hm2_[HOSTMOT2](BOARD).0.stepgen.01.maxaccel [AXIS_1]MAX_ACCELERATION
[15:43:42] <cradek> setp hm2_[HOSTMOT2](BOARD).0.stepgen.01.maxvel [AXIS_1]MAX_VELOCITY
[15:44:05] <cradek> so the TRAJ setting is irrelevant
[15:44:54] <SWPadnos> headroom is the difference between the TP limit (AXIS_N or TRAJ setting) and the HAL driver setting
[15:44:58] <cradek> but it seems like maybe the hm2 stepgen should have some headroom over the axis constraints
[15:45:00] <SWPadnos> which is zero in this case
[15:45:07] <cradek> what is zero?
[15:45:12] <SWPadnos> headroom
[15:45:19] <cradek> right
[15:45:38] <cradek> that seems bad
[15:45:57] <cradek> stick some *1.05 in the hm2 driver?
[15:45:58] <SWPadnos> amazing what a little bit of phase lag can do to you, isn't it?
[15:46:04] <SWPadnos> ewww
[15:46:14] <cradek> ok 1.02 then
[15:46:16] <SWPadnos> heh
[15:46:54] <cradek> what's the alternative? I think the user shouldn't have to deal with this.
[15:47:22] <SWPadnos> as we saw with stepconf, if you do something automatically, the user will be surprised when things aren't the way they expect
[15:47:35] <SWPadnos> such as when the actual vel limit is 0.95* what they entered
[15:47:59] <SWPadnos> or if the machine actually moves faster than they entered (or stalls, because the number they used has something added to it)
[15:48:18] <cradek> it won't be commanded any faster than that
[15:48:23] <SWPadnos> I agree that the user shouldn't have to deal with it, but there are surprises any way you look at it
[15:48:29] <SWPadnos> true, it shouldn't be
[15:48:43] <cradek> nah, I disagree that there is a surprise
[15:48:55] <cradek> the surprise is that two limits set exactly the same fight with one another
[15:49:01] <cradek> we know which one has to be a tad higher
[15:49:26] <SWPadnos> or a tad lower
[15:49:37] <SWPadnos> we know the relationship, but not which needs to change
[15:49:56] <cradek> I also disagree with that
[15:49:58] <SWPadnos> the limit may be a mechanical one, so you don't want to command anything faster
[15:50:08] <cradek> welllll
[15:50:49] <cradek> they can probably be so close that it doesn't matter.
[15:50:54] <SWPadnos> the real issue is that if the user tells us the machine can go "this fast" we can't set the TP limits that fast due to a problem with the way EMC deals with stepper machines
[15:51:13] <SWPadnos> so the TP limit should be lower
[15:51:24] <skunkworks_> This conversation sounds vaguely familiar.. ;)
[15:51:28] <SWPadnos> which yields the surprise of "I told it 400 IPM, and I only get 380"
[15:51:32] <SWPadnos> heh
[15:52:00] <cradek> right, so you raise the other one enough that it can keep up, which is only a tiny bit
[15:52:21] <cradek> it still moves 400 +- numeric precision rounding crap
[15:52:26] <SWPadnos> except that the user who actually enters the real machine limit will be screwed
[15:52:30] <SWPadnos> (if such a user exists :) )
[15:52:47] <cradek> only by +- N.P.R.C
[15:52:59] <skunkworks_> I don't think anyone is that accurite.
[15:53:07] <cradek> yeah, that's only the usual screwage.
[15:53:35] <SWPadnos> NPRC?
[15:53:39] <cradek> I don't believe anyone can know their real machine limit to within 2% and actually runs it there
[15:53:51] <SWPadnos> that's probably true
[15:54:43] <SWPadnos> changing the HAL component is "icky" though. it assumes that the hardware is being driven by the EMC2 TP, which has this little problem ...
[15:54:45] <cradek> they come to the limits emperically and if the real motion is 1% over the number they command, it makes no difference because they will end up with an appropriate setting after testing by ear or dry-run
[15:55:34] <SWPadnos> the real error is in the way EMC2 deals with stepper systems
[15:55:49] <SWPadnos> incidentally, does the USC exhibit this problem?
[15:55:57] <cradek> I dislike when some sense of puritanism causes the user to have to deal with crap they don't actually need to
[15:56:04] <SWPadnos> oh, no it doesn't - it's a rate generator, not a positioner
[15:56:12] <SWPadnos> I can agree with that
[15:56:27] <SWPadnos> I'm not arguing that there is no problem, or that it shouldn't be fixed
[15:56:41] <cradek> sure, arguing about the best fix is fine :-)
[15:56:55] <SWPadnos> yep - I thought I was doing that. sorry if I didn't make that clear :)
[15:57:02] <cradek> as long as we agree that the best fix isn't making the user set two numbers 1% apart
[15:57:11] <SWPadnos> heh
[15:57:18] <SWPadnos> we'll call that option zero ;)
[15:57:22] <jepler> if hal could let you say 1.01*[FOO]ACCEL it'd be less bad
[15:57:31] <SWPadnos> I had that thought too
[15:57:43] <jepler> (in a hal 'setp' where a number is expected)
[15:57:45] <skunkworks_> Stepwizard does this automatically already... ;)
[15:58:02] <SWPadnos> let's get cmorley to incorporate that into pncconf, and we'll be done! :)
[15:58:19] <seb_kuzminsky> so the fix is in the hm2 driver i should set stepgen max_vel and max_accel to (1+epsilon) times what the user requested?
[15:58:24] <seb_kuzminsky> 1.01 or 1.02 maybe?
[15:58:33] <SWPadnos> that's one possible fix
[15:59:07] <SWPadnos> didn't we discuss having a "headroom" param at one point? (for software stepgen I think)
[15:59:55] <SWPadnos> that's another one - have a param that defaults to 0.02 or 0.05 or something, but someone who knows what they want can set it to zero
[16:01:41] <cradek> seb_kuzminsky: are you pretty sure this is the actual problem?
[16:05:05] <seb_kuzminsky> i have no idea if that's the problem
[16:05:35] <seb_kuzminsky> i can't reproduce it
[16:06:18] <jepler> you can't run that config without motors and look at the feedback position?
[16:06:25] <jepler> or you do, but the problem doesn't manifest?
[16:06:35] <seb_kuzminsky> jepler: i do that, and the problem doesnt manifest
[16:07:05] <jepler> is it possible this guy has old firmwares with the high step rate problem?
[16:07:06] <seb_kuzminsky> although (i just realized) i only tried X, and in this config the different axes have different maxvel & maxaccel...
[16:07:34] <seb_kuzminsky> jepler: possible, but i dont think that firmware bug would cause this problem
[16:08:12] <seb_kuzminsky> that bug resulted in slower-than-commanded speed and very large ferrors
[16:08:31] <seb_kuzminsky> the position feedback in the driver corrected for this during the decel phase
[16:08:38] <seb_kuzminsky> accel was unaffected
[16:10:51] <seb_kuzminsky> hi peter
[16:11:01] <pcw> Hi Seb
[16:11:33] <pcw> Is it possible they have steplen-stepspace set near the velocity limit?
[16:12:34] <pcw> These should really be set to the electrical limits
[16:12:35] <pcw> which should be much > the mechanical limits
[16:13:32] <seb_kuzminsky> steplen+stepspace is 6 us
[16:14:26] <seb_kuzminsky> INPUT_SCALE is 320, biggest MAX_VELOCITY is 80
[16:15:18] <seb_kuzminsky> so that's 25600 steps/second, which is 39 us/step
[16:15:23] <seb_kuzminsky> so that should be ok
[16:15:51] <SWPadnos> that would result in the stepgen not keeping up over the move, not necessarily in overshooting at the end
[16:16:12] <seb_kuzminsky> pcw: did you see the accel headroom discussion above?
[16:16:19] <seb_kuzminsky> logger_dev: bookmark
[16:16:19] <seb_kuzminsky> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2009-04-14.txt
[16:20:20] <pcw> Yes
[16:22:45] <pcw> Just guessing about why you cant reproduce the problem
[16:22:47] <pcw> (5I20 uses PCI clock for stepgen and it can vary from system to system)
[16:23:08] <seb_kuzminsky> oh, right
[16:32:29] <BJT-Work> hi pcw
[16:35:46] <pcw> Hi BigJohn
[16:36:52] <BJT-Work> I got the THC hooked up to the 5i20 last weekend
[16:37:15] <BJT-Work> works real slick
[16:38:28] <BJT-Work> got a good start on the THC component too...
[16:38:33] <BJT-Work> * BJT-Work is off to lunch
[16:38:40] <pcw> Did you ever get the software counting to work?
[16:39:00] <BJT-Work> no, not past about 3 volts
[16:39:49] <pcw> At the slowest rate (1/128) you would need a 16 KHz base thread to count the max frq
[16:40:55] <BJT-Work> I don't remember what that config was running at
[16:40:59] <pcw> (I blame SWP)
[16:42:01] <SWPadnos> yep, my fault
[16:42:01] <pcw> he _assured_ me that 8KHz was not too fast
[16:42:08] <SWPadnos> what are you talking about though?
[16:42:13] <BJT-Work> I graphed the voltage/freq with the 5i20 and it is straight from 0 vdc to 10vdc input
[16:42:56] <pcw> The V-F should be linear to 12 bits or so
[16:43:18] <BJT-Work> I checked 1/128 and 1/64 and they were perfect as far as I could tell
[16:43:50] <BJT-Work> I did have a lab power supply to feed the input so it should be close
[16:44:29] <pcw> Yes thats Sebs good work on HM2s velocity output
[16:44:30] <pcw> I didnt think the lower rates would work as well
[16:44:45] <cradek> is this an adc for m5i20?
[16:44:50] <BJT-Work> I went with a full PID in the THC comp
[16:45:15] <BJT-Work> I still need to check the 1/32 and 1/1
[16:45:47] <BJT-Work> voltage to freq board cradek
[16:46:14] <seb_kuzminsky> pcw: i was thinking about hacking on hm2/spi at fest (mid may)
[16:46:22] <pcw> Its a V-F converted being fed into the encoder input and using the velocity out
[16:46:23] <seb_kuzminsky> mostly for the reprap folks
[16:46:24] <pcw> as the Analog
[16:46:54] <BJT-Work> * BJT-Work is heading to lunch
[16:46:54] <pcw> SPI is big unforch
[16:47:06] <BJT-Work> talk to you guys later
[16:47:08] <pcw> Bye BJT
[16:47:08] <cradek> so the point is to have adc - just v-f is the way to accomplish it?
[16:47:17] <pcw> Yes
[16:47:21] <cradek> neat.
[16:47:54] <cradek> would be fun to play with edm using that
[16:48:01] <pcw> Its a AD7740 V-F with one of ADs isolator+power
[16:48:39] <pcw> So its got 2500V common mode range :-)
[16:49:36] <pcw> (and only ~2 pf input output capacitance)
[16:50:09] <cradek> wonder if I could use my lathe for sinker edm. wonder if the spindle rotation and cutting oil circulation would work for flushing.
[16:51:03] <cradek> nah - surely if that worked, someone would have done it already
[16:52:20] <pcw> cradek: You dont want the EDM return current going through your spindle bearing!
[16:53:09] <cradek> well that's definitely true
[16:55:36] <pcw> Seb: do you want a 7I65 to use as a SPI guinea pig?
[16:56:52] <pcw> cradek: ever seen pictures of ball bearings "EDMed" by 60 cycle leakage current?
[16:57:45] <seb_kuzminsky> the 7i65 and the 7i64 are the two boards that have SPI on them, and the 7i64 is all digital right?
[16:58:08] <cradek> wow, that's twice the 7i33 on one plug?
[16:59:23] <pcw> Yes 7I64 is 24out and 24 in isolated I/O
[16:59:25] <pcw> 7I65 is 8 axis servo interface (with 16 bit SPI DACs)
[16:59:39] <cradek> woo
[17:00:26] <seb_kuzminsky> pcw: the 7i65 has some SPI ADCs too, right? that's what the reprap guys want
[17:00:54] <seb_kuzminsky> might have been useful for john too
[17:01:01] <pcw> Yes one 8 channel 12 bit ADC
[17:01:38] <seb_kuzminsky> ok cool, yes please send me one of those and i'll take a look at it at fest
[17:01:47] <cradek> I can't keep up with your cool new products.
[17:02:02] <pcw> The V-F is probably more suitable for noisy THC type applications
[17:02:16] <seb_kuzminsky> the spi doesnt need any special cables, it just runs over the 50-pin ribbon, right?
[17:02:43] <pcw> Yes 50 pin (Ive tried 15 feet)
[18:05:29] <jepler> cradek: thanks for fixing that unpack duh
[18:05:42] <cradek> np
[18:08:58] <alex_joni> hi guys
[18:12:12] <BJT-Work> hi alex
[19:13:37] <alex_joni> seb_kuzminsky: still around?
[19:13:49] <alex_joni> can you put the halscope.cfg somewhere online?
[19:14:04] <alex_joni> the one you used for tracking the stepgen issue
[20:52:14] <seb_kuzminsky> alex_joni: the computer i have it on is powered off at home, i'm at work
[20:52:22] <seb_kuzminsky> i can dig it up this evening
[20:54:40] <seb_kuzminsky> alex_joni: i finally noticed that his configs are different for the different axes, and i only tested X
[20:54:58] <seb_kuzminsky> do you know which axis/axes he's having the overshooting problem on?
[20:55:53] <SWPadnos> one other thing I noticed. I don't know if his information is more specific, but "55% FO" could mean 55% of normal, or 155% of normal
[20:56:13] <seb_kuzminsky> hmm, right
[20:56:19] <cradek> what a lousy bug report
[20:56:28] <SWPadnos> I can imagine some issue at > 1.5x speed much easier than I can imagine it at >0,5x
[20:56:41] <SWPadnos> well, that's a summary I think
[20:56:46] <SWPadnos> a summarized translation even :)
[20:56:54] <cradek> regardless of the FO setting emc will never command motion above the ini settings
[20:57:58] <SWPadnos> sure. I'm just imagining bugs in the free planner (that's used for jogs, right?) being more likely at >1x FO rather than <1x
[20:59:53] <seb_kuzminsky> i tested "g0" moves with F set to 60*MAX_VEL, that worked fine
[21:00:52] <jepler> I thought the bug report was about jogging ?
[21:01:23] <seb_kuzminsky> jepler: it is - i didnt realize at the time that jogging and traversing used different planners :-/
[21:02:20] <seb_kuzminsky> i'm not sure if it's a planner issue or a hostmot2 issue
[21:11:18] <seb_kuzminsky> oh, also i didnt know it was a jogging-only bug until i told the reporter i couldnt reproduce it...
[21:11:51] <seb_kuzminsky> it's been... frustrating
[21:26:07] <alex_joni> seb_kuzminsky: I'll try to drag him in here ;)
[21:26:18] <alex_joni> might be easier, or send your email to him
[21:26:30] <seb_kuzminsky> i dont speak any german :-(
[21:26:35] <alex_joni> he doesn't have the issue with 2.2.8 though
[21:26:40] <seb_kuzminsky> swedish or english would work
[21:26:53] <alex_joni> I hope he can speak a bit of english :)
[21:28:51] <seb_kuzminsky> i'll be here for another 1.5 hrs about, then again in about 5 or 6 hrs
[21:29:40] <alex_joni> it's after midnight here, and after 11pm in germany
[21:29:46] <alex_joni> so probably tomorrow
[21:29:55] <seb_kuzminsky> sounds good
[21:30:04] <seb_kuzminsky> thanks for being the middle man
[21:30:19] <alex_joni> sure thing, too bad I can't be a better one ;)
[23:13:52] <jmkasunich> I haven't finshed reading yet, but the idea of a HAL driver multiplying something you give it by 1.05 makes me see read
[23:13:55] <jmkasunich> red even
[23:19:05] <jmkasunich> a component should do what it says it will do, the guy who puts them together is responsible for making sure they play well together
[23:23:04] <SWPadnos> I think I'm in agreement there
[23:23:29] <SWPadnos> if motion has a problem with stepgens, then it should fix itself or leave the fixing to the integrator