Back
[00:21:27] <jmkasunich> you guys still around? got a question
[00:21:55] <jmkasunich> "override limits" allows a single jog command to override the limit switches (usually used to jog back inside the limits)
[00:22:07] <jmkasunich> should the wheel do the same?
[00:22:20] <jmkasunich> I'm thinking no, because the definition of a "single jog" is fuzzy
[00:22:36] <jmkasunich> (when you are turning the wheel)
[00:24:45] <petev> jmkasunich: I agree, I don't think the wheel needs to be able to jog on a limit override. if it does, the direction should be checked to make sure it's moving away from the limit and not further into it.
[00:26:04] <fenn> why would you only allow a single jog command?
[00:26:15] <fenn> override limits should mean just that
[00:26:35] <jmkasunich> because otherwise the dumb user will hit the button to get off limits, and the limits will stay disabled forever
[00:26:42] <jmkasunich> allowing him to crash the machine later
[00:27:03] <fenn> perhaps override limits should be reset on a mode change
[00:27:15] <jmkasunich> I dunno how axis handles it, but on tkemc if you hit the override limits button it turns red
[00:27:22] <jmkasunich> it goes gray again after you make a single jog
[00:27:31] <jmkasunich> if you are still on limits, you can hit the button again
[00:27:57] <jmkasunich> I think its safer that way, its been that way forever, and I'm not changing it
[00:28:00] <cradek> axis does the same thing but it uses a checkbutton instead of magic colors
[00:28:24] <fenn> magic colors is confusing but at least it gets your attention
[00:28:39] <jmkasunich> don't care about how the GUIs do it
[00:29:00] <jmkasunich> btw, "forever" = way back in emc1, not just emc2
[00:29:04] <cradek> yeah the one-jog-per-override is not a gui issue
[00:30:22] <jmkasunich> * jmkasunich is using "goto"
[00:30:32] <jmkasunich> (by another name - "continue")
[00:41:45] <jmkasunich> OK, who wants to test this?
[00:47:04] <jmkasunich> nobody? you guys are no fun!
[00:47:14] <fenn> * fenn hides
[00:47:28] <fenn> what am i not testing?
[00:47:33] <jmkasunich> jogwheel
[00:47:39] <jmkasunich> * jmkasunich looks at cradek
[00:54:51] <jmkasunich> dang...
[00:54:57] <jmkasunich> no volunteers
[01:13:26] <jepler> jmkasunich: it warms my heart to see those "-#if 0" in your patches
[01:14:02] <jmkasunich> warm hearts are good
[01:14:13] <jmkasunich> hey, how do I figure out what the address of my parport is?
[01:14:24] <jmkasunich> I thought it was 0x0378, but no joy
[01:14:27] <jepler> jmkasunich: lspci and stare at the output?
[01:14:55] <jepler> (though on my laptop it doesn't appear on lspci)
[01:14:59] <jmkasunich> nope, nothing resembling a parport
[01:15:34] <jmkasunich> pretty sad, I'm a core developer and its been ages since I actually spun motors
[01:15:41] <jmkasunich> dunno if I ever did it with this box
[01:15:45] <jepler> I wrote a whole user interface without hardware to call my own
[01:16:04] <jepler> cradek: I should get that first l298 board back from you...
[01:16:33] <jmkasunich> he's hiding
[01:16:44] <jmkasunich> cause if he comes out I'll ask him to test this
[01:16:56] <jmkasunich> dammit, theres gotta be a way to find the port
[01:17:13] <jmkasunich> HAL says the driver is loaded, and I can see the step and dir pins toggle with hal
[01:17:20] <jmkasunich> but the don't seem to be toggling for real
[01:17:32] <jmkasunich> (haven't got the real scope out yet)
[01:17:48] <jepler> hal just dumbly assumes there's a parport at the address you give it
[01:17:52] <jmkasunich> yes
[01:18:21] <jmkasunich> if the port doesn't appear in lspci, it seems like it should be at a legacy address
[01:18:36] <jepler> looks like 278 and 3bc are some other legacy addreses
[01:18:39] <jepler> (glancing through parport_pc.c)
[01:19:06] <jmkasunich> tried 0278, same result
[01:20:25] <jmkasunich> wading thru /sys looking for clues
[01:23:22] <jmkasunich> john@ke-main-ubuntu:~/emcdev/emc2head$ cat /sys/bus/pnp/devices/00:09/resources
[01:23:22] <jmkasunich> state = active
[01:23:22] <jmkasunich> io 0x3f8-0x3ff
[01:23:22] <jmkasunich> irq 4
[01:23:46] <jmkasunich> dunno what it means, sure seems like 0x03f8 is the right addr tho
[01:27:23] <jmkasunich> well, it ain't 3f8, "request_region(3f8) failed"
[01:28:05] <jepler> is parport_pc loaded?
[01:28:09] <jmkasunich> no
[01:28:11] <jmkasunich> just checked
[01:28:17] <jmkasunich> lp was loaded, I rmmoded it
[01:28:28] <jepler> does /proc/ioports show something taking that region?
[01:28:56] <jmkasunich> oops, I missed something
[01:29:03] <jmkasunich> parport_pc isn't but parport is
[01:30:06] <jmkasunich> duh, now I know why 3f8 sounded familiar
[01:30:11] <jmkasunich> thats a legacy serial port addy
[01:30:19] <jepler> oh
[01:30:27] <jepler> have you investigated whether the port is turned off in BIOS?
[01:30:37] <jmkasunich> nuttin on 278 or 378
[01:30:41] <jmkasunich> no, didn't want to reboot
[01:30:47] <jmkasunich> its possible
[01:31:02] <jmkasunich> guess its time to do that
[01:37:45] <jmkasunich> bios says its 378
[01:41:12] <jmkasunich> meter says the pins are changing state
[01:41:21] <jmkasunich> only 3.5V for a high, but still thats a high
[01:41:56] <jmkasunich> now it wors
[01:41:57] <jmkasunich> works
[01:42:02] <jmkasunich> didn't actually change anything
[01:42:07] <jmkasunich> (except reboot)
[01:42:29] <jmkasunich> I just love computers don't you?
[01:44:24] <alphaEMC> yippie kai yeh mother franker.
[01:44:28] <alphaEMC> :D
[01:44:47] <alphaEMC> ubuntu 5.10 breezy, running the emc install script, and the stepper motor is reconnected.
[01:45:18] <alphaEMC> still wonder why my internet isn't automagically DHCP with ubuntu...
[01:45:24] <alphaEMC> hello?? :P Where is everyone?
[01:45:32] <alphaEMC> where's my celebration party?
[01:47:39] <jmkasunich> yay!
[01:47:49] <jmkasunich> party at alpha's house!
[01:47:53] <alphaEMC> must restart now
[01:52:29] <skunkworksz> jmkasunich: ran around 5 amp though my little h-bridge using a basic stamp outputing pwm. the mosfets start to get warm at that current :)
[01:52:33] <alphaEMC> I have updates... which updates are safe now? I know not the kernel images
[01:53:11] <jepler> alphaEMC: any but the kernel image should be fine
[01:53:19] <skunkworksz> any of the updates are safe - atleast I have been installing whatever is shown - just don't click on the upgrade button ;)
[01:54:32] <alphaEMC> 85 megs. :(
[01:54:42] <skunkworksz> was I wrong? what kernel image?
[01:54:57] <alphaEMC> there's kernel image updates... that screw up the RTAI kernel.
[01:55:18] <alphaEMC> I clicked the upgrade button, but am not updating the kernel/linux images.
[01:56:03] <jepler> don't click "Upgrade"!
[01:56:09] <SWPadnos> did you click the button that says "a new version of Ubuntu is available - 6.06 LTS"?
[01:56:12] <jepler> at least, not the upgrade button shown at the bottom of this window:
http://www.electronicsam.com/images/KandT/upgrade.png
[01:56:19] <alphaEMC> SWPadnos, of course not. :)
[01:56:32] <SWPadnos> that looks like the top of the window to me ;)
[01:56:38] <alphaEMC> mine's the top too
[01:56:41] <SWPadnos> phew - update then, not upgrade
[01:56:48] <alphaEMC> I clicked it.. .but unchecked the linux images/kernels
[01:56:49] <jepler> SWPadnos: yes, the top
[01:57:09] <SWPadnos> ok. that should be all right then
[01:57:18] <jepler> alphaEMC: I am not sure whether upgrading the kernel is harmful (it might make the realtime kernel not the default) but it is certainly a waste of your time to download it, since you'll never used it.
[01:57:19] <jmkasunich> it works!!!!
[01:57:43] <jepler> jmkasunich: what are you playing with?
[01:57:44] <alphaEMC> 'ight
[01:57:48] <alphaEMC> thanks folks. :)
[01:57:59] <jmkasunich> jogwheel, RT implementation
[01:58:02] <alphaEMC> now... all I need to do... is double check the wiring, and do a test... maybe I'll do that tomorrow. :/
[01:58:11] <jepler> jmkasunich: cool. is it smoother?
[01:58:17] <jmkasunich> very much so
[01:58:20] <alphaEMC> anyone here play 3d scorched earth??
[01:58:33] <skunkworksz> alphaEMC: what - you come this far !!! :)
[01:58:56] <alphaEMC> damn neighbour... showed it to him, and he's ended killing 1.5hrs of my time, before I said I want my coffee now.
[02:02:29] <jmkasunich> hmm, only axis 0 seems to work
[02:02:52] <jmkasunich> duh, works better if you connect the pins
[02:04:19] <jmkasunich> dat's better
[02:05:06] <SWPadnos> now they're all moving! ;)
[02:05:23] <skunkworksz> you should have your fest cam setup again - so we can keep tabs on you
[02:06:00] <jmkasunich> no thanks
[02:06:21] <jmkasunich> don't need big bro watching
[02:06:29] <SWPadnos> remember, people working at home can be - um - improperly dressed ;)
[02:06:29] <skunkworksz> :)
[02:06:39] <alphaEMC> hmm... this is firefox 1.08
[02:06:45] <alphaEMC> I should really upgrade that to the newest.
[02:06:59] <SWPadnos> not that important for a machine controller, I'd say
[02:07:05] <alphaEMC> true
[02:07:06] <skunkworksz> to run your machine - c'mon
[02:07:17] <jepler> I like to browse the web while machining circuit boards
[02:07:19] <SWPadnos> new emc web interface, in RT!!!
[02:07:20] <alphaEMC> okay... I'll check my pins...
[02:07:22] <jepler> it gives me a feeling of smug superiority
[02:07:29] <jepler> oh yeah, I should do an AJAX web interface for emc
[02:07:30] <jmkasunich> jepler cradek got an issue here
[02:07:32] <jepler> that would kick boo-tay
[02:07:46] <jepler> jmkasunich: issue?
[02:07:51] <SWPadnos> you have to play MP3's and movies simultaneously, then you're a realy superior smug person ;)
[02:07:52] <jmkasunich> axis switches the motion controller to auto mode when you start a g-code program
[02:08:03] <jmkasunich> when you end (hit the stop button for instance)
[02:08:09] <jmkasunich> you ungray the jog buttons
[02:08:23] <jmkasunich> but you don't actually switch to manual mode until somebody hits one
[02:08:25] <jepler> yeah, everyone is complaining about that, now that halui is starting to take off
[02:08:28] <SWPadnos> halvcp and halgui to the rescue
[02:08:35] <SWPadnos> err - halui
[02:08:36] <jmkasunich> if you don't switch the controller to manual, the jogwheel won't work
[02:09:02] <SWPadnos> you should put a button on the panel, connected to the halui "manual_mode" pin
[02:09:11] <jmkasunich> just a click on the axis jog button (any axis) and the jogwheel works again
[02:09:12] <alphaEMC> "sudo locate -u" updates locate right?
[02:09:13] <SWPadnos> (when builfing a real panel)
[02:09:28] <SWPadnos> or building one
[02:09:35] <alphaEMC> yup
[02:09:37] <alphaEMC> :P :)
[02:09:38] <SWPadnos> man, I hope this typing problem wears off before tomorrow
[02:09:48] <alphaEMC> SWPadnos, it's called old age
[02:09:49] <alphaEMC> :D
[02:10:09] <SWPadnos> I haven't even hit 40 yet!
[02:10:22] <alphaEMC> and how close are you to 40?? ;)
[02:10:28] <jmkasunich> anyway, the RT part works, I think I'm gonna commit it
[02:10:34] <alphaEMC> omg... I went to a 30th birthday yesterdya
[02:10:35] <jmkasunich> can anybody think of any other tests?
[02:10:36] <alphaEMC> :(
[02:10:39] <SWPadnos> cool
[02:10:50] <alphaEMC> it was fun... but the number "30" scares me.
[02:11:01] <SWPadnos> I assume it doesn't jog when in auto mode
[02:11:05] <jmkasunich> nope
[02:11:15] <SWPadnos> what about MDI (or is that not an emc state?)
[02:11:17] <jepler> SWPadnos: if it did, jmkasunich wouldn't have complained about axis not switching into manual mode
[02:11:23] <SWPadnos> that's what I figured ;)
[02:11:34] <jmkasunich> mdi is "coord" mode for the motion controller, same as auto
[02:11:41] <skunkworksz> what about when the machine is in estop
[02:11:50] <jmkasunich> nope (duh)
[02:11:56] <jepler> jmkasunich: what about incremental jog mode?
[02:12:07] <jepler> or is that a stupid question
[02:12:09] <jepler> I suppose it is
[02:12:14] <jmkasunich> it doesn't care at all about NML jog commands
[02:12:24] <jmkasunich> actually you can get some strange interactions if you try
[02:12:33] <jepler> what happens when you spin the wheel so fast you exceed the machine constraints?
[02:12:36] <alphaEMC> man... I'm gonna need some help with this ini file.
[02:12:36] <SWPadnos> so it just updates the target position when there's jogwheel motion?
[02:12:43] <skunkworksz> now emc can be used as a tracer mill :)
[02:12:43] <jmkasunich> the GUI jog commands include a speed, the wheel commands use max speed
[02:12:59] <jmkasunich> if you spin it too fast, the machine falls behind
[02:13:06] <jmkasunich> and keeps going after you stop spinning
[02:13:11] <SWPadnos> what happens if you use some very large number for the increment, like 1"?
[02:13:16] <jmkasunich> same thing
[02:13:26] <jmkasunich> one click of the wheel and it moves an inch
[02:13:31] <jepler> when it falls behind will it ferror?
[02:13:33] <SWPadnos> ok, max accel and vel for the inch(es) you move the wheel
[02:13:34] <jmkasunich> spin the wheel and it moves to the limit
[02:13:54] <jepler> btw, my own philosophy is to commit early, as demonstrated by my earlier "merge segments" commit
[02:14:09] <jepler> so I won't fault you for doing it
[02:14:20] <skunkworksz> commit early, commit often?
[02:14:22] <SWPadnos> well, we may want to fiddle with some speed estimation later, but it sounds fine as is
[02:14:23] <jmkasunich> no ferror, the move is generated by the same "tp" as regular jogs
[02:14:43] <jmkasunich> I try not to commit totally busted stuff tho
[02:14:58] <SWPadnos> if it builds and doesn't break anything, then commit
[02:15:01] <SWPadnos> else wait ;)
[02:15:08] <SWPadnos> simple rules
[02:15:45] <jepler> * jepler taps his foot and waits for the amd "x2" processors to get cheaper
[02:15:58] <SWPadnos> heh
[02:16:01] <A-L-P-H-A> okie
[02:16:08] <SWPadnos> just need to wait for am2 to hit the street
[02:16:23] <jepler> A-L-P-H-A: any specific ini questions yet?
[02:16:31] <A-L-P-H-A> kinda.
[02:17:19] <SWPadnos> well, in the immortal words of Edna Mode, "Well, what are you waiting for?"
[02:17:38] <A-L-P-H-A> linear_units, that's the movement per step correct?
[02:18:09] <SWPadnos> nope
[02:18:13] <SWPadnos> that's inch vs mm
[02:18:17] <A-L-P-H-A> 5tpi, with a gear ratio of 30(motor):48(ball screw), 10uStepping, 1.8deg motor is... :/
[02:18:19] <A-L-P-H-A> oh.
[02:18:23] <SWPadnos> 1.0 = mm, 0.039370..... = inch
[02:18:30] <A-L-P-H-A> what
[02:18:31] <skunkworksz> that is her name? from the encredibles?
[02:18:36] <SWPadnos> yep ;)
[02:18:37] <A-L-P-H-A> what's my max velocity then?
[02:18:50] <jmkasunich> steps per inch is handled in INPUT_SCALE
[02:19:01] <SWPadnos> in the TRAJ section, and in the individual AXIS sections
[02:19:09] <jepler> you max velocity is in units per second -- you'd put .333 for 20ipm
[02:19:15] <SWPadnos> INPUT_SCALE, OUTPUT_SCALE, MAX_VELOCITY, MAX_ACCEL ...
[02:19:28] <skunkworksz> the incredibles even.
[02:19:28] <jepler> steps per units (steps per inch) is INPUT_SCALE
[02:19:54] <SWPadnos> skunkworksz - yep. great movie
[02:21:03] <CIA-8> 03jmkasunich 07HEAD * 10emc2/src/emc/motion/ (command.c control.c mot_priv.h motion.c motion.h): Realtime implementation of jogwheels. Seems to work quite well, very smooth. Needs more testing.
[02:21:48] <cradek> hey allright!
[02:21:59] <jmkasunich> now he shows up, after I already tested it...
[02:22:14] <jmkasunich> where were you when I was looking for a volunteer?
[02:22:15] <SWPadnos> heh - good timing
[02:22:21] <cradek> haha
[02:22:24] <cradek> out eating ice cream
[02:22:41] <jmkasunich> while I was slaving away here writing code....
[02:22:46] <A-L-P-H-A> cycle time, do I need to touch that?
[02:22:51] <A-L-P-H-A> cycle_time
[02:22:57] <jepler> I have a silly question. when talking about semiconductor processes, there seem to be "standard" sizes: 90nm is popular right now, and 65nm is coming. Is everybody really using exactly 65nm, or is some company's fab doing 63nm and another doing 68? Or is there some physical reason that 65nm (and not 64 or 66) is feasible?
[02:22:58] <jmkasunich> not usually
[02:23:15] <jmkasunich> no physical reasons
[02:23:29] <cradek> I'll buy you an ice cream someday, just remind me
[02:23:35] <jepler> (I assume this is the smallest feature size on the semiconductor die, like "8 mil trace/space" in circuit boards, but I don't know much about it)
[02:23:53] <A-L-P-H-A> it's has something to do with the wave length of light or electrons... i forget.
[02:23:55] <jepler> cradek: ooh ice cream
[02:24:03] <cradek> jepler: they're open 'til 10
[02:24:08] <jmkasunich> each generation of processing machinery has a lower limit, most fabs probably run near that limit, but its a tradeoff between getting the last few nm and having good yield, so theres probably a spread
[02:24:12] <A-L-P-H-A> hhhhhhhhhmmmmm... I kinda want some coffeecrisp icecream.
[02:24:12] <jepler> actually i had a bowl of ice cream earlier
[02:24:18] <skunkworksz> hey - we could mill our own ic's - any one have a silicon waffer?
[02:24:47] <A-L-P-H-A> aren't they chem etched?
[02:24:49] <cradek> jmkasunich: did you hook up your jogwheel/stepper cube thing?
[02:25:00] <jmkasunich> yes, thats what I tested with
[02:25:11] <cradek> cool
[02:25:14] <SWPadnos> I think they use specific "light" sources for the photo masking steps, so there would be specific feature sizes that are possible for a given source
[02:25:18] <cradek> I will happily test this soon
[02:25:18] <jmkasunich> (the thing with three steppers, wheel, xylotex, and power supply)
[02:25:23] <cradek> right
[02:25:26] <SWPadnos> (though they use X-rays for the lithography steps now)
[02:25:44] <cradek> is it the same idea I used in halui, but faster?
[02:25:48] <jmkasunich> I need to pack (traveling all week, bummer)
[02:26:01] <A-L-P-H-A> MAX_ACCERATION is in what units?
[02:26:18] <skunkworksz> units per second per second I assume
[02:26:18] <jmkasunich> cradek, there are three new HAL pins on the motion controller for each axis
[02:26:39] <jmkasunich> jog-counts: s32, connect to the counts pin of the encoder
[02:26:56] <jmkasunich> jog-enable: bit, turn on to make it jog when the encoder turns
[02:27:18] <jmkasunich> (if you have one wheel and 3 axis, you connect all three jog-counts to the same encoder, and enable only 1 to jog that one axis
[02:27:33] <cradek> got it
[02:28:15] <jmkasunich> jog-scale: float, distance it moves per count (you can set different for each axis if you are perverse, normally they'd all be tied to the same signal, that would either be constant, or come from a mux that selects between several values
[02:28:38] <cradek> jog-scale can be negative right?
[02:28:42] <jmkasunich> yeah
[02:28:52] <jmkasunich> I didn't test that, probably should
[02:29:04] <jmkasunich> should also test jogging into the limits and such
[02:29:44] <jmkasunich> but not tonight, I'll leave that to you
[02:29:58] <cradek> ok
[02:30:07] <jepler> jmkasunich: hope the travel goes OK
[02:30:18] <jmkasunich> its a stupid training course
[02:30:21] <jepler> yuck
[02:30:24] <jmkasunich> "design for six sigma"
[02:30:28] <jepler> can't you tell them you already know everything?
[02:30:29] <cradek> I just wondered because it sounds like I could jog diagonally too then
[02:30:31] <SWPadnos> well, you should be able to catch up on sleep then ;)
[02:30:32] <jepler> (that seems like a lot of sigmas)
[02:30:42] <jmkasunich> you can jog diag if you want
[02:30:51] <cradek> cool
[02:30:58] <cradek> sigma as in std dev?
[02:31:02] <SWPadnos> set the scales under program control, and you have an off-axis straight line
[02:31:06] <jmkasunich> or you can have multiple wheels, one per axis, etc
[02:31:09] <jepler> cradek: yeah, you could even set one jog-scale to sqrt(3)/2 and the other to .5 and jog at 60 degrees
[02:31:24] <cradek> nice
[02:31:26] <skunkworksz> you guys
[02:31:28] <jepler> cradek: btw I wrote "ckins" but don't really have any way to test it
[02:31:34] <SWPadnos> are the moves done as a single move to a new target poinf, or as separate moves per axis?
[02:31:49] <A-L-P-H-A> Someone really needs to write a stepper configuration gui. Plug in the values of your machine, and out comes some code to save as an ini file. [I'm willing to write it]
[02:31:50] <jmkasunich> in free mode all joints are completely independent
[02:31:51] <SWPadnos> point
[02:31:57] <SWPadnos> that could be a problem
[02:32:10] <A-L-P-H-A> okay... I'm at a loss...
[02:32:12] <jepler> A-L-P-H-A: actually I toyed with that but never used a generated configuration on a real machine
[02:32:15] <jmkasunich> yeah, you wouldn't really get a 60 degree line
[02:32:32] <A-L-P-H-A> what are my input scale and output scale? Do I even need an input scale? I have no feedback
[02:32:34] <SWPadnos> more like a staircase that ended up at the right point
[02:32:39] <jmkasunich> right
[02:32:53] <SWPadnos> A-L-P-H-A, yes, I think you still need it
[02:32:57] <jmkasunich> A-L-P-H-A, for historical reasons you need input scale
[02:33:05] <SWPadnos> but it's synthesized by the stepgen module
[02:33:07] <A-L-P-H-A> so leave that a lone.
[02:33:19] <jepler> A-L-P-H-A: you don't have to put any value on that line, but it may need to be there
[02:33:25] <A-L-P-H-A> okay.
[02:33:31] <A-L-P-H-A> output scale?
[02:33:38] <skunkworksz> what are your steps per rev - pullys and tpi?
[02:33:41] <jepler> OUTPUT_SCALE you leave alone
[02:33:51] <SWPadnos> the only things you should need to change to get your machine running are INPUT/OUTPUT scale, and the pin connections. after that, it's all about tuning and maximizing performance
[02:33:51] <jepler> INPUT_SCALE = NNNN 0
[02:33:55] <jepler> where NNNN is steps per units
[02:34:04] <jmkasunich> bye all, I'll have a laptop, dunno if the hotel has internet
[02:34:08] <A-L-P-H-A> OH! So I do need that.
[02:34:10] <skunkworksz> have a good trip
[02:34:11] <SWPadnos> see you later jmk
[02:34:28] <SWPadnos> OUTPUT_SCALEshould be the same as INPUT_SCALE, unless you want following errors all the time
[02:34:50] <SWPadnos> or has that changed?
[02:35:15] <A-L-P-H-A> so my input_scale should be... let me calculate that... 2000pulses = 1 rpm of motor, time 1.6 gear ratio = 3200pulses.
[02:35:20] <jepler> SWPadnos: well, this is what the example stepper_inch.ini has:
[02:35:20] <jepler> INPUT_SCALE = 4000 0
[02:35:20] <jepler> OUTPUT_SCALE = 1.000 0.000
[02:35:25] <A-L-P-H-A> INPUT_SCALE = 3200 0
[02:35:35] <SWPadnos> ok.
[02:35:47] <A-L-P-H-A> 4000 = WOULD BE A 10TPI, 1.8Degree motor, direct drive.
[02:35:51] <A-L-P-H-A> correct?
[02:35:57] <SWPadnos> ah - stepgen outputs the "current position" for you, so OUTPUT_SCALE isn't needed
[02:36:04] <SWPadnos> err - INPUT
[02:36:15] <jepler> A-L-P-H-A: you can beta-test my configuration generator if you want, but like I said I haven't tested it on a real machine. INPUT_SCALE = 4000 0
[02:36:15] <SWPadnos> I think they're being used backwards, but that's OK
[02:36:18] <jepler> OUTPUT_SCALE = 1.000 0.000
[02:36:23] <jepler> the URL is:
http://axis.unpy.net:8080/
[02:36:38] <A-L-P-H-A> checking
[02:37:08] <SWPadnos> I think 4000 would be a 20 TPI motor, direct connect, full steps
[02:37:15] <SWPadnos> gah
[02:37:27] <SWPadnos> 20 TPI screw, direct connect to a 200 step/rev motor
[02:37:37] <A-L-P-H-A> oh.
[02:37:48] <A-L-P-H-A> I forgotabout my microstepping.
[02:37:58] <jepler> yeah, it depends on whether you have half- or micro-stepping too
[02:37:58] <SWPadnos> or 10 TPI, same motor, half stepping ...
[02:38:05] <A-L-P-H-A> jepler, what's the period supposed to be?
[02:38:17] <skunkworksz> don't you have belt reduction also?
[02:38:20] <jepler> A-L-P-H-A: leave it at the default (50 microseconds)
[02:38:26] <A-L-P-H-A> k
[02:38:47] <A-L-P-H-A> what would be a safe acceleration?
[02:39:15] <A-L-P-H-A> I'm on page two... what would be the max/min limits of what?
[02:39:30] <jepler> the soft limits of the table
[02:40:01] <jepler> e.g., you designate some spot as X=0. how far can it move to the -ve direction before it reaches the end of safe travel, and how far can it move to the +ve direction?
[02:40:18] <jepler> you could enter -100 / 100 if you don't care about soft limits
[02:42:05] <jepler> for acceleration, I think 5 inch/sec2 is a conservative figure
[02:42:59] <jepler> one rev of your leadscrew is how much movement? not 1"?
[02:45:01] <A-L-P-H-A> me?
[02:45:05] <A-L-P-H-A> 1 rev = 0.2"
[02:45:13] <A-L-P-H-A> 5threads per inch ballscrew
[02:45:32] <jepler> 3200 pulses is .2 inch?
[02:45:46] <jepler> so you need 16000 steps / inch
[02:45:50] <A-L-P-H-A> OH.
[02:46:45] <skunkworksz> A-L-P-H-A: I thought you also had a belt reduction
[02:46:51] <A-L-P-H-A> 200pulses = 1 rev. 5revs per inch. 10000 revs = 1". geared 16000. yup
[02:47:42] <SWPadnos> see - it's not all that hard if you just break it down and think about each piece
[02:48:16] <A-L-P-H-A> and using his gui. :D
[02:48:21] <SWPadnos> wuss ;)
[02:48:27] <A-L-P-H-A> and like 5 people double checking everything.
[02:48:28] <A-L-P-H-A> :D
[02:48:45] <SWPadnos> oh - well that never hurts
[02:49:35] <skunkworksz> 500 ppr encoders should have 2000 edges right?
[02:49:51] <A-L-P-H-A> http://pastebin.ca/64666 <-- if you could all be so kind as to take a look at it. Please ignore my Z axis... as I forget what the units are for it. I will check it now.
[02:50:23] <jepler> MAX_VELOCITY = 1
[02:50:24] <SWPadnos> skunkworksz, yes, if that's "cycles" and not "pulses" per rev.
[02:50:41] <SWPadnos> though the nomenclature isn't exactly uniform, so it still could be ;)
[02:50:48] <jepler> A-L-P-H-A: earlier you were talking about somewhere from 20-25 inches per minute. this is 1 inch per second, 60 inches per minute
[02:51:05] <SWPadnos> I think you want 0.6666 there - for 40 IPM
[02:51:56] <SWPadnos> pinout.hal is a file you made (or modified)?
[02:52:07] <jepler> I think 40ipm is above what you can do with base_period of 50 (16000 * 40/minute = 93.75 microsecond)
[02:52:20] <jepler> SWPadnos: pinout.hal is either a copy of standard or xylotex .hal file
[02:52:25] <SWPadnos> ah - ok
[02:52:29] <jepler> whichever A-L-P-H-A chose
[02:52:47] <A-L-P-H-A> I'll go 0.3333 "/sec
[02:52:50] <A-L-P-H-A> make it the 20 i want.
[02:52:55] <A-L-P-H-A> if it works, I'll pump it up
[02:53:18] <SWPadnos> you had a period of 24 microseconds in emc1. you can probably go to 30 or 25 with emc2
[02:53:19] <skunkworksz> .625 would be the max - so less than that with headroom
[02:53:33] <A-L-P-H-A> Z is again... 1.6gear reduction... (30teeth on motor, 48 on Z handle/worm).
[02:53:48] <A-L-P-H-A> one rev of the Z worm = 0.1"
[02:53:57] <A-L-P-H-A> normal stepper
[02:54:05] <jepler> microstepping?
[02:54:06] <SWPadnos> so 32000 INPUT_SCALE
[02:54:08] <A-L-P-H-A> 32000
[02:54:15] <A-L-P-H-A> yup. microstepping again
[02:55:01] <SWPadnos> I remember this now - you were asking a long time ago if it was OK to have different scales for each axis, and also had some problem with Z not moving very fast at all
[02:55:18] <A-L-P-H-A> http://pastebin.ca/64667
[02:55:21] <A-L-P-H-A> yes.
[02:55:23] <skunkworksz> .3125 max vel for that one - but you should be able to lower your base period
[02:55:30] <skunkworksz> with the computer you have
[02:55:41] <jepler> yeah it's starting to look like you should choose a lower base_period
[02:55:43] <A-L-P-H-A> okay...
[02:56:21] <jepler> SWPadnos's advice of 30 or 25 is probably good
[02:56:27] <A-L-P-H-A> I'm happen with 18.75 ipm (0.3125"/sec)
[02:56:47] <SWPadnos> not like Z moves all that far
[02:57:15] <skunkworksz> .55 with z and that base period
[02:57:17] <skunkworksz> max
[02:57:22] <A-L-P-H-A> 0.15625 "/sec for the Z?
[02:58:57] <A-L-P-H-A> happen=happy
[02:59:10] <A-L-P-H-A> with the 50uS period
[02:59:34] <SWPadnos> closer to .333, I think
[02:59:53] <SWPadnos> 10/32 = 5/16 = .3125
[03:00:05] <SWPadnos> as skunkworksz said
[03:01:00] <A-L-P-H-A> I'll worry about Z later.
[03:01:22] <jepler> if you enter 0.15625 inch / second that will be well within the step rate for 50uS base period
[03:07:16] <alphaEMC> crap...where'd my weekend go??
[03:07:48] <jepler> alphaEMC: I've been wondering the same about my own weekend
[03:07:51] <jepler> it's inevitable
[03:07:56] <SWPadnos> there was a weekend?
[03:08:10] <alphaEMC> okay... copied the config over to my emc machine
[03:08:19] <skunkworksz> thats ok - I spent part of the weekend de-crapifing a computer. (well I should be getting paid for it)
[03:08:36] <alphaEMC> where should I copy it to?
[03:08:50] <jepler> alphaEMC: make the directory emc2/configs in your home directory if you haven't already
[03:08:57] <jepler> then unzip it in emc2/configs and rename the directory if you want
[03:09:05] <jepler> that name will appear on the list that you get when you run emc
[03:10:57] <jepler> goodnight guys
[03:11:02] <rootaccess> is an ATA SAN slower then a SCSI?
[03:11:09] <SWPadnos> see you later jepler
[03:11:11] <rootaccess> SATA that is :)
[03:11:15] <SWPadnos> rootaccess, wrong emc ;)
[03:11:22] <rootaccess> hehehe
[03:11:28] <rootaccess> oh
[03:12:03] <SWPadnos> but I'd say - yes, SATA will be slower, unless the storage server has very good caching
[03:12:40] <SWPadnos> though I think you can use longer cables with SATA (not sure about that). FC-AL is probably still the best for distance and speed
[03:13:05] <rootaccess> ic
[03:13:39] <rootaccess> I have a SATA EMC box and they told me its slower because it doesn't support parralell opperations :p
[03:13:41] <rootaccess> hehehe
[03:14:07] <SWPadnos> likely true - SATA is meant for a single drive, and they only added command queueing to SATA-II
[03:14:10] <rootaccess> oh well, $40,000 lesson learned
[03:14:23] <rootaccess> ba
[03:14:26] <rootaccess> +h
[03:14:29] <rootaccess> hehe
[03:14:31] <SWPadnos> SCSI is a full disconnect/reconnect protocol, so many commands can be in-flight simultaneously
[03:14:40] <SWPadnos> bummer ;)
[03:14:53] <rootaccess> yea -- thank goodness it wasn't my call
[03:14:56] <SWPadnos> heh
[03:15:01] <SWPadnos> one job, saved
[03:15:04] <rootaccess> yep
[03:15:05] <alphaEMC> I ran emc2... and after the splash screen nothing shows up.
[03:15:07] <alphaEMC> what gives?
[03:15:19] <SWPadnos> open a terminal, run dmesg, and pastebin the result
[03:16:19] <alphaEMC> http://pastebin.ca/64672
[03:16:50] <alphaEMC> hmmm... sec.
[03:16:59] <SWPadnos> I need a lottle more than that ;)
[03:17:02] <SWPadnos> little
[03:17:29] <alphaEMC> sec.
[03:17:34] <alphaEMC> let me fix something first. :)
[03:17:39] <SWPadnos> ok
[03:18:14] <SWPadnos> you can also run emc from a terminal, and you'll see some other info (at least the first thing that caused a problem)
[03:21:00] <alphaEMC> okay
[03:21:01] <alphaEMC> http://pastebin.ca/64675
[03:21:34] <cradek> [ 5488.613470] MOTION: bad traj period 1000000 nsec
[03:21:47] <SWPadnos> hmmm - wonder why that is
[03:21:53] <alphaEMC> http://pastebin.ca/64676 <-- from command line
[03:22:12] <SWPadnos> yep - as expected
[03:22:15] <cradek> don't know...
[03:22:27] <SWPadnos> is 64667 the corerct ini file?
[03:22:40] <skunkworksz> what is your ini file again?
[03:22:56] <alphaEMC> give me a sec... I'll post it in pastbin.ca
[03:23:17] <skunkworksz> do you still have to copy the common directory (or whatever it is ) in your home directory?
[03:23:30] <alphaEMC> http://pastebin.ca/64677 <-- stepper.ini file
[03:23:43] <alphaEMC> yes I have a copy of the common.
[03:23:44] <SWPadnos> he used jepler's web-based config creator, so I think it gives a full dir of files (in a tgz)
[03:23:47] <alphaEMC> it's in the sample-configs
[03:24:12] <SWPadnos> it generated that period for you?
[03:24:18] <SWPadnos> BASE_PERIOD = 45454
[03:24:53] <skunkworksz> can the servo and traj period be the same>
[03:25:00] <skunkworksz> >?
[03:25:02] <cradek> now wait a second, it says this is in sample configs
[03:25:02] <alphaEMC> yeah that was what was generator
[03:25:05] <alphaEMC> generated
[03:25:10] <SWPadnos> should be able to do that, I think
[03:25:13] <alphaEMC> I know... I copied it there.
[03:25:14] <cradek> you overwrote the sample config with the one from jepler's site?
[03:25:20] <alphaEMC> yes
[03:25:24] <alphaEMC> cradek, yes
[03:25:28] <SWPadnos> you are a bad man
[03:25:34] <SWPadnos> naughty naughty
[03:25:39] <alphaEMC> I have a backup of it.
[03:25:48] <alphaEMC> shall I revert to the original state?
[03:26:32] <cradek> it couldn't hurt
[03:26:38] <cradek> you should have those samples available as they were
[03:26:56] <cradek> the file from jepler's site is meant to be expanded into your home directory under ~/emc2/configs/
[03:27:55] <cradek> SWPadnos: I think it tries to use a base period that can supply the requested step rate
[03:28:10] <SWPadnos> the period is requested on page 1, but that could be
[03:28:28] <cradek> SWPadnos: if it doesn't do that (and the period is too large) you just get following errors because stepgen calculates its own maxvel
[03:29:03] <SWPadnos> it may lower the period if necessary - I entered 25 (uS, I assumed), and that's what the ini shows
[03:29:21] <alphaEMC> oh... okay
[03:29:48] <SWPadnos> noentheless, 45454 gives 12 ns error if the traj period is 22x the baase
[03:29:54] <SWPadnos> (999988 ns)
[03:30:07] <SWPadnos> that should be within the allowed error (I think it's 1%)
[03:30:40] <alphaEMC> okay... I have the config.zip contents in ~/emc/configs/stepper
[03:30:51] <alphaEMC> how to I tell emc to use that config file?
[03:31:01] <cradek> when you start emc it will show it as an option
[03:31:05] <SWPadnos> though I suppose it's possible that the SERVO_PERIOD was rounded up, and that the TRAJ period ended up being lower than SERVO_PERIOD, which would be an error
[03:31:26] <alphaEMC> cradek, no it doesn't it shows me /etc/emc2/sample-configs/ only
[03:31:51] <SWPadnos> if it still doesn't work, try changing TRAJ_PERIOD to 2000000
[03:32:02] <cradek> you have a directory level one too many or one too few
[03:32:21] <SWPadnos> change that to emc2/configs, I think
[03:32:21] <cradek> chris@buster2:~/emc2/configs$ unzip /home/chris/Desktop/config.zip
[03:32:25] <alphaEMC> okay
[03:32:35] <cradek> oh right, emc2
[03:33:04] <cradek> [2594796.117053] MOTION: bad traj period 1000000 nsec
[03:33:04] <alphaEMC> still dies with that config file... but works with axis sample.
[03:33:06] <cradek> I get this too
[03:33:24] <alphaEMC> okay... so back to manually editing the config file. :|
[03:33:26] <SWPadnos> try a 2 ms TRAJ period, or a 500 uS SERVO period
[03:33:37] <alphaEMC> SWPadnos, who?
[03:33:38] <alphaEMC> me?
[03:33:42] <SWPadnos> either
[03:33:45] <SWPadnos> both ;)
[03:33:46] <SWPadnos> whichever
[03:33:53] <SWPadnos> I'm on Windows ATM
[03:34:01] <skunkworksz> what he said
[03:34:06] <cradek> BASE_PERIOD = 50000
[03:34:08] <cradek> TRAJ_PERIOD = 1000000
[03:34:15] <cradek> what can possibly be wrong with this?
[03:34:25] <cradek> SERVO_PERIOD = 1000000
[03:34:38] <SWPadnos> the comments say that TRAJ period will be an even multiple of SERVO_PERIOD
[03:34:59] <skunkworksz> I guess 1 is an even multible :)
[03:35:04] <SWPadnos> if the 1.194304 MHz clock makes SERVO slightly longer than 1 mS, then TRAJ will be too low
[03:35:08] <cradek> I'm sure they can be the same
[03:35:23] <alphaEMC> still nonthing.
[03:35:29] <SWPadnos> make TRAJ 1010000 ns
[03:36:08] <cradek> no
[03:36:13] <cradek> but 2000000 works
[03:36:32] <SWPadnos> what's the actual period for each thread, from halcmd?
[03:37:00] <cradek> 2011440, 1005720, 50286
[03:37:49] <SWPadnos> ok - (partly) as I thought - the SERVO period was tounded up, so TRAJ was shorter, which is invalid
[03:37:53] <SWPadnos> rounded
[03:37:57] <alphaEMC> http://pastebin.ca/64680 <-- new error I think.
[03:38:08] <SWPadnos> same - need dmesg
[03:38:31] <SWPadnos> unfortunately, the terminal messages aren't very descriptive
[03:38:41] <SWPadnos> they're all "-1: operation not permitted" ;)
[03:38:53] <cradek> alphaEMC: did you change your TRAJ_PERIOD from 1000000 to 2000000? that fixes it for me
[03:39:14] <alphaEMC> http://pastebin.ca/64681
[03:39:22] <alphaEMC> I changed it to 1010000
[03:39:31] <SWPadnos> sadly, that doesn't work
[03:39:32] <alphaEMC> I'll change it to 2000000
[03:39:46] <SWPadnos> either that or SERVO_PERIOD goes down to 500000
[03:39:46] <alphaEMC> 2 000 000, two million right?
[03:39:50] <SWPadnos> yes
[03:40:20] <cradek> seems like that rounding needs some work
[03:40:35] <SWPadnos> yeah, and it may be requiring a multiple >=2 as well
[03:40:59] <cradek> no I've set them the same lots of times
[03:41:11] <alphaEMC> whoohoo!
[03:41:29] <alphaEMC> it's running axis... :D
[03:41:36] <alphaEMC> now... lets see if anything moves. :)
[03:41:43] <alphaEMC> oh wait... gotta check pinouts and stuff.
[03:41:45] <SWPadnos> ready on the estop
[03:41:49] <SWPadnos> ...
[03:41:50] <SWPadnos> ;)
[03:42:01] <alphaEMC> I guess I should plug that in too then. :D
[03:42:07] <alphaEMC> my acme stop button.
[03:42:19] <SWPadnos> ideally nothihng would move if the button weren't plugged in ;)
[03:49:10] <alphaEMC> what pin should the e-stop be on?
[03:49:31] <SWPadnos> whateer pin you connect in HAL
[03:49:35] <SWPadnos> whatever, that is
[03:50:22] <SWPadnos> it's just looped back in software in the hal file you have
[03:50:36] <SWPadnos> (assuming it's the same as I haev, from the config generator)
[03:50:44] <alphaEMC> # create a signal for the estop loopback
[03:50:44] <alphaEMC> linkpp iocontrol.0.user-enable-out iocontrol.0.emc-enable-in
[03:50:47] <alphaEMC> says that
[03:50:58] <SWPadnos> argh, looks like it's time for bed - I still can't type today
[03:51:03] <SWPadnos> yep - that's what it says
[03:51:21] <alphaEMC> it
[03:51:23] <alphaEMC> it's 0?
[03:51:35] <alphaEMC> man... screw it... I can hit esc right?
[03:51:49] <SWPadnos> change iocontrol.user-enable.out to something like parport.0.pin-11-in or something, then connect it to that port pin
[03:51:59] <alphaEMC> okay
[03:52:35] <SWPadnos> you may need parport.0.pin-11-in-not, if the logic is inverted
[03:52:47] <SWPadnos> (or use pin 13, on the end of the long row)
[03:54:00] <alphaEMC> 'ight
[04:09:04] <SWPadnos> SWPadnos is now known as SWP_Away
[04:09:15] <SWP_Away> good night. good luck A-L-P-H-A
[04:11:55] <alphaEMC> thanks
[04:11:56] <alphaEMC> good night
[04:13:13] <alphaEMC> oh... so much better.
[04:13:17] <alphaEMC> VNC into the emc box.
[04:13:27] <alphaEMC> in a comfy chair... not the workshop chair.
[04:15:54] <A-L-P-H-A> almost there.
[04:16:00] <A-L-P-H-A> will test in the morning... it's late now.
[04:35:40] <A-L-P-H-A> cradek, jepler, thanks for the help :_
[04:35:42] <A-L-P-H-A> :)
[06:57:35] <fenn> haha.. six sigma. how lame.
[07:00:53] <alex_joni> ?
[07:07:53] <eeboy> hello
[07:07:57] <alex_joni> hello
[07:08:33] <eeboy> good day.... just thought I'd ask a question of the group
[07:08:47] <alex_joni> sure starts like a good day ;)
[07:08:48] <alex_joni> go ahead
[07:09:22] <eeboy> what CAM processor (if exists) would you recommend for linux?
[07:09:49] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Cam
[07:11:34] <eeboy> any experience with the gCAD3D listed?
[07:11:52] <alex_joni> tried it once, but I wasn't quite impressed
[07:11:58] <alex_joni> didn't spend too much time on it though
[07:12:49] <alex_joni> although the features seem nice
[07:13:02] <eeboy> screen shots look nice!
[07:14:06] <eeboy> just looking for something to take in stl files (binary) as well as gerber files (pcbs) and generate nc files
[07:48:30] <wholepair> what keys if any are the button in the tkemc gui maped to. examp: if I want to hit run/resume/pause/step w/ out useing mouse what keys do I hit?
[07:51:11] <A-L-P-H-A> aj, almost ready to test emc2.
[07:51:23] <A-L-P-H-A> i'll test it tomorrow when I wake up
[07:51:27] <wholepair> im actually about to go to bed, but i will leave this running and check back in the morning - im so glad I have internet, ubuntu and emc2 in the shop now! this is great!
[07:51:30] <A-L-P-H-A> even though it's like 4am already... yikes.
[07:51:39] <wholepair> 1am here
[09:52:38] <A-L-P-H-A> there's not enough robin's.
[11:56:32] <jepler> wholepair: the keystrokes for axis are documented, and they were mostly modeled after tkemc. so you might have some luck trying them.
http://axis.unpy.net/quickref
[12:05:51] <alex_joni> morning jeff
[12:18:33] <cradek> hi all
[12:18:42] <alex_joni> hi chris
[12:18:48] <cradek> there's also tkemc help
[12:19:05] <cradek> some of it is incredibly out of date, but the key shortcuts are probably right
[12:31:49] <alex_joni> incredibly? :D
[12:31:59] <CIA-8> 03cradek 07HEAD * 10emc2/docs/help/tkemc.txt:
[12:31:59] <CIA-8> remove/update the worst of the out of date stuff, someone who knows
[12:31:59] <CIA-8> tkemc better should review it.
[12:32:13] <alex_joni> see.. now it's not that incredibly out of date :D
[15:01:45] <etla> anyone here ?
[15:01:51] <SWP_Away> nop
[15:01:52] <SWP_Away> e
[15:01:55] <SWP_Away> SWP_Away is now known as SWPadnos
[15:02:17] <etla> hi SWP
[15:02:28] <etla> do you know a lot about HAL ?
[15:02:36] <SWPadnos> I'm pretty good with it
[15:02:49] <etla> I'm using the sim config to test things
[15:03:00] <SWPadnos> (though I may screw up some specifics, since I have no machine handy to check myself with)
[15:03:07] <etla> and the sim HAL file uses the blocks component
[15:03:29] <etla> but after emc has loaded I want to use the blocks component for my own stuff (jogwheel/halui)
[15:03:47] <etla> and I get an error message when trying loadrt blocks
[15:03:53] <SWPadnos> you need to specify all the blocks you want at the first load time, as you've noticed
[15:04:01] <etla> insmod: error inserting '/home/etla/emc2/rtlib/blocks.ko': -1 File exists
[15:04:01] <etla> HAL:2: ERROR: insmod failed, returned 1
[15:04:15] <SWPadnos> did you make a copy of the sim config (in ~/emc2/configs)?
[15:04:39] <etla> I'm running from ~/emc2
[15:04:43] <SWPadnos> ok
[15:04:54] <etla> and the sim config I'm using is probably in /config/sim
[15:05:25] <SWPadnos> you should make a directory in ~/emc2/configs, and modify that
[15:05:32] <Bo^Dick> is usart and i2c the same thing?
[15:05:54] <etla> so the first time 'blocks' is loaded, I need to specify all the bits and pieces I want later on...
[15:05:56] <SWPadnos> you can just add the items you need to the "loadrt blocks ..." command (probably in sim_load.hal or similar)
[15:05:59] <SWPadnos> yep
[15:06:05] <etla> bodick: probably not
[15:06:26] <SWPadnos> we're trying to figure out a way to dynamically create and delete "subcomponents", but it can't be done now
[15:06:38] <SWPadnos> that's a 2.2 / 3.0 kind of change to HAL
[15:06:52] <etla> SWP: that's not very elegant... blocks components can be used in motion, IO, halui etc. - wildly different places
[15:06:56] <SWPadnos> Bo^Dick, some usarts can do I2C, but they're not the same thing
[15:07:40] <SWPadnos> that's the way it is right now, unfortunately. there's no easy (or even somewhat hard) solution to the problem
[15:07:40] <Bo^Dick> what interface will i need for an ATmega8515?
[15:08:10] <etla> SWP: OK, thanks for the explanation, I will have to load all blocks on one line then...
[15:08:21] <SWPadnos> Bo^Dick, sign up on www.avrfreaks.com, it's a good place to get info about the AVRs
[15:08:50] <Bo^Dick> thx :)
[15:08:59] <SWPadnos> etla, yep. the split of motion / IO / whatever else was done long after HAL was written, but that split is artificial
[15:09:17] <SWPadnos> Bo^Dick, no problem ;)
[15:09:38] <SWPadnos> etla, I mean in terms of the config files
[15:09:48] <SWPadnos> of course, emc has had the motion vs io split forever
[15:10:35] <etla> yes, but it's kind of cute to have one self-contained .hal file with motion stuff, one for io, one for jogwheel etc...
[15:10:43] <SWPadnos> that's true
[15:11:05] <SWPadnos> one thing you can do is create a "hal_load" file, and put all driver / module loads in there
[15:11:25] <SWPadnos> that keeps it all in one place, and the connections are still done in their respective files
[15:11:38] <SWPadnos> I think ppmc may be that way now
[15:13:09] <Bo^Dick> wish there was an irc channel though
[15:13:18] <SWPadnos> there probably is
[15:13:39] <Bo^Dick> i've tried "/list avr"
[15:13:47] <Bo^Dick> that's the way to search right?
[15:13:59] <SWPadnos> I think so - too bad the list server is overloaded ;)
[15:14:28] <SWPadnos> try #avr though
[15:19:49] <jepler> Bo^Dick:
http://searchirc.com/search.php?F=partial&N=59&M=min&C=1&D=color&T=both&PER=15&I=avr&Submit.x=0&Submit.y=0
[15:20:28] <jepler> looks like #avr and ##microcontrollers are two channels you might find helpful
[15:21:25] <etla> now my jog-increment rotary switch works!
[15:21:38] <etla> any ideas on how to get the axis selection switch to work ?
[15:21:44] <etla> it needs to output an int
[15:22:06] <etla> floats are easy with the mux2/4 block, but I'd want a similar thing with ints ??
[15:23:34] <jepler> good question
[15:23:38] <SWPadnos> err - I guess someone needs to write one ;)
[15:23:58] <SWPadnos> you may be able to use the weighted summer component though, if you can guarantee that only one input bit will be on at a time
[15:24:10] <etla> I have three digital inputs which will switch between six different states
[15:24:12] <SWPadnos> (and it's even separate from blocks, so you can load it later ;) )
[15:24:16] <SWPadnos> oh
[15:24:38] <SWPadnos> are you using a new cvs checkout from today?
[15:24:52] <etla> yesterday or the day before that I think
[15:24:56] <etla> HEAD
[15:25:12] <SWPadnos> ok. jmk added jogweheel support to the motion controller (in RT)
[15:25:26] <SWPadnos> there's a separate input for each axis, along with an enable
[15:25:35] <SWPadnos> and a scale (or jog increment)
[15:25:37] <etla> hmm... I'm using halui.jogwheel
[15:25:42] <SWPadnos> right
[15:26:16] <SWPadnos> what inputs does halui have for the jogwheel axis selection?
[15:26:17] <etla> so it's something like axis.X.jog ?
[15:26:51] <etla> halui.jog-wheel.axis which is an integer, don't know how many bits
[15:26:52] <Bo^Dick> why are DAC converters so expensive?
[15:27:24] <SWPadnos> they're nearly free
[15:27:29] <SWPadnos> unless you want a really good one
[15:28:31] <Bo^Dick> mention a typical price for a low cost one
[15:28:43] <SWPadnos> $0.15
[15:29:01] <etla> SWP: do you know if the motion jogging issues jog NML commands, or is it all handled internally in emcmot ?
[15:29:02] <SWPadnos> use a PWM output from the microcontroller, or make an R-2R ladder
[15:29:22] <SWPadnos> etla, the new code is all internal to the motion module
[15:29:37] <SWPadnos> no NML involved, which eliminates some smoothness issues
[15:29:47] <SWPadnos> err - lack of smoothness issues ;)
[15:29:51] <Bo^Dick> well the cheapest from my dealer is 3$ for the "DAC 0800"
[15:29:58] <etla> OK, makes halui.jog-wheel obsolete then...
[15:30:07] <SWPadnos> Bo^Dick, do you have any pins available on the microcontroller?
[15:30:27] <SWPadnos> etla, kind of. though halui.jogwheel may be useful for other things later
[15:31:14] <etla> ok, thanks for the chat guys, gotta go.
[15:32:56] <Bo^Dick> SWPadnos: not really
[15:33:17] <SWPadnos> well, then you can't talk to a DAC chip either ;)
[15:33:24] <Bo^Dick> SWPadnos: gonna use interrupts, usart and the built in A/D
[15:33:29] <SWPadnos> you need 3 or 4 pins to use a DAC
[15:34:14] <SWPadnos> if one of those can be a PWM, then an RC filter (two cheap components) is your DAC
[15:35:00] <Bo^Dick> ok
[15:35:18] <Bo^Dick> are there usart interfaces out there?
[15:35:28] <SWPadnos> what do you mean?
[15:36:02] <Bo^Dick> if one can buy an interface with lets say an 8-bit databus
[15:36:52] <SWPadnos> oh, yes there are
[15:37:29] <SWPadnos> maybe - I'm not sure I understand what you're trying to connect
[15:37:33] <SWPadnos> (or where)
[15:37:49] <Bo^Dick> my dealer doesn't appear to sell such interfaces. they sell i2c interfaces
[15:38:01] <SWPadnos> i2c interfaces to what?
[15:38:33] <SWPadnos> microcontroller -> (what protocol/connection) -> (some chip) -> (what I/O)?
[15:38:42] <SWPadnos> fill in the blanks ;)
[15:39:19] <Bo^Dick> microcontroller <- i2c or usart <- data
[15:39:27] <SWPadnos> data from what?
[15:39:38] <Bo^Dick> from jumper settings
[15:39:59] <SWPadnos> ok. so you don't have enough pins on the microcontroller, so you can't connect jumpers directly to it?
[15:40:01] <Bo^Dick> or an 8-bit switch
[15:40:12] <Bo^Dick> that's the very situation yes
[15:40:32] <Bo^Dick> this is a smart solution
[15:40:36] <Bo^Dick> isn't it
[15:40:52] <SWPadnos> are you already using a serial protocol to talk to other chips?
[15:41:04] <alex_joni> http://www.play-hookey.com/digital/shift-out_register.html
[15:41:33] <Bo^Dick> no i haven't determined which protocol to choose
[15:41:49] <Bo^Dick> i'm gonna use an ATmega8515 however
[15:41:59] <Bo^Dick> ...and it is said to support "usart"
[15:42:07] <alex_joni> http://www.allaboutcircuits.com/vol_4/chpt_12/3.html
[15:42:28] <SWPadnos> sure - the USARTs can be configured as microwire and possibly I2C as well
[15:42:38] <Bo^Dick> ok
[15:42:45] <SWPadnos> you'll use 3 pins (TX, RX, and clock) for the chip
[15:43:02] <alex_joni> there are one wire comms
[15:43:02] <Bo^Dick> that's awsome!
[15:43:24] <alex_joni> and I2C uses only 2 wires
[15:43:27] <Bo^Dick> so all i have to do is to buy me an I2C interface
[15:43:33] <alex_joni> only serial (usart) needs 3 wires
[15:43:44] <alex_joni> Bo^Dick: why isn't an par->serial shift register enough?
[15:43:48] <SWPadnos> microwire also uses 3 wires - remember the chip select
[15:44:17] <Bo^Dick> it's practical to use an established standard solution such as I2C and usart
[15:44:33] <alex_joni> par/serial is way more standard than I2C and usart
[15:44:37] <alex_joni> at least for reading jumpers
[15:44:42] <alex_joni> and it's way simpler/cheaper
[15:44:54] <Bo^Dick> if you say so...
[15:45:35] <Bo^Dick> i'll need to use several devices on the same line so i'll be stuck with any of them, i2c or usart or whatever
[15:45:51] <SWPadnos> there's a 74-series logic chip that's just an 8 bit parallel in -> serial shift out
[15:46:14] <Bo^Dick> yeah, but what about adressing several chips?
[15:46:29] <SWPadnos> that's where the extra lines come in, unless you use I2C
[15:46:30] <alex_joni> you can cascade them
[15:46:36] <alex_joni> and read them all
[15:46:49] <alex_joni> 74xx176
[15:46:51] <SWPadnos> assuming they're all parallel input chips
[15:46:53] <Bo^Dick> but the bottom line is, will an i2c interface work with usart or not?
[15:47:09] <alex_joni> err.. 165
[15:47:14] <alex_joni> Bo^Dick: not always
[15:47:15] <SWPadnos> look at the datasheet, for crying out loud ;)
[15:47:21] <alex_joni> it depends on the microcontroller
[15:47:36] <alex_joni> Jameco#: 45496
[15:47:36] <alex_joni> RoHS: Yes
[15:47:36] <alex_joni> MFG: MAJOR BRANDS
[15:47:36] <alex_joni> MFG#: 74HC165-R
[15:47:37] <alex_joni> PRICE: $0.27
[15:48:10] <Bo^Dick> if i hadn't burnt my pic i could have gone with i2c but with the atmel chip i need to mess with usart
[15:49:17] <SWPadnos> the atmel chip also has an SPI port
[15:49:30] <alex_joni> SPI is similar to I2C
[15:49:36] <Bo^Dick> ok
[15:49:43] <Bo^Dick> never heard about SPI before
[15:50:02] <SWPadnos> read the datasheet, then go to avrfreaks, then come here for motor-specific help ;)
[15:50:19] <SWPadnos> and remember #avr also :)
[15:50:27] <Bo^Dick> yeah, it'll take time before i'll have my system running
[15:50:29] <alex_joni> not quite sure what you want to connect to the I2C (except the microcontroller).. but that's your problem I reckon'
[15:50:56] <Bo^Dick> hey, #avr exits!!
[15:51:04] <Bo^Dick> had no idea!!
[15:51:14] <Bo^Dick> didn't find it with "/list avr"
[15:51:18] <Bo^Dick> that's for sure
[15:51:23] <alex_joni> 18:25 < jepler> looks like #avr and ##microcontrollers are two channels you
[15:51:23] <alex_joni> might find helpful
[15:51:25] <SWPadnos> you need to list #avr
[15:51:32] <alex_joni> that was 30 minutes ago
[15:52:44] <Bo^Dick> must've missed it
[15:52:58] <Bo^Dick> the "/list" function sucks then
[15:53:24] <SWPadnos> it's not a search, it just lists the exact channel you specify
[15:53:33] <SWPadnos> though jepler did post a link to an irc search tool as well
[15:56:04] <Roguish> SWPadnos: good morning. i have a few questions regarding the 5i20 and hal.
[15:56:12] <SWPadnos> uh-oh ;)
[15:56:15] <SWPadnos> go ahead
[15:56:16] <alex_joni> Roguish: hello
[15:56:22] <Roguish> hey all
[15:58:36] <Roguish> in the hostm54e.pin file which shows the map of signal to physical connectors on the 5i20 there are 'dir' signals listed for each axis. i have done a 'show' in hal to find the 'dir' signals but there are none listed.
[15:59:20] <Roguish> do they exist or do i need to somehow create them or am i lost in space?
[15:59:24] <SWPadnos> I don't think there should be.
[15:59:46] <SWPadnos> the input is a velocity (I think), which can be negative
[16:00:07] <SWPadnos> dir is set based on the sign of the input velocity (float)
[16:00:21] <SWPadnos> just as the PWM duty cycle is set by the magnitude
[16:02:05] <Roguish> so i have thought also. i have a small pwm amplifierd that takes a pwm frequency and a dir signal (hi or low) and drives an 18200.
[16:03:14] <Roguish> can i use hal commands to create a dir signal?
[16:03:39] <SWPadnos> yes, but you'll have to connect it to one of the digital outputs
[16:03:50] <SWPadnos> halcmd newsig X-Dir
[16:03:55] <SWPadnos> halcmd newsig X-Dir bit
[16:10:46] <Roguish> ok, that looks pretty straightforward. i have been reading hal documentation, but it seems rather lean.....
[16:11:04] <SWPadnos> how recent is your set of docs?
[16:11:39] <Roguish> i have 3 versions of hal docs. the latestest is 31 may 2006
[16:11:50] <SWPadnos> ok - that's pretty recent ;)
[16:12:18] <SWPadnos> there has been a lot of work on the docs recently - just wanted to be sure
[16:12:37] <SWPadnos> what is the document called, what do you find lacking?
[16:12:57] <Roguish> please, i am not wining or bitching, just trying to figure it all out. i think everyone is doing great!!!!
[16:12:57] <SWPadnos> (there are several places where this information resides, the docs have been reorganized recently)
[16:13:25] <SWPadnos> I'm looking for ways to improve it, so suggestions (and patches ;) ) are welcome
[16:14:35] <Roguish> within the 5i20 context, which component is loaded? stepgen, freqgen, and/or ...???
[16:15:23] <SWPadnos> none - the 5i20 has a PWM output, which looks like (and is named as) a DAC
[16:20:01] <Roguish> ok, with halcmd show i see a component 'hal_m5i20' is loaded. where is that file?
[16:23:09] <SWPadnos> what file?
[16:23:09] <alex_joni> dpkg -L emc2 | grep hal_m5i20
[16:23:56] <alex_joni> usr/realtime-2.6.12-magma/modules/emc2/hal_m5i20.ko
[16:24:08] <alex_joni> any reason to be looking for it?
[16:24:23] <SWPadnos> it depends on whether it's an installed (ubuntu) version, a BDI, or RIP though
[16:24:37] <alex_joni> * alex_joni assumed installed ubuntu
[16:25:21] <SWPadnos> you never know with this guy ;)
[16:38:26] <Roguish> sorry, was called away helping the girlfriend with some basic acad....
[16:38:43] <SWPadnos> heh
[16:38:50] <SWPadnos> that's not something you hear too often ;)
[16:39:00] <Roguish> i have a simple ubuntu 5.1 install
[16:39:03] <alex_joni> indeed
[16:39:29] <Roguish> interior designer at a really high end firm in SF
[16:39:32] <alex_joni> Roguish: any reason to be looking for the m5i20 module?
[16:39:34] <SWPadnos> (fwiw, that's 5 point ten, as in October 2005)
[16:39:54] <alex_joni> SWPadnos: no, it's 5.1 like the surround system
[16:39:58] <SWPadnos> heh
[16:39:59] <alex_joni> and the next one will be 7.1
[16:40:08] <alex_joni> but only next year :D
[16:40:13] <SWPadnos> January
[16:40:38] <Roguish> i need a 'dir' signal for my 18200 amp using the 5i20
[16:41:16] <Roguish> trying to see what is already available in hal
[16:43:08] <SWPadnos> it's there already - it's just controlled automatically
[16:43:36] <SWPadnos> (not in HAL, on the card)
[16:44:01] <Roguish> ok, how do i know that and how do i access it? halcmd newsig X-Dir?
[16:44:30] <SWPadnos> you can't access it - it's generated by the 5i20 card
[16:44:31] <Roguish> in the actual card driver?
[16:44:38] <SWPadnos> in the actual FPGA
[16:44:59] <Roguish> so the fpga program is generating my DIR signal?
[16:45:04] <SWPadnos> yes
[16:45:32] <Roguish> is that through peterv's driver?
[16:45:58] <SWPadnos> I didn't see any reference to the direction pin in the driver - I'm looking at the VHDL right now
[16:52:34] <SWPadnos> ok. the PWM is set to signed mode in the driver, so the DIR pin is controlled by the FPGA (in unsigned mode, the pin would be an input)
[16:54:18] <Roguish> ok, in m5i20.h i see a #define M5i20_pwm_ctl_direction
[16:54:25] <Roguish> that it?
[16:55:17] <SWPadnos> M5I20_PWM_CTL_SIGNED
[16:56:16] <SWPadnos> the direction var is a mask for when the DIR bit is input in unsigned mode, I thikn
[16:56:18] <SWPadnos> think, even
[16:56:43] <Roguish> ok, 2 lines above. are all those 'defines' hal signals?
[16:57:23] <SWPadnos> I don't see any HAL related stuff in m5i20.h
[16:58:38] <SWPadnos> that's the register map and other definitions for the card itself
[16:59:25] <SWPadnos> look at the function Device_ExportDacPinsParametersFunctions in hal_m5i20.c
[16:59:31] <Roguish> ok, is 'loadrt hal_m5i20' in m5i20_motion.hal
[16:59:54] <Roguish> should be "i see" not is
[17:00:18] <SWPadnos> that makes more sense ;)
[17:01:10] <Roguish> and i found 'hal_5i20.ko'
[17:01:23] <SWPadnos> what is it you're looking for?
[17:02:27] <Roguish> what, where, how, do i know what signals are available in hal?
[17:02:39] <SWPadnos> halcmd show sig
[17:02:57] <Roguish> done that. no 'dir' signals.
[17:03:15] <SWPadnos> correct - dir is an automatic function of the m5i20 hardware
[17:03:22] <SWPadnos> so you can't control it through HAL
[17:03:32] <SWPadnos> is there a problem with your 5i20 driving your motors?
[17:04:33] <Roguish> it doesn't seem like i am getting that dir signal on the physical connector pin. i will keep testing. i definitely get the pwm signal. shows on the scope.
[17:04:48] <Roguish> the dir should go high and low? correct?
[17:04:58] <SWPadnos> and you're sending both positive and negative numbers to the DAC signals?
[17:05:55] <Roguish> i'm trying a simple test system on the desk before going to my larger machine. also, trying to figure this whole emc2 thing out
[17:06:07] <SWPadnos> makes sense.
[17:06:23] <Roguish> i hate testing on full size machines.
[17:06:25] <SWPadnos> have you gone thtrough the hal/halcmd tutorial in the hal manual?
[17:06:30] <Roguish> yes.
[17:06:36] <SWPadnos> heh - good plan (unless E-Stop is known working)
[17:07:03] <SWPadnos> you should be able to set up a simple HAL, by just loading m5i20 and siggen
[17:07:18] <SWPadnos> connect a siggen output to one of the 5i20 DACs, and see what happens
[17:07:23] <SWPadnos> (on a scope)
[17:07:42] <Roguish> gave a proposal the other day to replace my client's 'burned up' machine. $75k
[17:07:59] <Roguish> they want to use emc2
[17:08:17] <Roguish> figure i better know what i'm talking about
[17:08:23] <SWPadnos> good plan
[17:10:03] <Roguish> in regard to the physical connector pin map for the 5i20, i am trying to check each one.
[17:10:37] <SWPadnos> ok. that's more of an m5i20 issue than emc2 itself.
[17:10:58] <SWPadnos> obviously, things would be different with a different servo card
[17:11:14] <Roguish> if the signals are not listed in 'show sig' then they are at the board level.
[17:11:18] <Roguish> ?
[17:11:31] <SWPadnos> well, sort of
[17:11:50] <SWPadnos> use halcmd show pin to see what things *could* be connected
[17:12:00] <SWPadnos> that's the "pinout" of the component
[17:12:12] <SWPadnos> signals are only there if they've been explicitly created
[17:14:43] <skunkworks> does the 5i20 do pwm and direction?
[17:14:50] <SWPadnos> yes
[17:15:19] <skunkworks> how hard would it be to make it like the freqgen pwm+pwm
[17:15:36] <Roguish> on connector 1, there are the usual encoder inputs, with pwm, dir, and enable for each axis
[17:15:49] <SWPadnos> it's set up more like a DAC at the moment, but it could be done. not sure if it's worth the effort though
[17:15:59] <skunkworks> (I guess it would only take a few componants to do that.)
[17:16:05] <skunkworks> externally
[17:16:11] <SWPadnos> ?
[17:17:21] <Roguish> SPW: thank you for you help. i will keep testing. i go slow as to not blow things up. (which i'm really good at doing)
[17:17:28] <SWPadnos> heh.
[17:19:22] <skunkworks> I am just thinking out loud - my servo drives are controlling the h-bridge - I would need 2 pwm signals
[17:20:17] <skunkworks> I would think a few logic chips would do that. (if I needed it)
[17:20:26] <SWPadnos> separate PWM for each phase of a 3-phase motor, or 2 opposing PWMs?
[17:20:49] <skunkworks> think what jepler is doing with his etchosketch
[17:21:16] <skunkworks> same thing - except I am using a larger h-bridge
[17:21:18] <SWPadnos> ok - the up/down outputs?
[17:21:21] <skunkworks> right
[17:21:48] <SWPadnos> you don't want them both on at the same time though, right?
[17:22:06] <skunkworks> right
[17:22:33] <skunkworks> although it would not do anything catostrofic (I think)
[17:22:34] <SWPadnos> ok. there's some sort of synchronization flag in the 5i20 FPGA, I'm not sure what it does
[17:22:52] <SWPadnos> I think it might try to short out the power supply, so it could be catastrophic ;)
[17:23:18] <skunkworks> I would think it would just turn on the 2 high mosfets -
[17:23:37] <SWPadnos> ok - that would be all right - just a braking mode
[17:24:14] <skunkworks> with the ir2111 I don't think you could ever get both high and low mosfets turned on at once.
[17:24:33] <skunkworks> although alex may have gotten it to :)
[17:24:42] <SWPadnos> right - it's a single pin for each par, with 2 pair making an H-bridge
[17:24:45] <SWPadnos> each pair
[17:24:51] <SWPadnos> (of transistors)
[17:24:59] <skunkworks> rigth
[17:30:21] <skunkworks> I think I have seen circuits that take pwm+dir and convert it to pwm+pwm. If I thought about it hard I could probabaly figure it out :)
[17:32:29] <SWPadnos> I'm not so sure it's that easy
[17:32:57] <SWPadnos> it may be - just invert the PWM signal for one side, and 50% duty cycle becomes "no motion"
[17:34:45] <alex_joni> * alex_joni heads home
[17:34:48] <alex_joni> later everyone
[17:34:54] <skunkworks> na - I was thinking dir pin would transfer the pwm signal from one bridge to another
[17:34:58] <SWPadnos> see you later
[17:35:04] <skunkworks> drive safe
[17:39:17] <skunkworks> I think alex_joni h-bridge circuit that I had seen does this - but it has been a while
[17:40:03] <skunkworks> like 2 and gates with one input on one of the gates inverted.
[17:40:22] <skunkworks> direction go to both as does the pwm signal
[17:40:37] <skunkworks> direction then toggles between the and gates
[17:40:43] <skunkworks> if that makes sense
[17:40:48] <SWPadnos> yep - that would work
[17:41:19] <SWPadnos> except that you need to invert the direction signal for one of the and gates
[17:41:27] <SWPadnos> otherwise they always output the same thing ;)
[17:42:19] <skunkworks> right ^ <skunkworks> like 2 and gates with one input on one of the gates inverted.
[17:42:30] <SWPadnos> oh - right
[17:42:56] <SWPadnos> more like 3 NAND (or XOR) gates, in discrete logic
[17:43:24] <skunkworks> that is where I get fuzzy - my logic is very old.
[17:43:50] <SWPadnos> heh - DeMorgan is easy to forget (or block from memory)
[17:44:03] <skunkworks> right
[17:44:24] <SWPadnos> one NAND gets both inputs connected to DIR, causing it to act like an inverter. otherwise, it's just as you described
[17:44:42] <skunkworks> ok
[17:59:58] <les_w> hi all
[18:00:10] <SWPadnos> hi Les
[18:00:31] <les_w> just taking a break
[18:01:13] <les_w> was looking at jeff's segment joining thing
[18:02:06] <SWPadnos> it looks good to me
[18:02:32] <les_w> I guess that implied the queue still starves
[18:03:03] <SWPadnos> I'm not sure, actually. Matt Timmermans sent an interesting mail to the list on that subject
[18:03:24] <les_w> oh really where is it?
[18:04:01] <SWPadnos> err - on the list ;)
[18:04:27] <les_w> always for me the queue would starve...it would pause and fill it again the motion would resumes
[18:04:41] <les_w> I missed it
[18:04:48] <les_w> have to check back
[18:04:51] <SWPadnos> it's from 10:25 AM today
[18:04:59] <les_w> hmm
[18:05:01] <SWPadnos> in reply to Jeff's post (on the developer lilst)
[18:05:03] <les_w> let me look
[18:05:04] <SWPadnos> list
[18:05:07] <les_w> dev list?
[18:05:33] <SWPadnos> he just questions whether queue startvation was actually happening on the particular files (3d_chips) that Jeff used
[18:05:49] <SWPadnos> not that the solution is only for that file though
[18:06:19] <etla> if the queue length is a known parameter, maybe the GUI could show it all the time ?
[18:06:26] <SWPadnos> you should take a file of yours that used to cause starvation (maybe some of the ones that you and Paul tested with), and see what happens
[18:06:42] <cradek> les_w: I saw queue starvation recently (on a program made bad on purpose) and improved segment throughput by a factor of 10 with a 1-line fix, I doubt you'd have trouble anymore.
[18:06:55] <SWPadnos> the GUI isn't realtime, so it might not show if starvation occurs
[18:07:21] <cradek> you could easily plot queuelen=1 in a different color with axis (like I had the blends colored)
[18:07:46] <cradek> but even without jeff's fix, I think the problem is pretty much gone
[18:07:51] <SWPadnos> well - whatever fix that was, plus Jeff's combining segments, would take care of it for sure ;)
[18:07:57] <cradek> yes definitely
[18:08:17] <cradek> jeff's change mostly makes it so you can run through the program at higher speed with the current planning algorithm
[18:08:34] <les_w> ok
[18:08:46] <les_w> I need some time to try this stuff!
[18:09:01] <les_w> booked solid though
[18:09:15] <les_w> "manhattan project"
[18:09:19] <SWPadnos> you need to hire someone to try this stuff ;)
[18:09:27] <les_w> that's what everyone wants these days
[18:09:35] <cradek> les_w: I bet there are a lot of things in emc2 that could help you.
[18:09:42] <les_w> yes
[18:10:27] <les_w> Seems likely i'll have to dive into factory automation very soon
[18:10:37] <les_w> That may be a time I can look at it
[18:11:25] <jepler> I also agree that the problem of queue starvation may be fixed without my changes.
[18:11:34] <skunkworks> was that my psyco program?
[18:11:36] <jepler> but there's still the problem with segments so slow there's no cruise phase, and merging segments can improve that
[18:11:47] <les_w> right
[18:11:56] <cradek> yes there's no doubt your changes will help keep speed up
[18:11:58] <jepler> er, "segments so *short* there's no cruise phase"
[18:12:22] <jepler> cradek: besides your factor-of-10, there's the factor-of-3 from merging the move, accel, and vel messages into a single message.
[18:12:24] <dmessier> hi all
[18:12:31] <cradek> jepler: right, forgot about that
[18:12:47] <les_w> normally there should be no problem with no cruise phase segments....but of course there was a math bug with that
[18:12:52] <cradek> now we've got hundreds of moves a second throughput from the interp
[18:13:04] <jepler> cradek: which change was the "factor of 10" one? is that the .ini change, or something else?
[18:13:12] <alex_joni> jepler: the CYCLE_TIME
[18:13:28] <cradek> jepler: yes the TASK CYCLE_TIME was being ignored (and the default was low)
[18:13:46] <les_w> my programs commonly aked for several hundred segments per second
[18:14:06] <alex_joni> les_w: sounds like "debateable" CAM ;)
[18:14:17] <cradek> les_w: that was a real problem then, not long ago the throughput was about 10 seg/sec
[18:14:17] <les_w> or the settings
[18:14:35] <cradek> yeah that must be some terrible gcode, no debate there
[18:14:46] <dmessier> some work requires that.. rthough...
[18:14:50] <les_w> no, it's just the combination of high accuracy and high speed both at the same time
[18:15:00] <alex_joni> the gcode probably isn't (bad by definition), just the CAM seems .. odd
[18:15:06] <alex_joni> les_w: how about arcs?
[18:15:48] <les_w> My programs use arcs some, but of course two tangwnt arcs blended have infinite jerk....
[18:16:12] <SWPadnos> was the CYCLE_TIME being ignored in emc1?
[18:16:17] <alex_joni> you could blend a straight line between them
[18:16:20] <jepler> SWPadnos: unknown
[18:16:21] <alex_joni> les_w: lol
[18:16:37] <dmessier> some times point to point is the only option when the intol/outlol is controled by the CAM system ie apt
[18:16:42] <alex_joni> SWPadnos: I'm probably not sure
[18:16:46] <SWPadnos> that's what les is using now, so we can't be sure that the fix would represent a change for him
[18:16:56] <les_w> yes, in fact even a cubic would make a tiny flat spot at tangent arc intersection
[18:17:56] <cradek> les_w: you're not even using an up-to-date emc1 are you?
[18:18:06] <les_w> Imagine something like a small parabola with .02 mm chordal error
[18:18:12] <anonimasu> hello
[18:18:20] <les_w> but cut at 400 ipm
[18:18:35] <dmessier> only 3 pts
[18:18:35] <les_w> er
[18:18:40] <les_w> 10 meters/min
[18:18:46] <les_w> haha
[18:18:59] <dmessier> meme chose
[18:19:05] <les_w> no tin g-code!
[18:20:19] <dmessier> you would need to drop feedrate by 1/10 to get thru that parabola
[18:20:36] <jepler> les_w: what's the machine's acceleration?
[18:21:15] <les_w> it can do 0,5 g in x, about 4 in y and z
[18:21:37] <dmessier> moving mass???
[18:21:47] <les_w> 1000 Kg
[18:21:50] <les_w> in x
[18:21:54] <dmessier> SHITE
[18:22:07] <les_w> 5.6 Kva servo
[18:22:15] <dmessier> still
[18:22:30] <dmessier> throwin' a ton around..
[18:22:40] <skunkworks> it must warp time and space while it is moving ;)
[18:22:48] <cradek> % units 4*gravity inch/sec2
[18:22:48] <cradek> * 1544.3543
[18:22:53] <cradek> is this the right number?
[18:23:16] <cradek> that seems pretty darn high
[18:23:20] <alex_joni> cradek: shouldn't it be 0.5*gravity ?
[18:23:27] <dmessier> but seems correct
[18:23:28] <alex_joni> oh.. that's y & z
[18:23:31] <alex_joni> nm
[18:23:41] <les_w> 1 g is 384 in/sec^2
[18:23:51] <cradek> 386
[18:24:02] <les_w> 9.81 meters/sec^2
[18:24:05] <alex_joni> 486
[18:24:08] <les_w> haha
[18:24:09] <cradek> still, damn
[18:24:11] <alex_joni> 586
[18:24:14] <alex_joni> pentium ;)
[18:24:44] <cradek> so do you run it at 100? 200?
[18:24:54] <dmessier> you ARE trying to ROCK and ROLL a MOUNTAiN brother... go big or stay home
[18:25:08] <dmessier> i love it
[18:25:20] <cradek> with some hard numbers one of us could plug them into emc2 and see how it does
[18:25:35] <cradek> and even plot the results
[18:25:38] <les_w> since I was using the old software I was limited to about 180 ipm and only 30 inches?sec^2
[18:25:39] <alex_joni> cradek: right, maybe les can send an ini
[18:25:46] <les_w> basically crippled
[18:26:00] <skunkworks> good idea
[18:26:00] <alex_joni> les_w: can you say what theoretical values the machine should handle?
[18:26:14] <les_w> yeah
[18:26:20] <dmessier> and heating up the drives to run it like that i bet??
[18:26:25] <les_w> 600 ipm max
[18:26:34] <les_w> and the g figures I mentioned
[18:26:54] <les_w> complex conjugate pole pair in x at about 20 Hz
[18:27:01] <les_w> q is about 5-10
[18:27:15] <les_w> y and z are very low q
[18:27:29] <alex_joni> MAX_VELOCITY = 10
[18:27:45] <alex_joni> MAX_ACCELERATION = 1544
[18:28:00] <alex_joni> BACKLASH = 0 ?
[18:28:07] <les_w> zero yes
[18:28:17] <alex_joni> this is servo.. right?
[18:28:21] <les_w> yes
[18:28:24] <les_w> big srvo
[18:28:24] <alex_joni> FERROR?
[18:28:31] <alex_joni> les_w: debateable ;)
[18:28:44] <alex_joni> * alex_joni runs some 5-10kW AC servos too
[18:28:55] <les_w> oh gosh it was pretty big with emc1
[18:29:03] <les_w> .01 in
[18:29:05] <alex_joni> I agree it's pretty big ;)
[18:29:15] <anonimasu> laters
[18:29:19] <alex_joni> FERROR = 0.01
[18:29:22] <les_w> that's min ferror
[18:29:26] <alex_joni> MIN_FERROR = 0.01
[18:29:27] <alex_joni> ok
[18:29:40] <alex_joni> and FERROR?
[18:29:41] <les_w> Ferror a little higher
[18:29:43] <les_w> .02
[18:29:48] <alex_joni> ok
[18:29:55] <SWPadnos> .02 seems low to me
[18:30:09] <les_w> inches
[18:30:10] <SWPadnos> that's the allowed ferror at full speed
[18:30:21] <SWPadnos> ok - that's high then ;)
[18:30:22] <cradek> no it's multiplied by the speed somehow
[18:30:29] <cradek> I think?
[18:30:36] <alex_joni> cradek: shouldn't be
[18:30:42] <cradek> oh ok
[18:30:47] <SWPadnos> right - if MIN_FERROR exists, then that's the min, and FERROR is the allowed error at max vel
[18:31:05] <SWPadnos> FERROR is multiplied by vel/max_vel to get the actual value used
[18:31:07] <cradek> maxferror = (speed/fullspeed) * FERROR + MIN_FERROR
[18:31:17] <alex_joni> Max and min ferror work like this: limiting ferror is
[18:31:17] <alex_joni> determined by slope of ferror line, = maxFerror/limitVel ->
[18:31:17] <alex_joni> limiting ferror = maxFerror/limitVel * vel. If ferror <
[18:31:17] <alex_joni> minFerror then OK else if ferror < limiting ferror then OK
[18:31:18] <cradek> ?
[18:31:18] <alex_joni> else ERROR
[18:31:19] <les_w> I can knock most all of it out with feedforward, but that causes the TP errors to be violent, so I don't
[18:31:21] <SWPadnos> I think min_ferror is a clamp, not an offset, but yeah
[18:31:29] <cradek> ok
[18:31:58] <les_w> yeah it's a clamp
[18:32:38] <alex_joni> sorry for the bad paste ;)
[18:32:43] <SWPadnos> heh
[18:34:03] <les_w> anyway the biggest limitation on the machine is bandwidth of the servo loop
[18:34:20] <les_w> because of those 20 hz poles
[18:35:25] <SWPadnos> you should have ~500 Hz with the stock settings - have you needed to set the SERVO_PERIOD lower?
[18:35:42] <SWPadnos> (or the emc1 equivalent)
[18:35:43] <les_w> I can knock em out (put zeros over them) with a dynamic absorber...but did not because emc1 really is not fast enough to excite them except for transients
[18:36:02] <les_w> servo period is as fast as you can go with stg2
[18:36:16] <SWPadnos> were you at 2 KHz?
[18:36:23] <les_w> yeah
[18:36:33] <les_w> which is way too slow
[18:36:55] <SWPadnos> seems like it shouldn't be
[18:36:59] <les_w> that can be solved by using the motenc though
[18:37:57] <les_w> at full speed. that's 2000 updates in 10 inches
[18:38:04] <les_w> one every .05 in?
[18:38:08] <les_w> not good
[18:38:35] <les_w> but I know the motenc can do 5 times that
[18:38:42] <les_w> so no problem there
[18:38:49] <les_w> just change ythr csrd
[18:38:53] <SWPadnos> the motors should be enough of a damper to be OK with that update rate, though very segments wouldn't survive intact
[18:39:09] <les_w> haha
[18:39:17] <les_w> what is a very segment?
[18:39:27] <SWPadnos> very short segments (so short you can't see the word ;) )
[18:39:33] <les_w> hahaha
[18:40:30] <les_w> so really the biggest issue with arbitrary motion is the poles at 20 hz
[18:40:52] <les_w> EMC has no band reject comprnsation filter
[18:41:09] <les_w> so 180 phase shift at the poles
[18:41:16] <SWPadnos> no, but it would be pretty easy to write one, and stick it after the PID
[18:41:29] <les_w> yeah
[18:41:43] <SWPadnos> something like an 8-tap or so FIR filter would do the trick, I bet
[18:41:47] <les_w> but a FIR filter is a double loop
[18:41:52] <les_w> slow it down?
[18:42:11] <les_w> might not
[18:42:27] <SWPadnos> it should be a single loop - it's a 1-d dot product I think
[18:42:40] <les_w> I think I talked to fred about that once
[18:42:51] <les_w> at the time the group delay was too much
[18:43:13] <SWPadnos> well - generating the constants is the hard part. calculating with them is easy
[18:43:29] <SWPadnos> you should be able to fiddle with group delay when generating constants
[18:44:11] <SWPadnos> maybe I'm thinking of IIR filters - who knows ;)
[18:44:13] <les_w> the filter coefficents are easy too....calculate to put zeros on the poles
[18:44:32] <les_w> FIR is constant group delay
[18:45:41] <les_w> anyway....most machine controllers have a band reject filter in the PID. Guess its a want list item. (for me)
[18:46:23] <les_w> However feedforward things like dynamic absorbers are always better
[18:47:02] <les_w> they put zeros on the poles, but make more poles elswhere.
[18:47:18] <les_w> lower q ones though.
[18:47:19] <SWPadnos> right - just outside the bandwidth of the system
[18:47:37] <les_w> well one of them is
[18:49:21] <les_w> anyway I think the boxes these days could do an 8 pt FIR pretty fast
[18:49:37] <les_w> 64 multiplications per servo cycle
[18:49:51] <les_w> nothin...right?
[18:49:54] <SWPadnos> I'm pretty sure that's just 8 multiplications: sum(coeff(n) * sample(n))
[18:50:12] <les_w> it's a convolution.....
[18:50:14] <SWPadnos> and you rotate the samples through
[18:50:28] <SWPadnos> hmmm - I must be thinking ofa different kind of filter then ;)
[18:50:46] <SWPadnos> anyway - float multiplies are ~3 cycles, I think
[18:50:48] <les_w> no you're right
[18:51:19] <SWPadnos> I think youend up with a convolution, but not in a single period
[18:51:58] <SWPadnos> IthinkIshouldeatsomethingbeforemytypinggetsreallybad
[18:52:18] <les_w> haha
[18:52:30] <les_w> me too
[18:52:33] <les_w> later
[18:52:36] <SWPadnos> see yuo
[18:52:38] <SWPadnos> you
[18:52:40] <SWPadnos> argh
[18:52:57] <les_w> see yuo mr low blood sugar
[18:53:42] <alex_joni> * alex_joni passes SWPadnos a power bar
[18:53:55] <skunkworks> great - the pressure is off of me :)
[18:54:19] <skunkworks> alex - are you actually testing les's settings?
[18:54:25] <alex_joni> skunkworks: not now
[18:54:37] <alex_joni> right now I'm cursing some strange ladder format
[18:55:15] <alex_joni> IEC 61131-3 :-X
[19:08:47] <jepler> cradek and I were looking at some halscope plots for a 4" parabola made from 4000 G1 moves and the simulator tweaked to be like les's specs
[19:08:53] <jepler> it looks .. weird .. in emc2
[19:09:18] <jepler> I think there's still a bug for cradek to solve
[19:09:31] <jepler> and also one for me
[19:10:27] <alex_joni> jepler: did you take a snapshot?
[19:11:10] <jepler> http://emergent.unpy.net/files/sandbox/halscope-parabola.png
[19:11:30] <jepler> this is with g64 p- so many of the segments are merged together
[19:11:46] <alex_joni> oii..
[19:11:48] <jepler> the top two plots are accelerations, the bottom are velocities
[19:12:01] <jepler> we don't have a clue why the X velocity would be so "sawtooth"
[19:12:29] <etla> do you have a pic of the toolpath ?
[19:13:36] <jepler> http://emergent.unpy.net/files/sandbox/toolpath-parabola.png
[19:14:15] <etla> strange...
[19:14:50] <cradek> what we really need is a plot of tangential velocity
[19:15:21] <etla> that can be computed from X and Y ?
[19:15:34] <jepler> etla: yes, but right now there's no way to get the plot of it easily
[19:15:35] <alex_joni> etla: and sin
[19:15:59] <fenn> do you get the same thing with a circle?
[19:18:19] <etla> alex: could you advise on how to get cvs acces for updating the manual
[19:18:42] <SWPadnos> what's the feedrate?
[19:19:36] <cradek> 400 ipm
[19:20:15] <SWPadnos> ok. so it's 4000 0.001 moves along a parabolic path?
[19:20:26] <cradek> yes something like that
[19:21:07] <cradek> which gets downsampled to 15-20 moves
[19:21:08] <jepler> http://emergent.unpy.net/files/sandbox/sim-les.ini http://emergent.unpy.net/files/sandbox/parabola.ngc
[19:21:36] <alex_joni> etla: /msg?
[19:21:48] <jepler> the other difference in my local copy of emc is that I increased the number of segments that can be merged compared to the setting in HEAD
[19:22:27] <jepler> --- src/emc/task/emccanon.cc11 Jun 2006 21:17:22 -00001.60
[19:22:27] <jepler> +++ src/emc/task/emccanon.cc12 Jun 2006 19:26:59 -0000
[19:22:27] <jepler> @@ -499 +499 @@
[19:22:27] <jepler> - if(chained_points().size() > 100) return false;
[19:22:27] <jepler> + if(chained_points().size() > 1000) return false;
[19:24:23] <giacus> Ghana go, go go! Go for it Ghana!
[19:24:26] <giacus> :D
[19:25:18] <SWPadnos> what do the plots look like if you reduce the feedrate to ~350 IPM?
[19:30:12] <skunkworks> what you are seeing in the plot is the 20 or so segments
[19:31:37] <SWPadnos> hmmm - it might be better to look at that with a scale that shows one sample per pixel or thereabouts
[19:32:00] <SWPadnos> right now, roughly 4 samples are collapsed into a single horizontal pixel
[19:32:24] <SWPadnos> I suppose I should just fire up my machine snd look for myself ;)
[19:32:29] <SWPadnos> s/snd/and/
[19:35:06] <alex_joni> SWPadnos: did you eat?
[19:35:28] <SWPadnos> not really - just some cheese and peanut m+m's ;)
[19:35:35] <alex_joni> go eat
[19:36:15] <SWPadnos> heh - unfortunately, the nice organic Spanish spicy chorizo sausage I bought tastes like shit :(
[19:36:28] <fenn> i wonder why
[19:38:30] <Jymmm> SWPadnos: You haven't figured out by now that "organic" == "tastes like shit"
[19:38:42] <alex_joni> it should taste like spicy spanish organic shit
[19:39:45] <cradek> maybe you can trade your chorizo for a nice loaf of sourdough, or some lentil soup
[19:40:03] <alex_joni> lentil soup?
[19:40:09] <cradek> mmm or falafel
[19:40:15] <SWPadnos> I'm heating some nice clam chowder, thank you ;)
[19:40:20] <SWPadnos> falafel would be good
[19:40:50] <SWPadnos> this si amazing - the neighbor is mowing or weedwhacking, and the cat still manages to sleep on the deck
[19:40:54] <SWPadnos> s/si/is/
[19:41:04] <cradek> they have a special talent for that
[19:41:10] <SWPadnos> this one especially
[19:41:41] <SWPadnos> in D&D, cats would have a +20 cloak of sleeping or something
[19:43:20] <jepler> bad return value from emcTrajSetAxes
[19:43:20] <jepler> emc/ini/iniaxis.cc 226: bad return from emcAxisSetBacklash
[19:43:20] <jepler> emc/ini/iniaxis.cc 226: bad return from emcAxisSetBacklash
[19:43:20] <jepler> emc/ini/iniaxis.cc 226: bad return from emcAxisSetBacklash
[19:43:25] <jepler> huh, I wonder what this is about
[19:43:29] <jepler> "I didn't change anything!"
[19:43:45] <alex_joni> jepler: odd
[19:43:50] <alex_joni> bad compile?
[19:43:57] <jepler> I dunno
[19:44:43] <jepler> something must be wrong with my new 'hypot' component
[19:45:09] <alex_joni> jepler: jmk removed some stuff last night
[19:45:14] <alex_joni> might be related?
[19:45:30] <jepler> no, it is working unless I attach my 'hypot' thread
[19:46:19] <alex_joni> oh
[19:47:18] <skunkworks> what happens if you run the program without the hypot - what is the max feed it will go and what does it look like?
[19:47:40] <jepler> aha, found a possible mistake
[19:48:25] <davidf> hi
[19:48:33] <alex_joni> hello
[19:48:36] <SWPadnos> hi.
[19:48:43] <davidf> Hey.
[19:48:47] <alex_joni> ho
[19:48:52] <SWPadnos> hidey-ho
[19:48:59] <alex_joni> hidey-hey-ho
[19:49:00] <davidf> I have emc2 running, and can draw my parts.
[19:49:08] <SWPadnos> yo dog, whaddap?
[19:49:10] <alex_joni> wot? that fast?
[19:49:24] <alex_joni> davidf: something is surely still wrong:D
[19:49:24] <davidf> OKIt's running. :)
[19:49:34] <davidf> Yes, there is.
[19:49:39] <fenn> alex_joni: you had any doubt?
[19:49:42] <alex_joni> of course, or you wouldn't be here
[19:49:51] <davidf> I'm having trouble with radius comp.
[19:50:13] <davidf> C'mon, guys.
[19:50:17] <davidf> :)
[19:50:25] <alex_joni> davidf: what trouble?
[19:50:40] <davidf> Next time I pop a beer I'll check in just because. OK?
[19:51:15] <davidf> Any tool radius set in .tbl file causes gouging error.
[19:51:53] <alex_joni> did you select that tool?
[19:51:56] <davidf> I put these lines in G code:
[19:51:59] <davidf> G0
[19:52:07] <davidf> at the top.
[19:52:16] <davidf> Then G41 D1
[19:52:31] <davidf> The fisrt tool is radius 0.125
[19:52:50] <davidf> But any non zero radius causes the gouging error.
[19:52:53] <alex_joni> davidf: tried the manual?
[19:53:00] <alex_joni> * alex_joni grins
[19:53:19] <alex_joni> davidf: I suspect you have an angle in your file
[19:53:20] <davidf> Yes. I did. Been trying for an hour to get it right.
[19:53:42] <davidf> Rather than an arc, huh?
[19:54:04] <davidf> So the tool won't fit.
[19:54:05] <alex_joni> no, an angle less than 180degrees
[19:54:12] <alex_joni> yeah, that's what I mean
[19:54:22] <alex_joni> not sure how that's called
[19:54:28] <alex_joni> I think the other one is obtuse
[19:54:32] <SWPadnos> acute
[19:54:40] <SWPadnos> but that's < or > 90 degrees
[19:54:48] <SWPadnos> (acute vs. obtuse)
[19:54:55] <alex_joni> ok, then twice that
[19:55:03] <alex_joni> SWPadnos: back me up on this?
[19:55:06] <davidf> I understand I think. Any angle with straight lines meeting has zero radius at the corner.
[19:55:22] <alex_joni> you can have angles
[19:55:28] <alex_joni> but the tool needs to be outside
[19:55:30] <SWPadnos> right - just listen to Alex - he really knows what he's talking about ;)
[19:55:34] <SWPadnos> (how's that)
[19:55:45] <alex_joni> SWPadnos: not what I bargained for.. but it's ok
[19:55:49] <SWPadnos> heh
[19:56:31] <alex_joni> davidf: I remember reading about this in the user Handbook
[19:56:41] <alex_joni> but this was quite some time ago.. let me refresh my memory
[19:56:53] <SWPadnos> G41 is left hand side compensation
[19:56:59] <davidf> I get it, but I checked the code. It seems ok. If you think that's the problem I'll have a closer look at the drawing I started with.
[19:57:07] <SWPadnos> can you pastebin the code?
[19:57:12] <davidf> Yes, G41 = Left G42=Right.
[19:57:35] <davidf> Yeah...
[19:58:11] <alex_joni> davidf: page 128
[19:58:18] <alex_joni> http://www.linuxcnc.org/EMC2_User_Manual.pdf
[19:58:27] <alex_joni> davidf: it has pictures :D
[19:58:38] <alex_joni> better explained that I ever could ;)
[19:58:42] <SWPadnos> ah - I'm looking at rs274ngc_3.pdf, and there are only 121 pages ;)
[19:58:57] <davidf> The error says 'Near line 2 - Gougeing etc. So can I just paste the first few lines, or could the actual gouge be anywhere down the list?
[19:58:58] <alex_joni> SWPadnos: THE manual ;)
[19:59:09] <davidf> I have the manual on my box.
[19:59:36] <SWPadnos> paste in a couple dozen lines at least
[19:59:39] <alex_joni> "In particular, the interpreter treats concave corners and concave arcs into which the circle will not
[19:59:42] <davidf> OK...
[19:59:43] <alex_joni> fit as errors, since the circle cannot be kept tangent to the contour in these situations. This error
[19:59:46] <alex_joni> detection does not limit the shapes which can be cut, but it does require that the programmer
[19:59:49] <alex_joni> specify the actual shape to be cut (or path to be followed), not an approximation."
[20:00:13] <fenn> hm thats annoying
[20:00:29] <alex_joni> fenn: what is?
[20:00:36] <fenn> that it doesn't just round the corner
[20:00:36] <davidf> I programmed the actual shape to 4 dec. places.
[20:00:51] <alex_joni> fenn: I wouldn't want it to do that
[20:01:15] <davidf> Right. I think it would be nicer if you got a warning with option to proceed rather than a balk.
[20:01:20] <fenn> you'd rather it wuss out and make you scramble your gcode all to hell?
[20:01:31] <alex_joni> fenn: honestly? :D
[20:01:42] <SWPadnos> it's not always possible to calculate the correct path from the G-code
[20:02:03] <SWPadnos> consider that it might have to go back 20 segments to find a spot from where a tangent arc can be started
[20:02:12] <fenn> yeah yeah
[20:02:22] <alex_joni> fenn: patches happily accepted
[20:02:24] <les_w> I have actually programmed in anti vibration a couple of times
[20:02:32] <fenn> tool comp shouldnt be in the motion control anyway
[20:02:35] <les_w> it works, but is hard on ballscrews
[20:02:41] <fenn> to hell with those idiots that sharpen their tools
[20:02:49] <davidf> Here's the G code
[20:02:50] <alex_joni> fenn: it's not, it's in the interp.
[20:02:57] <davidf> G40
[20:02:57] <davidf> G41 D1
[20:02:57] <davidf> G00 Z0.7000
[20:02:57] <davidf> G00 X0.1250 Y0.0000
[20:02:57] <davidf> G01 Z-0.2600 F6.0
[20:02:58] <davidf> G02 X0.1250 Y0.0000 I-0.1250 J0.0000
[20:02:59] <fenn> the interp is part of "the motion control"
[20:03:00] <davidf> G00 Z0.7000
[20:03:02] <davidf> G00 X2.2957 Y0.0423
[20:03:04] <davidf> G01 Z-0.2600
[20:03:06] <davidf> G02 X2.3163 Y0.0717 I0.0312 J0.0000
[20:03:12] <davidf> G01 X2.3492 Y0.0837
[20:03:14] <davidf> G03 X2.3697 Y0.1145 I-0.0107 J0.0294
[20:03:16] <davidf> G03 X2.3585 Y0.2576 I-2.3697 J-0.1145
[20:03:18] <davidf> G03 X2.3334 Y0.2849 I-0.0311 J-0.0034
[20:03:20] <davidf> G01 X2.2990 Y0.2915
[20:03:22] <davidf> G02 X2.2741 Y0.3173 I0.0060 J0.0307
[20:03:24] <davidf> G01 X2.2609 Y0.4009
[20:03:26] <davidf> G02 X2.2766 Y0.4332 I0.0309 J0.0049
[20:03:28] <davidf> G01 X2.3072 Y0.4501
[20:03:30] <davidf> G03 X2.3226 Y0.4838 I-0.0152 J0.0273
[20:03:32] <davidf> G03 X2.2891 Y0.6234 I-2.3226 J-0.4838
[20:03:34] <davidf> G03 X2.2601 Y0.6464 I-0.0302 J-0.0082
[20:03:36] <davidf> G01 X2.2251 Y0.6476
[20:03:38] <les_w> I always do tool comp in the cam....just less chance of errors and crashes for me
[20:03:38] <davidf> G02 X2.1965 Y0.6692 I0.0011 J0.0312
[20:03:42] <davidf> G01 X2.1703 Y0.7497
[20:03:44] <davidf> G02 X2.1808 Y0.7840 I0.0297 J0.0097
[20:03:46] <davidf> G01 X2.2084 Y0.8055
[20:03:48] <davidf> G03 X2.2184 Y0.8412 I-0.0192 J0.0246
[20:03:49] <les_w> but it could be in the control I guess
[20:03:50] <davidf> G03 X2.1634 Y0.9738 I-2.2184 J-0.8412
[20:03:52] <davidf> G03 X2.1311 Y0.9920 I-0.0285 J-0.0128
[20:03:54] <davidf> G01 X2.0964 Y0.9877
[20:03:56] <davidf> G02 X2.0647 Y1.0045 I-0.0038 J0.0310
[20:04:03] <les_w> you just need to see the tool path before you run it
[20:04:10] <les_w> emc can di that
[20:04:20] <SWPadnos> a few dozen lines at
http://pastebin.com would have been better ;)
[20:04:37] <les_w> sorry I BROKE IN THERE
[20:04:42] <les_w> oops
[20:04:44] <SWPadnos> NO PROBLEM!
[20:04:49] <davidf> I have a file with the ofset drawn, ie, the tool path rather than the material path.
[20:05:31] <davidf> Oh, sorry. I didn't understand the pastbin thing (Thought it was a typo for paste in. oops.)
[20:05:37] <SWPadnos> are you trying to get a full circle in that girst G2 move?
[20:05:40] <SWPadnos> heh - np
[20:05:45] <SWPadnos> first, not girst
[20:05:50] <SWPadnos> see - I never make typos
[20:05:58] <fenn> ooo its a gear
[20:06:07] <fenn> or a timing pulley maybe
[20:06:10] <davidf> Yes. The first cut is a 1/4 inch circle for and axis hole.
[20:06:28] <davidf> The part is a 4.7475 inch timing pulley.
[20:06:30] <SWPadnos> with a 1/4# cutter, that results in no motion
[20:06:34] <SWPadnos> 1/4"
[20:06:48] <davidf> 1/8th inch diameter cutter.
[20:06:54] <SWPadnos> no - 1/2 radius, I think
[20:06:56] <SWPadnos> gah
[20:06:58] <SWPadnos> 1/8
[20:07:10] <SWPadnos> .125 is the radius in the tool file, isn't it?
[20:07:29] <davidf> The tool I specified in the tool table is .1250 inch diameter.
[20:07:36] <SWPadnos> ok. you had said radius before
[20:07:51] <davidf> The table askes for diameter, not radius, I believe.
[20:08:00] <davidf> Sorry.
[20:08:19] <davidf> radius is .0625 just to be clear.
[20:08:32] <SWPadnos> ok
[20:08:51] <davidf> I can't even put a .01 dia tool in the tool table without error.
[20:09:46] <davidf> can I post a dxf at pastebin.com?
[20:10:15] <SWPadnos> if it's text
[20:10:40] <davidf> Oh. I just thought it might help to see the part.
[20:11:20] <fenn> * fenn is trying to run axis and mini at the same time
[20:11:34] <fenn> and failing miserably i might add
[20:11:38] <davidf> But it's just a timing pulley with .375 inch pitch if you can picture that.
[20:11:48] <Jymmm> fenn run mini remotely =)
[20:11:51] <fenn> i can see the outline in axis' preview
[20:12:14] <SWPadnos> I can just go out and look at one if I need to ;) how many teeth?
[20:12:49] <davidf> It has 1/16th inch radii at the tooth-gap corners, inside and out.
[20:12:57] <davidf> 40 teeth.
[20:13:08] <davidf> 4.7475 inch diameter.
[20:13:38] <alex_joni> fenn: that should work!?
[20:13:44] <davidf> Or something like that. It's a standard size listed in Machinery's Handbook.
[20:15:25] <fenn> alex_joni: if i start axis first, tkemc/mini hogs all the cpu and never starts... if i start mini/tkemc first, axis throws this error: File "/usr/lib/python2.3/lib-tk/Tkinter.py", line 1130, in _configure self.tk.call(_flatten((self._w, cmd)) + self._options(cnf)) _tkinter.TclError: bad menu entry index "Show EMC Status"
[20:16:08] <jepler> fenn: that's weird. I have often started tkemc first and axis later, but maybe not lately
[20:16:57] <davidf> SWPadnos, When I drew the pattern, I used the fillet tool everywhere to put smooth arcs at the intersections of all the lines.
[20:18:06] <SWPadnos> those 1/16 arcs - if you made them slightly larger, it might work
[20:18:16] <SWPadnos> it could be a slight floating point error
[20:18:51] <davidf> IE, I drew one tooth and one gap with straight lines. Then filleted the corners to a 1/16 radius. Then I copied with rotate, all the way around the circle with 40 teeth. Everthing looks good even at hishest zoom.
[20:19:05] <fenn> no it gouges even with a .001" diameter tool
[20:19:23] <SWPadnos> ok. try .07 instead of 0.0625 for the fillet radius
[20:19:31] <SWPadnos> oh yeah - right ;)
[20:19:40] <davidf> That's what I thought too, bu I can't even use a tiny radius. So alex_joni 's idea re an angle sounds like it might be right.
[20:19:42] <fenn> oh wait G41 D1 doesnt that mean diameter 1?
[20:20:44] <SWPadnos> tool 1
[20:21:09] <davidf> Well, the manual says it means radius, even though it would seem logical that D meant Diameter. But again, thats why I tried a tiny number in the tool file. That should work either way.
[20:21:26] <davidf> It means tool 1. Yes.
[20:21:53] <davidf> And nothing but zero will work in tool one pocket.
[20:22:33] <davidf> Can't be a bug or everyone would have this problem.
[20:22:45] <alex_joni> * alex_joni is gone to bed
[20:22:47] <alex_joni> night all
[20:22:55] <SWPadnos> good night alex
[20:22:57] <Jymmm> nite
[20:23:21] <davidf> By the way, I did not explode the drawing first. It is all joined, lines and arcs. Could that be a problem?
[20:23:22] <SWPadnos> davidf, I suspect there's something simple going on, but since I've never used cutter comp, I can't tell what it is ;)
[20:23:31] <davidf> Good Night alex. Thanks.
[20:25:08] <davidf> Hmm.. Maybe it is a bug then. I can just draw the tool path. Thats not a big deal. It would just be nice to use radius comp so I can try different bits, and also use it to size up or down to tweak the tooth dimensions.
[20:25:45] <cradek> maybe you should ask for help on the emc-users list
[20:25:55] <cradek> (if there's a bug we'll fix it)
[20:26:15] <davidf> OK. I would think it would have shown up by now, no?
[20:26:20] <SWPadnos> you know - I think I remember someone adding a parameter for radius comp tolerance or sometihng similar. does that ring a bell with anyone?
[20:26:44] <cradek> all I can think of is the r-format arc endpoint tolerance
[20:26:56] <SWPadnos> that could have been it
[20:27:02] <cradek> it's possible lerman put in something for radius comp
[20:27:24] <davidf> Oh, yeah, that reminds me - I never quite understood the FERROR etc in the ini.
[20:27:59] <davidf> Oh you mean maybe that new code broke it? Or what?
[20:28:19] <SWPadnos> there are two options for ferror: first is constant ferror, the other is velocity-sensitive ferror
[20:28:22] <cradek> I don't know how many of his changes are in the modern emc2 - he put them in emc1 very late in the game
[20:29:01] <davidf> That's clear as mud to me... :)
[20:29:14] <SWPadnos> if you specify only FERROR, that's a constant tolerance, regardless of feedrate
[20:29:24] <davidf> ferror I mean.
[20:29:24] <cradek> sorry
[20:29:39] <davidf> Oh, Feedrate error.
[20:29:43] <davidf> Yes?
[20:29:56] <SWPadnos> no - following error
[20:30:29] <davidf> Oh. Oh yeah that's only for servos or steppers with feedback right?
[20:30:45] <SWPadnos> yes, for the most part
[20:31:15] <davidf> I remember now. So I didn't change the defaults.
[20:33:17] <davidf> Well, I don't want to be a big pita. I'll check the emc user's list or just program tool paths. It works fine with no cutter compensation.
[20:33:44] <cradek> if you can narrow down your program to the simplest possible that shows the error, and post it to the list, I bet someone will help
[20:34:05] <cradek> I think a lot of users don't use cutter comp, we need to find one who has used it a lot
[20:34:37] <skunkworks> yah - never was able to use cutter comp before - (old machine) we always offset the actual cad program
[20:34:55] <cradek> that's what I do too since I don't sharpen tools
[20:35:17] <SWPadnos> it's also useful for roughing / finish passes
[20:35:21] <skunkworks> it would come in handy though now - for long running parts.
[20:35:36] <cradek> yes I'm sure not saying it's not useful
[20:35:49] <SWPadnos> set the diameter to 0.0001 over the actual tool for roughing, then to the actual tool diameter for the finish pass
[20:35:54] <skunkworks> I am talking for my self :)
[20:37:15] <davidf> Yeah, and I'm planning on making some very large (10 inch dia) timing pulleys, so I may want to tweak the radius to fake changing the part size slightly.
[20:38:28] <davidf> Anyway, I'll be glad to try and narrow down the problem as above. That's at least something I could maybe give back that might be of help.
[20:39:12] <davidf> Probably I'll just succeed in figureing out what bonehead mistake I made though.
[20:39:53] <cradek> something something "entry move" something something I'm sure
[20:40:00] <SWPadnos> even that could be helpful, if you create/edit some wiki pages on the subject
[20:40:42] <davidf> I'll try just two lines connected by an arc & experiment to see if I can make it not work, & why.
[20:41:10] <davidf> I don't understand the something something entry move etc. thing cradek .
[20:41:13] <cradek> is that the beginning of the program that you posted?
[20:41:18] <davidf> Yes.
[20:41:31] <davidf> It's 318 lines long.
[20:41:35] <cradek> I think you have to have a move before turning comp on - you could be anywhere otherwise
[20:42:07] <SWPadnos> one other thing - just for the heck of it, put in a G20
[20:42:10] <cradek> then the first move after turning comp on is the "entry"
[20:42:16] <cradek> yes always put a g20 or g21
[20:42:42] <davidf> Oh, and it doesn't have % at beginning and end. But It ran ok with no comp so I figured that was ok.
[20:42:46] <SWPadnos> I think it may be the cirst move that causes X or Y motion - do Z only moves count?
[20:42:55] <SWPadnos> first, not cirst
[20:43:01] <davidf> I'll do the above.
[20:43:42] <cradek> doubt it, no radius compensation in Z
[20:43:43] <davidf> That seems like a good idea. & I'll look up the G20 / 21 thing too & add it.
[20:43:57] <cradek> I think you have to be very careful about your entry move
[20:44:05] <cradek> did you go over that section in the manual? I can find it for you
[20:44:30] <SWPadnos> yep - according to some manual I read on it, you have to be sure that the entry move is tangent to the first "real" compensated move
[20:45:43] <davidf> Ah! That reallky sounds like that's it. I started at 0,0 with the first move perpendicular to the side of a circle.
[20:45:46] <cradek> http://www.isd.mel.nist.gov/personnel/kramer/pubs/RS274NGC_3.web/RS274NGC_38a.html#999476
[20:45:49] <SWPadnos> in the manual that alex linked to, start ar page 139 or so
[20:46:30] <davidf> OK! Thanks loads. Think you guys got it figured out.
[20:47:00] <cradek> yeah, but now you have to do the hard part!
[20:47:10] <SWPadnos> G17 can also help, according to the manual
[20:47:16] <SWPadnos> what fixed it?
[20:47:29] <SWPadnos> oops - had a "reado"
[20:47:30] <davidf> Think I'll add a line to the drawing tangent to the starting point for bout the inner axis hole & the first tooth top. Sound right?
[20:47:30] <SWPadnos> ;)
[20:48:05] <davidf> A reado. Thats cute. :)
[20:48:19] <CIA-8> 03jepler 07HEAD * 10emc2/src/hal/components/blocks.c:
[20:48:19] <CIA-8> add new "hypot" component. Use it to calculate the tangential velocity in the
[20:48:19] <CIA-8> simulator configurations (signal "XYZvel")
[20:48:19] <CIA-8> 03jepler 07HEAD * 10emc2/configs/common/core_sim.hal:
[20:48:19] <CIA-8> add new "hypot" component. Use it to calculate the tangential velocity in the
[20:48:20] <CIA-8> simulator configurations (signal "XYZvel")
[20:48:38] <SWPadnos> I thikn you need to do that for each compensated path
[20:48:55] <SWPadnos> so if you cut the center hole, then the tooth profile, that's two paths
[20:49:00] <SWPadnos> though I could be wrong about that
[20:49:01] <cradek> right
[20:49:33] <davidf> Right. I can see why. Otherwise it makes it's own hard corner coming in. With zero radius.
[20:49:59] <davidf> Makes perfect sense.
[20:50:41] <davidf> Thanks a lot. I'll go play some more now.
[20:50:49] <SWPadnos> enjoy
[20:51:16] <davidf> See ya. I'll let you know how it goes. 'Bye.
[20:51:31] <SWPadnos> bye
[20:52:02] <cradek> blind leading the blind?
[20:52:26] <SWPadnos> hopefully blind leading the blinder ;)
[20:59:08] <skunkworks> jepler: does that help the les_test
[21:16:24] <A-L-P-H-A> <yawn>
[22:01:48] <K4ts> helo
[22:01:52] <K4ts> hello
[22:06:00] <robin_sz> meep?
[22:06:08] <robin_sz> ca va?
[22:06:25] <robin_sz> * robin_sz is back in the UK
[22:12:22] <A-L-P-H-A> as opposed to where?
[22:12:25] <A-L-P-H-A> the USA?
[22:17:42] <robin_sz> Switzerland
[22:18:16] <robin_sz> I sent someone elese to the USA, I couldnt be bothhered to go
[22:19:03] <robin_sz> unfiortyuenaltey he had a bit of an accident while he was there, so I had to do a week in Geneva to cover for him
[22:23:31] <A-L-P-H-A> 'accident'? He was arrested for prostitution? He was hold on 'terrorism charges'?
[22:30:21] <K4ts> night
[22:44:19] <giacus> http://www.med.harvard.edu/AANLIB/cases/caseNA/pb9.htm
[22:44:34] <giacus> open source brain
[22:52:38] <A-L-P-H-A> I read "transaxial" as "transexual"
[22:52:50] <giacus> :D
[22:55:29] <A-L-P-H-A> grab dinner, and then testing the mill out
[22:55:30] <A-L-P-H-A> :)
[22:55:38] <A-L-P-H-A> hopefully nothing blows up.
[22:57:02] <jepler> skunkworks: the "hypot" change is just for visualizing the machine speed in halscope, nothing to improve performance.
[22:57:51] <jepler> skunkworks: now you can get a display of sqrt(dx*dx + dy*dy + dz*dz), e.g., the speed of the machine, not just the speed of one axis
[22:58:19] <giacus> night
[22:58:25] <jepler> night giacus
[23:05:41] <skunkworks> jepler: nice. thanks
[23:21:02] <skunkworks> logger_aj: bookmark
[23:21:02] <skunkworks> See
http://81.196.65.201/irc/irc.freenode.net:6667/emc/2006-06-12#T23-21-02
[23:32:32] <A-L-P-H-A> hypotnus in 3d. :)
[23:32:37] <A-L-P-H-A> yummy dinner...
[23:44:19] <A-L-P-H-A> Try this
http://www.ochenk.com/entry.php?id=63 I can hear with headphones 21000Hz.
[23:44:19] <A-L-P-H-A> 14000 on my speakers...
[23:44:44] <A-L-P-H-A> I don't think the response range is good that good on my headphones though.
[23:56:23] <A-L-P-H-A> who's around, and wants to play a simple game?
http://www.scorched3d.co.uk/downloads.php
