Back
[00:18:00] <jepler> jmkasunich: yes at the moment
[00:19:26] <jmkasunich> what kind of noise issues are you seeing? random edges when you are far from the switch, or extra edges right around the real one?
[00:22:01] <jepler> oh whoops -- I just ran that trace isolation at 200% feed override
[00:22:06] <jepler> jmkasunich: random edges
[00:23:01] <jmkasunich> is the switch NO or NC? (which state is it in when the random edges appear?)
[00:23:25] <jepler> I am using the NC terminal
[00:23:42] <jmkasunich> so it is closed and you still see noise.... interesting
[00:23:58] <jmkasunich> what is the existing circuit? pull up, pull down, cap, etc?
[00:24:51] <jepler> no cap. pull up.
[00:25:09] <jmkasunich> switch is pulling down, right?
[00:25:41] <jmkasunich> how strong is the pullup?
[00:25:51] <jmkasunich> and are you sure you don't have any intermittent connections?
[00:27:58] <jepler> no I'm not that confident of my job soldering the switches
[00:28:15] <jepler> in fact that seems like the most likely cause of the noise to me
[00:28:43] <jmkasunich> well, usually solder joints are pretty good, unless they are visibly hideous
[00:28:56] <jmkasunich> I was envisioning crimped or twisted wires, etc
[00:29:13] <jmkasunich> crappy crimps that is - proper crimps are very reliable
[00:29:33] <jepler> the problem is that immediately behind the solder joints I bent the wires to fit them into the available space
[00:29:58] <jmkasunich> think they might have cracked?
[00:30:06] <jepler> or something
[00:30:09] <jepler> that's my theory
[00:31:29] <cradek> jepler: have you halscoped any other pluto inputs?
[00:33:13] <jepler> cradek: no
[00:33:55] <jepler> (unfortunately, they are all in fact just floating -- there's no option to use in-fpga pull-ups or downs -- so it would be a pretty useless test)
[00:34:02] <jepler> (yes I know that is a bad thing)
[00:35:30] <cradek> would someone please tell month-ago-me to meter the supply voltages for the servo amps before I take the control all apart?
[00:36:11] <jepler> hah that's not funny at all
[00:38:37] <rayh> 90 volt
[00:39:50] <cradek> rayh: I did measure that one - it's +v, -v that I'm trying to find in the book
[00:40:31] <rayh> Where is that used? The logic, the stepper?
[00:41:01] <cradek> the logic, it's on the screw strip with the tach and velocity inputs
[00:41:47] <cradek> +15, -15, +-1
[00:42:13] <rayh> You got it.
[00:42:35] <cradek> hm it's optional...?
[00:42:37] <cradek> still reading
[00:42:42] <cradek> (thanks for the book!)
[00:43:39] <rayh> Glad I found it.
[00:45:17] <cradek> oh I see, they supplied a separate bias supply if requested
[00:46:18] <rayh> I don't think I ever saw one of those power supplies.
[00:46:56] <cradek> one of the 9 (!) other transformers is probably it, I can reuse it
[00:47:21] <cradek> 10
[00:50:12] <rayh> There are a pile of transformers in there.
[00:56:15] <cradek> what's funny to me is the big one isn't the servo supply
[00:57:35] <jmkasunich> is the big one making 5V and <large> amps?
[01:00:56] <rayh> I've got a three +5 volt switcher supplies out there 85 amp continuous.
[01:01:17] <rayh> AB stuff.
[01:01:22] <skunkworks> the servo supply for the k&t is about 100 gallons of oil.. ;)
[01:01:52] <jmkasunich> the nice thing about electricity is that when it leaks it doesn't leave a puddle
[01:01:59] <skunkworks> exactly
[01:02:21] <rayh> Do the servo proportioning valves still work on that k&t.
[01:02:42] <skunkworks> they did when the control finally smoked.. about 2 years ago
[01:02:55] <skunkworks> there are only 2 - we probably have 4 total
[01:03:45] <skunkworks> (initially we had 2 complete machines.)
[01:05:28] <skunkworks> question.. well - now that I think about it - I could just post jeplers release notes on his site... but there shouldn't be an issue posting on cnczone about the tormach config?
[01:16:22] <cradek> what kind of issue?
[01:32:30] <jepler> IMO anything that happens in irc, the mailing lists or cvs is public, unless it's an obvious error like posting a password. It's very much a matter of fact that there's a configuration for the tormach machine in 2.2.6..
[01:35:41] <cradek> oh, I agree if that's the question
[01:37:37] <jepler> whee I now have the switches wired independently, instead of in series
[01:38:17] <jepler> on about the third try I got a usable board ..
[01:41:48] <cradek> neat
[01:43:47] <jepler> now I'd better make good on my promise to be social after getting this working :(
[01:43:51] <jepler> I mean :)
[01:43:52] <jepler> have a good night guys
[01:45:13] <jmkasunich> jepler: I bet you could have wired the circuit up on perfboard in 1/2 the time it took to make a PC board
[01:45:26] <jmkasunich> (if its the simple kind of thing I think you just did)
[01:58:23] <jepler> jmkasunich: I'm sure you're right, but I also want to exercise the machine and software
[02:00:07] <jepler> http://ask.metafilter.com/99131/Drowning-In-Waves
[02:01:12] <cradek> yay, got the servo drives and power supply out
[02:02:50] <cradek> I love the "questionable scientific merit" advice
[02:03:46] <skunkworks> ok - I think I compiled the gopt.. what is the incarnation?
[02:03:50] <skunkworks> incantation?
[02:04:07] <jepler> skunkworks: gopt.py < input.ngc > optimized.ngc
[02:04:26] <jepler> input.ngc has to be a gcode file with special comments (the files generated by gcode.ulp fit into this category) or there will be no effect
[02:04:52] <cradek> gopt.py is very slick
[02:05:09] <jepler> it should print a few lines on the terminal, ending with a line that tells you how many inches of G0 moves you saved
[02:05:10] <skunkworks> Yes - I have used it before.
[02:05:14] <skunkworks> it works wonders
[02:07:47] <jmkasunich> jepler: I understand completely
[02:08:10] <jmkasunich> * jmkasunich is making a scraped straightedge - I could have bought one
[02:12:30] <skunkworks> do you need the < >?
[02:12:54] <skunkworks> yes you do :0
[02:12:58] <skunkworks> :)
[02:13:28] <skunkworks> total inprovements 618? I assume that is mm?
[02:13:41] <cradek> if it's inch gcode, it's inches
[02:14:16] <skunkworks> woo
[02:14:28] <cradek> look at the rapids before and after - it's very easy to see
[02:19:14] <skunkworks> http://imagebin.org/24197
[02:19:26] <cradek> ah, much better
[02:20:22] <skunkworks> http://imagebin.org/24164
[02:20:31] <skunkworks> ^yes - original
[02:21:10] <cradek> 618 inches is 20 extra minutes on my machine
[02:21:44] <jepler> the picture tells the story
[02:21:57] <jepler> I should get gopt into the package repository and blog it again..
[02:22:31] <skunkworks> do you have a blog entry for this? (showing sytax?)
[02:22:34] <cradek> it only works for closed loops or points (like drills)
[02:23:13] <jepler> skunkworks:
http://axis.unpy.net/downloads/01103508580 http://unpy.net/cgi-bin/viewcvs.cgi/tsp/Attic/README?rev=1.1.2.1;content-type=text%2Fplain
[02:24:16] <jepler> hah I wrote that readme when max was much slower than it is now
[02:24:19] <jepler> 10IPM rapids
[02:24:44] <cradek> wow
[02:24:49] <cradek> that really hurt
[02:25:37] <cradek> 30 seconds to move from one end of the board to the other...
[02:25:51] <cradek> (it's still slow, of course)
[03:22:34] <fenn> jepler: small world, one of the answers on the 'drowning in waves' page is my brother
[03:22:40] <fenn> (sergeant sandwich)
[03:30:58] <fenn> heh he listens to feist
[12:39:42] <skunkworks_> logger_dev: bookmakr
[12:39:42] <skunkworks_> I'm logging. I don't understand 'bookmakr', skunkworks_. Try /msg logger_dev help
[12:39:46] <skunkworks_> logger_dev: bookmark
[12:39:46] <skunkworks_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2008-08-14.txt
[12:39:57] <jepler> good morning skunkworks
[12:43:47] <skunkworks_> Good morning jepler
[12:44:10] <skunkworks_> Are the limit switches sorted out?
[12:45:22] <jepler> now that they are on independent inputs I have to look at the noise issue again -- I will be able to tell if it's occurring on a particular switch.
[12:45:44] <jepler> there's also still no homeswitch on 'Z' (only the tool length sensor) so I'll want to add that at some point
[12:46:44] <skunkworks_> Neat.
[12:50:03] <mozmck> jepler: do you have any filtering on the switches?
[12:51:41] <jepler> mozmck: before, I didn't. Now I have an RC filter but haven't tested again to see whether I get noise
[12:52:09] <jepler> the noise that worries me is not contact noise, it's spurious TRUE inputs when the switch is nowhere near being closed
[12:52:37] <skunkworks_> like communication issues with the pluto?
[12:53:09] <jepler> skunkworks: no, I doubt that's it.
[12:53:54] <jepler> it's sooooo reliable .. communication errors would show up quickly as following errors
[12:54:29] <mozmck> just a .1uF cap to ground will often work pretty well.
[12:54:58] <mozmck> TRUE inputs?
[12:58:14] <mozmck> what is the input level on whatever you are inputting to? 5V?
[12:58:28] <jepler> the input circuit looks about like this:
http://emergent.unpy.net/files/sandbox/inputs.png (first revision had no cap) -- if the wiring to the switch terminals is intermittent, you'd get spurious HIGH/TRUE readings
[12:59:23] <jepler> 3.3v pull-up going to 3.3v logic
[12:59:27] <mozmck> With the pullup resistor it will be high all the time now won't it?
[12:59:56] <mozmck> oh wait, no it won't
[13:00:03] <jepler> no -- I used the NC switch contact so normally the input is grounded
[13:00:11] <mozmck> i see.
[13:00:27] <mozmck> 3.3v is much more difficult
[13:00:41] <mozmck> far less noise immunity.
[13:01:06] <jepler> it's not correlated with running the spindle or other sources of noise
[13:01:50] <mozmck> not even the axis motors?
[13:02:26] <jepler> I guess I didn't test with the drivers off
[13:02:32] <mozmck> I'm not sure what a logic high is on a 3.3v system, but I know it's less than 3 volts.
[13:02:38] <jepler> bbl -- thanks for some troubleshooting ideas
[13:03:06] <mozmck> the cap may do the trick.
[13:03:40] <mozmck> one problem we had once is undershoot, I guess because of inductance on the switch lines.
[13:04:31] <mozmck> we cured it by putting a 330 ohm resistor in series with the pin.
[17:15:13] <skunkworks_> seb! sound like the hostmot is coming along :)
[17:15:35] <seb_kuzminsky> nothing like testing to find bugs...
[17:16:16] <skunkworks_> That is about all I am good for ;)
[17:39:08] <alex_joni> hi all
[17:41:32] <seb_kuzminsky> hi alex_joni
[17:42:52] <alex_joni> hey seb... how's it going?
[17:43:16] <alex_joni> * alex_joni has been doing different CNC stuff lately
[17:43:22] <alex_joni> mostly physical things :D
[17:43:36] <alex_joni> coding is more fun sometimes ....
[17:43:57] <seb_kuzminsky> i'm looking forward to physical CNC things some day :-)
[17:44:09] <alex_joni> I've been aligning some robot positioners today
[17:44:34] <alex_joni> they were too big for transport so they were made from 2 pieces
[17:44:43] <alex_joni> ~ 18m long both of them
[17:45:17] <alex_joni> aligning the rails on those is no fun
[17:50:09] <cradek> seb_kuzminsky: is it true that encoder index handling isn't in hm2_5i20 yet?
[17:52:13] <seb_kuzminsky> cradek: yes its true
[17:52:29] <cradek> ok, just checking
[17:52:47] <seb_kuzminsky> is it something you'd like to use? i could make it a priority to add it
[17:52:55] <cradek> yes that will keep me from using it on the hnc project
[17:53:20] <cradek> also the hnc could really use a feature I understand is in hm2, but may not be available in our driver: index input masking
[17:53:38] <seb_kuzminsky> i *think* it has that feature but i'm not sure
[17:53:45] <cradek> the hnc has many indexes per screw revolution, and a prox on the screw pulley that you can use to mask all but one per revolution
[17:53:59] <seb_kuzminsky> hm
[17:54:01] <cradek> they call that prox the fine limit switch
[17:54:15] <cradek> there is also a coarse limit switch on the axis motion
[17:55:24] <cradek> it is an unusual setup.
[17:56:02] <alex_joni> sounds like a very precise setup
[17:56:03] <skunkworks_> won't you have a single index with the resover->encoder converter
[17:56:06] <cradek> I could also AND the two home switches and feed that to motion's home switch input, but I think it would have trouble not overshooting the fine home switch
[17:56:16] <cradek> arg, I meant fine/coarse HOME switch above, not limit
[17:56:31] <cradek> skunkworks_: the resolver turns many times per screw rev
[17:56:54] <skunkworks_> oh - some reason I thought it was attached to the leadscrew.. Must have been the tach
[17:57:15] <cradek> neither is attached directly to the screw. they are both geared up.
[17:57:24] <skunkworks_> oh
[17:57:51] <cradek> motor ---belt--- screw ---very precise gear--- tach and resolver
[17:57:51] <alex_joni> hopefully withou play
[18:02:37] <cradek> it is very carefully aligned so all three signals (index, both home switches) can happen at the same time. this is how the original control homed.
[18:03:35] <cradek> the home switch is on for only about .005" of travel and the index has to be within that.
[18:03:47] <cradek> err, 'both home switches are on'
[18:04:29] <alex_joni> the combo switch
[18:04:57] <cradek> it is not a great match for emc because you can be on the wrong side of it and not know.
[18:05:17] <cradek> but it would work nicely enough if I had the masking. I would have to start from the correct side, which would be easy.
[18:05:45] <seb_kuzminsky> how does encoder index masking work? i'm a noob
[18:06:06] <jepler> seb_kuzminsky: I think it's basically an AND of the index signal and another signal that takes place in the fpga before the index pulse handling is done
[18:06:17] <jepler> at least, that's what chris wants
[18:06:40] <cradek> yes I suspect that's it - I can't think of anything else that would be called that
[18:06:54] <jepler> the encounter should be reset to 0 and index-enable to false at the rising edge of index if index-enable and index-mask are true
[18:07:13] <cradek> if the fpga/driver doesn't have it, I could do the same thing in hardware. it is not a big deal really.
[18:07:22] <seb_kuzminsky> hm2 has "reset count on index"
[18:07:30] <jepler> I think I see what has to be done in the hostmot2 emc2 driver, assuming that what's in the hostmot firmware works
[18:08:14] <seb_kuzminsky> there's a bit in the encoder config register called "UseIndexMask", but i'm not sure what it does
[18:08:22] <jepler> seb_kuzminsky: yes -- I have been reading the vhd source code and I think it is going to be pretty easy to make it work with emc
[18:09:15] <seb_kuzminsky> if you want to AND the index with another signal, that signal needs to be available to the encoder module, and all it sees is A, B, and Index afaik
[18:09:22] <seb_kuzminsky> what am i missing?
[18:09:43] <jepler> 'indexmask' is another input into the vhdl qcounter entity
[18:11:50] <jepler> I'm not sure what physical pin that gets read from..
[18:14:58] <jepler> in the old firmware it may have been pins 1, 3, 5, 7, 17, 19, 21, 23 on connector P4
[18:18:38] <jepler> but in the hostmot2 .PIN files there is no mention of an index mask pin
[18:20:55] <jepler> cradek: so if you want index mask, the old 5i20 driver may be your better bet
[18:21:25] <cradek> ok
[18:21:52] <cradek> (I wonder how to enable it)
[18:22:35] <alex_joni> might need to hack the driver
[18:23:10] <jepler> add a new "index-mask" parameter in hal--when it's true you set another bit in the same 5i20 hardware register you set when you turn on index-enable
[18:24:36] <seb_kuzminsky> i just mailed pcw asking about this
[18:25:07] <cradek> I appreciate all your work, seb
[18:25:36] <seb_kuzminsky> thanks :-)
[18:29:35] <jepler> cradek: assuming the pinout in the manual is right for old hal_m5i20 it looks easy to add to the driver .. we can test it when you have your machine moving
[18:30:33] <cradek> excellent
[18:31:18] <cradek> would we put that in a release? I'd really prefer to use an unmodified version.
[18:32:07] <cradek> if it doesn't belong in the release I would probably just use external hardware to do it.
[18:32:33] <jepler> if it's as easy as I think it is, I'd stick it in 2.2
[18:33:40] <jepler> also adds inverts for index and index mask signals:
http://emergent.unpy.net/index.cgi-files/sandbox/5i20-index-mask-and-polarity.patch
[18:34:36] <cradek> neato. it does look simple.
[18:35:48] <cradek> I am happy with the mesa stuff so far. my only complaint is the screw terminals could be better.
[18:37:12] <jepler> oh on the 7i37t?
[18:37:26] <cradek> all three boards I got were "t"
[18:37:47] <cradek> the screws are inaccessible while the screw strip is plugged onto the board
[18:38:17] <cradek> the ones on the ppmc stuff are much, much better
[18:38:46] <cradek> but they stick off the end of the card - hmm
[18:38:58] <cradek> there has to be something better.
[18:39:24] <jepler> oh I didn't realize there was a 7i33t as well
[18:39:58] <jepler> I thought all their servo interfaces had the special amp connector blocks which are worse still
[18:40:26] <cradek> yeah, those are terrible.
[18:40:33] <jepler> there's simply not enough "edge" on the mesa boards to have 50 terminals..
[18:40:40] <cradek> no
[18:40:53] <jepler> at least not with .200 terminals
[18:40:57] <cradek> but they could use the type with the screw perpendicular to the board, and the wire goes in the side
[18:41:00] <jepler> some of elson's stuff uses .100, since it's all data and never power
[18:41:02] <cradek> then, face them opposite one another
[18:41:26] <jepler> (maybe it's all .100?)
[18:41:40] <cradek> these "t" boards are wire-perpendicular, screw-parallel
[18:42:18] <cradek> so one strip's screws face the other strip about .2" away
[18:43:08] <cradek> uh, I should give them my feedback, not you guys.
[18:43:20] <jepler> heh
[18:45:03] <jepler> hah! looking for the terminal on digikey, I can choose the following for "pitch": 1.37" (3.50mm), 1.38" (3.500mm), 1.40" (3.50mm)
[18:45:31] <cradek> wow
[18:45:46] <cradek> all aboard the failboat
[18:46:01] <alex_joni> seb_kuzminsky: info should be there by default I think
[18:46:09] <alex_joni> default rtapi debug level is 3 iirc
[18:46:23] <alex_joni> it's defined in /etc/emc2/rtapi.conf
[18:47:51] <alex_joni> jepler: actually neither of those is 3.50mm
[18:48:24] <cradek> I get .1378"
[18:48:24] <alex_joni> that sould be 1.3779527559055118110236220472441" :)
[18:48:40] <cradek> alex_joni: you fail too!
[18:48:47] <alex_joni> err.. yeah .***
[18:49:00] <alex_joni> your units are bogus anyways
[18:49:07] <cradek> here we go again
[18:49:27] <alex_joni> * alex_joni learned that they will never go again
[18:49:32] <alex_joni> so we won't go there again :D
[18:54:27] <seb_kuzminsky> alex_joni: yeah, it looks to me like eric's not seeing the info he wants because he didnt load the modules...
[18:55:19] <jepler> I think everyone so far has had trouble reading the documentation and getting the right sequence of load operations
[18:55:34] <seb_kuzminsky> jepler: for hostmot2?
[18:55:37] <jepler> yeah
[18:55:47] <seb_kuzminsky> ok, i'll try to fix that...
[18:55:52] <jepler> I sure didn't get it at first, but luckily alex_joni was here to read the docs to me
[18:55:57] <seb_kuzminsky> heh
[18:56:00] <jepler> I think it was alex_joni, maybe it was cradek
[18:56:07] <alex_joni> I think it was me :)
[18:56:16] <seb_kuzminsky> what docs helped? which ones didnt?
[18:56:18] <alex_joni> the manpages are quite good
[18:56:30] <alex_joni> I'm not sure how much there is in the regular manual
[18:56:30] <cradek> I mostly read your emails to the list when I was trying to figure it out
[18:56:44] <alex_joni> seb_kuzminsky: I'd stick some comments in the README at least
[18:56:52] <cradek> yes I would have liked to see a sample config with some comments
[18:57:04] <alex_joni> yeah...
[18:57:10] <cradek> one that works by default with my setup :-)
[18:57:10] <alex_joni> * alex_joni votes for a sample 4-4 config :)
[18:57:17] <seb_kuzminsky> like the ones in configs/hostmot2? :-P
[18:57:17] <alex_joni> 4 steppers, 4 servos :D
[18:57:36] <alex_joni> seb_kuzminsky: that's even a really good place to put them :D
[18:57:50] <cradek> I guess those didn't make it into 2.2.6?
[18:58:08] <seb_kuzminsky> yea they did
[18:58:24] <seb_kuzminsky> i think...
[18:58:58] <alex_joni> I only see some hal's there
[18:58:59] <cradek> yes they did. my mistake.
[18:59:00] <alex_joni> no ini
[18:59:07] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/configs/hostmot2/?only_with_tag=RELEASE_2_2_6
[18:59:10] <cradek> well that's true
[18:59:22] <seb_kuzminsky> right, just .hal, nothing else
[18:59:29] <alex_joni> that's not a sample config
[18:59:39] <alex_joni> a sample config is something you can pick from teh config picker :D
[18:59:52] <seb_kuzminsky> because i dont know the rest of the config system... i dont have a machine or anything yet...
[19:00:16] <seb_kuzminsky> my ui is halcmd ...
[19:01:31] <alex_joni> seb_kuzminsky: don't take it personal :)
[19:01:47] <alex_joni> any one of us could make this just as well
[19:02:22] <seb_kuzminsky> i hope to have my machines up and running by spring 2009, if no one adds the rest of the configs by then i will :-)
[19:03:10] <alex_joni> cradek has a 5i20, jepler has one, I have one, jmk has 2, swpadnos has 2, ...
[19:03:54] <seb_kuzminsky> but you all probably have them working with the m5i20 driver, so there's not much incentive to break working machines
[19:04:03] <alex_joni> mine is in a box
[19:04:11] <alex_joni> still in the original packaging
[19:04:17] <seb_kuzminsky> oh ok :-)
[19:04:45] <alex_joni> and it's a bit hard to plug it into my hardy laptop
[19:05:25] <cradek> and my machine is not working yet...
[19:05:33] <seb_kuzminsky> maybe if you fold it in half it'll fit in that slot on the side
[19:05:50] <alex_joni> nope. it's one of those half slots
[19:05:56] <alex_joni> so it'll be folding in 4
[19:06:00] <seb_kuzminsky> lol
[19:06:20] <alex_joni> and by that time I doubt I can connect anything to Px
[19:06:25] <cradek> so I have incentive to use the newest driver possible so I don't have to mess with it for a long time
[19:06:37] <jepler> I don't use my m5i20 either -- but someday I'll want to try out the hm2/m5i20 step generator and see how it compares to pluto-step
[19:07:01] <alex_joni> cradek: if I recall when you started working with emc it was the other way around :D
[19:07:37] <seb_kuzminsky> i think the hm2 driver's going to be messy for a little while yet, but thanks for volunteering to alpha-test :-)
[19:07:46] <cradek> eek
[19:08:08] <alex_joni> seb_kuzminsky: call it beta and he'll do it :D
[19:08:21] <alex_joni> or maybe gamma
[19:08:23] <seb_kuzminsky> oh yeah, that's what i meant, eric's the alpha
[19:08:45] <alex_joni> cradek: you also get 24/7 IRC support for FREE
[19:08:46] <seb_kuzminsky> and the frakking steppers didnt step, how embarassing :-(
[19:09:10] <alex_joni> although 50% of that support is rubbish :D
[19:09:26] <jepler> <cradek> can I ask a question about emc2?
[19:09:31] <jepler> [silence]
[19:09:31] <cradek> ha
[19:10:22] <cradek> I tried to use EMC and it didn't work. You losers can't expect me to use this if it doesn't even work. I am not a geek like all you abberations.
[19:10:41] <seb_kuzminsky> cradek: <shudder>
[19:10:58] <cradek> uh, sorry
[19:11:16] <jepler> cradek: you misspelled "approbation" hth
[19:13:04] <cradek> I hope one of you guys understands peter's reply...
[19:13:05] <alex_joni> <SteveStallings> cradek - Is it safe to assume you have looked around the SourceForge site enough to be aware of the EMC2 development fork?
[19:13:08] <alex_joni> <cradek> yes
[19:13:33] <cradek> he's amazingly responsive to emc questions/users
[19:13:51] <alex_joni> <cradek> so is anyone using emc2? what's the status of it?
[19:14:05] <alex_joni> <cradek> I looked briefly at the hal and it looks very nice (configurable)
[19:14:15] <alex_joni> that's from 2004.05.30 ;)
[19:14:21] <seb_kuzminsky> peter's good people
[19:14:32] <alex_joni> cradek: would you believe it's only 4 years?
[19:15:00] <cradek> I recall AXIS was written for emc1
[19:16:36] <alex_joni> http://axis.unpy.net/01118085817
[19:17:08] <cradek> heh
[19:17:13] <cradek> amazing
[19:17:20] <alex_joni> it is
[19:17:24] <alex_joni> hahaha
[19:17:30] <alex_joni> + printf("alex_joni was here\n");
[19:17:33] <alex_joni> ROFLMAO
[19:17:53] <alex_joni> that was my debugging skills back then :)
[19:19:24] <alex_joni> bbl
[19:19:53] <jepler> seb_kuzminsky: so .. I don't have a stepper motor hooked up but I can see what position-fb looks like from here
[19:20:05] <jepler> seb_kuzminsky: it doesn't stay stuck at 0, but it doesn't seem right
[19:20:28] <seb_kuzminsky> position-fb changes on a 5i20 with hm2?
[19:20:32] <jepler> (I'm also on a remote machine from it so I can't halscope)
[19:20:41] <jepler> seb_kuzminsky: with your modified stepgen.c that you mentioned on the list
[19:20:53] <seb_kuzminsky> oh ok! whew, i thought i was on crazy pills!
[19:22:17] <seb_kuzminsky> position_fb = counts/position_scale
[19:22:23] <seb_kuzminsky> is that the right way to think of it?
[19:23:08] <jepler> yes
[19:24:51] <seb_kuzminsky> hm, well i'll take a look at it tonite
[19:26:19] <jepler> http://emergent.unpy.net/files/sandbox/hm2-step-scoped.png
[19:26:57] <jepler> what is determining the rate it steps at?
[19:27:05] <jepler> since the input is a step function ..
[19:27:44] <jepler> the other thing I saw was in halcmd, on one occasion the velocity reported was 0 even though it was in "mid-move"
[19:27:47] <jepler> 4 s32 OUT -16065 hm2_5i20.0.stepgen.00.counts
[19:27:50] <jepler> 4 u32 OUT C13F8A56 hm2_5i20.0.stepgen.00.debug.accumulator
[19:27:52] <jepler> 4 float OUT 2.3935 hm2_5i20.0.stepgen.00.debug.error
[19:27:55] <jepler> 4 u32 OUT F1B2080C hm2_5i20.0.stepgen.00.debug.rate
[19:27:57] <jepler> 4 float IN -4 hm2_5i20.0.stepgen.00.position-cmd
[19:28:00] <jepler> 4 float OUT -1.6065 hm2_5i20.0.stepgen.00.position-fb
[19:28:02] <jepler> 4 float OUT 0 hm2_5i20.0.stepgen.00.velocity-fb
[19:28:15] <seb_kuzminsky> ehm, the stepgen code is *very* primitive right now and i'm not surprise if it lies and misbehaves
[19:29:15] <seb_kuzminsky> rate = error * position_scale / fperiod
[19:29:30] <seb_kuzminsky> error = position_cmd - position_fb
[19:29:46] <jepler> a trace with velocity-fb:
http://emergent.unpy.net/files/sandbox/hm2-step-scoped2.png
[19:29:52] <jepler> anyway bbl ..
[19:30:23] <seb_kuzminsky> thanks jepler
[21:52:10] <jepler> it's interesting to look at what pluto-step does with a step input instead of a nice smooth input
[21:53:23] <jepler> (it also doesn't have an acceleration paramter, but relies on the position input to have an acceptable acceleration profile)
[21:53:30] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/pluto-step-position-step.png
[22:00:46] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/pluto-step-position-smooth.png
[22:15:58] <jepler> * jepler pushes pluto-step to a 4kHz servo cycle
[22:15:59] <jepler> Period FP Name ( Time, Max-Time )
[22:15:59] <jepler> 249753 YES servo-thread ( 276141, 316987 )
[22:16:15] <jepler> not too shabby!
[22:21:54] <skunkworks> Neat
[22:27:01] <jepler> CPU is 2133MHz so that represents about 50% of the time in the servo thread and 50% for everything else
[22:28:40] <skunkworks> is that bad?
[22:28:46] <skunkworks> how responsive is it?
[22:31:46] <jepler> oh -- there's no real benefit and it does lower responsiveness of the GUI
[22:31:53] <jepler> but hey I can say I do it
[22:32:08] <skunkworks> heh :)
[22:40:56] <jepler> I think it might do a tiny bit better at keeping up speed on flowsnake (lots of short segments and direction changes) at 4kHz than 1kHz
[22:41:10] <jepler> but frankly both are pretty good
[22:43:05] <BigJohnT> does the R word do anything in the G38 cycle?
[22:43:10] <BigJohnT> in the word table it says R is Arc radius or canned cycle plane
[22:43:12] <BigJohnT>
[22:43:14] <BigJohnT> the example in the manual is G83 X0.285 Y0.00 Z-0.500 R0.2 L1 Q0.05 which doesn't make sense for a drilling cycle...
[22:44:10] <jepler> and looking at halscope velocity plots I'm not sure there's really a difference!
http://emergent.unpy.net/index.cgi-files/sandbox/velocity-flowsnake-1khz.png http://emergent.unpy.net/index.cgi-files/sandbox/velocity-flowsnake-4khz.png
[22:44:22] <cradek> R in canned cycles is the 'retract plane'
[22:44:30] <jepler> BigJohnT: "All canned cycles use X, Y, R, and Z numbers in the NC code." "The R (usually meaning retract) position is along the axis perpendicular to the currently selected plane (Z-axis for XY-plane, X-axis for YZ-plane, Y-axis for XZ-plane)."
[22:44:35] <jepler> http://linuxcnc.org/docs/html/gcode_main.html#sub:G81-to-G89:
[22:45:05] <jepler> use of R- in canned cycles depends on the G98/G99 modal setting
[22:45:59] <BigJohnT> ok thanks looks like the table is a bit confusing
[22:46:36] <BigJohnT> ahh, it is much better explained in G81
[22:46:43] <BigJohnT> thanks
[22:47:59] <jepler> be my guest if you want to improve it
[22:48:02] <jepler> .. but you know that
[22:48:07] <BigJohnT> :)
[22:50:14] <jepler> hm -- the xxx_PERIOD inifile settings are only used in the hal files, never by anything else that reads the inifile.
[22:50:51] <jepler> so you can have just a single PERIOD setting with an appropriate loadrt motion line (servo) or two xxx_PERIOD settings (stepper)
[22:51:24] <jepler> +loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]PERIOD servo_period_nsec=[EMCMOT]PERIOD traj_period_nsec=[EMCMOT]PERIOD key=[EMCMOT]SHMEM_KEY num_joints=[TRAJ]AXES
[22:51:32] <jepler> note use of PERIOD three times ^^
[23:10:28] <CIA-35> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: bump version after release
[23:10:38] <CIA-35> EMC: 03jepler 07v2_2_branch * 10emc2/VERSION: bump version after release
[23:11:25] <CIA-35> EMC: 03jepler 07v2_2_branch * 10emc2/src/configure: regenerate
