Back
[00:31:20] <jmkasunich> hi guys
[01:44:47] <cradek> hi
[01:45:55] <cradek> You have just received a virtual postcard from a friend ! You can pick up your postcard at the following web address:
http://www.emin3m09.uv.ro/postcard.gif.exe
[01:49:38] <jmkasunich> heh
[01:50:11] <cradek> well I do have a friend in romania - maybe it's from him
[01:51:13] <jmkasunich> src/hal/utils is starting to get crowded
[01:51:21] <jmkasunich> I'm about to add 6 files to it
[01:51:51] <jmkasunich> it already has all the halscope source, halcmd (multiple files now), halmeter
[01:51:57] <jmkasunich> I guess thats not too bad tho
[01:53:55] <cradek> can you look at control.c:402 please
[01:54:22] <jmkasunich> ah, do I have to? <whine>
[01:54:32] <cradek> I don't think it's reachable, but I wonder if you recall the intent
[01:54:37] <cradek> no :-)
[01:55:16] <cradek> seriously, it's not important if you're busy
[01:55:25] <jmkasunich> you mean the stopping the free mode planner stuff?
[01:55:32] <cradek> yes
[01:55:43] <jmkasunich> I don't think you can probe in free mode
[01:55:46] <cradek> I don't think you could have emcmotStatus->probing
[01:55:49] <cradek> right exactly
[01:56:01] <jmkasunich> but all that state stuff is so borked that I don't trust it
[01:56:13] <jmkasunich> what if you request a coord->free mode change in the middle of a probe move?
[01:56:22] <cradek> ok so it's CYA
[01:56:36] <cradek> I thought it was maybe supposed to abort if the probe is hit while not probing
[01:57:03] <cradek> brb
[01:57:55] <jmkasunich> that code is weird
[01:58:50] <jmkasunich> I mean the entire probing part
[01:58:56] <jmkasunich> not just the freemode thing
[02:01:02] <jmkasunich> the code at 382 doesn't really do what the comment says
[02:01:36] <jmkasunich> 396 is what checks the actual probe input
[02:02:46] <jmkasunich> ping me when you get back
[02:55:58] <cradek> back
[02:56:47] <cradek> yeah I don't really understand that code, even though I changed it today
[02:57:12] <jmkasunich> looks like alex did most of it, which is why I was drawing a blank
[02:57:36] <jmkasunich> the only thing that really confuses me is the stuff at 382-384
[02:58:31] <jmkasunich> there is a three way if / else if / else if
[02:58:44] <cradek> 382-384 is what gets triggered when the probe touches
[02:58:50] <jmkasunich> all three contain Status->probing, so if you aren't probing, it all gets skipped
[02:58:52] <jmkasunich> nope
[02:59:07] <jmkasunich> 376 reads the hal pin and sticks it in probeval
[02:59:13] <jmkasunich> 382 ignores val
[02:59:26] <jmkasunich> 396 checks val, and sets tripped
[02:59:35] <jmkasunich> then on the NEXT pass, 382 triggers
[02:59:49] <jmkasunich> don't ask me why
[03:00:11] <cradek> oh is tpAbort getting called twice?
[03:00:33] <jmkasunich> looks like it
[03:00:36] <cradek> that top abort was a clear, which was a bug
[03:00:38] <jmkasunich> I'd have to put prints in there to be sure
[03:00:44] <cradek> but I didn't notice there were two
[03:01:09] <jmkasunich> I really don't understand the two stage process
[03:01:20] <cradek> this whole thing is not what ngc describes, maybe we should start over
[03:01:34] <jmkasunich> if it was to deal with some requirement of the TP (abort after it runs one or something) I wish he had commented it
[03:01:46] <cradek> ngc says the probe backs off when done
[03:02:08] <jmkasunich> if we = you, then sure, start over ;-)
[03:02:09] <cradek> if it did that, we could abort any time the probe is triggered when not probing - which would be a very good thing
[03:02:37] <jmkasunich> what if you have a probe that reports triggered when its not in use
[03:02:48] <jmkasunich> some probes open a circuit when tripped
[03:03:10] <cradek> the motion.probe-input goes high when the probe touches
[03:03:15] <jmkasunich> if you remove it from the chuck and set it aside (or its in a toolchanger slot), it won't be connected, and the probe might report tripped
[03:03:56] <cradek> well I dunno
[03:04:14] <jmkasunich> I think this is one of those "whatever you do someone won't like it" cases
[03:04:59] <jmkasunich> if you have a probe in the spindle, its logical to abort any time it trips - could save an expensive bit of hardware
[03:05:10] <jmkasunich> but once you remove the probe, you want to ignore that input
[03:05:18] <cradek> or set it false in hal
[03:05:29] <jmkasunich> that thought occurred to me
[03:05:39] <jmkasunich> not sure how though
[03:05:40] <cradek> I'm trying to think of a parallel
[03:06:07] <cradek> but I think the situation is unique
[03:07:55] <jmkasunich> the "abort anytime it trips" issue is a diversion tho, lets go back to "do we want to redo this, so it backs off when it hits like the spec says, and so we have the option of abort anytime it trips"
[03:08:52] <cradek> ok
[03:09:10] <jmkasunich> s/do we want to redo/do you want to redo/ ;-)
[03:09:10] <cradek> backing off the switch automatically seems nice
[03:09:26] <cradek> well at least I can test it currently
[03:09:34] <jmkasunich> how far would you back off?
[03:09:44] <cradek> the spec says "slightly" (seriously)
[03:09:56] <cradek> I think "until the probe input goes back off"
[03:09:59] <jmkasunich> a bit ambiguous
[03:10:23] <jmkasunich> your version isn't ambiguous, seems reasonble to me
[03:10:47] <jmkasunich> although...
[03:11:13] <jmkasunich> you might want to do probing as follows:
[03:11:34] <jmkasunich> move to start xy, move down till hit, move up to clear, move over to new xy, OR till hit
[03:11:50] <jmkasunich> if hit, must be sloping up, move up a little and try the horizontal move again
[03:12:19] <jmkasunich> in that case, the hit on the "move over" doesn't want to back off in the direction it came from, it wants to back off up
[03:12:54] <cradek> I think g38.2 as described in the spec is not useful for probing 3d surfaces
[03:13:19] <jmkasunich> you have the url for the spec handy?
[03:13:37] <cradek> go to the gcode quick ref on your apps/cnc menu and click g38.2
[03:14:12] <jmkasunich> reading
[03:15:17] <cradek> the overshoot thing is bogus, I suggest we ignore it
[03:15:30] <jmkasunich> agreed
[03:15:41] <jmkasunich> I don't see the logic behind the 0.254mm thing either
[03:16:05] <jmkasunich> arm probe, make move... who cares if the move is a zero length one
[03:16:12] <cradek> that may combine with the "back off slightly" to ensure that you don't end up farther from the work than you started
[03:16:26] <cradek> I dunno, it's weird
[03:16:59] <cradek> I think I may have taken out that "too close" check
[03:17:14] <cradek> however I think it SHOULD be an error if the probe is already tripped at the beginning of a probe move
[03:18:47] <jmkasunich> can we add more .X to the 38?
[03:18:54] <jmkasunich> 38.2 - move till touch
[03:19:04] <jmkasunich> 38.3 - move till touch, then back off
[03:19:15] <jmkasunich> etc
[03:19:19] <cradek> SMOP
[03:19:42] <jmkasunich> not a matter of the other numbers already mean something?
[03:20:04] <cradek> not to my knowledge
[03:20:15] <jmkasunich> ok
[03:20:25] <jmkasunich> when would backoff NOT be desired?
[03:20:43] <jmkasunich> I think it would be the "digitize a 3d surface" case
[03:21:19] <jmkasunich> move horizontally between one xy location and the next, if you hit during that move, backoff up, not horiz
[03:21:20] <cradek> yes possibly
[03:21:42] <cradek> reportError("G38.2 probe move finished without tripping probe\n");
[03:21:43] <jmkasunich> the horiz move in that case isn't even intended to collect data
[03:21:49] <cradek> this is going to be trouble too then
[03:22:12] <jmkasunich> yep
[03:22:23] <jmkasunich> a "surface hugging scan" will be non-trivial to do
[03:22:40] <jmkasunich> but could take many hours off of a probing run
[03:22:47] <cradek> yes it would be great
[03:22:56] <jmkasunich> so if we can provide the hooks that let a clever g-code programmer do it, we should
[03:23:05] <cradek> but it would be nice if the simple case (ngc) worked first
[03:23:45] <jmkasunich> yes
[03:23:45] <cradek> the maxnc software would do a surface hug scan, and write out gcode to reproduce it
[03:23:55] <cradek> it worked really well actually
[03:24:12] <jmkasunich> lets think about what primitives would be needed
[03:24:23] <cradek> we could probably do something like that, but it's nearly unrelated to this work
[03:24:27] <jmkasunich> 38.2 for the vertical moves that actually capture a point
[03:24:45] <jmkasunich> and if the 38.2 had an auto-backoff, that would make it easier
[03:24:57] <jmkasunich> then you need something else for the horizontal moves - one that:
[03:25:02] <jmkasunich> 1) doesn't error out
[03:25:11] <jmkasunich> 2) doesn't do anything after hitting, just stops
[03:25:37] <jmkasunich> and maybe a third one, that moves in a commanded direction until the probe comes clear
[03:26:35] <jmkasunich> then you'd do 38.2 down, while not (at new xy) { "move-till-clear" up, "move-while-clear" over to new xy } then 38.2 down again for the next point
[03:27:31] <cradek> yes I agree
[03:27:59] <jmkasunich> 38.2 is basically, "move till hit or target pos reached, error if target reached"
[03:28:30] <cradek> yes
[03:28:44] <jmkasunich> I think we need "move till clear or target pos reached, error if target pos reached"
[03:29:04] <jmkasunich> and "move till hit or target pos reached, no error"
[03:29:52] <jmkasunich> I would not have 38.2 do backoff, the "move till clear" command can be used to do that
[03:30:05] <jmkasunich> that way you can back off the way you came, or any other direction
[03:33:30] <cradek> http://pastebin.ca/466830
[03:34:23] <jmkasunich> is there any chance that the TP might alter cartes_pos_fb?
[03:34:33] <jmkasunich> (if so, snapshot it first, then abort)
[03:35:13] <cradek> fixed
[03:35:33] <jmkasunich> it seems to simple
[03:35:39] <jmkasunich> compared to what was there before
[03:35:50] <cradek> well, mind you, I didn't test it
[03:35:57] <jmkasunich> lol
[03:36:23] <cradek> and if I was smart I'd go to bed instead
[03:36:32] <jmkasunich> it seems right
[03:36:36] <cradek> ok
[03:36:46] <jmkasunich> as long as there is no way to switch to free mode in the middle of a probe move
[03:36:55] <jmkasunich> I think a switch to free mode aborts the TP anyway doesn't it?
[03:37:19] <cradek> I don't know
[03:37:52] <jmkasunich> I think so, but I'm in the middle of something else and don't want to go trapsing thru the code
[03:39:10] <jmkasunich> ah, I think the request to go into free mode is ignored if moving
[03:39:15] <jmkasunich> line 934
[03:39:24] <cradek> ok
[03:39:42] <jmkasunich> this stuff is butt ugly
[03:40:04] <jmkasunich> that test should be made in command.c, so that it can pass "sorry, can't do that" back to user space
[03:40:35] <jmkasunich> as it is, command.c will accept the command without complaint, and control.c will silently ignore it (or do it after movement stops)
[03:40:50] <jmkasunich> some commands silently ignore, some do later, I think
[03:42:31] <SWPadnos> command.c and control.c end up in the same executable, at the same end of an NML channel?
[03:42:41] <jmkasunich> they end up in kernel space
[03:42:43] <jmkasunich> in the same RT thread
[03:43:03] <SWPadnos> at the same end of an NML channel was the important part, I guess
[03:43:20] <SWPadnos> which I suspect is true if they're in kernel space :)
[03:43:22] <jmkasunich> command is a huge switch that processes a command from user space
[03:43:31] <jmkasunich> it sets flags and such that are acted on by control.c
[03:44:07] <jmkasunich> the actual user/kernel channel is not NML, its direct from task
[03:44:35] <SWPadnos> ok - that qualifies
[03:45:23] <SWPadnos> my concern was that for things at opposite ends of a command/status channel, the status could change between the last status update and the command getting sent, so the command would have to be sent
[03:45:27] <SWPadnos> but it's irrelevant here
[03:47:37] <cradek> well it seems to work
[03:50:43] <SWPadnos> that's relevant here :)
[03:51:45] <cradek> anyone want my config with simulated probe?
[03:52:43] <SWPadnos> maybe when (if?) I get that darned SMP RT (A64) kernel working
[03:52:48] <SWPadnos> or at least booting
[03:53:09] <cradek> bah, boot 2.6.15-magma and GBTW
[03:53:25] <SWPadnos> pthbthbthb
[03:53:51] <SWPadnos> getting that to work is - err - work
[03:54:30] <cradek> the smp kernel I buitl doesn't work?
[03:54:53] <cradek> or do you want x86_64 too?
[03:55:05] <SWPadnos> actually, your kernel didn't boot on that machine
[03:55:10] <cradek> hmm
[03:55:22] <SWPadnos> I'd like x86_64, but I wouldn't have bothered if the 386 kernel had worked
[03:55:41] <cradek> the usual 2.6.15-magma doesn't boot either?
[03:56:00] <cradek> I thought that (through some miracle/freak of nature) worked on everything under the sun
[03:56:00] <SWPadnos> I don't know. maybe I should try the liveCD
[03:56:36] <SWPadnos> I couldn't install the EMC stuff since the arch is wrong (and I didn't want to bother with --force-architecture on the kernel stuff ...)
[03:56:44] <cradek> or just run in userland sim - realtime sucks for development anyway
[03:56:52] <cradek> (says the guy typing on a ppc)
[03:56:56] <SWPadnos> heh
[03:57:31] <SWPadnos> I'd like to be able to compile hardware drivers, and also to test hardware, even if I couldn't run a machine (due to Nvidia problems)
[03:57:47] <cradek> fwiw:
http://timeguy.com/cradek-files/emc/sim-probe.tar.gz
[03:57:51] <jmkasunich> play with FPGAs too?
[03:57:54] <SWPadnos> it would be great to be able to do FPGA dev on that machine
[03:57:56] <SWPadnos> yes :)
[03:58:15] <SWPadnos> but since I can't load a mesa card driver without RT ...
[03:59:31] <jmkasunich> if you want to play with FPGAs but don't need hard RT, my upci lib will let you access the card easily from a user space program
[04:00:19] <jmkasunich> three or four calls will scan the bus, find the card, map its memory
[04:00:32] <SWPadnos> I'd like to be able to tet HAL drivers, so even though I don't care about really hard RT, I think I need an RT kernel
[04:00:34] <SWPadnos> test
[04:00:37] <jmkasunich> and then there are calls to read and write 8, 16, or 32 bits to addresses in the card
[04:02:05] <cradek> goodnight guys
[04:02:10] <jmkasunich> goodnight
[04:03:22] <SWPadnos> night cradek
[04:18:44] <jmkasunich> bedtime here too
[04:21:13] <SWPadnos> night jmkasunich
[11:44:19] <jepler> SWPadnos: likewise I've developed the pluto driver partially under userspace, by hacking the Submakefile to compile it and putting a call to iopl(0) in
[16:08:30] <SWPadnos> well, I got an RT SMP X86_64 kernel to boot just fine yesterday but had no X, hopefully due to driver silliness
[16:09:01] <skunkworks> eww
[16:09:03] <SWPadnos> I downloaded the newest Nvidia driver, and will compile that today. hopefully I don't need to do much more than that
[16:09:12] <SWPadnos> (though nv didn't work either)
[16:10:03] <SWPadnos> actually, it was funny. I couldn't bot at first since this machine is SATA, and I hadn't made an initrd with the sata_nv driver
[16:10:09] <SWPadnos> boot, not bot
[16:11:02] <SWPadnos> when I tried to make an initrd, it turned out that the sata_nv driver hadn't been made, though I could swear I had used the .config from the previous ubuntu kernel (which should have all that, since it works on that machine)
[16:11:59] <skunkworks> * skunkworks doesn't have to duck at all - it all goes right over the top.
[16:12:20] <SWPadnos> heh -shorty
[16:13:50] <skunkworks> :)
[17:13:32] <petev> jmkasunich, u there?
[17:13:42] <SWPadnos> hi pete. he's probably at work
[17:13:54] <petev> I thought he had limited access from work?
[17:14:01] <SWPadnos> true enough
[17:14:05] <petev> its lunch time, isn't it ;-)
[17:14:17] <SWPadnos> heh
[17:14:26] <petev> make any progress on your machine?
[17:15:31] <SWPadnos> not on the mill
[17:15:43] <petev> you have another machine ?
[17:15:44] <SWPadnos> but I have gotten somewhere with RTAI + SMP + X86_64
[17:15:51] <petev> ah
[17:16:29] <SWPadnos> I was actually away for the last 2 weeks (actually, 4 of the last 5), so I haven't had much access to the machine :)
[17:16:51] <petev> jmk got me motivated with all his plans
[17:17:04] <SWPadnos> which plans?
[17:17:07] <petev> I pretty much finished my machine, but still having emc issues
[17:17:13] <petev> for his machine
[17:17:49] <SWPadnos> hmm. I noticed the boss module - what else is going on?
[17:18:35] <petev> I haven't gotten past homing
[17:18:49] <SWPadnos> hmm
[17:18:55] <petev> but PID behavior doesn't seem quite right and homing has some problem
[17:19:12] <petev> after the index move, the axis takes off with ballistic accel
[17:19:21] <petev> totaly disrespecting machine limits
[17:19:38] <petev> I have digital drives, so I can see exactly what is happening
[17:19:55] <petev> no matterh what I set the drive limits to, emc tries for more
[17:20:04] <SWPadnos> odd. I wonder if it's related to the bug regarding "run-from-line" (which may also be at play in probing)
[17:20:09] <petev> I need to HAL scope things to see whats going on
[17:20:30] <petev> I don't have the belts on, but I start a home sequence
[17:20:38] <petev> it starts with correct vel
[17:20:44] <petev> then I press the switch
[17:20:50] <petev> and it reverses with correct vel
[17:21:07] <petev> when I let the switch go, it contiunes for a bit at same vel
[17:21:14] <petev> this I assume is the index move
[17:21:20] <petev> then it takes off
[17:21:39] <petev> not sure where it would go, as my drives stop it too quickly
[17:21:44] <SWPadnos> I'm hoping you have a nonzero HOME_OFFSET?
[17:22:14] <petev> actually, this is on Z where the offset is only 0.050"
[17:22:23] <petev> havent tried X or Y yet
[17:22:31] <petev> I have larger offsets on them
[17:22:58] <petev> I need to find the cause of the problem
[17:23:23] <petev> I'll HAL scope it in a bit
[17:25:18] <SWPadnos> at some point, I'd like to see your ini/hal files
[17:25:20] <SWPadnos> but not right now :)
[17:25:35] <petev> I have some old versions in cvs
[17:25:53] <petev> I'll check in some newer ones as soon as I test a bit more
[17:26:01] <SWPadnos> ok
[17:26:05] <petev> the ones in cvs are pretty much the first shot before debug
[17:26:11] <petev> but they aren't too bad
[17:28:04] <SWPadnos> ok, I see the boss directory now
[17:29:37] <SWPadnos> bbiab
[17:29:45] <petev> ok
[17:59:01] <cradek> petev: hal/components/boss_plc.c:625: warning: passing argument 3 of 'hal_param_float_new' from incompatible pointer type
[18:44:17] <SWPadnos> hmmm. the RT kernel does seem to be quite a bit slower
[18:44:30] <SWPadnos> I wonder if the CPU frequency scaling is somehow screwed up
[18:50:34] <petev> cradek, is that on the latest version in CVS?
[18:50:42] <cradek> yes
[18:51:00] <cradek> looks like a float/int mismatch
[18:51:05] <petev> ok, let me take a look, maybe I didn't check in the latest from my machine
[18:51:11] <petev> I'll fix it
[18:53:37] <petev> yep, that export should be a u32
[18:58:07] <cradek> jepler:
[18:58:08] <cradek> File "/usr/local/src/emc2.trunk/bin/axis", line 2928, in func
[18:58:08] <cradek> e.widget, "<%s-%s>" % (g, e.char))
[18:58:08] <cradek> TclError: bad event type or keysym "["
[18:58:16] <cradek> when trying to jog A with [
[18:58:44] <petev> cradek, while your looking at axis jog, I was having some strange behavior there
[18:58:44] <jepler> sigh
[18:58:51] <jepler> cradek: thanks for the report
[18:58:56] <cradek> np
[18:59:09] <petev> seems like I couldn't jog the same axis twice without swithcing to another one and back
[18:59:27] <petev> I can try and test again to get more consise behavior
[18:59:47] <petev> I think I was using an incremental jog
[18:59:55] <cradek> petev: what version? jogging with mouse or keyboard?
[19:00:12] <petev> latest axis from cvs about a month ago
[19:00:22] <petev> using the mouse or touch panel
[19:00:44] <cradek> update and retry
[19:00:58] <petev> ok
[19:06:25] <jepler> cradek: update and try jogging with [ again
[19:07:11] <jepler> hm looks like petev is right -- the incremental jogging with mouse bug that I introduced and fixed in the v2_1_branch is still in trunk
[19:07:37] <cradek> oh I didn't even think about checking today's, since he said his was a month old
[19:11:49] <jepler> OK, that is now reverted on TRUNK
[19:11:51] <jepler> I suppose I should test it
[19:12:37] <cradek> we should just remove mouse jogging - it's the worst possible way to jog
[19:12:57] <petev> if you do that, then touch panel won't work either
[19:13:12] <skunkworks> with a roller ball - it would be 'ok'
[19:13:25] <petev> BTW, I tried that GOK onscreen KB, but it sucked
[19:13:42] <cradek> I think touch panel + jogwheel would be a sane setup
[19:13:43] <petev> what are the chances there could be a built in on screen KB in axis?
[19:13:46] <cradek> touch panel alone would suck
[19:14:00] <cradek> petev: zip IMO
[19:14:08] <jepler> yeah -- zero sounds about right to me
[19:14:16] <jepler> what are the odds I'll be able to do better than all the gnome developers combined?
[19:14:19] <petev> it's actually pretty good if you have the right hard controls too
[19:14:34] <petev> jepler, I think pretty good ;-)
[19:14:38] <cradek> yeah I bet it would be fine with a few additional controls
[19:14:59] <petev> they have to make it work for all apps and conditions, where as built in would only need to work for axis
[19:14:59] <SWPadnos> petev, I think gnome has an on-screen keyboard available - it's probably in the accessibility options
[19:15:06] <jepler> 14:13:25 <petev> BTW, I tried that GOK onscreen KB, but it sucked
[19:15:14] <petev> yeah, that's GOK
[19:15:16] <SWPadnos> ah - my bad
[19:15:21] <jepler> bbl
[21:35:11] <petev> jepler, the incremental mouse jog fix looks like it works
[21:35:22] <petev> cradek, do you run a home sequence on your machine?
[21:43:53] <cradek> petev: no, I hope the axes individually since I do it by jogging to a certain position (no switches)
[21:45:43] <petev> ok, I'm seeing some serious problems with switches
[21:45:54] <petev> I'm going to start looking at the code
[21:46:13] <cradek> what's the problem?
[21:46:44] <petev> one sec, on phone
[21:47:11] <SWPadnos> as he described it earlier, the axis moves correctly until the home switch is closed (manually)
[21:47:19] <SWPadnos> correctly backs off until he lets go of the switch
[21:47:20] <cradek> my lathe has a home switch on X, unfortunately it's apart
[21:47:30] <SWPadnos> correctly finds the encoder index
[21:47:54] <SWPadnos> then takes off at higher than max speed to points unknown (possibly HOME_OFFSET, but that's set to some very low number, like 0.05)
[21:48:22] <cradek> it should go to HOME
[21:48:29] <cradek> HOME_OFFSET is the position of the switch on the axis
[21:48:50] <SWPadnos> right - so it should move 0.05 off the switch (depending on sign) if HOME_OFFSET is 0.05
[21:48:53] <SWPadnos> ?
[21:49:00] <cradek> depends what HOME is
[21:49:01] <SWPadnos> err - off the index
[21:49:28] <cradek> I'm really puzzled by the "higher than max speed" - how much higher?
[21:49:39] <SWPadnos> the more troubling part is that the velocity and/or accel are above the axis max settings
[21:49:41] <SWPadnos> right
[21:50:00] <SWPadnos> it sounded to me like it could be related to the other high-speed motion bug in probing
[21:50:07] <cradek> that's hard to believe
[21:50:23] <cradek> it's not related to probing since it's not coordinated motion like probing is
[21:50:27] <SWPadnos> not when I consider it as a motion that has an unknown endpoint, similar to probing
[21:50:55] <cradek> homing is the free mode planner
[21:51:08] <cradek> it only considers one axis
[21:51:12] <petev> ok, here's the deal
[21:51:27] <petev> I have pretty smart digital drives so I can see exactly what is going on
[21:51:28] <cradek> it doesn't get confused about diagonals when it loses track of the endpoint, like coordinated motion does
[21:51:38] <SWPadnos> ok
[21:51:38] <petev> the initial move happens at the correct vel
[21:51:52] <petev> then reverses off of the switch, also at the correct vel
[21:52:01] <petev> then the index pulse happens
[21:52:10] <petev> and the encoder clears to zero
[21:52:17] <petev> the next move should be 0.05"
[21:52:39] <petev> but the axis takes off at a ballistic accel rate that totally violates the machine settings
[21:52:53] <petev> not sure how far it would have gone, as the drive stops it pretty quickly
[21:53:11] <petev> I cranked up limits in the drive, but EMC kept exceeding them
[21:53:23] <cradek> what's maxaccel on the axis and what accel are you getting?
[21:53:26] <petev> the intial settings were 20 ipss in emc and 25 ipss in the drive
[21:53:34] <cradek> ok
[21:53:52] <petev> not sure what I'm getting as emc keeps wanting more than whatever I give it in the drive
[21:53:59] <cradek> my home switch does NOT use index
[21:54:10] <petev> didn't want to go too far and have the key fly out or something ;-)
[21:54:13] <cradek> can you pastebin your ini?
[21:54:31] <petev> I used hal scope and the encoder does zero fine
[21:54:39] <cradek> that's good
[21:55:16] <SWPadnos> if this is the boss setup, just check the changes into CVS
[21:55:31] <cradek> good idea
[21:55:35] <petev> it's pretty close, I will paste bin
[21:55:43] <petev> ok, I can do that
[21:58:37] <petev> ok, it's there
[22:00:35] <cradek> X?
[22:00:57] <petev> what?
[22:01:01] <cradek> what axis?
[22:01:06] <petev> no, this is on Z axis
[22:01:17] <petev> shouldn't make much diff
[22:01:35] <cradek> well X should do a 9" rapid after it homes, Z shouldn't
[22:01:43] <petev> thought you were asking about the X server problems, which seem to be back
[22:01:44] <cradek> so yes it does :-)
[22:04:29] <cradek> so it is Z that's having this problem, or all of them?
[22:04:57] <petev> have not tried the others as they are not as convenient to operate and see the motor
[22:05:41] <petev> right now none have the belts on, so I suspect the same result on all of them
[22:06:57] <cradek> ok you're using scheme 3 (third from top in the image) where it homes when pulling off the switch
[22:07:14] <petev> yes, then should continue to the index pulse
[22:07:21] <cradek> right
[22:07:34] <SWPadnos> you have a scal of 3 on all the axes. I haven't looked at the motenc driver - does that set the "full scale value", or does the driver multiply tour output by that to get its output voltage? (ie divide or multiply?)
[22:07:37] <SWPadnos> scale
[22:07:37] <cradek> and the index pulse's position should be 0.05
[22:07:55] <petev> no, look at the pid scale too
[22:08:04] <petev> pid is set so the output is ips
[22:08:16] <petev> then that is scaled to make 10V full scale at the drive
[22:08:23] <SWPadnos> what does 1 volt equate to on your drives?
[22:08:24] <SWPadnos> ok
[22:08:31] <petev> and the drive is scaling full command to full motor speed
[22:08:37] <cradek> so I agree it should continue only .05 past the switch to get to 0 (HOME)
[22:08:44] <petev> 1V = 200 rpm
[22:08:59] <petev> 10 rev = 1 in
[22:09:15] <SWPadnos> ok. the PID max output is 9, so you should scope that to be sure it isn't erroneously going above 9
[22:09:15] <cradek> the moves are so short that you should be able to scope the whole sequence
[22:09:25] <SWPadnos> that leaves the motenc card or driver
[22:09:27] <petev> no, PID output is 3.3333333333
[22:09:36] <petev> that's in ips
[22:09:45] <petev> which is 200 ipm
[22:10:08] <petev> I can see the whole sequence intil the drive fault
[22:10:15] <petev> until
[22:10:19] <SWPadnos> ah - ok. I should realy get X going on that machine again ;)
[22:10:52] <petev> the other problem is hal scope doesn't seem to show enough resolution on the floats
[22:11:22] <petev> and there seems to be some funny behavior when you are zoomed all the way in with the value it shows you
[22:11:22] <SWPadnos> it should be "full" resolution - ofa 32-bit float
[22:11:46] <petev> I think the cursor dot gets out of synch by a sample +/- depending on which way the mouse is moving
[22:12:02] <petev> SWPadnos, it's what it displays that matters
[22:12:11] <cradek> yeah I've noticed the cursor isn't quite right sometimes
[22:12:21] <petev> and I don't think it's showing more than 3 decimal places
[22:13:00] <petev> so, anyhow I had a hard time seeing the following error issues in hal scope, but emc complained about them and I could see them in the drive
[22:18:22] <petev> where are the accel calcs done for homing? are they in the traj planner or somewhere else?
[22:20:44] <cradek> no they're in the free mode planner in emc/motion
[22:21:03] <cradek> hey if you just disable home to index, does it work right?
[22:21:09] <cradek> that would narrow it down a lot.
[22:21:17] <petev> don't know, let me go try it
[22:30:05] <petev> no, the result is the same without using the index
[22:30:56] <SWPadnos> and if you set HOME_OFFSET to 0?
[22:31:04] <cradek> wild
[22:31:10] <SWPadnos> (that should be an obvious thing, but what the heck :) )
[22:31:21] <petev> ok, let me go try it
[22:31:34] <cradek> no HOME_OFFSET=0 and HOME=0 means it won't move off the switch
[22:31:41] <cradek> that can't be what you want
[22:32:16] <SWPadnos> it moves off the switch for homing type 2 (or whichever it is)
[22:32:24] <SWPadnos> click, then back off slowly
[22:33:17] <cradek> right but at the end it will move to HOME which is back toward the switch then
[22:33:51] <SWPadnos> hmm
[22:34:19] <SWPadnos> shouldn't it consider the current position to be 0, once the home switch opens?
[22:35:22] <cradek> no, I think you need to read the help again, HOME_OFFSET is the coordinate of the switch, HOME is the final position
[22:35:41] <SWPadnos> heh - I need to read the help for the first time ;)
[22:37:55] <SWPadnos> cradek, when you were experimenting with FF, was it FF1 or FF2 that had a great effect when set to some very slightly nonzero number?
[22:38:00] <jmkasunich> petev: you still there?
[22:38:13] <jmkasunich> just reading back, I'm pressed for time (going out for the evening)
[22:38:14] <cradek> SWPadnos: they were both pretty touchy for me
[22:38:16] <petev> yes, was just testing
[22:38:18] <SWPadnos> FF1=1 seems like it may be high (based on what I've heard - I have no experience with that)
[22:38:29] <petev> SWPAdnos, you're on to something, it works with offset = 0
[22:38:34] <jmkasunich> have you halscoped the actual outputs of EMC itself, or just the motor commands (after PID)?
[22:38:36] <petev> what?
[22:38:40] <petev> ff1 is 1
[22:38:43] <SWPadnos> that should prevent the last move from happening
[22:38:50] <petev> and with my PID setup, that should be correct
[22:39:04] <SWPadnos> so it's a no-brainer that it would "fix" the problem :)
[22:39:32] <jmkasunich> I really don't think that emc's output will violate the vel constraint, but it WILL make a step change when it hits the index
[22:39:47] <jmkasunich> it has to, because the encoder also makes a step change when it resets on index
[22:39:53] <petev> jmkasunich, it's the accel
[22:40:06] <petev> I have no idea what the vel would reach, as the drive stops it first
[22:40:08] <jmkasunich> vel, accel, I don't think emc will exceed either one
[22:40:20] <jmkasunich> have you halscoped it?
[22:40:26] <petev> no, I took the index out of the pic and the result was the same
[22:40:48] <jmkasunich> I thought you said it happened when it hit the index?
[22:40:48] <petev> yes I used hal scope and saw nothing wrong, other than the ballistic accel on the last move
[22:41:02] <jmkasunich> that accel was on the output from motmod?
[22:41:07] <jmkasunich> axis.N.motor-pos-cmd IIRC?
[22:41:09] <petev> it does, and it also happens without the index which I just tested
[22:41:39] <petev> now I just tried it with a 0 offest and there is no problem
[22:41:54] <petev> so it seems related to having the offset, but not using index
[22:42:04] <SWPadnos> right - there;s no problem because that last move (to home position) is eliminated when home==home_offset
[22:42:17] <petev> and the motenc card zeroed the count correctly according to hal scope
[22:42:25] <jmkasunich> ok
[22:42:36] <jmkasunich> there is a hal parameter: axis.N.home-state
[22:42:44] <jmkasunich> scope that along with the other things next time
[22:42:47] <petev> I have not looke at that
[22:42:54] <jmkasunich> that will tell you what state the homeing process is in
[22:43:01] <jmkasunich> then you can see what code its running
[22:43:08] <petev> it does the same thing everytime, so I can just try it again
[22:43:32] <jmkasunich> also, axis.N.free-pos-cmd is (IIRC) the command to the free mode planner
[22:43:37] <petev> the only sketchy behavior is the emc apps sometimes exiting with a X error by themselves
[22:43:42] <petev> none of the other apps do this
[22:43:56] <petev> and when hal scope does, it seems to leave the RT part running
[22:44:00] <jmkasunich> emc apps don't to it either, for anybody else ;-/
[22:44:15] <cradek> what X error?
[22:44:22] <petev> well on this machine they do, but it has not happened with any other X app
[22:44:38] <petev> the one I posted before about unexpected disconnect or somthing like that
[22:44:55] <cradek> oh, right
[22:45:02] <cradek> lost connection to the x server etc etc
[22:45:13] <petev> I still have to try with another GUI, but HAL scope exited with axis running, and axis was still fine
[22:45:19] <cradek> I've never seen that of course
[22:45:32] <petev> so it doesn't appear to be GUI related, but more emc related
[22:45:44] <jmkasunich> halscope is just a user app, it dying won't affect emc, or even the RT part of scope
[22:45:49] <petev> I had several other X apps running and they were also uneffected
[22:46:11] <jmkasunich> we digress,and I have to run very soon... let me give you some hints that might help on the homing thing
[22:46:18] <petev> yes, but it's annoying, and even more annoying when it;s the GUI that exits
[22:46:22] <petev> ok
[22:46:45] <jmkasunich> there are params that will give you a look at the internals - axis.N.home-state, axis.N.free-pos-cmd, and others
[22:47:01] <jmkasunich> look in src/emc/motion/motion.c around line 700-750 to see them
[22:47:13] <petev> ok
[22:47:13] <jmkasunich> the homing state machine is in control.c, function do_homing
[22:47:26] <jmkasunich> the states are defined in either motion.h or mot_priv.h
[22:47:32] <jmkasunich> oops, gotta go...
[22:47:33] <jmkasunich> later
[22:47:36] <petev> ok
[22:48:03] <cradek> petev: remind me what version/build you're using
[22:48:20] <petev> this is the latest, I just updated to test jepler's fix
[22:48:26] <petev> so from a bit earlier today
[22:48:28] <cradek> ok
[22:51:37] <SWPadnos> the code looks OK. one thing you can do to isolate where the problem is would be to add in a HOME_DELAY
[22:52:15] <SWPadnos> that's a delay between finding the index and moving to HOME (in seconds)
[22:53:08] <petev> It fails without the index move
[22:53:22] <petev> I think it's something in the offset move
[22:53:56] <petev> I can see the motor make the index move, it's pretty slow
[22:54:05] <petev> and happens after I release the switch
[22:54:54] <SWPadnos> ok - so you're back to more or less the ini you checked into CVS?
[22:55:03] <SWPadnos> (plus/minus the index)
[22:55:17] <petev> I can got back to that, or leave the index out for testing
[22:56:03] <SWPadnos> I'd test like you had it. I suspect that the issue occurs after the index is found, and I think the only thing after that is moving to HOME
[22:56:27] <SWPadnos> actually, you said the issue is after the index is found, because you were manually operating the home and index inputs
[22:56:57] <petev> yes, and hal scope confirms, so I'm pretty sure it's in the offset move where the problem is
[22:57:27] <SWPadnos> so, set HOME_DELAY to 2 or 3 seconds, and make sure that no motion is attempted before that time
[22:58:35] <petev> look at the HOME_SET_SWITCH_POSITION state
[22:59:02] <petev> if it sets the current position to home offset, what keeps the PID from going ballistic?
[23:00:21] <petev> is that motor_offset supposed to take care of that?
[23:00:26] <SWPadnos> hmmm
[23:00:42] <petev> I don't see how it could, as the PID is indepentant
[23:00:51] <petev> the pos_cmd is being changed
[23:00:56] <SWPadnos> the PID isn't getting its feedback from here, so that could be a problem
[23:01:03] <petev> right
[23:01:10] <SWPadnos> but I don't think that pos_cmd is directly output
[23:01:38] <petev> we need jmk
[23:01:50] <SWPadnos> it could be, if there's a switch from the free mode planner (or homing planner, if it's different( to the coordinated planner
[23:02:25] <petev> let me do a hal scope run with the state displayed
[23:03:19] <SWPadnos> did you try setting HOME_OFFSET == HOME = 0, but with index enabled?
[23:03:43] <SWPadnos> if not, please do :)
[23:08:00] <SWPadnos> bbiab
[23:12:59] <petev> looks like state=18 when the problem happens
[23:15:58] <petev> 18 is final move wait
[23:16:03] <petev> let me see what's before that
[23:16:56] <petev> HOME_SET_SWITCH_POSITION goes right to HOME_FINAL_MOVE_START
[23:18:06] <petev> let me try the HOME_DELAY to break apart a PID problem from final move issue
[23:19:01] <petev> what are the units for HOME_DELAY?
[23:20:00] <petev> it's being multiplied by servo_freq, but I suspect that might be period
[23:31:31] <petev> well HOME_DELAY doesn't seem to do anything
[23:31:45] <petev> I still see states 12, 17, 18 with the same timing
[23:37:49] <SWPadnos> HOME_DELAY should be seconds, from my reading of the code
[23:39:23] <petev> if you beleive servo_freq
[23:39:28] <SWPadnos> yes :)
[23:39:32] <petev> but it doesn't seem to work
[23:39:44] <SWPadnos> odd
[23:39:46] <petev> and I don't see state 13, even when zoomed all the way in
[23:40:10] <petev> it goes from 12 to 17
[23:40:53] <petev> I don't see how that happens from the code
[23:41:01] <SWPadnos> hold on - are you saying that the HOME_DELAY doesn't cause the homing state to change later, or that it doesn't delay the problem you're seeing?
[23:41:02] <petev> maybe a hal scope issue?
[23:41:31] <petev> both, I see the same state change timing, and the problem happens at the same time
[23:41:42] <SWPadnos> there's an option to skip several samples per saved sample - you may want to check that it's not enabled
[23:41:47] <petev> from the code, I would expect 12, 13, 17, 18
[23:41:57] <petev> but 13 seems to get skipped from hal scope
[23:42:25] <petev> hmm, let me look at that, as 13 would only be 1 sample
[23:42:29] <SWPadnos> that's possible. note the flag "immediate_state" - the case statement is in a loop
[23:42:46] <SWPadnos> I'm not looking at what the numbers are (12,13 ...)
[23:42:47] <petev> oh, didn't realize that
[23:42:55] <petev> so maybe that state is super short
[23:43:13] <SWPadnos> nonexistent as far as halscope is concerned
[23:43:19] <petev> right
[23:43:27] <SWPadnos> since the last state change is the only one that later funcs see
[23:43:27] <petev> so why isn't HOME_DELAY working?
[23:43:41] <SWPadnos> it may be, but the problem may be before the delay
[23:43:45] <SWPadnos> that's what I wanted to check
[23:43:56] <SWPadnos> but I'd need to look at the state numbers first :)
[23:44:09] <petev> no, the problem is happening as soon as I let go of the switch (not using index) and the sate is 18
[23:44:45] <petev> I would have expected a delay between letting go of the switch and state 18
[23:45:03] <SWPadnos> hmm. lemme look at that again
[23:45:20] <petev> it should stay in 17 until HOME_DELAY expires
[23:45:39] <petev> let me go check hal scope once more to be sure
[23:49:11] <SWPLinux> ok, this may be easier :)
[23:49:30] <petev> ok, I think I'm not setting HOME_DELAY correctly
[23:49:45] <petev> does it get picked up from the INI with the other home params or not?
[23:49:52] <SWPLinux> I'm not sure where it comes from, to be honest
[23:49:58] <SWPLinux> actually, it looks like it may be compiled in
[23:50:10] <petev> state 17 only lasts about 100 msec, no matter what I put for HOME_DELAY
[23:50:30] <SWPLinux> yep - control.c
[23:50:31] <petev> yeah, I don't think it's paying any attention to the INI file, that's for sure
[23:51:03] <SWPLinux> it's set to 0.100 by default, so the problem seems to be before that
[23:51:11] <petev> so it looks like the problem occurs in state 18
[23:51:17] <petev> which is the final move
[23:51:24] <petev> so I guess it's not a PID thing
[23:51:30] <petev> though it sure seemed like it
[23:51:45] <petev> maybe you were right about pos_cmd not being output directly
[23:52:58] <SWPLinux> I think that somewhere else, there's a decision as to whether to use the free mode planner or the coordinated planner, but they have separate variables
[23:53:45] <petev> this is such simple shit, it shouldn't be this hard
[23:54:09] <SWPLinux> stick a ddt on the output of joint.2.motor-pos-cmd (or whatever it's actually called), and trip halscope on that going over Z maxaccel
[23:54:33] <petev> why bother, I can clearly see in the drive
[23:54:44] <petev> I trust the code in the drive ;-)
[23:54:53] <SWPLinux> it probably isn't. if the problem is in motmod, then it should be easy to reproduce, without any hardware drivers
[23:54:58] <SWPLinux> in fact, it should be there in sim
[23:55:33] <petev> that may be, but most guys don't have home switches, or drives that will detect this
[23:55:39] <SWPLinux> that's why we need to see halscope traces from the PID output and PID input (motor-pos-cmd)
[23:56:39] <SWPLinux> sure, but anyone can set up a vcp panel with fake home switches and index marks, and they should then be able to see the erroneous output fdrom motmod
[23:56:45] <petev> does sim have support for home switches?
[23:57:07] <petev> that's true, you volunteering? ;-)
[23:57:20] <SWPLinux> as far as I know, motmod acts basically the same as the RT version, it just can't output to hardware
[23:57:22] <SWPLinux> maybe :)
[23:58:01] <petev> I would run the RT version with cmd looped to fb
[23:58:08] <petev> and use halvcp
[23:58:18] <petev> then it should be the exact same setup
[23:58:24] <SWPLinux> I would too, if the RT kernel were cooperating with me at the moment :)
[23:58:25] <petev> but with fake sw switches
[23:58:31] <SWPLinux> rigth
[23:58:34] <SWPLinux> right
[23:58:59] <petev> doing it on the machine is a pain right now, it;s not networked and I don't have a good KB or anything
