Back
[02:14:41] <jepler> Condit says that it's something besides the acceleration
[02:14:43] <jepler> *grumble*
[02:15:41] <cradek> it seems like it would be easier for him to troubleshoot it than you
[02:15:54] <jepler> indeed
[02:15:59] <cradek> for me I was convinced something was broken, but it turned out I was wildly wrong about the timing specs I gave it
[02:16:09] <cradek> without doublestep, you didn't have to care about those
[02:16:14] <cradek> now, it's critical
[02:16:31] <jepler> I looked but did not find useful information on the breakout board and stepper driver he says he's using
[02:18:23] <cradek> hmm.
[12:45:25] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/hal/ (10 files): French translation
[12:45:33] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/ (Master_HAL_fr.lyx Submakefile index.tmpl index_fr.tmpl): French translation
[13:16:18] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/Master_User_fr.lyx: French translation update
[13:48:50] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/Master_User_fr.lyx: French translation update
[13:48:51] <CIA-42> EMC: 03tissf 07v2_2_branch * 10emc2/docs/src/gcode/main_fr.lyx: French translation update
[13:55:18] <CIA-42> EMC: 03tissf 07TRUNK * 10emc2/docs/src/gcode/main_fr.lyx: French translation update
[14:24:40] <skunkworks> video?
[14:48:04] <alex_joni> huh?
[14:49:24] <skunkworks> cradek had mentioned that he had made a video I think..
[14:49:40] <skunkworks> morning - how is the fretting? ;)
[14:50:09] <alex_joni> boring
[14:50:35] <skunkworks> eh
[14:50:36] <skunkworks> heh
[14:56:06] <cradek> skunkworks: I haven't pulled it off the camera yet ...
[14:56:10] <cradek> let me describe it:
[14:56:17] <cradek> it's roughing passes
[14:56:20] <cradek> it's making a lot of noise
[14:56:24] <cradek> it's probably out of focus
[14:56:32] <cradek> ok, now you don't have to watch it
[14:57:46] <cradek> for parts of it I was messing with the coolant nozzle, making sure it stayed pointed at the tool, and I forgot to keep the camera pointed in the right place :-)
[14:58:49] <alex_joni> bring it on
[14:59:17] <cradek> hm they're forecasting -10F windchills tomorrow
[14:59:24] <cradek> I didn't think it would get cold yet
[14:59:35] <alex_joni> ouch
[14:59:39] <cradek> (-23C)
[14:59:51] <cradek> I now have 4 space heaters in the shop :-)
[15:00:07] <cradek> surprisingly I can put two on a 20A circuit
[15:00:57] <cradek> oh I guess that's no surprise, that's only 3kW
[15:01:16] <cradek> err
[15:01:21] <cradek> * cradek struggles with very basic math
[15:01:39] <cradek> * cradek should go back to bed
[15:01:40] <skunkworks> heh - we have about 12 inches of snow here. The last few years - we wouldn't have snow until after christmas
[15:02:23] <cradek> feels like this will be a long winter
[15:06:01] <jepler> all this clearly proves global warming wrong....
[15:08:38] <skunkworks> my very right wing coworker thinks it is caused by solar cycle. (and every time we have a cold snap - say exactly what jepler said)
[15:09:22] <fenn> * fenn thinks global warming should be put in the same category as abortion and gun control
[15:09:56] <cradek> there are several categories that seem appropriate...
[15:10:27] <fenn> things you shouldn't bring up in an irc channel unless you want to have an argument about it
[15:10:31] <cradek> hot-button issues that can be exploited to get simple people to vote for you?
[15:10:51] <skunkworks> good point
[15:11:02] <cradek> things for people to rant about on AM radio?
[15:11:09] <fenn> same thing really
[15:12:01] <cradek> personally I wonder whether congress considered the effect extending DST would have on global warming
[15:12:19] <cradek> if you add it up, that's a lot of extra hours of sunlight...
[15:12:34] <jepler> that's a very good point
[15:12:35] <skunkworks> People that are at the extreme - are really easy to egg on... I have a hell of a lot of fun with my coworker..
[15:12:43] <cradek> I should see if I can get on some AM radio show.
[15:12:49] <fenn> maybe coast to coast AM
[15:13:33] <cradek> I hope we're making fun of everyone equally - at least that was my goal
[15:13:42] <skunkworks> same here
[15:16:01] <cradek> jepler: I, uh, blamed the users who are having trouble with stepconf, so you don't have to
[15:18:06] <jepler> cradek: great, I appreciate it.
[15:18:49] <skunkworks> I tried to use stepconf to hook up my servos - It doesn't work.
[15:18:59] <cradek> and if my guess is wrong, maybe we'll get more information.
[15:22:12] <alex_joni> skunkworks: *step*conf
[15:22:23] <skunkworks> whatever ;)
[15:22:25] <cradek> on another topic, I actually saw a bug in autocad 12 last night. I was in an iso view and tried to 'move' something and it didn't move. when I changed the view, it worked.
[15:23:07] <cradek> like anyone cares
[15:23:14] <cradek> but I was shocked
[15:23:31] <alex_joni> heh
[15:52:53] <skunkworks> huh - I used 12 for years and I can't think of any bugs.
[15:52:56] <skunkworks> funny
[16:52:47] <fenn> whew. finally got pygtk+cairo playing together
[16:53:05] <fenn> now looking back on it i cant even figure out what i was doing wrong in the first place
[16:53:46] <fenn> expecting the tutorial code to work is never a good idea
[17:27:20] <jmkasunich> 22 passes of memtest, 11+ hours, no problems - looking good after reseating the memory dimms
[17:27:54] <SWPadnos> RIMMs
[17:27:55] <SWPadnos> :)
[17:28:05] <jmkasunich> :-P
[17:28:09] <SWPadnos> heh
[17:28:37] <jmkasunich> time to figure out how to mount it in the box
[17:28:47] <jmkasunich> I'm leaning toward old hard drive magnets ;-)
[17:29:06] <SWPadnos> I thought magnetism+metal machining was a bad equation
[17:29:06] <skunkworks_> I thought you had already mounted it in the box. (motherboard)
[17:29:08] <jmkasunich> (since I'm still not 100% sure I'm gonna stick with this PC, and a replacement would be physically different
[17:29:18] <SWPadnos> heavy duty velcro
[17:29:41] <jmkasunich> this is how the PC looks now:
http://jmkasunich.com/cgi-bin/blosxom/shoptask/pc-panel-12-27-06.html
[17:29:47] <SWPadnos> and just put the mini-tower on the bottom of the enclosure
[17:29:59] <SWPadnos> oh, right
[17:30:22] <SWPadnos> that's a tiny motherboard (depth-wise)
[17:30:24] <jmkasunich> that mobo is 1" narrower than standard ATX
[17:30:29] <skunkworks_> ah - that is what I remember
[17:31:03] <jmkasunich> so I don't want to drill any holes in the oiltite main box that are unique to that package
[17:31:25] <jmkasunich> (of course I cut a gaping huge hole in it last night, 4x7")
[17:31:41] <SWPadnos> ouch - what's that for?
[17:31:48] <jmkasunich> wires in and out
[17:32:04] <jmkasunich> eventually I'll cnc machine a panel to cover it, with nice holes for connectors and such
[17:32:07] <SWPadnos> oh, just sticking a grommet strip around the edge and using the hole like a conduit?
[17:33:00] <jmkasunich> its a lot easier to mill d-shell connector slots in a 5 x 8 x 1/8 aluminum than in the side of a 24 x 30 x 10 steel box
[17:33:21] <jmkasunich> and easier to replace if I screw it up ;-)
[17:33:28] <SWPadnos> heh
[17:33:41] <SWPadnos> and much less expensive than getting the hydraulic punch/die for a D-sub
[17:36:25] <skunkworks_> I have some small network switches attached to metal trusses with velcro...
[17:36:59] <skunkworks_> * skunkworks_ is thinking hot glue.. ;)
[17:38:16] <jmkasunich> I have a nearly full roll of double sided tape, and quite a few hard disk magnets.....
[17:39:00] <jmkasunich> what is it with the non-standard mobos....
[17:39:17] <jmkasunich> I just opened up an old gateway tower that I had sitting here.. it has a narrow mobo too
[17:39:33] <jmkasunich> (but it has mounting provisions and space for a regular one
[17:39:36] <SWPadnos> the bottom plate looks to be about the same thickness as a motherboard - you could use a couple of motherboard standoffs (or screws) to hold it up, and velcro/double-stick tape/magnets to tack it in place
[17:40:24] <SWPadnos> if you change motherboards, the support posts are still useful, as long as you leave enough room above them for a normal-sized motherboard
[17:40:37] <alex_joni> jmkasunich: hi
[17:40:50] <alex_joni> seen the report by buckie555 in #emc?
[17:41:07] <alex_joni> he's having some big troubles with index-homing and m5i20 on emc2.2.x
[17:41:23] <jmkasunich> alex_joni: yeah, I saw that
[17:41:39] <alex_joni> sounds to me like the counters don't get reset.. or something like that
[17:41:48] <jmkasunich> I'm very confused that it works for two axes but not the third
[17:41:50] <alex_joni> I looked at motion, and can't see any difference from 2.1 to 2.2
[17:41:55] <alex_joni> it doesn't work for 2 axes
[17:42:11] <alex_joni> he didn't even try X & Y.. those would cause even greater issues
[17:42:25] <jmkasunich> I'm also incredibly rusty about that stuff, and would have to go back to square one and come up to speed
[17:42:41] <alex_joni> darn.. was hoping you know a bit more than me
[17:43:09] <jmkasunich> ISTR the issue is that when the encoder sees an index, it's position takes a huge step
[17:43:28] <jmkasunich> therefore the commanded position also needs to take a huge step, to prevent the runaway
[17:43:35] <alex_joni> right
[17:43:47] <alex_joni> but I think in this case only the commanded position takes the step
[17:43:56] <alex_joni> and the m5i20 driver actually doesn't reset the counter
[17:44:04] <jmkasunich> why not?
[17:44:10] <alex_joni> (I could only see differences in the driver.. not in motion)
[17:44:43] <jmkasunich> oh. you mean "I think the bug is that the driver doesn't reset the counter"
[17:44:57] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_m5i20.c.diff?r1=1.12.2.3;r2=1.17;f=h
[17:45:28] <alex_joni> (left is 2.1.x, right is 2.2.x)
[17:46:15] <jmkasunich> ok, rust is showing - I thought we made m5i20 canonical for 2.1?
[17:46:35] <jmkasunich> like at the workshop, or around that time
[17:47:06] <alex_joni> I think so too..
[17:47:19] <alex_joni> but it's a different thing than 2.2
[17:47:25] <jmkasunich> that diff is on the 2.1 branch
[17:47:43] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_m5i20.c?graph=1
[17:47:58] <jmkasunich> I was just looking at that ;-)
[17:48:29] <jmkasunich> petev made to commits to the trunk (and thus 2.2) that aren't in the 2.1 branch
[17:48:43] <alex_joni> yes
[17:48:47] <alex_joni> I saw that too
[17:49:23] <jmkasunich> wtf - petes changes are before the changes that I did to the branch in june
[17:49:56] <jmkasunich> I touched trunk on 6/22 and 2.1 branch on 6/25
[17:50:22] <jmkasunich> but apparently in different ways, because in petes stuff is in trunk and not branch
[17:50:54] <jmkasunich> (I have no idea what, if any, difference there _should_ be between trunk and 2.1
[17:51:11] <jmkasunich> considering that 2.1 has the most recent work, its probaby more "right" than anything else
[17:51:25] <alex_joni> and it's working for at least a user :)
[17:51:34] <fenn> mostly
[17:51:37] <jmkasunich> unless 2.1 was constrained by some "bugfix only" rule
[17:52:14] <jmkasunich> I guess I should diff trunk against 2.1
[17:52:24] <alex_joni> the 2.1 didn't change pin names
[17:52:34] <alex_joni> (e.g. it uses -reset-count, not -reset)
[17:53:05] <alex_joni> jmkasunich: the first link I gave you was 1.7 (latest trunk) against 1.12.2.3 (latest 2.1-branch)
[17:53:17] <jmkasunich> updating both my checkouts, will diff in a moment
[17:53:20] <jmkasunich> oh
[17:53:21] <jmkasunich> duh
[17:54:41] <alex_joni> note: I'm not 100% sure it's not an issue somewhere else..
[17:56:16] <jmkasunich> I sure don't see anything in that diff that would make index work differently
[17:56:58] <jmkasunich> unless the control register is affected by the difference between a short (signed I assume) and a u16
[17:57:31] <jmkasunich> the only index related thing in there is a comment
[17:58:50] <jepler> I don't see the equivalent to this on the 1.7 revision: *(pEncoder->pResetCount) = 0;
[17:59:10] <jmkasunich> that is reset, not index
[17:59:30] <jepler> oh, hm
[17:59:46] <jmkasunich> the correct behavior of reset is "when pin is active, output is zero"
[18:00:05] <jmkasunich> the old behavior was "when pin goes active, set output to zero and set pin inactive"
[18:00:20] <jmkasunich> but homing doesn't (shouldn't) use reset, it should use index
[18:01:27] <jmkasunich> heh, I know why I'm getting a bit confused by this
[18:01:46] <jmkasunich> I worked on the same area of the ppmc driver at the workshop
[18:01:53] <jmkasunich> and the two are blurring together
[18:03:03] <jepler> seems like we did something for every board while we were there -- wasn't there something wrong on motenc as well?
[18:03:14] <jmkasunich> probably
[18:03:25] <jmkasunich> thats what is in the mazak, so at least we tested that one
[18:03:44] <jmkasunich> the revs I made to 5i20 (on both trunk and 2.1) are actually after the fest I think
[18:04:01] <jmkasunich> 6/22 and 6/25, wasn't the fest the week before?
[18:04:06] <jepler> dunno
[18:04:10] <jepler> that was a long time ago
[18:04:47] <jmkasunich> 6/22 was a friday. and 6/25 was monday - at least one of them wasn't at the fest
[18:05:03] <jmkasunich> I think the fest was the week of 6/11 - 6/15?
[18:06:00] <jmkasunich> yep: google says "Third Annual CNC-Workshop ( June 11-17, 2007 ) Galesburg, Illinois, USA"
[18:06:26] <jepler> bbl
[18:06:38] <jmkasunich> hmm, there seems to be an encoder on my bench
[18:06:52] <jmkasunich> it even seems to be wired to a 50 pin ribbon breakout
[18:06:58] <jmkasunich> and a ribbon is connected to that
[18:08:17] <jmkasunich> I guess that is what I was working on after the fest
[18:08:36] <jmkasunich> that period of my life is a bit blurry
[18:10:33] <jmkasunich> alex_joni: you there, or am I mumbling to myself?
[18:14:45] <jmkasunich> there is one other place where 2.2 and 2.1.7 differ
[18:14:50] <jmkasunich> the bitfiles are NOT the same
[18:15:37] <jmkasunich> * jmkasunich stops caring
[18:17:17] <alex_joni> jmkasunich: sorry.. back now
[18:17:30] <jmkasunich> the bitfiles are a mess
[18:17:40] <alex_joni> * alex_joni reads back
[18:17:46] <jmkasunich> there is one bitfile embedded in the code (an autogenerated .h file)
[18:17:57] <jmkasunich> there are other bitfiles that can be loaded manually
[18:18:40] <jmkasunich> and those "other" files don't match from 2.2 to 2.1 - pete "moved" them from one dir to another, but the files in the new dir don't match the files in the old dir, so it must be more than just a move
[18:18:50] <alex_joni> yuck
[18:19:05] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/m5i20/README.txt?rev=1.3
[18:19:57] <alex_joni> so hostmot5_4.bit is the one to use?
[18:20:09] <jmkasunich> I have no clue
[18:20:32] <jmkasunich> I have resolved to never personally use any of the old configs, I'm doing my own fpga work (someday)
[18:20:50] <jmkasunich> but I guess that isn't a very helpfull attitude
[18:21:09] <alex_joni> well.. if buckie show up, maybe he brings a halscope snapshot
[18:21:32] <jmkasunich> I'm almost certain that all coding and testing I did was using the "embedded" configuration
[18:21:44] <jmkasunich> but almost certain, and completely certain, are two different things
[18:22:01] <jmkasunich> I also don't know if the embedded config changed from 2.1 to 2.2
[18:22:11] <alex_joni> doesn't seem like it
[18:22:18] <alex_joni> (it's in m5i20.c .. right?)
[18:22:30] <jmkasunich> don't think so, lemme check a few things
[18:26:56] <jmkasunich> the embedded bitfile is in src/drivers/hal/m5i20_HM5-4E.h, and is not the same between the two versions
[18:27:05] <alex_joni> jmkasunich: after looking at
http://www.freedrive.com/files/8il35w2d5sowc/HomingWithIndex.png I don't think it's in the driver anymore
[18:28:01] <jmkasunich> emc isn't stepping the output position
[18:28:26] <alex_joni> yes
[18:41:56] <alex_joni> I'm puzzled by this change:
[18:42:07] <alex_joni> < pCard16->encoderControl[i] |= M5I20_ENC_CTL_LOCAL_CLEAR;
[18:42:19] <alex_joni> > pCard16->encoderControl[i] = pEncoder->control | M5I20_ENC_CTL_LOCAL_CLEAR;
[18:47:28] <alex_joni> I'm tempted to tell him to try a 2.1 driver
[18:49:07] <jmkasunich> the 2.1 driver contains differnet FPGA bits and different code - probably worth trying
[18:49:22] <alex_joni> I'm extrating the .ko, so it's easy for him
[18:49:42] <cradek> what log went with that change?
[18:50:03] <jmkasunich> which change?
[18:50:04] <alex_joni> cradek: lots of logs.. :/
[18:50:13] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_m5i20.c?graph=1
[18:51:10] <jmkasunich> the change that you posted a few lines back - where is that one?
[18:51:18] <jmkasunich> (from version ? to version ?)
[18:51:31] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_m5i20.c.diff?r1=1.12.2.2;r2=1.12.2.3
[18:51:49] <cradek> that was you fixing index at fest I think
[18:51:59] <cradek> but only on the branch...?
[18:53:17] <jmkasunich> +// write control word to hardware only if changed
[18:53:17] <jmkasunich> +if ( pEncoder->control != old_control ) {
[18:53:17] <jmkasunich> + pCard16->encoderControl[i] = pEncoder->control;
[18:53:40] <jmkasunich> after fest, by a week or two
[18:54:12] <cradek> the 2.2.2 and 2.1.7 drivers are virtually the same I think
[18:54:20] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/hal_m5i20.c.diff?r1=1.12.2.3;r2=1.17
[18:54:30] <cradek> the only difference is something about reset that he's probably not using
[18:54:41] <jmkasunich> the driver _code_ is the same, except for the behavior of the reset line (which doesn't matter)
[18:54:52] <cradek> right
[18:54:59] <cradek> so why are you having him try the other version?
[18:55:12] <jmkasunich> the embedded firmware that is part of the driver is not the same
[18:55:21] <cradek> oh ok
[18:55:27] <cradek> this is why I asked here...
[18:55:33] <alex_joni> :-)
[18:55:56] <cradek> how do we diff the firmware?
[18:56:17] <jmkasunich> I wonder if we should have him explicitly load fpga code and then use "loadFpga=0" to avoid overwriting it with the embedded version
[18:56:26] <jmkasunich> instead of having him swap around .ko files
[18:58:05] <jmkasunich> cradek: we can't diff the firmware very well
[18:58:13] <jmkasunich> other than doing binary compares
[18:58:32] <jmkasunich> the .h file that contains the embedded version is created during build, and not in cvs
[18:58:39] <jmkasunich> it is created from a .bit file which is binary
[18:59:20] <jmkasunich> I'm not sure the vhdl to bit process is deterministic, so it might be possible to have two bit files created from the same source which work the same, but don't pass a binary compare
[18:59:44] <cradek> I didn't ask what I meant to ask. I meant how can we see the difference at the firmware source level between the two firmwares?
[19:00:02] <jmkasunich> I'm not sure
[19:00:15] <alex_joni> I think index-enable will shed more light
[19:00:25] <jmkasunich> the source is in cvs, but its been moved around and stuff has been renamed, so....
[19:00:39] <cradek> argh
[19:00:48] <jmkasunich> and we don't know exactly what pile of source peterw created the bit files from, we only hope it is the committed source
[19:01:19] <jmkasunich> this is why I don't like the existing system, and I want to have vhdl to bitfile capability as part of our makefiles
[19:01:27] <jmkasunich> (assuming you have the xilinx tools installed)
[19:01:47] <cradek> that would be ideal.
[19:03:14] <alex_joni> * alex_joni goes back to some more fretting
[19:03:55] <jmkasunich> * jmkasunich goes back to pondering PCs and the mounting thereof
[19:04:32] <cradek> * cradek goes back to laying out holes
[19:05:25] <alex_joni> groundhog day?
[19:07:37] <jmkasunich> alex_joni: are yo ustill here, or fretting already
[19:08:25] <jmkasunich> I looked at his scope log, home-state transitions from 16 (looking for index) to 18 (start final move) at the same time as the feedback goes to zero
[19:08:31] <jmkasunich> so emc must be seeing index-enable fall
[19:08:47] <jmkasunich> there is nothing on the index pin at that instant - his sample rate is too slow to see it
[19:09:05] <jmkasunich> the pulse on index happens later, when state is 19 (final move in process)
[19:40:16] <alex_joni> jmkasunich: I am around now
[19:42:30] <alex_joni> jmkasunich: that would mean it's a problem inside the motion controller?
[19:43:05] <alex_joni> or maybe index-enable gets reset by the m5i20, before the feedback position gets set to 0 ?
[19:43:23] <alex_joni> I think this should be visible with sim too, if it would be only a motion controller issue
[20:00:56] <jmkasunich> I'm gonna wait for better data
[20:10:38] <alex_joni> * alex_joni is tired of fretting
[21:30:26] <tissf_> tissf_ is now known as tissf
