Back
[02:39:02] <cradek> we should talk about 2.1 when we're all around
[02:39:27] <cradek> and 2.0.5 for that matter
[02:39:36] <cradek> alex was talking about another fix but I can't remember what it was
[02:42:31] <cradek> and maybe we should look into porting forward some of rumley's changes like ray suggests
[02:42:46] <cradek> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc/generic.ini?rev=1.19;only_with_tag=rumley_changes
[02:42:50] <cradek> I mean in 2.1
[02:43:07] <jepler> which changes are these?
[02:43:13] <cradek> ^^
[02:43:45] <cradek> specifically the G92/M2 interaction stuff
[02:45:04] <jepler> I would have to be convinced of most of those changes
[02:45:14] <jepler> they will lead to programs that run on one system but not another, or have a different meaning
[02:45:47] <cradek> right now I mean just the G92/M2 stuff
[02:46:16] <cradek> ; Keep G92 axis offsets in effect after Work Coordinate System change
[02:46:19] <cradek> ok NOT this one
[02:46:36] <cradek> ok I see we'd all have to talk about it.
[02:47:00] <cradek> g54 turns off g92? that's news to me
[02:47:36] <jepler> does the stuff in that file reflect the old behavior?
[02:47:45] <cradek> I *think* so
[02:47:50] <jepler> I'll UTSL
[02:47:58] <cradek> good luck finding it
[02:48:11] <cradek> in 5 mins or so I couldn't find what happens at abort
[02:48:44] <cradek> and that was the entirety of my attention span...
[02:49:09] <jepler> yeah I think I'm in the same boat
[02:49:30] <cradek> nah, that was barely one minute
[02:49:32] <cradek> four to go
[02:49:46] <jepler> but yeah it looks like G54 turns off G92
[02:50:01] <cradek> wow that's wild
[02:50:12] <cradek> did you find that in the spec, the source, or the mdi?
[02:50:21] <jepler> the source
[02:50:31] <jepler> the spec doesn't seem to say how they interact
[02:50:53] <jepler> but in the source they both set some interp-wide state, and only G92 takes into account the G5x coordinate system, not the other way around
[02:51:29] <jepler> I'm content to let the G92-users argue over it
[02:51:32] <jepler> but you know I hate options
[02:51:35] <jmkasunich> goodnight guys... I was up way too late last night
[02:51:48] <cradek> goodnight
[02:51:51] <jepler> see you jmk
[02:52:13] <cradek> jepler: I guess I'd rather just decide too. I was hoping to start that process on the list (while I was away) but it didn't really work
[02:52:14] <jmkasunich> heh, me going to be before jeff - thats a first
[02:52:27] <cradek> yeah first I recall too
[02:52:46] <cradek> but jeff is only ~ 6 mins behind you
[02:52:57] <jepler> sometimes I stay up past ten!
[02:53:06] <jepler> and at next year's fest I'll make an exception several days in a row!
[02:53:10] <cradek> but jeff is only ~ 6-10 mins behind you
[02:53:43] <jepler> 'night guys
[02:53:44] <cradek> I bet I could lose an entire day over fest
[02:54:02] <cradek> night jeff
[14:20:09] <cradek_> about ben's email: I wonder if there's anything good we can do with steppers + encoders.
[14:20:15] <cradek_> cradek_ is now known as cradek
[14:21:12] <cradek> the two benefits I like on my servo lathe are: stopping when there's a following error, and being able to turn off the drives and jog around with the handwheels
[14:21:47] <cradek> I can't decide if one could set up a stepper config that would have those two features
[14:22:03] <jepler> seems like you would get those if you use the encoder feedback value + stepgen, still without any pid
[14:22:57] <SWPadnos> no - stepgen maintains its position "feedback" internally
[14:23:11] <SWPadnos> err - unless you're talking about changing that ;)
[14:23:48] <cradek> so the problem is once you jog, stepgen will not know the position anymore?
[14:24:03] <SWPadnos> that's one problem
[14:24:06] <cradek> but doesn't emc follow it (command the feedback position) when in machine-off?
[14:24:54] <jepler> no, I think swp is right. stepgen still has an internal position
[14:24:55] <SWPadnos> stepgen takes in a position, and outputs steps to go to that position. as far as I know, there's no way to tell stepgen that it's actually somewhere other than where it thinks it is, from its internal step counter
[14:26:35] <jepler> so you'd need stepgen.N.reset, which copies position-cmd to positionf-b
[14:27:21] <SWPadnos> or an input that gives stepgen an error, so it can try to correct
[14:27:30] <SWPadnos> but then you're in semi-PID-land
[14:28:26] <SWPadnos> you can do the "stop on following error" without any changes though - just connect encoder.position to the motion feedback position instead of stepgen feedback
[14:28:45] <alex_joni> SWPadnos: I think stepgen updates it's internal position to match the command while switched off
[14:28:47] <cradek> yeah that's a very nice feature
[14:28:57] <alex_joni> right
[14:29:40] <SWPadnos> ok - I thought that change was to have motion update its commanded position to the feedback inputs when "off"
[14:29:50] <alex_joni> that too
[14:29:54] <SWPadnos> unless stepgen was also twiddled with
[14:29:57] <jepler> I don't see stepgen changing -fb when it's not enabled
[14:30:08] <alex_joni> it's not changing -fb
[14:30:49] <SWPadnos> ah - you're saying that it just says internal_pos = commanded_pos when off
[14:31:06] <SWPadnos> but that should also update the -fb pin
[14:31:55] <alex_joni> /* test for disabled stepgen */
[14:31:55] <alex_joni> if (*stepgen->enable == 0) {
[14:31:55] <alex_joni> /* disabled: keep updating old_pos_cmd */
[14:31:55] <alex_joni> stepgen->old_pos_cmd = *stepgen->pos_cmd * stepgen->pos_scale;
[14:31:59] <alex_joni> seems I was wrong
[14:32:47] <SWPadnos> ok. that keeps it from taking off at high speed when re-enabled
[14:33:10] <SWPadnos> (pos_cmd - old_pos_cmd) will be 0 when re-enabled
[14:33:50] <alex_joni> right
[14:34:31] <cradek> so it might just work as-is?
[14:34:40] <jepler> no, not moving the handwheels
[14:35:03] <SWPadnos> actually, that might "just work"
[14:35:15] <SWPadnos> since motion changed cmd-pos to = feedback-pos
[14:35:20] <SWPadnos> changes
[14:35:47] <SWPadnos> when stopped, if you have an encoder connected as feedback, motion will see that as the actual position and update its commanded position to match
[14:35:58] <SWPadnos> stepgen will track that as well
[14:36:03] <alex_joni> SWPadnos: you still need to somehow connect both the encoder and the stepgen-fb to motion
[14:36:12] <cradek> why do you care about stepgen-fb?
[14:36:15] <alex_joni> here's a wild idea.. how about not connection the stepgen-fb
[14:36:16] <SWPadnos> why does stepgen-fb need to be connected?
[14:36:19] <SWPadnos> heh
[14:36:22] <alex_joni> right :)
[14:36:30] <alex_joni> ok, then it works as it is
[14:36:49] <SWPadnos> the only reason for it would be to account for requested step rates in excess of what BASE_PERIOD will allow
[14:37:35] <SWPadnos> hmmm. here's a wild idea
[14:37:40] <SWPadnos> nope - it won't work
[14:37:42] <SWPadnos> admn
[14:37:46] <SWPadnos> damn
[14:38:36] <cradek> the stepgen-fb is nice, but you'll get FE aborts in those same situations still, because the motors themselves are still limited by the stepgen constraints
[14:39:08] <cradek> so I don't think you actually lose anything
[14:39:44] <jepler> you start emc. command a move to 1". Hit MACHINE OFF. Turn the handwheel to 2". Hit MACHINE ON
[14:39:53] <jepler> I think the machine will move to 3"
[14:40:08] <jepler> because emc will begin commanding 2" but the current stepgen thinks it's at 1"
[14:40:23] <jepler> so stepgen will command 1 inch worth of movement
[14:40:31] <jepler> in a nice s-curve form
[14:40:33] <cradek> even if you hook stepgen->enable to machine on?
[14:40:53] <cradek> (I think that's the hookup now)
[14:41:15] <alex_joni> right, machine off disables the step gens
[14:42:02] <alex_joni> jepler: why do you think stepgen will keep thinking it's at 1" ?
[14:43:55] <jepler> because that's what its -fb says
[14:44:41] <SWPadnos> does stepgen update -fb when disabled?
[14:44:44] <SWPadnos> I bet it doesn't
[14:44:44] <alex_joni> hmm.. maybe it should track cmd while disabled
[14:45:00] <alex_joni> SWPadnos: the -fb is updated only by multiplying pulses with scale
[14:45:11] <alex_joni> if there are no pulses.. no update
[14:45:24] <alex_joni> another idea : on machine off, not disable stepgen
[14:45:30] <SWPadnos> ok. it should update old_pos from that (or from cmd-pos while off), and update -fb from old_pos
[14:45:52] <alex_joni> just disable the stepper drivers
[14:46:21] <alex_joni> this will have as an sideeffect that one can't turn the handwheels faster than max_vel or it will ferror
[14:46:41] <SWPadnos> and you must remain within accel limits ;)
[14:47:22] <alex_joni> but somehow I feel this might cause some oscilation at some point
[14:47:36] <alex_joni> if stepgen cmd pos and the emc are off
[14:47:59] <alex_joni> maybe/probably/surely I'm wrong :)
[14:48:07] <cradek> http://pastebin.ca/222746
[14:48:14] <cradek> anyone mind that I send this response?
[14:48:16] <SWPadnos> for this to work, stepgen has to allow for external changes to its internal position
[14:48:37] <cradek> I'd like to guide the discussion with these concrete goals
[14:48:49] <SWPadnos> looks good to me
[14:48:55] <jepler> me too
[14:49:12] <alex_joni> same here
[14:49:13] <cradek> sent then
[14:50:16] <alex_joni> maybe you should have mentioned emc2 instead of emc
[14:50:37] <SWPadnos> now he tells us ;)
[14:51:19] <alex_joni> he'll come back when EMC won't do this
[14:52:05] <alex_joni> jepler: had a chance to look at optional stop?
[14:52:18] <jepler> alex_joni: no it hasn't crossed my mind again
[14:52:25] <jepler> spindle speed slider is next
[14:53:14] <alex_joni> ok.. let me know if there are bogons around :)
[14:54:33] <cradek> I think if you accomplish goal #2 you also can add "without losing position" to goal #1
[14:55:30] <SWPadnos> and by using PID in some strange ways, you may be able to do adaptive feed override when a stepper starts to lose position
[14:55:44] <SWPadnos> freqgen instead of stepgen though
[14:55:46] <cradek> yes but you'll notice I didn't mention anything like that
[14:55:51] <SWPadnos> yep
[14:56:01] <cradek> that's how emc 1 worked, and it wasn't very good.
[14:56:34] <jepler> PID + steppers, you mean?
[14:56:38] <cradek> yes
[14:56:54] <SWPadnos> but that was used in "normal
[14:57:03] <SWPadnos> but that was used in "normal" PID mode
[14:57:14] <SWPadnos> ie, ask for more when things fall behind
[14:57:44] <SWPadnos> that doesn't work with steppers. you need to reduce commanded speed when a stepper lags behind, not increase the "drive" to it
[14:58:08] <alex_joni> SWPadnos: adaptive-feed-override ;)
[14:58:15] <jepler> but I don't think your feedback will show you anything short of a stall
[14:58:16] <cradek> how much can a stepper lag without just stalling? It's not clear to me that you can detect this easily
[14:58:22] <cradek> yeah that
[14:58:24] <alex_joni> one pulse
[14:58:25] <SWPadnos> yep - that's what I said
[14:58:35] <SWPadnos> that's true - so it's possible it won't work
[14:58:38] <jepler> and you basically have to stop and start again in that case
[14:58:46] <jepler> ugh, I wouldn't want to have this
[14:58:54] <alex_joni> if you have a high-res encoder you "might" detect it
[14:59:00] <alex_joni> but that would be a nightmare to tune
[14:59:16] <SWPadnos> I think you can reduce the step rate and have the stepper "come back" - I'm not sure you need to stop it completely
[14:59:20] <cradek> I think abort-and-fix-your-configuration-or-gcode is best, and straightforward
[14:59:31] <alex_joni> cradek: right :)
[14:59:50] <SWPadnos> yeah, or have a motor driver that tells you when the motor is getting close to stalling, but that's beyond EMC2's control ;)
[15:00:51] <alex_joni> I'd like to see such technology for steppers
[15:01:03] <SWPadnos> Mariss is working on it (still)
[15:01:03] <alex_joni> if you have _that_ money.. why not go AC
[15:01:07] <alex_joni> and be done with it
[15:01:25] <alex_joni> what? the unstallable drive?
[15:01:28] <SWPadnos> yep
[15:01:35] <alex_joni> heh.. some day
[15:01:38] <SWPadnos> yep
[15:01:49] <alex_joni> it will still ferror at some point
[15:01:56] <alex_joni> not sure how the link back works there
[15:02:04] <alex_joni> back to the pc doing the pulses
[15:02:23] <SWPadnos> actually, I think you need hardware like the G-Rex for that
[15:02:33] <SWPadnos> the white heat processor in the FPGA is what does that work
[15:02:41] <alex_joni> heat?
[15:02:42] <alex_joni> :D
[15:02:54] <alex_joni> only in spring
[15:02:58] <SWPadnos> I don't know why they called it that :)
[15:03:15] <alex_joni> better than turtle
[15:03:30] <SWPadnos> I think a Turtle processor would have been better
[15:03:38] <SWPadnos> and more in keeping with the reptile names ;)
[15:03:39] <alex_joni> not necessarely faster
[15:03:44] <alex_joni> but better
[15:03:53] <SWPadnos> "slow but sure wins the race"
[15:03:55] <alex_joni> although I vaguely recall that the turtle _did_ win the race
[15:03:59] <alex_joni> right :D
[15:04:00] <SWPadnos> heh
[15:04:16] <alex_joni> * alex_joni goes back to his mindless job :(
[15:06:55] <alex_joni> jepler: do you have some nice CNC pictures?
[15:06:57] <SWPadnos> hmmm - I wonder if I should try an edgy install
[15:07:09] <alex_joni> SWPadnos: is it released yet?
[15:07:12] <alex_joni> or still the beta?
[15:07:13] <SWPadnos> today, yes
[15:07:26] <SWPadnos> https://wiki.ubuntu.com/EdgyAnnouncement?highlight=(edgy)
[15:08:31] <alex_joni> "Proactive security features, preventing many common security vulnerabilities even before they are discovered" ????
[15:08:37] <SWPadnos> heh
[15:08:42] <alex_joni> how does THAT work?
[15:08:48] <SWPadnos> we don't know what it is, bit it isn't allowed
[15:09:08] <SWPadnos> things like buffer overflow protection, stack checkin, that sort of thing
[15:09:11] <SWPadnos> checking
[15:09:41] <skunkworks> alex_joni: did you see I have foxpro 2.6 for dos?
[15:09:52] <skunkworks> Too new? ;)
[15:10:16] <alex_joni> skunkworks: asking now :)
[15:10:47] <alex_joni> skunkworks: is it big?
[15:10:53] <alex_joni> * alex_joni laughs
[15:11:01] <SWPadnos> 6 floppies ;)
[15:11:12] <skunkworks> 8
[15:11:15] <SWPadnos> that could be 2M or even 9M you know
[15:11:18] <alex_joni> oh.. really :)
[15:11:24] <SWPadnos> oh, it could be as much as 10M then ;)
[15:11:36] <SWPadnos> oh noes - almost a minute to download
[15:11:36] <alex_joni> 11,52
[15:11:57] <alex_joni> skunkworks: thanks for looking
[15:12:41] <skunkworks> np
[15:21:01] <alex_joni> dapper was a good choice for emc2
[15:21:07] <alex_joni> There are now two versions of Ubuntu, choose which is best for you:
[15:21:07] <alex_joni> Ubuntu 6.10, the newest Ubuntu release: If you would like to benefit from the latest Ubuntu features, this is the release for you
[15:21:10] <alex_joni> Ubuntu 6.06 LTS, Ubuntu with long-term support: Choose this to benefit from the long support life-cycle of the 6.06 LTS release. This version is supported for 3 years on the desktop and 5 years on servers.
[15:26:42] <SWPadnos> I wonder if an EMC2 install could qualify as a "machine server" ;)
[16:33:14] <cradek> jepler: what became of 'home all' in axis? I thought you had it going but I don't see it.
[16:34:35] <jepler> cradek: I think it's hidden on a key-combination like ctrl-home
[16:35:27] <cradek> but I even looked in the key help...
[16:35:39] <jepler> looks like you'll be fixing that any second now
[18:05:29] <jepler> should I be able to add tasks on the sourceforge page?
[18:06:10] <alex_joni> * alex_joni looks
[18:07:23] <alex_joni> yes
[18:07:37] <alex_joni> Task Manager: Admin & Tech
[18:07:41] <jepler> oh -- duh
[18:07:44] <jepler> I'm not logged in
[18:08:57] <alex_joni> might be a reason
[18:10:52] <jepler> to what extent are these two tasks addressed by the recent improvements?
https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=129025&group_id=6744&group_project_id=46285 https://sourceforge.net/pm/task.php?func=detailtask&project_task_id=129024&group_id=6744&group_project_id=46285
[18:11:27] <alex_joni> I closed 129025
[18:11:50] <alex_joni> 129024 (accel/vel limits) has been improved, but not 100% fixed
[18:12:32] <alex_joni> a backlash move now obeys vel/accel limits, but if there's another move planned by TP in the meantime it can go up to 2*max_accel and 2*Max_vel (worst case)
[18:14:21] <jepler> can you add that note to the task?
[18:14:46] <cradek> as far as I know, the new backlash code is totally untested, except by the submitter whose name I unfortunately forget
[18:15:03] <alex_joni> jepler: I am just doing that
[18:15:26] <alex_joni> cradek: would it be insane to stop the movement while the backlash happens?
[18:16:22] <jepler> if we're not going to do '928 and '929 for 2.1, maybe we should change the dates
[18:16:37] <cradek> I'm not sure what it would mean to stop the movement
[18:17:01] <alex_joni> emc2.1.0 is not dependent on the CL tasks
[18:17:23] <alex_joni> so I have no issues about changing the dates
[18:17:35] <cradek> any particular "stop" can be a violation of an accel constraint already
[18:18:07] <alex_joni> I meant FO=0
[18:18:10] <cradek> so assuming your backlash ramp starts at zero, you're in violation bigtime if you stop normal motion and start backlash motion
[18:18:14] <alex_joni> but that probably takes a while too
[18:18:52] <cradek> using something like FO to do it won't necessarily apply it at the right place
[18:19:02] <alex_joni> or time
[18:22:06] <SWPadnos> I think that backlash compensation with a machine configured at the true limits of the motor may be impossible
[18:22:16] <cradek> I was just typing that
[18:22:19] <SWPadnos> heh
[18:22:33] <cradek> the simplest fix is to have separate constraints for normal motion and backlash "motion"
[18:22:45] <cradek> the sum of the worst cases should be doable by your machine
[18:22:51] <SWPadnos> yes. a machine with backlash should have some headroom that can be used to compensate for it
[18:23:07] <SWPadnos> it's a machine configuration error if you don't allow for that
[18:23:30] <cradek> it's beneficial that the comp motion doesn't usually move any mass, I bet you can do it surprisingly fast
[18:23:46] <SWPadnos> it depends on the machine, but that's probably true
[18:23:51] <cradek> I guess that's not always going to be true
[18:24:17] <SWPadnos> at low speeds, the motor inertia should have low total energy
[18:24:35] <SWPadnos> and you're not moving the cutter or table
[18:25:11] <jepler> and it's at a reversal so as long as it's not a large amount the velocity contribution will not be large
[18:25:49] <SWPadnos> however, backlash is a machining problem as well. consider doing climb milling - the cutter will be pulling against the backlash, so you really don't need any compensation when reversing
[18:25:51] <alex_joni> guess we'll see if anyone complains :)
[18:25:59] <SWPadnos> rather than the motor pushing against the backlash
[18:26:10] <SWPadnos> (that may make no sense)
[18:27:57] <alex_joni> jepler: might have missed it earlier.. do you have some nice CNC shots?
[18:28:06] <alex_joni> maybe of the mazak or some machining?
[18:30:22] <jepler> alex_joni: I lost the memory card that I used at fest, I don't have any photos from there.
[18:30:38] <alex_joni> maybe from the nist lathe then ?
[18:30:39] <alex_joni> :)
[18:30:59] <jepler> not really, sorry
[18:31:11] <alex_joni> * alex_joni doesn't need them this instant
[18:31:31] <alex_joni> <hint hint>
[18:32:29] <jepler> what are you looking for?
[18:34:28] <alex_joni> I want to design a book cover
[18:34:35] <alex_joni> not quite sure though
[18:35:04] <alex_joni> I'm thinking of an AXIS screenshot, and maybe a machine with the same part machined
[18:35:24] <jepler> I see
[18:35:31] <jepler> mill would be better than lathe, I bet
[18:35:37] <jepler> there's not much to look at in a lathe preview
[18:36:30] <alex_joni> unless there's a stock there :)
[18:37:03] <alex_joni> something eye-catching would be a PCB, but that might be too particular
[18:42:30] <skunkworks> alex_joni: there are a few here
[18:42:44] <skunkworks> http://www.electronicsam.com/images/KandT/cncworkshop/
[18:43:51] <skunkworks> nothing spectacler
[18:44:13] <skunkworks> spectacler? ;)
[18:46:57] <alex_joni> yeah, this one will do:
http://www.electronicsam.com/images/KandT/cncworkshop/cradek.JPG
[18:47:29] <skunkworks> cradek front and center ;)
[18:49:22] <alex_joni> skunkworks: thanks.. I'll look tomorrow (feeling a bit inspirationless at the moment)
[19:13:49] <Lerneaen_Hydra> 'night
[19:14:11] <alex_joni> night
[19:15:39] <Lerneaen_Hydra> oops wrong channel
[19:34:57] <alex_joni> good night all
[19:43:16] <anonimasu> night
[20:37:25] <SWPadnos> that last user list message was kind of odd
[20:38:01] <SWPadnos> there could be a step|freqgen that uses two phases for all steps - one for all forward axes and one for all reverse axes
[20:38:21] <SWPadnos> it would only decrease the max vel by a factor of 2, regardless of the number of axes involved
[20:38:28] <SWPadnos> it's still dumb though
[20:38:48] <jepler> say what?
[20:39:25] <SWPadnos> the "can I share the dir pin between axes" thing
[20:39:36] <jepler> I don't understand your solution, though
[20:39:46] <jepler> oh, maybe I do
[20:39:50] <jepler> I misunderstood "phase"
[20:40:02] <SWPadnos> sorry about that ;)
[20:40:24] <SWPadnos> I do a lot of AVR programming where I need to split interrupt work, and I settled on the term "phase" a long time ago
[20:41:53] <jepler> I still worry that the chip translating the signals to winding activations will have setup or hold time requirements
[20:42:09] <jepler> since you'll be changing dir back and forth all the time, you have to wait the setup and hold times
[20:42:47] <jepler> my other bad idea was this: For each axis there are 3 possible states: step +, step -, do nothing
[20:43:18] <SWPadnos> yeah - setup / hold times do throw a wrench in there
[20:43:20] <jepler> so you need 3 * 3 * 3 = 27 < 2^5 states to express step+direction for 3 axes
[20:44:10] <jepler> (if you're moving forward, then you issue +0+0+0+0, which translates to a steady 'direction' and a toggling 'step' output out of the hypothetical external translator)
