Back
[00:00:39] <jmkasunich2_> at 120 ipm, 2 ips, which should be 101600 steps/sec, I get 103 KHz
[00:00:53] <jmkasunich2_> close enough given my instrumentation
[00:01:19] <mshaver> built in freq readout? or counting boxes?
[00:01:24] <jmkasunich2_> cursors
[00:01:56] <mshaver> * mshaver doesn't have cursors :(
[00:02:05] <jmkasunich2_> at 150 ipm, 2.5 ips, 127 KHz, I get 127 KHz
[00:02:15] <mshaver> * mshaver is lucky to have triggered sweep!
[00:02:38] <jmkasunich2_> but there is clear deviation between the command and the feedback - the driver is over-driving the command to make the actual go where it should
[00:03:47] <jmkasunich2_> at 180 ipm 3 ips 152400 Hz, the output is only 132.3 Khz, the driver no longer has enough headroom to push it any higher
[00:03:57] <jepler> hm, git's not perfect:
[00:03:58] <jepler> #copied: demo/AVR/demo.c -> demo.c
[00:03:58] <jepler> #renamed: demo/AVR/demo.c -> excoils.c
[00:03:58] <jepler> #deleted: demo/AVR/excoils.c
[00:04:51] <jepler> (turns out that demo.c and excoils.c are fairly similar files)
[00:07:22] <mshaver> can we lie to the stepgen about steplen or space to get the right output?
[00:07:52] <jmkasunich2_> if you are desperate to get something working for a deadline, yes
[00:08:03] <jmkasunich2_> at risk of maybe violating drive timings
[00:08:11] <mshaver> no i'd rather have it be right
[00:08:23] <jmkasunich2_> well, I have a scope, so I can check...
[00:08:31] <mshaver> i won't ship it till it's right
[00:08:52] <jmkasunich2_> when do you ship?
[00:08:59] <mshaver> jan
[00:09:07] <jmkasunich2_> I understand you leave there soon (tomorrow)? and return later
[00:09:19] <mshaver> we have one sold, but I won't let it out until I'm happy
[00:09:23] <jmkasunich2_> if there are benefits to running it in between then with a hack, then lets try that
[00:09:39] <mshaver> yep, I leave thurs & come back after new years
[00:10:05] <mshaver> not really, I'm the only one here who can run it anyway
[00:10:17] <jepler> bbl
[00:10:37] <mshaver> I just figured if we lied to it, and it worked, seb would have a clue of what to do
[00:10:48] <mshaver> see you Jeff!
[00:10:53] <jmkasunich2_> the easiest thing would be to config the max veloity to 2.5 ips (150 ipm)
[00:11:08] <jmkasunich2_> I can give seb far better clues than you can at this point
[00:11:31] <mshaver> true, but that's less than it's capable of
[00:11:39] <jmkasunich2_> actually, I can do better
[00:11:40] <mshaver> i _agree_ with you!
[00:11:50] <mshaver> you are much father along
[00:11:55] <jmkasunich2_> set hm2_5i20.0.stepgen.0x.stepspace to 100
[00:11:58] <mshaver> farther
[00:12:28] <mshaver> is stepspace the "high" time?
[00:12:28] <jmkasunich2_> as long as max velocity is set right (3.93, 3.75, whatever) it won't make bad pulses, but it will let you get to 200KHz
[00:12:36] <jmkasunich2_> no, it is the time between steps
[00:12:57] <jmkasunich2_> high/low is another issue, you need to invert or not depending on your drive requirements
[00:13:07] <mshaver> steps being low to high transitions
[00:13:07] <jmkasunich2_> step-len is the length of a pulse, fixed
[00:13:18] <mshaver> got you
[00:13:33] <jmkasunich2_> step-space is the minimum space between pulses, which can be much longer at low speed, and infinite when stopped
[00:13:48] <mshaver> I can set those timings, then scope & adjust polarity
[00:14:12] <jmkasunich2_> as is, I have 2.5uS high going pulses, with variable low times between them
[00:14:26] <jmkasunich2_> with step-space set to 100nS, I can get 200KHz
[00:14:29] <jmkasunich2_> lemme try a few other values
[00:14:39] <mshaver> it should be the other way around (polarity wise)
[00:14:53] <mshaver> constant low time, variable high
[00:15:07] <jmkasunich2_> then you gotta invert - I think the 5i20 can do that, but I don't know for sure, and it is unrelated to this problem, so I don't really care ;-)
[00:15:26] <mshaver> but I'm driving the inputs with rs422, so I'll have to see what's out there
[00:15:27] <jmkasunich2_> I will care, since I'll soon be driving some geckos that need the same thing
[00:15:54] <jmkasunich2_> I'm describing the signal in the ribbon cable, you may get lucky and have inversion in hw already
[00:15:59] <jmkasunich2_> btw, I lied
[00:16:11] <jmkasunich2_> stepspace = 100 gives you just short of 200KHz
[00:16:22] <jmkasunich2_> stepspace = 10 lets you get all the way to 200
[00:16:38] <mshaver> good!
[00:17:03] <mshaver> and, maybe, seb/peter will fix this in the mean time
[00:17:22] <jmkasunich2_> they will
[00:17:26] <jmkasunich2_> I'll beat on them
[00:17:35] <mshaver> you'll really like it - it's the smoothest sounding stepper machine I've ever heard
[00:18:03] <jmkasunich2_> I don't care about smithy's machine - I want to convert my own machine (geckos) from software stepping to 5i20
[00:18:16] <jmkasunich2_> that is one of my "christmas break" projects
[00:18:25] <mshaver> that's what I mean
[00:18:46] <jmkasunich2_> well, my geckos are 10x microstepping, and that won't change
[00:18:50] <jmkasunich2_> you are using different drives
[00:18:58] <mshaver> true
[00:19:17] <mshaver> you could gear down if that would buy you anything
[00:19:34] <mshaver> use the whole drive bandwidth
[00:19:53] <mshaver> I think Geckos are 200kHz too
[00:19:54] <jmkasunich2_> my only problem to date has been a few X stalls (in lathe mode)
[00:20:15] <jmkasunich2_> I dunno if that was too much torque for the motor, or a realtime hit of some kind messing up the step sequence, or too much accel, or....
[00:20:40] <mshaver> it's freezing in the shop and I get stalls until the oil flows
[00:21:03] <jmkasunich2_> my other break project is just playing around with some servos
[00:21:17] <mshaver> analog drives?
[00:21:20] <jmkasunich2_> I have a 7i40 amp, a motor, and just got encoder yesterday
[00:21:33] <jmkasunich2_> 7i40 is pwm from fpga direct to power devices
[00:21:37] <jmkasunich2_> 80V 7A cont
[00:21:57] <jmkasunich2_> the motors are 38V nominal, 3-4A cont, 12A peak, I'm gonna use a 48V supply
[00:22:05] <mshaver> nice! that's the high tech way to do it
[00:22:20] <jmkasunich2_> $149 for two channels on a board about the size of a gecko
[00:22:28] <jmkasunich2_> peter makes some nice stuff
[00:22:41] <mshaver> He really does.
[00:23:15] <mshaver> SWP talked me into using the 5i20 instead of parallel ports and I'm so glad he did.
[00:23:39] <jmkasunich2_> I think it is time for dinner - I'll be back later
[00:24:03] <mshaver> THANKS! It's snowing here, so I'm going to head back to my room.
[00:24:18] <mshaver> I'll be on tomorrow!
[00:37:59] <jmkasunich2_> hi PeterW
[00:39:07] <jmkasunich> I'm in the middle of cooking dinner, I have about 10 mins, then I'm off again for a bit
[00:39:18] <jmkasunich> logger_dev: bookmark
[00:39:18] <jmkasunich> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-12-17.txt
[00:39:37] <jmkasunich> you can read back at that link if you want, but there is a couple hours of chasing stuff there
[00:39:43] <jmkasunich> I'll try to summarize
[00:40:04] <jmkasunich> matt has a drive with 2.5uS step length and step space requirements
[00:41:07] <jepler> hi PeterW
[00:41:07] <jmkasunich> when he enters those numbers into the driver (and the driver passes hopefullly correct values to the fpga) he should be able to get 200KHz
[00:41:08] <jmkasunich> he does get the correct 2.5uS step pulse length
[00:41:12] <jmkasunich> but the step space never goes under 5.0uS, so he can't get the full output frequency
[00:41:40] <jmkasunich> I've looked at the frequency command that the driver is writing to the DDS
[00:42:00] <jmkasunich> the command and the output frequency stay in sync up to about 100KHz
[00:42:14] <jmkasunich> then the output frequency no longer tracks the command, it falls behind
[00:42:44] <jmkasunich> I haven't carefully quantified the amount, except to say that when asking for 200K, 2.5uS on and 2.5uS off, we get 2.5uS on and 5.0uS off
[00:42:54] <jmkasunich> if I shorten step-space, I can go faster
[00:43:04] <PeterW> Hi J&J, Ill try and duplicate that here. I though I had tested the idle time stuff but it is the last thing I added but that was back in Feb.
[00:43:05] <PeterW> It will take me a bit to set this up maybe 20 minutes or so.
[00:43:24] <jmkasunich> I'll be back after dinner
[00:43:38] <jmkasunich> btw, I really don't think the fpga needs to enforce step-space
[00:43:51] <jmkasunich> the driver can just limit the maximum frequency it asks for
[00:44:11] <jmkasunich> to 1/(sum of length and space)
[00:46:05] <PeterW> I have to be sure I'm not late for dinner...
[00:46:07] <PeterW> Originally it was done that way (no StepSpace)
[00:46:08] <PeterW> (StepSpace was a late addition,as was sharing the same counter)
[00:46:48] <jepler> jmkasunich: you had to rtapi_print the frequency command to the 5i20? (I tried using raw but see in the regmap that it's a write-only register)
[00:50:42] <jepler> steplen=5000, stepspace=0 seemed to have the same problem as steplen=2500, stepspace=2500
[00:50:50] <jepler> so it's not *just* stepspace
[01:09:30] <jepler> cradek: what is the way to ASSIGN an integer output in classicladder?
[01:14:51] <jepler> aha there it goes
[01:14:56] <jmkasunich> jepler: I was looking at vel_fb
[01:14:56] <jepler> %QW0 = %W0
[01:15:47] <jepler> * jepler got his AVR modbus integer register value to appear in classicladder and then on a hal pin
[01:15:53] <jmkasunich> yay!
[01:16:29] <LawrenceG> cool...
[01:18:27] <jmkasunich2_> I need a non-EMC way to test this
[01:18:38] <jmkasunich2_> wish the hm2 stepgen had a velocity mode
[01:20:10] <jepler> you can use raw register access for that, if only you could figure out the details
[01:20:29] <jepler> add enable_raw=1 to the config string
[01:20:31] <jmkasunich2_> I'm gonna start with an EMC-less hal file, siggen square wave into the stepgen
[01:20:48] <jmkasunich2_> that will run it at the max for whatever timing params I enter
[01:20:52] <skunkworks> jepler: what did I tell you about your avr issues? :)
[01:20:58] <jepler> then by writing to hm2_5i20.0.raw.write_address hm2_5i20.0.raw.write_data hm2_5i20.0.raw.write_strobe you can set individual registers
[01:21:04] <jepler> skunkworks: this is a different, unrelated avr project
[01:21:18] <skunkworks> oh. never mind. ;)
[01:21:22] <jepler> skunkworks: last time it was running ladder logic directly on the avr
[01:21:32] <jepler> skunkworks: this time it's running a modbus slave on the avr and talking to classicladder over usb serial
[01:21:56] <skunkworks> well - congrats on this one then :)
[01:22:02] <jepler> the puzzle would be keeping the regular hm2 stepgen from stomping on your rate register setting..
[01:22:03] <skunkworks> nice
[01:22:28] <jmkasunich2_> can probably disable the driver part with a setp
[01:24:15] <jepler> jmkasunich: or if not, just comment out the regular rate-register-setting line (?)
[01:24:35] <jmkasunich2_> I'm doing the hal approach first
[01:24:54] <jmkasunich2_> I suspect I'll be into registers sooner or later, unless PeterW comes back with something first
[01:29:29] <jepler> now would be a good time for me to try the 5i20 bitfile I built
[01:31:50] <jepler> [202396.337073] hm2/hm2_5i20.0: IDROM IOPorts is 3 but MD IOPort NumInstances is 2, inconsistent firmware, aborting driver load
[01:31:53] <jepler> doesn't work
[01:32:53] <PeterW> OK Ive verified that limiting the frequency with StepLength and StepSpace doesn't work correctly
[01:32:54] <PeterW> I probably cant fix it tonight but Ill fix it tommorow. For the time being a workaround is to set StepSpace to 0
[01:32:56] <PeterW> and limit maximum velocity in software (to 90% or so of hardware limit)
[01:33:18] <jmkasunich2_> ok, thanks
[01:33:36] <jepler> thank you PeterW
[01:33:55] <jmkasunich2_> I was thinking at dinner that the solution would be for the driver to write 0 (or very small) stepspace to the hardware, and then compute max vel using whatever actual step-space the user provides
[01:35:35] <jmkasunich2_> hmm, I'm trying to run the stepgen without the rest of EMC, and I get no output
[01:35:44] <jmkasunich2_> is there some hidden enable I'm missing?
[01:35:53] <jepler> pet-watchdog? halcmd start?
[01:36:03] <jmkasunich2_> bet its the dog
[01:36:14] <jmkasunich2_> uh, does that have its own hal functino?
[01:36:19] <PeterW> NP, sorry for the bug, I guess I didn't test this against the limits very well...
[01:36:20] <PeterW> That would be a workaround until I understand what happening and get it fixed
[01:36:38] <jmkasunich2_> as far as I'm concered, it can be a permanent workaround
[01:36:56] <jmkasunich2_> I'm sure you have reasons for enforcing space in the firmware, but I think it is a waste of gates ;-)
[01:37:00] <jepler> if it's only stepspace that is the problem, not steplen
[01:37:52] <PeterW> The problem is the same for both I think
[01:38:00] <jmkasunich2_> jepler: it might be a mix of both, but if so it would only show up when you ask for spaces shorter than the pulse length
[01:38:25] <jmkasunich2_> ie, want 2500 length, 1000 space, set params for 2500, 0 for workaround, get 2500, 2500
[01:38:37] <jmkasunich2_> (maybe - those are the cases I'm trying to test now)
[01:40:20] <jmkasunich2_> yep, I forgot to pet the nice doggie
[01:40:35] <jmkasunich2_> mo better
[01:41:56] <jepler> aha I think I found the mistake in SVST8-(IOPortTag,x"00",ClockLowTag,x"02",PortAddr&PadT,IOPortNumRegs,x"00",IOPortMPBitMask),_4.spec
[01:42:00] <jepler> +(IOPortTag,x"00",ClockLowTag,x"03",PortAddr&PadT,IOPortNumRegs,x"00",IOPortMPBitMask),
[01:42:02] <jepler> oops
[01:42:35] <jmkasunich2_> substitution error?
[01:43:44] <jepler> the spec says there are 2 IO ports, but there are 3
[01:43:53] <jepler> and seb wrote paranoid checks for that sort of thing
[01:44:13] <jmkasunich2_> it shouldn't have built then
[01:44:21] <jmkasunich2_> built the bitfile I mena
[01:44:22] <jmkasunich2_> mean
[01:44:31] <jepler> I'm not taking a position on that
[01:44:38] <jepler> obviously it would have been ideal for it not to build :-P
[01:44:57] <jepler> but as far as I can see that part of the idrom is just believed
[01:45:10] <jepler> and it's in one of those long verbatim strings in the spec, so spec2bit isn't checking it
[01:45:32] <jmkasunich2_> oh
[01:46:27] <jepler> now it loads -- yay
[01:46:37] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/SVST8_4.spec: fix inconsistent firmware error with generated bitfile
[01:47:22] <jmkasunich2_> I wonder how that happened - that spec should just be a copy of the original data in IDParms.vhdl
[01:47:40] <jepler> not sure
[01:47:40] <jepler> bbl
[01:49:55] <jmkasunich2_> PeterW: some data points
[01:50:16] <jmkasunich2_> the space I'm seeing isn't as simple as the sum of len+space, or 2*space
[01:50:33] <jmkasunich2_> with len and space both 2000, I get 2000 pulses with 4000 between them
[01:51:48] <jmkasunich2_> with len 2000 and space 3000, I get 2000 pulses with ~5600 between them
[01:52:32] <jmkasunich2_> with len 2000 and space 4000, I get 2000 pulses with ~7100 between them
[01:54:03] <jmkasunich2_> with len 2000 and space 1000, I get 2000 pulses with ~2600 between them
[01:54:47] <jmkasunich2_> with len 2000 and space 1, I get 2000 pulses with ~1050 between them
[01:55:27] <jmkasunich2_> and of course, I'm not 100% sure the proper data is being written to the hardware, at least for space
[01:55:41] <jmkasunich2_> len is right, I've never seen a pulse length other than what I tell the driver to make
[01:58:07] <SWPadnos> jmkasunich2_, is that nanoseconds?
[01:58:31] <jmkasunich> yes
[01:59:54] <SWPadnos> I think there's a debug parameter you can set to see what gets written
[02:00:01] <jepler> apparently they make a ouija board "for girls":
http://trus.imageg.net/graphics/product_images/pTRU1-4759799_alternate1_dt.jpg
[02:00:14] <SWPadnos> "I see pink ponies" :)
[02:00:25] <cradek> you can tell it's for girls because it's pink, which is a girl color
[02:00:40] <SWPadnos> of course. I said that without looking :)
[02:00:55] <jepler> well I have to admit it doesn't actually say "for girls" on it
[02:12:35] <PeterW> OK, the dog is telling me its time to go home (and EAT!)
[02:12:37] <PeterW> Ill fix this tomorrow
[02:13:08] <cradek> yay
[02:13:39] <jmkasunich> peter takes his dog to work? cool
[02:18:27] <jepler> 2.2.9 here we come :-/
[02:18:54] <cradek> yay.
[02:19:05] <cradek> punctuation matters, doesn't it
[02:43:13] <SWPadnos> cradek, what size are the holes for bolting the HNC down to the floor?
[02:46:01] <jepler> hi again pcw
[02:46:22] <pcw> Hi Jepler, figured out the problem...
[02:46:33] <jepler> is it easy to explain? to fix?
[02:46:56] <pcw> I do my best thinking whilst feeding the rabbits
[02:47:19] <pcw> Its pretty easy just an added term to DDS hold
[02:48:04] <jmkasunich> pcw: does your dog come to work with you?
[02:48:30] <pcw> Yes, Henry (black lab mix)
[02:48:37] <jmkasunich> neat
[02:50:21] <jmkasunich> wish my dog could do that
[02:50:32] <jmkasunich> well, dog can, but work can't
[02:50:36] <jepler> that's probably equal parts dog and work .. yeah
[02:52:57] <pcw> Henrys a new dog (1 year old now) we lost our old Black lab this February.
[02:52:59] <pcw> Still getting used to a rambunctious young dog...
[02:54:29] <jmkasunich> my neighbor has a ~9 months black lab
[02:54:36] <jmkasunich> he drives them nuts
[02:55:22] <pcw> Henry was a real trial as a puppy but he's getting more settled now
[02:57:10] <jmkasunich> my dog is a golden retriever - german sheppard mix (I think)
[02:57:21] <jmkasunich> he's about 5, had him since 1ish - he was a rescue
[02:57:28] <jmkasunich> he's finally mellowing out
[02:58:47] <pcw> Henry was a rescue as well (we got him at 5 months) He's small for a lab (55 #)
[02:58:48] <pcw> Not sure what he's mixed with
[02:59:07] <jmkasunich> pure mutt
[02:59:14] <jmkasunich> I like mixes
[02:59:57] <jmkasunich> http://willepadnos.net/jmkasunich/buddy.jpg
[03:03:03] <pcw> Very nice. A friend of mine had a golden retriever, wonderful dog, always collected sticks on any kind of walk...
[03:03:54] <jmkasunich> darn - I need 21" of 5/8-5 acme threaded rod, and I have 18"
[03:05:58] <jmkasunich> it comes in 36" pieces, for $41 each, so I'll wind up paying $41 for 3"
[03:06:20] <jmkasunich> the retriever part must have gotten the short end of the stick in his genes
[03:06:28] <jmkasunich> he really doesn't chase balls or such
[03:06:48] <jmkasunich> at the dogpark, when people throw balls, he chases the dogs that are chasing the balls
[03:08:36] <jmkasunich> cool - I do have the 1" and 2" bronze rod I need
[03:10:50] <pcw> Henry is crazy about balls, just mentioning the word 'ball' makes him frantic
[03:11:46] <jmkasunich> heh
[03:19:00] <pcw> Anyway, I'll fix bug tomorrow. Problem is that DDS hold is asserted when a step pulse is present or a stepspace timer is running and accumulator MSB would change without qualifying the hold with the current direction. (we should ignore the edge we dont care about)
[03:20:17] <jepler> that's great
[03:20:52] <jepler> I'd be just as happy waiting until after the first of the year to do another emc2 release
[03:21:14] <jepler> to be honest
[03:24:37] <pcw> I think in most cases theres a work around, plus I can update the firmware for those that need it now
[03:25:03] <pcw> By all
[03:25:18] <pcw> bye
[03:28:39] <SWPadnos> well I'll be darned:
http://www.sherline.com/lm.htm
[03:29:25] <jepler> sounds like just the thing you need
[03:29:30] <SWPadnos> yeah, it is
[03:29:40] <jepler> well, that, or crossing your fingers and hoping for the best
[03:29:42] <SWPadnos> I just didn't realize that Sherline made them
[03:30:50] <cradek> huh, that's neat
[03:31:00] <cradek> SWPadnos: it doesn't bolt down...
[03:31:12] <SWPadnos> shouldn't need to
[03:31:30] <SWPadnos> that tall hex thing comes off, so it's a relatively flat base
[03:35:09] <cradek> no, the lathe
[03:35:22] <SWPadnos> oh, heh :)
[03:35:26] <SWPadnos> interesting
[03:35:41] <SWPadnos> I guess lathes are a bit more stable than mills
[03:35:49] <cradek> you also don't have to level or untwist it - the manual says don't bother
[03:36:04] <SWPadnos> that's convenient
[03:36:11] <SWPadnos> is it true?
[03:36:12] <cradek> one of the feet is adjustable, so you can make it not rock on the floor - that's all you have to do
[03:36:17] <cradek> yes IMO
[03:36:18] <SWPadnos> ah, nice
[03:36:31] <cradek> I think the bed is mounted at three points to the box, so it can't be twisted
[03:36:34] <jmkasunich> probably the bed and critical stuff is a 3-point mount to the stand
[03:36:58] <SWPadnos> ok -I hae some chain binders with a high load rating. I think those with some wood should be OK, but I definitely don't want to bend or break anything
[03:37:00] <SWPadnos> have
[03:37:33] <SWPadnos> is there anywhere pseudo-convenient to attach a strap other than going across the bed?
[03:37:48] <cradek> lifting or hold-down?
[03:37:52] <SWPadnos> hold-down
[03:37:58] <cradek> no, I don't think so
[03:38:01] <SWPadnos> I have as much time as I want to get it off the trailer
[03:38:01] <jmkasunich> I think you can probably go over the base and under the bed?
[03:38:19] <cradek> it's true you could, but only for a center strap I think
[03:38:33] <SWPadnos> OK - I have ratchet straps too :)
[03:38:43] <SWPadnos> those should be soft enough :)
[03:39:01] <cradek> screwing 4x4 around it so it can't slide makes multiple hold-downs less critical
[03:39:02] <jmkasunich> what about straps in an X, or >< pattern, passing thru the middle
[03:39:20] <jmkasunich> 4x4 or even 2x4 for slide, but straps for tip
[03:39:30] <SWPadnos> yeah
[03:39:31] <cradek> honestly I don't remember exactly what I came up with
[03:39:53] <SWPadnos> there are 4 stake pockets (2 on each side), and that's it - no other tie-downs
[03:40:22] <SWPadnos> I can put ey ebolts or other hardware anywhere I want - through the wood, tied to the metal frame, whatever
[03:40:56] <SWPadnos> of course, I'll need to have it shipped to Cleveland at this point
[03:41:11] <jmkasunich> ?
[03:41:20] <SWPadnos> not much of that stuff locally
[03:41:25] <jmkasunich> oh, hardware
[03:41:26] <cradek> bizarre - M60 is accepted and pauses (or something) but I don't see it in the interp
[03:42:02] <jmkasunich> assuming you still come thursday, when do you expect to hit cleveland? late pm, or before stores close?
[03:42:57] <SWPadnos> late PM most likely, I'd do the trip in 1 day
[03:43:11] <jmkasunich> so any prep realisticly would be the next morning
[03:43:14] <SWPadnos> yep
[03:43:21] <SWPadnos> I'm planning on 2 days back
[03:43:41] <SWPadnos> thr first day only ~250-300 miles (to Rochester)
[03:43:47] <jmkasunich> I have a fair amout of "crap", ranging from bits of wood to some heavy rope (former boat docklines, 3-strand about 5/8" diameter)
[03:44:27] <SWPadnos> ok, cool
[03:44:28] <jmkasunich> I'll bring a bit of everything to HGR
[03:44:39] <SWPadnos> I have a bunch of 2x4, and a little bit of 4x4 around
[03:44:49] <jmkasunich> if you use anything I want back, you can bring it to the CNC workshop - I'm unlikely to need it before then
[03:44:59] <SWPadnos> ok, thanks
[03:47:00] <jmkasunich> do you have any of the cheap harbor freight ratchet straps?
[03:47:21] <SWPadnos> I have some smaller ones
[03:47:36] <SWPadnos> not too many though - maybe 3-6 or so
[03:47:41] <jmkasunich> those will be handy for secondary stuff
[03:47:51] <SWPadnos> and lots of bungies of various sizes
[03:49:07] <jmkasunich> heh, 3000 lbs on the trailer, and 1500 lbs of misc in the back of the jeep
[03:49:20] <SWPadnos> yeah ;)
[03:49:36] <jmkasunich> I wish I could remember what else I wanted from McMaster
[03:49:40] <SWPadnos> the limit is 1000 pounds in the jeep and 6500 pounds gross trailer weight ;)
[03:50:37] <SWPadnos> maybe a few hundred pounds less in the Jeep so I can be in it, and maybe some clothes :)
[03:56:15] <jmkasunich> what is the empty trailer weight
[03:56:25] <SWPadnos> I'm not sure
[03:56:40] <SWPadnos> I think it's in the 1500-2000 pound range
[03:56:43] <jmkasunich> anyplace local where you could weigh it?
[03:56:53] <SWPadnos> I'll try to find the tag in daylight tomorrow
[03:57:08] <SWPadnos> hmmm, maybe at the steel yard
[04:01:17] <SWPadnos> ok, the registration says 1800 pounds unladen weight
[04:01:51] <jmkasunich> so 5300 with the lathe
[04:02:05] <jmkasunich> cradek: did you use the control cabinet, or just some of the contents?
[04:02:27] <SWPadnos> yah, it'll be close with both on there
[04:13:31] <SWPadnos> ok, there is some very cold metal outdoors right now
[04:13:47] <jmkasunich> yeah
[04:13:52] <jmkasunich> did you get your tongue stuck?
[04:14:08] <SWPadnos> no (neither mine nor the trailers :) )
[04:14:26] <SWPadnos> I did find out that the clevis pin I got was too small
[04:14:39] <SWPadnos> so one more trip to Home Depot :)
[04:15:34] <jmkasunich> do you know where you're gonna stay when you get here?
[04:16:06] <jmkasunich> I'm thinking of things like "there is a home depot near there"
[04:16:14] <SWPadnos> I have a hotel reservation about 3 or 5 miles (or something) from HGR
[04:16:24] <jmkasunich> which direction ;-)
[04:16:37] <SWPadnos> I was going to ask you about food near HGR too - you know me and my stomach :)
[04:16:48] <SWPadnos> south - it's on 271
[04:17:03] <jmkasunich> name?
[04:17:13] <SWPadnos> Central Parkway and I271 (exit 29)
[04:17:19] <SWPadnos> Homewood Suites by Hilton
[04:17:22] <jmkasunich> near HGR is iffy - it is in a less than wonderfull part of town
[04:17:36] <SWPadnos> heh
[04:18:37] <SWPadnos> I guess it's actually in Beachwood
[04:18:41] <jmkasunich> exit 29 is fairly far south
[04:18:58] <SWPadnos> hmmm. maybe it was 13.93 miles or something
[04:19:06] <jmkasunich> that sounds about right
[04:19:18] <SWPadnos> I think the two closest hotels were under construction :)
[04:19:18] <jmkasunich> oh
[04:19:22] <SWPadnos> ie, not opened yet
[04:20:02] <jmkasunich> there are several much closer to HGR
[04:20:19] <jmkasunich> google maps: eastlake oh hotel
[04:20:35] <SWPadnos> yeah. I just go to the Hilton site by reflex :)
[04:20:42] <SWPadnos> plus I like the hot tubs
[04:20:53] <jmkasunich> red roof, days in, raddison, courtyard
[04:21:13] <jmkasunich> ramada inn and conference center
[04:21:31] <SWPadnos> they should have food :)
[04:22:00] <jmkasunich> food for thurs night will be easy - chagrin and 271 is full of places, from fast food to $$$$
[04:22:14] <SWPadnos> how about $$+1/2$ :)
[04:22:32] <jmkasunich> little of everything there
[04:22:48] <SWPadnos> cool. that's what I like
[04:22:59] <jmkasunich> at that hotel, you will be twice as far from HGR than I am
[04:23:03] <SWPadnos> oh
[04:23:03] <jmkasunich> as I am
[04:23:20] <SWPadnos> it seemed like a straight shot up 271
[04:23:26] <jmkasunich> more or less
[04:24:12] <jmkasunich> maybe not twice, but definitely farther - if you go from the hotel to HGR as the crow flies, you probalby pass a bit west of my house
[04:24:23] <jmkasunich> as the interstates runs, you pass a few miles easy
[04:24:34] <jmkasunich> and then north, and then southwest
[04:24:53] <SWPadnos> you're in Mayfield?
[04:24:54] <jmkasunich> no big deal tho, compared to the rest of the drive
[04:24:55] <jmkasunich> yes
[04:25:09] <SWPadnos> ok, I see it a little north of the hotel
[04:25:39] <jmkasunich> the hotel is at 271 and chagrin, right?
[04:25:42] <SWPadnos> I can call you when I'm getting into town, if you'd like to have dinner or go get hardware :)
[04:25:45] <SWPadnos> more or less
[04:25:45] <jmkasunich> or at least, near that exit
[04:25:49] <SWPadnos> yep
[04:26:49] <SWPadnos> ah, there's Central Parkway
[04:27:03] <SWPadnos> the little E-W nub off Enterprise Parkway
[04:28:21] <jmkasunich> ah
[04:33:16] <SWPadnos> HGR is between 196th and 204th streets, right (near Dille Road)?
[04:40:15] <jmkasunich> yes
[04:41:27] <SWPadnos> ok, I thoought I recognized that huge building
[09:02:17] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[10:31:08] <micges> jepler: did you check my patch to halui?
[13:17:40] <jepler> what patch is micges asking about?
[13:22:38] <jepler> oh, he sent it directly to me and it went in my spam folder
[13:51:26] <seb_kuzminsky> good morning
[13:51:40] <seb_kuzminsky> something came up last night and i couldnt come here, sorry
[13:51:54] <seb_kuzminsky> looks like y'all got it figured out, thanks
[13:58:50] <skunkworks_> It was fun to read :)
[13:59:48] <seb_kuzminsky> after all this bragging on halscope, it makes me want an *actual* scope ;-)
[14:52:06] <cradek_> I have one you can have - all it needs is repair
[14:52:15] <cradek_> cradek_ is now known as cradek
[14:52:49] <jepler> cradek: that one with no vertical that I had borrowed from you?
[14:52:57] <cradek> yeah
[14:53:32] <jepler> 2-channel digital storage scopes are frequently available on ebay, but they still go for hundreds of dollars..
[14:55:41] <cradek> here's a BIN tek 465 (my broken one) for $150, with the usual busted off knobs
[14:57:27] <cradek> http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=270242363766
[14:57:43] <cradek> interesting - here's a pull that I think has the magic IC mine needs
[14:58:03] <cradek> 466 is the storage version of the 465 - I bet this vertical output board is the same or almost the same
[14:59:37] <cradek> wonder if it's worth $50 + time to fix it...
[15:12:24] <seb_kuzminsky> we have a nice digital storage scope at work that i've borrowed occasionally... it's a tek 24? or 24?? or something
[15:12:33] <seb_kuzminsky> super nice, really thin & light
[15:12:36] <seb_kuzminsky> so i'm spoiled ;-)
[15:14:31] <cradek> nothing useful to borrow from work here - you guys who work in techie places are lucky that way.
[15:27:37] <jmkasunich> seb_kuzminsky: 2440 maybe?
[15:28:08] <jmkasunich> probably not, if you call it thin and light
[15:30:00] <SWPadnos> I have a digital scope you could buy, but it wouldn't be a "deal" :)
[15:32:01] <jmkasunich> I have a 2440, 500Ms/sec, only 512 or 1K samples tho
[15:34:56] <jmkasunich> mid 90's technology I think
[15:53:40] <seb_kuzminsky> jmkasunich: thanks for the hm2 firmware debugging yesterday, sorry i had to bail
[15:55:11] <jmkasunich> no problem
[15:56:00] <jmkasunich> regarding stepgen
[15:56:21] <jmkasunich> I've been thinking about making that driver more like the software stepgen
[15:56:29] <jmkasunich> one big feature would be velocity mode
[15:56:40] <jepler> jmkasunich: if you can library-ize the stepgen logic, pluto_step would use it too
[15:56:41] <jmkasunich> but it is also a big problem, because how do we config vel vs pos
[15:57:53] <seb_kuzminsky> gotta go again, i'll be back in a couple of hours
[15:58:11] <seb_kuzminsky> jmkasunich: if there's a better way to do hm2 stepgen i'm all for it, and i'll be happy to help with the work
[15:58:14] <seb_kuzminsky> bye!
[15:58:36] <jmkasunich> jepler: I hadn't thought about actually putting the common code in a separate file
[15:58:39] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/firmware/src/spec2bit.py: the pcf file ended up renamed after my earlier changes; compensate
[15:58:50] <SWPadnos> isn't the VHDL just a rate generator?
[15:58:56] <jmkasunich> that would be the smart approach of course, but I don't know how messy the interface is
[15:59:05] <jepler> jmkasunich: yeah that's the puzzle
[15:59:28] <jmkasunich> SWPadnos: more or less - there are three extra timers, for step length, dir setup, and dir hold
[16:00:11] <SWPadnos> unless my coffee isn't working, doesn't that mean that the firmware already supports velocity mode?
[16:00:19] <jepler> right
[16:00:22] <jepler> the problem is the hal component
[16:00:23] <jmkasunich> the firmware is the easy part
[16:00:25] <SWPadnos> phew! :)
[16:00:26] <jepler> how to specify it at load time or whatever
[16:00:36] <jmkasunich> it is inherently velocity, position is wrapped around it by the driver
[16:01:06] <jmkasunich> the problem is config. for software there is ctrl_type="p,p,v" to make 2 position mode and one velocity mode
[16:01:28] <jmkasunich> that results in different hal pins being exported - pos cmd in one case, vel cmd in the other
[16:01:51] <jmkasunich> the config string for a 5i20 is already too complex, I don't want to make it worse
[16:02:32] <jmkasunich> one thing I thought about this morning was to always export pos-cmd and vel-cmd, but make vel-cmd a bidirectional pin
[16:02:45] <jmkasunich> then if you enable pos mode, it becomes an output, otherwise it is an input
[16:03:18] <SWPadnos> pos and vel can both be I/O that way
[16:03:29] <jmkasunich> why would pos be I/O?
[16:03:29] <SWPadnos> since you should be able to read back the position in vel mode
[16:03:45] <SWPadnos> I mean in or our, not both - sorry
[16:03:51] <SWPadnos> s/our/out/
[16:03:53] <jmkasunich> there will always be a position-fb pin, independent of the command
[16:04:16] <SWPadnos> there should also be an actual-vel output in vel mode
[16:04:21] <jepler> I was thinking along the same lines, but imaginging velocity-cmd and velocity-fb as different pins as well
[16:04:31] <SWPadnos> if the closest attainable rate isn't exact
[16:04:46] <jmkasunich> hmm
[16:05:28] <jmkasunich> maybe the way to library-ize this is to make the hw specific part be velocity mode only, and then make a comp that takes pos cmd and pos fb, and generates vel cmd
[16:05:47] <SWPadnos> actually, I think exporting all the pins and allowing on the fly changes to the mode would be great
[16:06:10] <jmkasunich> lost me there I think
[16:06:19] <SWPadnos> consider the perennial "can I use my A axis as a spndle and a positioning axis?" question
[16:06:22] <jepler> you'd have velocity-cmd position-cmd command-source
[16:06:27] <jmkasunich> four pins, pos-cmd, pos-fb, vel-cmd, and vel-fb
[16:06:31] <SWPadnos> yes
[16:06:34] <SWPadnos> and a mode pin
[16:06:59] <jmkasunich> when in pos mode, vel-cmd is just ignored, ditto for pos-cmd in vel mode
[16:07:03] <SWPadnos> yep
[16:07:07] <jmkasunich> both fbs are always updated
[16:07:11] <SWPadnos> yep
[16:07:11] <jepler> yep
[16:07:23] <jmkasunich> I like it
[16:07:27] <jmkasunich> only one problem
[16:07:30] <jepler> only one!
[16:07:35] <SWPadnos> hmmm
[16:07:41] <jmkasunich> now I want to make the software stepgen work that way too
[16:07:45] <SWPadnos> heh
[16:07:46] <jmkasunich> consistency you know
[16:08:00] <jepler> that's fine; if you care about backwards compatability, use ctrl_mode= to preload the mode pin
[16:08:07] <jepler> bb l
[16:08:07] <SWPadnos> that can be left as an exercise for the reader :)
[16:08:14] <jmkasunich> jepler: clever
[16:08:22] <SWPadnos> yep - I was thinking that too
[16:08:28] <SWPadnos> must be good coffee this morning :)
[16:09:10] <jmkasunich> the position control stuff really does want to get pulled out into its own file
[16:09:36] <SWPadnos> yeah - it's more or less "pre-tuned PID"
[16:09:54] <jmkasunich> sort of, there isn't really any P, or I, or D
[16:10:10] <SWPadnos> yeah, that's true
[16:10:24] <jmkasunich> it is more about knowing the accel limit of the rate generator, and knowing that the rate generator will do very close to what you tell it to do
[16:10:26] <SWPadnos> it does the same function - use velocity control to change position
[16:10:33] <jmkasunich> yes
[16:11:07] <jmkasunich> dang, I keep getting EMC stuff to do
[16:11:13] <jmkasunich> I have metal to cut too
[16:11:40] <jmkasunich> I think I'll do metal this morning, coding later in the day when I'm smarter
[16:11:40] <SWPadnos> heh
[16:11:54] <SWPadnos> I wonder if I should shovel off the Jeep and move it into the garage
[16:12:09] <jmkasunich> you got dumped on?
[16:12:28] <jmkasunich> we got a half-inch last evening, and nothing more overnight
[16:12:55] <SWPadnos> we have 4 or 5 inches and it's still snowing
[16:12:59] <jmkasunich> ick
[16:13:21] <SWPadnos> yeah. I'm wondering where in NY or PA it turned from your weather into our weather
[16:13:41] <jmkasunich> the good news is that boundary line should be moving toward you
[16:13:48] <jmkasunich> hopefully it will arrive before you leave
[16:14:01] <SWPadnos> yep, that would be good
[16:17:09] <SWPadnos> heh - now here's a deal:
http://www.sealevel.com/subcategories.asp?subcat_id=323
[16:18:59] <SWPadnos> well, that was annoying
[16:26:44] <jmkasunich> that's a great price, I want 10!
[16:27:00] <SWPadnos> yeah. and no complex FPGAs to get in the way of your I/O
[16:28:03] <jmkasunich> their 24 channel TTL board is only $159
[16:28:25] <SWPadnos> a bargain at half the price
[16:30:54] <SWPadnos> ok, time to brave the cold. bbl
[16:38:46] <jmkasunich> one thing that will be really nice when I get my machine switched over to 5i20 - no "clunkety clunk clunk clunk" of contactors on power up - the BIOS must go poking at the parport
[16:51:38] <cradek> that's kind of scary
[16:54:22] <jmkasunich> only annoying - the main power contactor is controlled by a charge pump and estop chain
[16:54:43] <jmkasunich> the ones that clunk take power from the main and apply it to the spindle motors, so if the main is open, nothing happens
[17:26:48] <jmkasunich> wish I had CSS
[17:27:16] <cradek> what's keeping you from changing your motor? I thought you had a new motor for it already.
[17:27:48] <jmkasunich> I have a motor, but it is a permanent magnet AC servomotor, so an ordinary VFD won't work
[17:28:03] <jmkasunich> also, I need to redo the drivetrain
[17:28:23] <jmkasunich> current is motor on hinge (for belt tension) and two stages of v-belt step pulleys
[17:28:49] <jmkasunich> the new motor is too huge to hang on a hinge
[17:29:09] <cradek> darn, sounds multi-day
[17:29:27] <cradek> (I find it easier to start things I can do in one day)
[17:30:03] <jmkasunich> me too
[17:30:52] <skunkworks_> jmkasunich: are you planning on creating a driver for the ac servomotor?
[17:31:01] <skunkworks_> * skunkworks_ is hoping he isn't the only crazy one..
[17:31:41] <cradek> that sounds crazy to me
[17:31:43] <jmkasunich> skunkworks_ yes, partly
[17:32:08] <jmkasunich> I'll use an existing power structure (from a dumpster VFD) and do the motor control in 5i20 FPGA + HAL
[17:32:20] <skunkworks_> Neat
[17:32:38] <cradek> cool
[17:33:09] <cradek> can you use a toothed belt and generate fake encoder feedback from it too?
[17:34:21] <jmkasunich> huh?
[17:34:42] <cradek> will hal know the motor position?
[17:34:44] <jmkasunich> the motor has an encoder, which I'll need to do vector control
[17:34:49] <cradek> oh ok
[17:34:55] <jmkasunich> there will be another encoder on the spindle for EMC
[17:35:05] <cradek> (I'm a motor idiot)
[17:35:37] <jmkasunich> the motor is a beast, probably good for 4HP at max speed - what that means for me is that I'll be able to get 1HP over a 4:1 or slightly better speed range
[17:35:50] <jmkasunich> then two belt ratios will give me a total of 16:1
[17:36:17] <jmkasunich> * jmkasunich types while lathe works - I can get used to this!
[17:36:46] <jmkasunich> facing worm gear blanks to length
[17:37:32] <cradek> how much rework do you have to do on the "discount" jig?
[17:38:00] <jmkasunich> I'm estimating about 100 hours, between the two jigs
[17:38:18] <jmkasunich> I quoted it three ways - bare minimum, new gearbox, new jig
[17:38:20] <cradek> is that less than starting over with your own proven design?
[17:38:23] <jmkasunich> they took the middle one
[17:38:46] <jmkasunich> from scratch would probably be 100 hours each (a little less for the 2nd one, setup)
[17:39:03] <jmkasunich> I've never had CNC before, if I'm lucky that will reduce times quite a bit
[17:39:08] <cradek> ouch.
[17:39:35] <cradek> it might increase if doing 1, decrease if 2
[17:39:54] <jmkasunich> fortunately I'm doing 2
[17:40:10] <jmkasunich> today's project is to prep gear blanks, and make acme nuts
[17:40:23] <cradek> also, maybe #3 later on will be a lot easier
[17:40:29] <jmkasunich> both parts (4 total) need 5/8-5 acme threads thru ~1" of bronze
[17:42:01] <cradek> do you have a tap?
[17:42:15] <jmkasunich> I have a homemade tap (4140 amce threaded rod, fluted and heat treated), but it doesn't stay real sharp
[17:42:17] <cradek> seems like 1" is pretty deep for making a threading tool for 5/8
[17:42:26] <jmkasunich> and even when it is sharp, it is very hard work
[17:42:48] <cradek> I did 3/4 deep 5/8-11 recently - it went fine
[17:43:07] <jmkasunich> there's no way I'd try to make the actual ACME thread on the lathe - I want a near perfect fit, and the tap gives me that since it is made of the same rod that I'll be running thru the holes
[17:43:20] <cradek> ah
[17:43:34] <jmkasunich> 5/8-5 is only a 0.412 initial hole, and a thread that coarse means a LOT of metal to remove
[17:44:00] <jmkasunich> I'm thinking about roughing it on the lathe, cut a 60 degree thread 90% depth
[17:44:44] <cradek> will you need a tool with more than the usual slant for 5 tpi? seems pretty steep
[17:44:48] <jmkasunich> facing the 2nd end of the 2nd gear blank now, next face the nut blanks, then bore all four
[17:44:54] <jmkasunich> good question
[17:46:42] <jmkasunich> note to self - don't leave dial calipers next to lathe when cutting bronze
[17:46:52] <jmkasunich> even tho the rack is covered, those little chips get everywhere
[17:47:37] <cradek> fortunately my calipers jump back in their drawer automatically
[17:47:49] <jmkasunich> I need to get me a set of those
[17:47:55] <cradek> I wish the drawer would always close itself though
[17:48:18] <cradek> I filled it with flycut-aluminum recently - it was pretty funny actually.
[17:50:25] <jmkasunich> heh
[18:09:12] <seb_kuzminsky> the scope at work is a tek tds 224, and i've been invited to make an offer on it ^_^
[18:10:20] <jmkasunich> sounds much newer than mine
[18:10:23] <jmkasunich> LCD or CRT?
[18:10:52] <SWPadnos> thin portable/benchtop LCD
[18:10:54] <SWPadnos> I think
[18:12:01] <seb_kuzminsky> lcd
[18:12:06] <seb_kuzminsky> here's the glossy brochure:
http://www.chiptech.com/secondary/manu-prod_pdf/T/Tektronix.pdf
[18:12:25] <seb_kuzminsky> 4 channel, 100 mhz, 1 gsample/sec
[18:12:30] <jmkasunich> nice
[18:12:50] <jmkasunich> we have one of those at work I think
[18:12:58] <jmkasunich> not my favorite
[18:13:12] <seb_kuzminsky> what dont you like about it?
[18:13:32] <jmkasunich> the screen seems rather pixelated, and I'm just not used to it
[18:13:49] <skunkworks_> * skunkworks_ thinks jmk is a crt guy..
[18:13:49] <seb_kuzminsky> there's also a couple of tek 465's available, they're older and clunkier-looking
[18:14:08] <jmkasunich> I usually use a TDS754 or 744 for fast work, and I've gotten pretty familiar with them
[18:14:31] <jmkasunich> recently used another one (don't recall the number) for some startup issues, it has 10M samples per channel!
[18:14:56] <seb_kuzminsky> there are no 224's for sale on ebay, but some dude wants to sell "product comparison dvd" for $10...
[18:14:58] <seb_kuzminsky> no thanks
[18:15:08] <seb_kuzminsky> jmkasunich: nice :-)
[18:15:08] <jmkasunich> that was great, I could record a 3/4 second long startup procedure, and then observe SCR gate timings with sub-microsecond resolution
[18:15:18] <seb_kuzminsky> * seb_kuzminsky drools
[18:15:51] <jmkasunich> the thing that makes me nuts about Tek's recent scopes is that they seem inherently incapable of building two scope with compatible user interfaces
[18:16:01] <jmkasunich> you gotta relearn everything whenever you change scope
[18:16:40] <jmkasunich> I can't rememeber how many times I said "f$ck you" at that scope after hitting the wrong button or turning the wrong knob
[18:18:23] <seb_kuzminsky> they should all have themable interfaces, and come with a halscope theme ;-)
[18:19:02] <skunkworks_> wait - I want 'classic scope' theme
[18:19:48] <jmkasunich> heh - halscope comes with a TDS74x theme (at least, that is kind of what I had in mind when I was designing it)
[18:20:47] <seb_kuzminsky> several 210's and 220's have been sold on ebay recently, $400-$600
[18:21:37] <jmkasunich> interesting
[18:21:54] <jmkasunich> my 2440 is much older, but ISTR that those fetch close to the same on ebay
[18:21:58] <jmkasunich> 300-400 anyway
[18:23:10] <seb_kuzminsky> teks seem to hold their value pretty well
[18:24:32] <SWPadnos> the newest Tek user interface is pretty good
[18:24:42] <SWPadnos> but of course that's on the newest scopes (as of earlier this year)
[18:37:38] <skunkworks_> les_: as in les watts?
[18:38:26] <skunkworks_> nope - les newell
[18:38:33] <skunkworks_> nope - les newell
[18:38:44] <skunkworks_> wow - that was odd
[18:38:55] <seb_kuzminsky> it's like there's two of you in here
[18:41:22] <les_> Yes it is Les Newell. I just dropped in to see if anything was happening...
[18:53:06] <SWPadnos> it looks as though you could safely say that not much is happening at the moment :)
[18:53:29] <les_> LOL
[18:53:56] <SWPadnos> it's also possible that so much is happening that people don't have the time to chat about it
[18:57:06] <jmkasunich> I'm boring
[19:04:06] <seb_kuzminsky> jmk is too busy listening to his own boring chatter to bore us with his chatter
[19:08:29] <jmkasunich> boring just got finished
[19:09:30] <seb_kuzminsky> done with the boring, next comes the milling about
[19:09:38] <SWPadnos> wouldn't diameter mode have been helpful there?
[19:09:53] <jmkasunich> n0, I'm perfectly capable of dividing by 2
[19:10:00] <SWPadnos> heh
[19:11:17] <jmkasunich> I think lunch is next
[19:11:53] <SWPadnos> rear defroster repair and brake controller install for me :)
[19:21:31] <jepler> hi les_, welcome to irc
[19:40:31] <les_> Thanks Jepler. I'm afraid I don't monitor irc all that closely so sometimes I take a while to reply.
[19:41:00] <les_> SWPadnos - Brake controller? <visions of emc controlled ABS>
[19:43:48] <SWPadnos> heh
[19:44:15] <SWPadnos> going to pick up a lathe tomorrow (unless the weather sucks too badly), good to have the trailer brakes work too
[19:45:56] <les_> Ah, I see. I'm picking one up on Friday. Using someone else's trailer and tow vehicle so I don't have to worry about the brakes :-) What lathe are you getting?
[19:46:17] <SWPadnos> a Hardinge HNC
[19:46:30] <SWPadnos> this is a borrowed trailer, the Jeep is mine :)
[19:47:20] <les_> Nice. Presumably a candidate for emc? I'm getting a Colchester electronic Triumph with a blown Fanuc control.
[19:47:32] <SWPadnos> yep. I expect to use EMC2 on it
[19:47:44] <SWPadnos> the control may work - it still has a (paper) tape in it :)
[19:48:59] <les_> Ah, gool old paper tape - lots of little paper dots all over the place :-)
[19:49:11] <SWPadnos> "chads" I guess :)
[19:49:43] <SWPadnos> ah, here it is:
http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=320274513641
[19:51:11] <les_> Looks like it's got a tool turret on it as well. Unfortunately mine hasn't :-(
[19:51:28] <SWPadnos> yep, turret (with tools/holders in it) and bar feed
[19:51:33] <SWPadnos> and an air chuck
[19:52:58] <les_> I've got an air chuck for my current lathe. Damn thing leaks so bad my compressor can't keep up.
[19:53:47] <SWPadnos> heh
[19:54:12] <SWPadnos> in that case my compressor will surely not keep up. I have a cheapo "auto parts store special"
[19:54:31] <cradek> SWPadnos: the thing will leak air everywhere...
[19:54:44] <skunkworks_> yecky
[19:55:14] <skunkworks_> cradek: is it using piston ring style seals and such?
[19:57:15] <les_> On my chuck the air is fed into a big ring on the back of the chuck. The rotating seal between the ring and the chuck itself is the problem. TBH I haven't really used it in anger as I only do small runs and one-offs.
[20:01:19] <les_> OK I'm confused. I'm working on the G07/G08 extensions and I can't get axis to play ball. I increased ACTIVE_G_CODES by 1 to make room for the G7/G8 flags in the active_g_codes array. There should now be 16 items in the array. However Axis seems to think there are only 15 so it doesn't display the G7/G8 status..
[20:03:22] <les_> Just addded this code to the section of Axis that displays the active G-codes:
[20:03:23] <les_> for i in self.stat.gcodes[1:]: active_codes.append("x")
[20:03:57] <les_> It only shows 15 Xes where there should be 16.
[20:08:03] <jepler> static PyObject *Stat_activegcodes(pyStatChannel *s) {
[20:08:03] <jepler> return int_array(s->status.task.activeGCodes, ACTIVE_G_CODES);
[20:08:03] <jepler> }
[20:08:25] <jepler> hm, ACTIVE_G_CODES is used to determine how many items to put in stat.gcodes
[20:09:22] <les_> That's what I thought. 'm confused!
[20:10:23] <jepler> ah -- it's correct
[20:10:30] <jepler> without your change, stat.gcodes[1:] is 14 items
[20:10:58] <jepler> python is zero-based, and so is activeGCodes in C++, but "modal group 0" is not really a modal group
[20:11:23] <jepler> stat.gcodes[1:] is called a 'slice'; it gets rid of the first item
[20:12:18] <les_> OK. That makes sense. I wonder why it won't display my G7/8 status then.
[20:12:20] <jepler> >>> s = ['a', 'b', 'c']
[20:12:20] <jepler> >>> s
[20:12:20] <jepler> ['a', 'b', 'c']
[20:12:20] <jepler> >>> s[1:]
[20:12:20] <jepler> ['b', 'c']
[20:12:35] <skunkworks_> les_: I think there will be a lot of people on cnczone happy with this addition.
[20:18:18] <les_> skunkworks - I have to admit I do find dia mode so much easier.
[20:19:26] <les_> Hmm, something funny going on with library paths I think. I was using run in place but just did a make install and suddenly Axis does what I expect.
[20:20:51] <les_> jepler, thank you for your help.
[20:27:05] <les_> Just trying some destruction testing. I'm in G8 mode (radius). I enter G7G0X1 in MDI and the machine moves to x1(radius) On the next line I enter G0X1 and it moves to X0.5(radius). Is this correct?
[20:27:43] <les_> The G7/G8 appears to only take effect at th end of the current line.
[20:28:22] <jepler> the language specification says (for existing codes) what order they are executed; that order is irrespective of their order on the line
[20:28:32] <jepler> however, it obviously doesn't specify the order for G7/G8 since they don't exist yet
[20:29:04] <jepler> http://linuxcnc.org/docs/html/gcode_main.html#sec:Order-of-Execution http://linuxcnc.org/docs/html/gcode_main.html#r3_5
[20:29:19] <jepler> so part of your project is to determine what the order should be, and then document it
[20:33:01] <jepler> you should figure out what a user expects, and then do that if possible
[20:33:10] <jepler> I take it by what you said that the behavior was the opposite of what you expected...
[20:33:54] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: don't use a confusing term to describe what G28/G30 do
[20:34:15] <jmkasunich> as a user, I would expect that a mode setting code on a line, should affect that line - so mode setting codes should be executed first
[20:34:32] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: it is CRITICAL?
[20:34:39] <jmkasunich> as a smart user, I won't put mode setting codes on lines with codes that I want them to affect, I'll put them by themselves
[20:35:04] <les_> I hadn't really thought about it until I started trying to break it. Hmm, I would say that it should be before any G-code that can use X so just after G20/21 makes sense to me
[20:35:08] <CIA-42> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: duh, typo
[20:36:32] <cradek> jmkasunich: for a nice surprise, try G20 / G1 X1 F5 / G21 G1 X50.8 F127
[20:37:25] <jmkasunich> I hate surprises
[20:38:14] <les_> jmkasunich: I agree. I would say in most cases it would just be part of the guard codes at the beginning of the program. Trying to mix rad/dia sounds loike a recipe for disaster.
[20:47:11] <cradek> les_: on the contrary, I believe it should work fine and the behavior should be well-defined
[20:47:35] <cradek> people used to say that about g20/g21 but they were just making an excuse for a bad implementation (IMO)
[20:55:32] <cradek> fwiw, I think I agree with your idea of putting it right after G20/G21 (you could even call it the same time as G20/G21 since they work independently but are similar conceptually)
[20:55:36] <les_> Slight snag. I can't easily change the way G7/G8 behave. It appears that the axis values are read before the block is executed. Therefore G7/8 will only ever take effect on the next block.
[20:56:50] <cradek> yeah, read_* parse the entire line before any evaluation is done. it has to be that way, since you can put the gcode words in any order without changing their meaning
[20:59:39] <cradek> in that thread didn't we also decide/suspect that X should be radius for some operations?
[20:59:58] <jmkasunich> joomla sucks
[21:00:08] <cradek> G10 L1 seems like one of those
[21:00:41] <cradek> I also think that G76's I,J,K should be diameter when in diameter mode
[21:00:54] <jmkasunich> eww
[21:01:13] <jmkasunich> I just happen to be programming a G76
[21:01:44] <jmkasunich> you are probably right, but it better be spelled out somewhere ON the g76 page
[21:02:01] <cradek> jmkasunich: I'm trying to put aside the fact that I don't really care for the extra complexity tradeoff of diameter mode, and instead consider how it should work if we have it
[21:02:12] <jmkasunich> heh
[21:02:47] <cradek> if you can and/or care to do that too, how do you think g76 should work?
[21:02:55] <cradek> hi PeterW_
[21:03:05] <PeterW_> Hi
[21:03:09] <cradek> how's stepgen?
[21:03:20] <PeterW_> Better!
[21:03:23] <cradek> yay
[21:03:27] <jmkasunich> after thought, I think you are right
[21:03:39] <jmkasunich> it's just that I can never do a G76 without referring to the docs
[21:03:44] <cradek> same here
[21:03:48] <jmkasunich> the working will have to be very carefull to not be confusing
[21:03:51] <PeterW_> Ive got bitfiles if anyone want to test
[21:03:59] <PeterW_> (wants)
[21:04:02] <les_> Reading thgrough a Fanuc manual, only X is ever diameter. I'm not sure about G10 though.
[21:04:04] <jmkasunich> "beyond the thread peak" implies radius
[21:04:18] <jmkasunich> s/working/wording
[21:04:25] <jmkasunich> I wish I could spell/type
[21:04:35] <jepler> PeterW_: I'm not near my machine with 5i20 now, but would be this evening
[21:05:00] <jmkasunich> PeterW_: I'm making some parts at the moment, but I might get a chance to test later
[21:05:15] <jmkasunich> maybe
[21:05:18] <cradek> les_: how do you specify thread "heights" etc in the fanuc canned threading cycle?
[21:07:42] <cradek> (or maybe it's completely different - doubt anything is just like our G76)
[21:08:52] <cradek> jmkasunich: did you finish and check in the absolute arc centers?
[21:09:26] <cradek> sorry, I should have just looked, yes you did
[21:10:52] <jmkasunich> cradek: I have a minor gripe about G76
[21:10:59] <jmkasunich> dunno if I griped this before or not
[21:11:01] <cradek> les_: the more I think about this, the more complex it gets
[21:11:06] <cradek> jmkasunich: uh-oh
[21:11:13] <jmkasunich> I'm doing an internal thread
[21:11:26] <jmkasunich> I start on the drive line, the final depth of cut is 0.060
[21:11:42] <cradek> I=0?
[21:11:50] <jmkasunich> after the first pass, it doesn't pull out to the drive line, it pulls out ~0.060 past the drive line
[21:12:09] <jmkasunich> I = 0.01
[21:12:22] <cradek> hmm
[21:12:22] <jmkasunich> sorry, wording unclear
[21:12:35] <cradek> yeah, I think the pullout is the same for all passes
[21:12:39] <jmkasunich> my drive line clears the bore of the hole
[21:12:40] <jmkasunich> yep
[21:12:53] <jmkasunich> that pullout will push the back of the tool against the other side of the hole
[21:13:07] <cradek> I bet the problem is even worse if you have tapered infeed
[21:13:21] <jmkasunich> you mean 29 deg? not really
[21:13:35] <cradek> no, I mean ... uh, have to look at the docs
[21:13:42] <jmkasunich> the entire retract pass is offset in X by whatever the pullout is
[21:14:12] <cradek> I mean E!=0, L1 or L3
[21:14:13] <jmkasunich> for OD threading it doesn't much matter - you can set the drive line well outside the part, and if the return passes are another 0.060 outside that, who cares
[21:14:18] <jmkasunich> oh
[21:14:30] <les_> The Fanuc 20-TA canned cycle is very primitive. It is simply a single pass with retract. X is diameter.
[21:14:36] <jmkasunich> fortunately I'm threading all the way thru, so I'm not doing that
[21:15:01] <cradek> jmkasunich: I'd be thrilled if it did not ever go past the drive line
[21:15:05] <jmkasunich> for ID threading, the drive line may be threading a needle down the center of the hole
[21:15:21] <cradek> jmkasunich: so, in effect, I have the same gripe
[21:15:32] <jmkasunich> so you're saying, PGA?
[21:15:41] <cradek> haha
[21:16:02] <cradek> (patches|commits|fixes)GA
[21:16:03] <jmkasunich> for my current problem, I'll probalby write a loop with G33
[21:16:19] <jmkasunich> since I want to cut metal today
[21:16:21] <cradek> yeah, that's the easiest way to get on with it
[21:16:41] <jmkasunich> glad I tested with no tool on the toolpos
[21:16:42] <cradek> no shame in using G33, that's what it's for - when you need "anything else"
[21:16:42] <jmkasunich> t
[21:18:31] <cradek> I have to admit I had mostly outside threading in mind when I did g76. inside (X positive from drive line) was an afterthought
[21:19:11] <jmkasunich> well, it works, so I won't complain too loudly
[21:19:29] <jmkasunich> just not for coarse threads (large depth of cut, hence large pullout) in small holes
[21:19:49] <cradek> worst of all worlds
[21:20:06] <jmkasunich> my Z is just barely fast enough to track my slowest spindle speed (175 rpm) at 5 tpi
[21:20:20] <jmkasunich> I'm starting 2" outside the part to let it catch up
[21:20:42] <cradek> are you running recent trunk? it shouldn't have to do any catchup if so
[21:20:48] <jmkasunich> 2.2.8
[21:21:08] <cradek> ah, good thing you have a lot of Z to spare.
[21:21:10] <jmkasunich> there is still accel time
[21:26:18] <cradek> les_: anything I can do to help?
[21:28:00] <cradek> hi matt!
[21:28:11] <mshaver> Hi chris!
[21:28:47] <cradek> PeterW has a fixed stepgen for you to try...
[21:28:47] <mshaver> just cleaning up here at smithy, getting ready to take a nap until morning, then drive home
[21:28:57] <mshaver> really?
[21:29:03] <cradek> so I hear!
[21:29:14] <jmkasunich> PeterW_: did you build the mshaver flavor bitfile, or just a regular SVST one?
[21:29:21] <mshaver> yep, it sounded like he had it all figured out
[21:30:04] <cradek> 15:03:51 < PeterW_> Ive got bitfiles if anyone want to test
[21:30:38] <mshaver> it would be the same as the second one he sent me, but with the fix. I will need another soon as peter made another version of the rs422 board which will change my pinout slightly
[21:30:39] <cradek> he may have wandered off though, or we bored him to tears with our other talk about diameter mode
[21:31:03] <mshaver> i've really got to learn to make these myself...
[21:31:18] <les_> cradek: Thanks. I think the main thing to do at the moment is to decide if my current plan to use read_x is the right way to go.
[21:31:37] <PeterW_> I have mshaver.bit and svst8_4.bit atm
[21:31:38] <les_> On the up side it is easy to code, covers most eventualities and is easy to maintain.
[21:31:39] <jmkasunich> we (jepler and I and peter) working on the ability to make bitfiles from the command line
[21:32:49] <mshaver> cradek: a while back i sent you some code for eztrol. What do you really think of this - future inclusion into the source tree.
[21:33:29] <mshaver> Perter_W: e-mail it to me & I'll put it on the lathe right now!
[21:33:38] <mshaver> darn...
[21:34:01] <mshaver> PeterW_: e-mail it to me & I'll put it on the lathe right now!
[21:34:20] <jmkasunich> tab-completion ;-)
[21:35:29] <mshaver> hey, you're right! this client does do tab completion
[21:36:20] <mshaver> also, Peter did send me an e-mail asking whether I'd like to test a new bitfile
[21:36:30] <PeterW_> Done
[21:37:39] <mshaver> new file is here! going to try it now!
[21:38:37] <PeterW_> (hope Sebastians driver doesn't barf on changed revisions)
[21:38:38] <PeterW_> Stepgen revision bumped from 0 to 1
[21:38:47] <cradek> les_: to me, not being able to honor G7/G8 before reading X seems like a show stopper for that implementation
[21:39:03] <cradek> but like you, I sure appreciate how simple it is
[21:40:04] <seb_kuzminsky> hi guys
[21:40:11] <seb_kuzminsky> the current driver *does* check MD version
[21:40:25] <cradek> this is sure a happenin' place
[21:40:40] <seb_kuzminsky> if the only diff between stepgen v0 and stepgen v1 is the stepspace/steplen fix, i'll update trunk to accept both
[21:43:19] <les_> cradek: I could modify Interp::find_ends instead. I'll have to investigate the implications.
[21:43:28] <PeterW_> Thats all:
[21:43:30] <PeterW_> ++if (stepmsb = '1' and nextmsb = '0' and stepdir = '0')-- we would count up
[21:43:32] <PeterW_> ++or (stepmsb = '0' and nextmsb = '1' and stepdir = '1') then -- we would count down
[21:43:33] <PeterW_> ++wewouldcount <= '1';
[21:43:35] <PeterW_> ++else
[21:43:36] <PeterW_> ++wewouldcount <= '0';
[21:43:38] <PeterW_> ++end if;
[21:43:40] <PeterW_> --wewouldcount <= nextmsb xor stepmsb;
[21:45:04] <seb_kuzminsky> ok, hold on
[21:48:46] <PeterW_> I can build a temp bitfile with the old version but I wanted the old bifiles to be detectable
[21:49:05] <seb_kuzminsky> makes sense
[21:49:17] <seb_kuzminsky> i'll have the driver emit a warning message if it sees a stepgen v0
[21:50:58] <jepler> how many bits for version number?
[21:51:03] <seb_kuzminsky> 8
[21:51:08] <seb_kuzminsky> ;-)
[21:51:14] <jepler> if there are plenty, maybe you could split it for "compatible" and "incompatible" changes, if there is such a thing
[21:59:59] <les_> Off to bed now - it's been a long day.
[22:05:57] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/ (encoder.c hostmot2.c hostmot2.h ioport.c pwmgen.c watchdog.c): change md-validating code so the complaining is optional
[22:06:16] <CIA-42> EMC: 03seb 07TRUNK * 10emc2/src/hal/drivers/mesa-hostmot2/stepgen.c: accept both stepgen v0 and v1, but warn about v0
[22:06:20] <seb_kuzminsky> mshaver: there we go, give that a try
[22:06:36] <seb_kuzminsky> it compiles, but i havent tested it at all... i have no anyio boards within reach...
[22:31:01] <seb_kuzminsky> PeterW_: can you send me a v1 stepgen .bit to test with tonight?
[22:39:15] <mshaver> ok, I tried the new firmware
[22:39:25] <mshaver> it's interesting
[22:39:46] <jmkasunich> "interesting" is often not the same as "works great!"
[22:41:33] <mshaver> swapping back and forth between the previous version and this version, everything else being the same, the new firmware causes the X and Z axes to move simultaneously when a Z move is commanded. Regardless of the Z move direction, X always moves in the minus direction.
[22:41:48] <seb_kuzminsky> ugh
[22:41:59] <seb_kuzminsky> that's no good at all
[22:42:17] <seb_kuzminsky> cnc machines should be boring, not interesting...
[22:42:38] <seb_kuzminsky> well, i dont *think* that's the driver changes...
[22:42:42] <mshaver> another thing, unless I run my base and servo threads at 10kHz, the movement is rough sounding
[22:43:08] <jmkasunich> argh
[22:43:16] <seb_kuzminsky> tonight i may try to implement the workaround that jmk suggested last night
[22:43:24] <seb_kuzminsky> then v0 stepgens should work for you
[22:43:42] <seb_kuzminsky> unless PeterW_ fixes the firmware before then
[22:43:45] <mshaver> I haven't tried stepspace=0 yet
[22:43:51] <seb_kuzminsky> i'll be back in a couple of hours
[22:43:56] <jmkasunich> mshaver: get out halscope
[22:44:03] <mshaver> ok
[22:44:19] <jmkasunich> check the position feedbacks of both stepgens (look at the hm2 pins, not the axis pins)
[22:44:38] <jmkasunich> see whether only one hal pin changes, even tho both axes are moving
[22:44:53] <jmkasunich> if so, it is almost certainly some kind of pinout oops in the fpga file
[22:44:59] <mshaver> ok, give me 5 mins
[22:45:14] <mshaver> yep, it's an oops, I'm sure
[22:45:19] <jmkasunich> if the Z step pin is going to both X and Z, but the dir isn't, that would give the exact symptoms you have
[22:45:19] <mshaver> but I'll check it out
[22:45:32] <mshaver> yep
[22:45:35] <jmkasunich> we gotta get PeterW_ onto CVS
[22:45:54] <jmkasunich> then we could check things like the pinout, and fix it without bothering him
[22:46:14] <mshaver> I have the source files
[22:46:33] <jmkasunich> for the latest version, as of just now?
[22:46:54] <mshaver> http://www.mattshaver.com/kc6/newsteptest.zip
[22:46:56] <mshaver> yes
[22:47:01] <jmkasunich> oh, he sent you everything
[22:47:05] <mshaver> peter always sends the whole lot
[22:47:24] <jmkasunich> well, sort of
[22:47:29] <jmkasunich> the stuff that changed anyway
[22:48:06] <mshaver> I have the older sources as well
[22:48:22] <jmkasunich> there are older sources in our cvs, and therefore in my checkout
[22:48:51] <mshaver> but this is a custom pinout
[22:49:19] <jmkasunich> it's in there
[22:51:07] <jmkasunich> ick
[22:51:46] <mshaver> ick?
[22:52:57] <jmkasunich> - IOPortTag & x"00" & StepGenTag & StepGenStepPin, -- I/O 04
[22:52:58] <jmkasunich> + IOPortTag & x"01" & StepGenTag & StepGenStepPin, -- I/O 04
[22:53:09] <jmkasunich> the ick was just looking at the files
[22:53:28] <jmkasunich> the xilinx editor uses 3 space tabs or some such crap, they are horrible on a regular screen
[22:53:51] <jmkasunich> anyway, the lines I posted are from a diff of the new IDParms.vhd (in your zip) and the one in our CVS
[22:54:09] <jmkasunich> there are other differences that seem logical, but this one smells wrong
[22:54:40] <mshaver> I/O4 is one of my step lines I think
[22:54:54] <jmkasunich> is PeterW_ still here? I'm not quite sure how to interpret those lines
[22:55:37] <jmkasunich> all the other changes to that file are of the form:
[22:55:43] <jmkasunich> - (StepGenTag, x"00", ClockLowTag, x"0C", StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask),
[22:55:43] <jmkasunich> + (StepGenTag, x"01", ClockLowTag, x"0C", StepGenRateAddr&PadT, StepGenNumRegs, x"00", StepGenMPBitMask),
[22:55:47] <mshaver> yep: I/O4 StepGen STEP (X Axis) 7I34-TX0
[22:56:07] <jmkasunich> freaking long lines - I hates them!
[22:56:58] <mshaver> The Z step signal s/b on I/O8
[22:57:05] <mshaver> typo
[22:57:37] <jmkasunich> there are 17 instances of the "other changes" thing I posted, only the one instance of the -- I/O 04 change
[22:59:07] <mshaver> that's the problem, both of the step outputs are tied together and driven by stepgen 0
[22:59:32] <jmkasunich> stepgen 1 I think
[22:59:51] <jmkasunich> note the line with the +
[23:00:12] <jmkasunich> Z should be (and probably is) on 8
[23:00:20] <jmkasunich> Z is also on 4 because of that change
[23:04:32] <mshaver> if peter shows up again tonight, i can test another build
[23:05:01] <mshaver> I _think_ i'm leaving for home tomorrow morning, but I have to check weather.com
[23:05:20] <mshaver> possible storm may have me bolting out of here tonight :(
[23:07:00] <SWPadnos> hmmm. which storm?
[23:07:35] <PeterW_> OK what did I break?
[23:07:38] <mshaver> everyone keeps telling me a storm is coming
[23:07:43] <jmkasunich> PeterW_: pinout
[23:08:04] <jmkasunich> - IOPortTag & x"00" & StepGenTag & StepGenStepPin, -- I/O 04
[23:08:04] <jmkasunich> + IOPortTag & x"01" & StepGenTag & StepGenStepPin, -- I/O 04
[23:08:04] <SWPadnos> yeah -the one I need to drive through twice, once with an empty trailer, once with a full trailer :(
[23:08:17] <jmkasunich> IDParms.vhd, latest copy vs. the one in CVS
[23:08:22] <jmkasunich> I don't think you intended that change
[23:08:22] <mshaver> PeterW_: swapping back and forth between the previous version and this version, everything else being the same, the new firmware causes the X and Z axes to move simultaneously when a Z move is commanded. Regardless of the Z move direction, X always moves in the minus direction.
[23:08:52] <mshaver> I have time to retest this evening if you like!
[23:08:53] <jmkasunich> that is line 2012 in the file
[23:11:56] <PeterW_> No i got carried away with my version editing (need a constant for that)
[23:12:53] <PeterW_> Mshaver did you just update to trunk or should I send you a fixed bitfile with rev (0)
[23:15:57] <mshaver> PeterW_: I updated my TRUNK yesterday morning
[23:16:15] <jmkasunich> I'm getting very confused
[23:16:42] <jmkasunich> what does trunk have to do with these latest changes - they were sent direct from peter to matt, and aren't in cvs yet
[23:16:58] <jmkasunich> oh, I get it
[23:17:03] <mshaver> all the tests i've been running are with TRUNK from Tuesday morning
[23:17:31] <jmkasunich> seb fixed the driver in cvs trunk (just now) so it won't fail if it sees a version 1 stepgen
[23:17:39] <PeterW_> Sebastian just updated the driver not to barf on the rev. 1 stepgen so I'm sending you a bitfile that reports rev0
[23:18:04] <mshaver> OK!
[23:18:05] <jmkasunich> matt should just do a cvs update, so he'd have seb's revised driver
[23:18:12] <mshaver> OK!
[23:18:28] <jmkasunich> well, pick one or the other, so PeterW_ knows what bitfile to send you
[23:18:53] <jmkasunich> I guess one that reports rev 0 is safest, but it is something that shouldn't really be set free in the wild
[23:19:02] <jmkasunich> (it lies about its version)
[23:19:11] <mshaver> how about I keep the TRUNK I have now
[23:19:24] <jmkasunich> the ONLY reason to have the bitfile lie about the version is if you have an old driver that wants version 0
[23:19:33] <jmkasunich> you are going to wind up with a bastard bitfile
[23:19:47] <jmkasunich> "cvs up" takes what, 2 minutes?
[23:20:19] <mshaver> OK, I'll update TRUNK, but why does the firmware rev have to match EMC?
[23:20:30] <jmkasunich> the driver checks the firmware version
[23:20:30] <PeterW_> Well at least you can check that the driver belly-aches about it
[23:20:52] <jmkasunich> some firmware changes might require the driver to do something different
[23:21:09] <PeterW_> Theres a firmware version for each module...
[23:21:49] <jmkasunich> which is a good thing
[23:22:06] <jmkasunich> peter released a new stepgen, and bumped the version
[23:22:09] <jmkasunich> which is a good thing
[23:22:19] <jmkasunich> seb released a driver that accepts the new version
[23:22:22] <jmkasunich> which is a good thing
[23:22:31] <mshaver> OK, I'll try what you just sent with my current TRUNK, and then with an updated TRUNK - we'll see if seb's driver notices
[23:22:48] <PeterW_> Mshaver: sent you a new bitfile (reports rev 0 though), building proper bitfile now
[23:23:47] <mshaver> should I wait? and just update TRUNK?
[23:23:54] <seb_kuzminsky> the new trunk should accept both stepgen v0 and v1, but complain about v0
[23:24:08] <jmkasunich> update your cvs checkout
[23:24:22] <mshaver> OK, updating!
[23:24:40] <jmkasunich> you should pretty much _always_ be updating your cvs checkout - if you are gonna run cvs, then you should be running the latest cvs
[23:25:01] <mshaver> SWPadnos: snow is said to start in Ann Arbor between 9pm Thursday & Midnight
[23:25:24] <mshaver> true, going to do that now & recompile
[23:26:53] <PeterW_> Just sent mshaver1.bit (should report version 1 stepgens)
[23:27:25] <mshaver> got it, will test latest cvs & bitfile
[23:27:32] <mshaver> give me a few mins
[23:48:55] <mshaver> http://www.mattshaver.com/kc6/g0z8vel235a50.png
[23:49:07] <mshaver> I think it's fixed.
[23:49:19] <skunkworks> that looks nice :)
[23:49:31] <mshaver> yep
[23:53:59] <jmkasunich> yay!
[23:54:51] <mshaver> 235"/min & SCALE=50800 that's pretty good!
[23:56:06] <jmkasunich> sure is
[23:56:18] <jmkasunich> right up there a percent or two below abs max for the amps
[23:56:29] <jmkasunich> that is one quick lathe
[23:56:30] <mshaver> I wonder why I have to run such a fast base & servo rate - I need to experiment with this some to see what's going on
[23:56:47] <mshaver> I can't wait to get threading working
[23:56:55] <jmkasunich> (as I listen to my 35ipm lathe threading 5tpi at only 180 rpm)
[23:57:06] <mshaver> I want to bring this machine to the workshop next year
[23:57:30] <jmkasunich> how big is it? 500 lbs, 1000, 2000?
