Back
[02:31:35] <jepler> just booted the new 64-bit kernel with the patch from rtai-3.6.1 and at a cursory glance everything's OK
[02:31:42] <jepler> I'll let it run overnight and see how things go
[02:32:38] <jepler> hm but I didn't actually install the rtai-3.6.1 package ..
[02:33:47] <jepler> still works after installing that
[02:35:55] <jepler> alex_joni: I'm putting the sources and packages on the hardy repo but without regenerating the metadata so it won't appear in updates yet ... but you can get the source I used from there if you want to build new packages based on it rather than pulling from git
[02:36:18] <jepler> 'night all
[13:20:13] <BigJohnT> alex_joni: are you around?
[13:38:51] <alex_joni> yes
[13:40:22] <BigJohnT> I updated the G64 in the manual
[13:40:31] <BigJohnT> http://pastebin.ca/1034943
[13:41:00] <BigJohnT> less manual-change.patch | wc -l
[13:41:04] <BigJohnT> 31
[13:41:17] <BigJohnT> gotta run be back in a few after breakfast
[13:42:22] <SWPadnos> it would be best to spell "benefit" correctly :)
[13:42:39] <SWPadnos> (end of line 22)
[13:45:54] <skunkworks> * skunkworks feels like he is in good company ;)
[13:50:46] <rayh> I just added the numbers from the $200 newegg box on the latency test. It's Via PC2500G.
[13:52:46] <alex_joni> http://en.wikipedia.org/wiki/Multiple_Sleep_Latency_Test
[13:53:33] <rayh> Hi alex
[13:53:36] <alex_joni> hey ray
[13:54:04] <rayh> On that definition I work at about 20 seconds.
[13:55:31] <jepler> BigJohnT: I'll tweak and commit that doc improvement.
[13:56:21] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx:
[13:56:21] <CIA-32> EMC: * document the new effect of the naive cam detector on arcs
[13:56:21] <CIA-32> EMC: * describe the limitations of the cam detector on lines a bit more
[13:57:02] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/docs/src/gcode/main.lyx: fix spell-o
[13:58:48] <BigJohnT> jepler: thanks
[14:00:55] <rayh> jepler, Got a question on stepconf. Is home from all limit permitted on the same pin.
[14:02:15] <jepler> rayh: no, stepconf doesn't let you place all the homes and all the limits on a single pin.
[14:02:57] <rayh> So I'd be best off using all home and then add the limits by hand?
[14:04:01] <rayh> I know that I'd need to disable limits during home moves.
[14:05:08] <jepler> rayh: yes, if you have worked out the other stuff to write in hal to make this work as you like ..
[14:05:47] <rayh> Okay. Thanks. The all homes makes it pretty easy.
[14:06:01] <rayh> Thanks for all the great work on this tool.
[14:07:25] <jepler> my pleasure, as always.
[14:08:01] <BigJohnT> when running make I get this warnging "man9/pluto_servo.9:106: warning [p 154, 4.3i]: can't break line" is that an issue?
[14:08:10] <jepler> BigJohnT: no, that's just a stupid warning
[14:08:17] <BigJohnT> ok
[14:08:19] <BigJohnT> thanks
[14:11:53] <BigJohnT> just looking at the G61/64 section I see some weird stuff in the pdf file
[14:11:55] <BigJohnT> addition, when you activate G64 P- it turns on the "naive cam detector";< < < < < < < main.lyx when
[14:12:12] <rayh> I unticked the tool change box in stepconf and get a non-functioning config.
[14:12:28] <rayh> pin iocontrol.0.tool-changed does not exist.
[14:12:31] <alex_joni> BigJohnT: that's because you got a merge error
[14:12:41] <BigJohnT> hmmm
[14:12:49] <alex_joni> you had a modified version, and jeff commited another version
[14:12:59] <alex_joni> use 'cvs up -dPC' to get the version from CVS
[14:13:05] <jepler> BigJohnT: if you have no other changes in that file, just "rm" it and "cvs up" again, or do as alex_joni suggests
[14:13:05] <BigJohnT> thanks
[14:13:06] <alex_joni> this will move your local changes to another file
[14:13:34] <BigJohnT> I have no other changes in the file
[14:18:26] <alex_joni> BigJohnT: you do.. you have the changes you showed us.. jepler commited a variation of those
[14:18:30] <alex_joni> so yours won't match
[14:18:58] <alex_joni> and even if it would match 100% you have a locally modified file, versus the file from CVS..
[14:33:09] <BigJohnT> so if I just delete my main.frx file and do a cvs I'll get the latest one right?
[14:33:31] <alex_joni> lyx..
[14:36:27] <BigJohnT> ok
[14:36:43] <BigJohnT> I meant lyx
[15:35:20] <BigJohnT> yea! it works
[15:41:15] <SWPadnos> rayh, there's a typo in stepconf.py
[15:41:50] <SWPadnos> oh, maybe not that simple. hmmm
[15:46:34] <jepler> probably icontrol.0.tool-changed should be iocontrol.0.tool-changed -- but that checkbox just switches you between getting the pop-up at tool change time to having the tool change finish instantly.
[15:47:05] <jepler> if what you want is an automatic toolchanger you have to write it
[15:47:46] <SWPadnos> but the pin should exist in either case
[15:48:07] <jepler> yes but there is a typo
[15:48:10] <jepler> you may just not have seen it
[15:48:16] <jepler> icontrol, missing "o"
[15:48:57] <SWPadnos> ok, I saw it when you typed it, but I did miss it in stepconf :)
[15:50:11] <CIA-32> EMC: 03jepler 07TRUNK * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix the typo that ray ran into
[15:51:58] <CIA-32> EMC: 03jepler 07v2_2_branch * 10emc2/src/emc/usr_intf/stepconf/stepconf.py: fix non-working configuration if "onscreen prompt for toolchange" was disabled
[15:51:58] <CIA-32> EMC: 03jepler 07v2_2_branch * 10emc2/debian/changelog: fix non-working configuration if "onscreen prompt for toolchange" was disabled
[15:53:39] <SWPadnos> I think it might be good to add another way to calculate the BASE_PERIOD: let the user choose between fastest time or lowest CPU load
[15:54:09] <SWPadnos> unless it's already doing fastest time, which I think is better in most cases (very slow CPUs being the exception)
[15:54:18] <jepler> so far about 80% of the options I've added to stepconf were buggy. that's why I don't want to add any more
[15:54:48] <SWPadnos> heh
[15:55:26] <SWPadnos> hmmm - oh, I guess adding "spindle_hz" to the ideal_period might be a good thing too
[15:55:33] <jepler> that is true
[15:55:55] <jepler> (see what I said earlier about 80% buggy)
[15:56:16] <alex_joni> jepler: I don't think it's any different for the rest of emc
[15:56:18] <alex_joni> :)
[16:05:03] <rayh> Another bugfix in less than 2 hours.
[16:05:39] <SWPadnos> some people pay for that kind of response time
[16:06:20] <rayh> Yea they do.
[16:07:42] <jepler> * jepler considers that the flip side of that is that some people *get paid* for that kind of response time
[16:07:52] <cradek> haha
[16:07:58] <SWPadnos> that thought had occurred to me
[16:08:06] <cradek> we wish
[16:08:16] <SWPadnos> though they also carry pagers and the like, and are on call 24/7 (or someone is anyway)
[16:09:32] <rayh> Um, jepler "the check is in the mail."
[16:09:46] <SWPadnos> just bring extra candy to Fest :)
[16:09:47] <jepler> cradek: on one of my little unipolar steppers I hooked scope ground clips to the center taps and probes to two of the winding ends. while the motor is rotating at a good regular clip you see nice square waves with offset (clipped by the scope), but when rotating slowly you get very irregular waveforms.
[16:09:57] <rayh> k
[16:10:29] <SWPadnos> err - are those center taps supposed to be grounded?
[16:10:43] <SWPadnos> or is that supply/driver floating relative to frame ground?
[16:10:53] <cradek> jepler: I wonder what gene came up with. he was working on that too.
[16:11:00] <jepler> this was without anything driving it -- turning the shaft in my finger
[16:11:07] <SWPadnos> ok, phew :)
[16:11:14] <cradek> seems like the high voltage low current steppers would be better (opposite what we usually want)
[16:11:36] <SWPadnos> are you turning by hand or with a drill or something?
[16:11:42] <jepler> SWPadnos: just by hand
[16:11:55] <SWPadnos> ok, my first bet would be poor velocity control :)
[16:12:17] <jepler> SWPadnos: chris and I were thinking about MPGs
[16:12:18] <jmkasunich> especially at low speed, you'll have a hard time turning it at a constant speed
[16:12:19] <cradek> jepler: I hear adding a massive knob can help
[16:12:26] <jmkasunich> (due to cogging)
[16:12:36] <jepler> SWPadnos: stuart had some of these little boxes with some circuitry and a stepper, which were supposedly able to function like an MPG
[16:12:44] <jmkasunich> the voltage you are seeing is proportional-ish to speed
[16:12:50] <SWPadnos> yep - I figured out the application, but I think it's as jmkasunich mentioned - turning at slow speed is hard
[16:13:06] <jmkasunich> that stepper = mpg idea will work, but you can never be sure you won't miss a step at low speeds
[16:13:10] <jepler> this motor is a tiny floppy drive motor, I think. I didn't pay too much attention to the acual voltages.
[16:13:14] <jmkasunich> if you don't have numbers around the dial it won't matter
[16:14:07] <jepler> I have a feeling cradek wouldn't be satisfied with an mpg that loses steps
[16:14:24] <SWPadnos> me either :)
[16:14:39] <jmkasunich> if there aren't any numbers on the dial, you'd never know
[16:14:45] <cradek> jepler: lots of machines have no marks and the wheel is still useful
[16:14:48] <SWPadnos> oh, that is an advantage
[16:14:50] <jmkasunich> s/know/notice
[16:15:22] <jepler> jmkasunich: if you can see it not-step just by turning it slowly, you can still know
[16:15:56] <jmkasunich> I guess that depends on the speed at which it stops working right
[16:16:15] <SWPadnos> is the shaft big enough to stick a knob on it?
[16:16:37] <SWPadnos> well, you'd tend to notice more when turning slowly, which is where the problem would be more common
[16:16:38] <jepler> SWPadnos: I doubt I have anything appropriate laying around
[16:17:02] <SWPadnos> ok. the one I have (a 12V stepper from DigiKey) has a 1/4 shaft, so I stuck a knob on it
[16:17:06] <jmkasunich> an appropriate knob you mean?
[16:17:10] <SWPadnos> makes it easier to turn regularly
[16:17:16] <SWPadnos> err - at constant V
[16:17:28] <SWPadnos> only 24 steps/rev though
[16:17:39] <jmkasunich> if you are turning it one "click" at a time, constant V might not really be the ideal
[16:18:04] <SWPadnos> V=velocity, not voltage, in this instance (in case there was confusion)
[16:18:18] <jmkasunich> you might like it better if you loaded one winding with a resistor to increase the cogging, and the detent action might get you a stronger signal once per "click" as it "falls off" the detent
[16:19:00] <SWPadnos> hmmm. that's interesting. you can use a unipolar or center-tapped bipolar motor in quadrature while applying current to the other half of one (or both) coils
[16:24:30] <jmkasunich> seems that most cheap steppers are very coarse steps
[16:24:40] <jepler> the other problem I've seen in stepper-as-mpg circuits is that they lose information about where in the quadrature cycle you were when you stopped turning. It seems like the solution is as simple as building hysteresis into the comparator that converts winding voltages into A/B signals
[16:24:43] <jmkasunich> you'd want at least 50, preferrabbly 100 steps/rev
[16:24:57] <jepler> jmkasunich: I think these are 200, but there are also 5 degree/72 step motors out there
[16:24:58] <jmkasunich> yeah, hystersis is a must
[16:25:08] <jmkasunich> jepler: what did they cost?
[16:25:36] <jmkasunich> I'm looking at a $1.99 one at electronic goldmine, but it is 20 steps/rev
[16:25:40] <jepler> hm
[16:26:01] <jepler> I would have guessed way under $10 but it's just been in one of my junk boxes for a few years
[16:26:22] <jmkasunich> understood - I have those too
[16:26:48] <jmkasunich> I was having thoughts of a "product" consisting of a cnc milled PCB, a couple bucks worth of parts, and a cheap motor
[16:27:11] <jmkasunich> product = at least semi-reliable source of supply
[16:27:42] <jepler> it looks a lot like this one but without the coupler on it:
http://www.allelectronics.com/make-a-store/item/SMT-89/2-PHASE-1.8-DEGREE-STEPPER-MOTOR-USED-/-/1.html
[16:28:29] <jmkasunich> nice
[16:29:08] <SWPadnos> http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=403-1013-ND
[16:29:21] <SWPadnos> they actually have 4 motors that are steps/rev
[16:29:29] <SWPadnos> that are 100 steps/rev
[16:29:49] <SWPadnos> the other 3 are bipolar
[16:30:01] <cradek> 12v is a good sign too
[16:31:33] <SWPadnos> 35 mNm - I wonder how that would feel when turning a knob
[16:31:55] <jmkasunich> $18.70 is NOT cheap
[16:32:09] <SWPadnos> $15 at qty. 10, $12 at 100
[16:32:22] <jmkasunich> the $5 one the jepler posted is the upper end of what I would be interested in
[16:32:27] <SWPadnos> heh
[16:32:55] <jmkasunich> I'd want the total material cost, with board, electronics, motor, and knob, to be under $20
[16:33:00] <jmkasunich> sell for $40-50
[16:33:04] <cradek> a relevant question would be what's the chepaest suitable encoder
[16:33:11] <jmkasunich> remember, you are selling to cheap-ass hobbyists like us
[16:33:40] <jmkasunich> there are mechanical encoders (sliding contacts instead of optical) for $5 or less
[16:33:45] <jmkasunich> but they don't have detents
[16:33:47] <alex_joni> you can get mechanical "encoders' quite cheap
[16:33:53] <jmkasunich> IMO a detent is nice for a jogwheel
[16:33:54] <alex_joni> but limited to 20 detents or so
[16:33:57] <SWPadnos> they don't have proportional force feedback
[16:33:58] <jepler> there are cheap (also under $10) mechanical encoders with detent, but they are on the order of 12 or 24 detents per revolution
[16:34:16] <SWPadnos> which is possible with a stepper, but not with an encoder
[16:34:37] <jmkasunich> proportional force feedback?
[16:34:54] <alex_joni> energize the coils based on cutting forces :D
[16:34:55] <SWPadnos> make it harder to turn when there's more load on the spindle/axis servo
[16:35:13] <jmkasunich> that is a completely different project ;-)
[16:35:34] <jmkasunich> with a much much smaller market - what percentage of machines have the hooks to measure the forces?
[16:35:46] <SWPadnos> any EMC2 machines ;)
[16:35:53] <SWPadnos> (hardware notwithstanding)
[16:36:04] <jmkasunich> you need spindle or axis drives with analog outputs, and you need A/D inputs to your computer
[16:36:12] <jmkasunich> that takes it way out of stepconf class machines
[16:36:26] <cradek> pid output ~= cutting force
[16:36:38] <jmkasunich> depends on the drive
[16:36:56] <cradek> true, for velocity it's not true
[16:37:00] <cradek> true not true
[16:37:02] <jmkasunich> on Stuart's G&L, PID output is proportional to velocity, not torque
[16:37:05] <SWPadnos> true - PID output is a good measure of effort, which can be used for feedback
[16:37:54] <SWPadnos> you could also use the speed as a measure - faster is harder, if you're cutting
[16:38:12] <jmkasunich> how often do you cut with a jogwheel?
[16:38:21] <jmkasunich> _especially_ on a larger servo-class machine?
[16:38:22] <SWPadnos> never, I don't have a CNC ;)
[16:38:25] <cradek> relatively often
[16:38:33] <SWPadnos> oh, so always ;)
[16:38:40] <SWPadnos> it's just a mechanical jogwheel
[16:38:57] <cradek> to face off/square up a part, I almost always use the wheel
[16:39:09] <jmkasunich> but the force on your mechanical jogwheel is determined more by torque and cutting force than by speed
[16:39:25] <SWPadnos> cutting force is proportional to speed
[16:39:45] <jmkasunich> and to depth of cut, and to width of cut, etc etc
[16:39:45] <cradek> and depth, and cutter size
[16:39:54] <SWPadnos> (mostly - obviously there are bumps when you're going too slowly in SS, or too fast in most anything)
[16:40:14] <jmkasunich> if "feel" is to be at all usefull, it needs to be based on force, not speed
[16:40:30] <SWPadnos> sure - there's no absolute measure of force, but the proportion of "it's harder to go faster than it is to go slower" still holds
[16:40:41] <jmkasunich> if it were based on speed, it wouldn't change as I go from cutting air to cutting steel
[16:40:55] <SWPadnos> true
[16:41:32] <SWPadnos> so you get so-so feel when you have no feedback hardware, and better / more accurate feel when you do have hardware - sounds like most of EMC2
[16:47:53] <lerman_> lerman_ is now known as lerman
[16:55:29] <CIA-32> EMC: 03eric-johnson 07TRUNK * 10emc2/src/emc/usr_intf/emclcd.cc: *** empty log message ***
[16:55:29] <CIA-32> EMC: 03eric-johnson 07TRUNK * 10emc2/src/hal/utils/halrmt.c: *** empty log message ***
[17:01:04] <CIA-32> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build FAILED ; see
http://linuxcnc.org/compile_farm/emc2head_slot1_log.txt
[17:40:39] <dmwaters> {global notice} Hi all, we've had some maintenence going on with one of our sponsors. We also found a small problem with services that we're in the process of working on. Thank you for your patience, and thank you for using freenode!
[17:45:30] <CIA-32> EMC: 03eric-johnson 07TRUNK * 10emc2/src/hal/utils/halrmt.c:
[17:45:30] <CIA-32> EMC: Not sure of the correct action when in sim, commenting out the offending
[17:45:30] <CIA-32> EMC: line for now.
[17:47:22] <CIA-32> EMC: 03compile-farm 07Ubuntu 5.10 (breezy) non-realtime (2.6.12-10-386) * 10emc2head/: build PASSED
[17:59:05] <SWPadnos> jepler, do you remember what you were thinking when you put this line in stepconf (in the hz function):
[17:59:07] <SWPadnos> if self.units or axname == 'a': leadscrew = 1./leadscrew
[17:59:27] <SWPadnos> ah - I get it
[17:59:41] <SWPadnos> metric screws are measures in mm/turn, rather than turns/inch
[17:59:52] <SWPadnos> thanks :)
[18:10:29] <jepler> welcome
[18:14:41] <SWPadnos> hmmm. can you add text labels to the spindle page for count rate / max spindle speed at which the computer can keep up?
[18:15:00] <SWPadnos> oh - maybe I can load glade files now
[18:18:14] <SWPadnos> then again, I'm not sure what to do if a user wants to run a spindle faster than they can count pulses
[18:18:51] <SWPadnos> so I guess I'll procrastinate and not commit the spindle speed code
[18:21:09] <jepler> hah!
[18:21:24] <SWPadnos> heh
[18:21:51] <SWPadnos> I did a test config with a fast spindle and high res encoder, and was surprised to see 30000 BASE_PERIOD
[18:22:01] <SWPadnos> when it would have needed to be <5000 (3200RPM, 4000 counts)
[18:22:35] <SWPadnos> (which was <minperiod)
[18:25:35] <jepler> right, because as you discovered, the spindle encoder frequency isn't taken into account...
[18:31:03] <jmkasunich> if they spec a spindle encoder PPR, it should generate a "max threading speed", which is calculated from the base period and the ppr
[18:31:22] <jmkasunich> display it in the wizard, or print it as a comment in the ini file, or whatever
[18:31:53] <jmkasunich> it is quite reasonable for the max spindle speed for turning to be higher than is usable for threading, you shouldn't mung with base period just because of threading
[18:49:21] <SWPadnos> I added cpde to account cor the spindle encoder frequency
[18:49:23] <SWPadnos> code
[18:49:26] <SWPadnos> for
[18:50:02] <SWPadnos> I was just thinking of that - show the max readable spindle speed in that lower area
[22:42:48] <BigJohnT> when I do a "cvs diff -u > manual-change.patch" I get the error "cvs diff: No CVSROOT specified! Please use the `-d' option"
[22:43:01] <BigJohnT> hmmm, didn't use to do that
[22:43:45] <SWPadnos> is there a CVS/ directory where you did the diff?
[22:45:22] <BigJohnT> I was in the config folder I just had to move up to the /docs/src folder it seems
[22:45:56] <BigJohnT> yep, it worked now
[22:47:34] <BigJohnT> I updated the homing section to include the HOME_FINAL_VEL. Anyone got time to check it out?
[22:47:47] <BigJohnT> http://pastebin.ca/1035347
[22:48:29] <BigJohnT> less manual-change.patch | wc -l returned 96
[22:52:58] <SWPadnos> negative is misspelled on line 48
[22:53:28] <SWPadnos> also, there's a problem with sentence structure in the same place
[22:53:46] <BigJohnT> ok
[22:54:24] <SWPadnos> so if HOME_FINAL_VEL is left out, 0, or negative, then the move to HOME_POSITION will be at MAX_VEL?
[22:54:32] <BigJohnT> yes
[22:54:37] <SWPadnos> ah, ok
[22:54:47] <SWPadnos> so the default is really MAX_VELOCITY, not 0
[22:55:19] <BigJohnT> yes
[22:55:26] <BigJohnT> did I word that confusing
[22:55:36] <SWPadnos> did yes you!
[22:56:01] <BigJohnT> strike the The default is zero...
[22:56:04] <SWPadnos> also, on line 52 the wourd "your" should be "you're" (or you are)
[22:56:11] <SWPadnos> s/wourd/word/
[22:57:43] <SWPadnos> on line 89, maybe change "left out of that axis" to unspecified or missing
[22:58:04] <BigJohnT> ok
[22:58:14] <SWPadnos> I think the word axis should be wrong there, it should be a joint (but I'm not sure it is :) )
[22:59:06] <SWPadnos> cool. thanks. I can't check it in at the moment, but thanks for the work
[22:59:13] <BigJohnT> i
[22:59:21] <BigJohnT> I'll do the diff again in a second
[23:00:02] <BigJohnT> I'll try in the morning to get it checked in
[23:00:07] <BigJohnT> thanks for looking at it
[23:01:52] <SWPadnos> sure