Back
[00:02:31] <SWPLinux> hi Ray
[00:02:44] <rayh> Hi Steven.
[00:03:06] <rayh> You into spring up there?
[00:03:10] <SWPLinux> I think so
[00:03:20] <SWPLinux> hard to tell after being in Honolulu for a week ;)
[00:03:35] <rayh> Ah. I don't think that's right.
[00:04:21] <SWPLinux> hey - do you need a manual for the pulsegen?
[00:04:29] <SWPLinux> I realized I had forgotten to send one
[00:04:45] <rayh> Please.
[00:05:03] <rayh> I believe that it's working but I don't know how well.
[00:05:06] <SWPLinux> ok. I'll email you a pdf sometime soon.
[00:05:13] <SWPLinux> heh - that's relatively good news
[00:05:13] <rayh> Have to check when I get back down there.
[00:05:21] <rayh> Thanks
[00:16:50] <SWPLinux> man - what a PITA it is to get the boss setup to load in simulator mode
[00:18:36] <petev> yep, it has a lot of connections
[00:18:57] <SWPLinux> and some are net commands (With motenc pins in them), followed later by other connections to that net
[00:19:09] <petev> yep
[00:19:10] <SWPLinux> so the nets need to exist ...
[00:19:15] <SWPLinux> bastid ;)
[00:19:31] <petev> that's a slightly old version too, got more connections now ;-)
[00:20:50] <SWPLinux> lots of joint amplifier faults :)
[00:21:03] <SWPLinux> maybe I should connect the boss controller to something :)
[00:21:38] <petev> the amp fault stuff is processed by the boss plc
[00:22:01] <SWPLinux> yep. can I just set a signal to true and connect it to all the amp-ready inputs?
[00:22:01] <petev> this is because the enable also resets existing faults, and emc doesn't wait for this to happen
[00:22:28] <petev> you don't have to connect anything to it, if you don't care about the fault out signals
[00:23:07] <SWPLinux> I get joint [0123] amplifier faults, which cause the machine to go to OFF (estop reset) state
[00:23:37] <petev> and you set the ready input to true?
[00:23:46] <SWPLinux> err - no :)
[00:25:41] <petev> I just bought a USB wifi, hopefully I'll have it in a few days and can get the machine on the net
[00:25:47] <petev> that will make things easier
[00:25:57] <SWPLinux> indeed
[00:26:48] <SWPLinux> ah, not all the bits in the comment (in boss_plc.c) are implemented
[00:27:15] <petev> should be, what is missing? though I kept it up to date
[00:27:37] <SWPLinux> it looks like the amp-ready / amp-fault stuff isn't there
[00:27:44] <SWPLinux> or I just don't see where it's exported
[00:27:51] <petev> it is as I'm using it
[00:28:43] <SWPLinux> ok, it's acalled boss_plc.0.z-fault-out instead of boss_plc.<id>.z-amp-fault-out
[00:29:04] <petev> oh, better check those comments for accuracy ;-)
[00:29:13] <SWPLinux> heh
[00:31:54] <SWPLinux> much better once I fake those to true :)
[00:32:19] <petev> hmm, should I change the comments or the exports, which name do you prefer?
[00:32:58] <SWPLinux> I think the -amp-fault-out is more descriptive
[00:33:06] <SWPLinux> (but also longer, so YMMV :) )
[00:33:13] <petev> right
[00:35:29] <SWPLinux> strange. the CPU clock control doesn't pop up the frequency when a single core is maxed out
[00:35:48] <SWPLinux> which would be ideal for AXIS generating a preview, since it's single-threaded
[00:36:21] <petev> hmm, you're throwing more variables into the mix witth the duo core stuff
[00:36:32] <SWPLinux> nope, but I am with simulator mode ;)
[00:36:41] <petev> have you sucessfully run sim already?
[00:36:58] <SWPLinux> yes, I have a modified version of your boss setup loaded right now
[00:37:09] <petev> cool
[00:37:26] <SWPLinux> I'm just playing with a large g-code file - I think they've improved the nVidia drivers significantly
[00:38:10] <SWPLinux> I can spin this large preview around in very fluid realtime, with axis at 1920x1100-ish
[00:38:21] <SWPLinux> it's 515634 lines of g-code
[00:38:38] <petev> that's pretty good
[00:39:25] <SWPLinux> it's only a 7800GT video card - not even one of the quadro FX3500's
[00:41:07] <SWPLinux> ok, enough playing - now to make a vcp panel for home testing
[01:32:08] <cradek> how's homing?
[01:37:40] <SWPadnos> dunno - I got sidetracked :)
[01:40:30] <petev> well the problem happens during the final move in state 18
[01:40:55] <petev> I don't really understand all the data structures used in there, so I'm not sure what's going on
[01:41:08] <petev> state 13 appears to change the cmd pos
[01:41:28] <petev> which seems like it would upset the PID, but I'm not sure if it gets sent out directly
[01:42:27] <petev> what is clear is if HOME_OFFSET = 0, there is no problem as there is no final move
[01:43:16] <petev> was stuart using a final move in his homing?
[01:43:29] <cradek> I definitely did, on both my lathes
[01:43:47] <cradek> but I haven't used either of them for a few months
[01:43:55] <petev> did you have drives that would detect accel violations?
[01:44:26] <cradek> yes, one was steppers, the other was servo with tight FE limits
[01:44:38] <cradek> neither would have allowed a big accel violation
[01:44:52] <cradek> I *know* I would have noticed it
[01:44:52] <petev> hmm
[01:45:14] <petev> what magnitude was your emc FE set to?
[01:45:22] <cradek> did you home sim/axis and scope it?
[01:45:41] <petev> SWP was working on the sim
[01:45:47] <SWPadnos> just to eliminate the drives themselves from the equation, you should be able to disconnect the drive, and use a physical (digital / storage) scope to look at the voltage swing
[01:45:50] <cradek> .1mm
[01:45:51] <petev> not sure how far he got, he was making a VCP
[01:46:04] <petev> what is that, about 4 thou?
[01:46:08] <cradek> FERROR=.1 MIN_FERROR=.03 (mm)
[01:46:11] <SWPadnos> I got to the point of copying a vcp file into the boss sim dconfig, not much further
[01:46:19] <cradek> yeah something like that
[01:46:26] <petev> that's pretty loose
[01:46:32] <cradek> that was at 1ips rapids
[01:46:42] <petev> that's pretty slow ;-)
[01:47:07] <petev> I'm running 3.3 ips and 1 thou now, and I consider that a bit loose
[01:47:11] <cradek> not on a machine with 2" of travel
[01:47:15] <petev> oh
[01:47:30] <cradek> it's very fast
[01:48:15] <petev> when using just the drives, they will hold about 2 counts (100,000 = 1 in) on fast moves
[01:48:57] <petev> this is not any big deal, as the belts are not on
[01:49:06] <petev> so I would expect it to be at least this good
[01:49:22] <petev> the emc position loop doesn't hold anything near as good
[01:51:01] <cradek> http://timeguy.com/cradek-files/emc/simaxis-Xhoming.png
[01:51:35] <petev> what are the signals?
[01:51:56] <cradek> green=switch, purple=state, cyan=acc, red=vel
[01:52:26] <petev> so you're using a different homing seq then what I was trying?
[01:52:35] <cradek> I just homed X in sim/axis
[01:52:38] <petev> looks like you are moving back onto the switch, no?
[01:52:44] <cradek> yeah looks like
[01:52:53] <petev> and what is HOME_OFFSET?
[01:53:23] <cradek> 0
[01:53:28] <petev> the problem I see occurs in state 18
[01:53:41] <petev> it doens't happen unless HOME_OFFSET is non zero
[01:53:53] <petev> I can home fine with HOME_OFFSET=0
[01:55:26] <cradek> http://timeguy.com/cradek-files/emc/homing-with-offset.png
[01:55:59] <cradek> offset=.5, so the last move in stage 18 is longer
[01:56:40] <petev> try changing the latch vel sign so it's like the sequence I was using
[01:56:45] <cradek> sim/axis is a nicely configured test bed - there are ddt for vel/acc etc
[01:57:02] <petev> what are you using to sim the switches?
[01:57:03] <cradek> search +, latch -?
[01:57:09] <cradek> there are some comparators
[01:57:14] <cradek> it's all in there already
[01:57:26] <petev> I have the sign of latch the opposite of search
[01:57:39] <petev> search is +, latch is -
[01:58:21] <cradek> http://timeguy.com/cradek-files/emc/stillfine.png
[01:58:50] <cradek> you can see the last move is a rapid (-1.2) and accel is right
[01:59:15] <petev> hmm, the graphics are messed up on this one
[01:59:24] <petev> I'll take your word for it
[01:59:29] <cradek> ?
[01:59:36] <petev> what is your ACCEL limit?
[01:59:43] <cradek> 20
[01:59:42] <petev> portions of the traces are missing
[01:59:55] <petev> maybe its an explorer issue
[01:59:57] <cradek> click it
[02:00:06] <cradek> the image is fine
[02:00:16] <cradek> you must be throwing out pixels
[02:00:28] <petev> not me, bill
[02:00:55] <cradek> well surely even windows can view a png without screwing it up
[02:01:11] <petev> not really
[02:01:21] <cradek> well nmfp
[02:01:33] <skunkworks> I don't have problems with them
[02:01:41] <skunkworks> (png)
[02:01:41] <petev> so I wonder what the difference is here?
[02:01:51] <petev> looks like the same seq and limits now
[02:01:59] <cradek> I don't know what to suggest except you make the same plot for us to see
[02:02:02] <petev> what is your VEL limit?
[02:02:12] <cradek> you have this exact config, it's sim/axis
[02:02:27] <petev> you didn't change any params?
[02:02:34] <cradek> no it's running right off trunk
[02:02:47] <petev> ok, what are you using to sim the switch?
[02:02:50] <cradek> well I made LATCH_VEL negative
[02:02:57] <petev> sure
[02:03:06] <petev> is the switch sim built in too?
[02:03:09] <cradek> yes
[02:03:26] <SWPadnos> damn. I wish I had known that :)
[02:03:46] <cradek> there's a lot of stuff in sim/axis...
[02:04:04] <petev> I can make the same plot, but we will not see much at the end where is counts as the drives and emc will stop due to the accel problem
[02:04:41] <petev> I'll try and crank the following error way up to get more data
[02:04:54] <SWPadnos> can you scope the output of the motenc card with a digital / storage scope?
[02:05:12] <petev> maybe, but what would that help?
[02:05:24] <petev> I can see the command to the drive from the drive GUI
[02:05:24] <SWPadnos> you can see if the problem is in the PC
[02:05:36] <petev> so you don't trust the AB drives?
[02:05:49] <SWPadnos> well, there's some funky software somewhere. when debugging, I don't like to assume anything
[02:06:24] <SWPadnos> the drives may be fine, but who knows if there's a problem somewhere else (like mm instead of inches set somewhere in the drive, causing all the acc/vel/ferror stuff to be wrong)
[02:06:44] <petev> I can try and capture with a scope, but we will have to estimate the accel from the ramp
[02:06:44] <cradek> good point
[02:06:47] <SWPadnos> "put on your stupid hat", as one engineer friend once said :)
[02:06:49] <petev> not exactly accurate
[02:07:18] <petev> I don't think so, as I can make moves with the jog wheel, etc. without problem
[02:07:25] <SWPadnos> if you have a spare DAC on the motenc (or one that can be used as such), you can output acc from a ddt to the extra output
[02:07:29] <cradek> this IS a rapid which is 7x the search vel
[02:07:53] <petev> the search vel is pretty low
[02:08:10] <petev> I ran moves at the full 200 ipm from the drive
[02:08:18] <petev> I have emc limited to 180 ipm
[02:08:25] <petev> so I expect it would work
[02:08:35] <SWPadnos> who knows, maybe the drive needs 20 ms after homing before another move
[02:08:42] <petev> not
[02:08:51] <petev> the drive doesn't know it's a home move
[02:08:55] <petev> how would it?
[02:09:02] <SWPadnos> the drive provides faked encoder feedback, doesn't it?
[02:09:19] <petev> it's not faked, it's actual encoder feedback
[02:09:25] <SWPadnos> ah, ok
[02:09:36] <SWPadnos> 100k counts/inch - that's quite a bit
[02:10:01] <petev> 2500 lines * 4 * 5 TPI * 2:1 ratio
[02:10:14] <SWPadnos> 2500 lines - there you go :)
[02:10:22] <SWPadnos> mine are "only" 1000 :)
[02:10:29] <petev> my jog wheel has 500 lines ;-)
[02:11:02] <petev> I think 50 would have been better, but it's what I had in my junk box
[02:11:21] <SWPadnos> ok. I was thinking that this drive was one of the ones that provides a (programmable) encoder output, so it would need to have its internal counter zeroed or something
[02:11:38] <cradek> clearly we need more data
[02:11:50] <cradek> and I don't think anyone but petev is going to be able to collect it
[02:11:52] <petev> it can divide the count from the motor, but I have the divide set to 1
[02:12:46] <petev> I think the only way I can get more data is to increase the FE, and just have the drive limit accel, but not fault
[02:13:00] <petev> then it should run until emc decides the FE is too much
[02:13:05] <petev> I can try this
[02:13:44] <SWPadnos> what happens if you set the EMC maxvel to something insanely low, like 0.1 IPS, with accel similarly low?
[02:13:49] <SWPadnos> or did you already go that low?
[02:14:01] <petev> no, haven't tried anything like that
[02:14:23] <cradek> argh, somehow a windows machine mangled your .ini file
[02:14:35] <petev> the boss file?
[02:14:38] <cradek> yes
[02:14:41] <cradek> err, hal
[02:14:42] <cradek> boss.hal
[02:14:50] <SWPadnos> ok, 0.1 vel, 1 acc might be something to try - to see if it's porportional to the limits or "constantly very high" ...
[02:14:51] <petev> hmm
[02:15:09] <petev> looks ok here, how is it mangled?
[02:15:14] <SWPadnos> yeah - I noticed basically the entire file being - then + in that diff
[02:15:15] <cradek> ^M ^M ^M
[02:15:24] <petev> hmm
[02:15:55] <petev> I wonder if that happens somehow if I commit with tortoise?
[02:16:09] <cradek> maybe, but only if it sucks
[02:16:23] <cradek> more likely an editor did it
[02:16:30] <petev> tortoise is the best cvs/svn I have found
[02:16:38] <petev> my editor does not change it
[02:16:42] <petev> that I know
[02:16:59] <cradek> want me to fix it?
[02:17:06] <petev> sure
[02:17:22] <SWPadnos> there's a tortoise option to "use UNIX line endings" (options tab)
[02:17:34] <petev> I'll try and check the files to see if I can see what's happening before any further checkins
[02:17:36] <SWPadnos> but it's not "if detected" - I suspect it's always
[02:18:12] <petev> I can only commit from the linux box, it's not a big deal
[02:18:18] <cradek> oh you fixed it in rev 1.2
[02:18:18] <SWPadnos> petev, how did you get ssh to work with tortoise?
[02:18:42] <petev> SWPadnos, I used Putty
[02:18:45] <cradek> 1.1, which I had from earlier today, was the screwed up one
[02:18:56] <petev> hmm, that's odd
[02:19:12] <petev> I didn't specifically edit it anywhere, it must be the cvs client
[02:19:38] <petev> you can load your ssh key into pageant, which is part of the putty package
[02:20:23] <SWPadnos> ok, cool
[02:22:56] <petev> cradek, were you using servo_sim.hal ?
[02:23:10] <cradek> no, just sim/axis
[02:23:23] <petev> axis.ini ?
[02:23:43] <cradek> yes configs/sim/axis.ini
[02:24:01] <cradek> sorry, I don't mean to speak in code
[02:24:05] <petev> ok, looks like that loads core_sim.hal
[02:26:10] <petev> ok, I see an issue with the sim file
[02:26:27] <petev> where are the PID loops? the ddt are on the commanded positions
[02:26:38] <petev> it may well be the PID that is causing the large accel
[02:26:59] <cradek> try the sim that uses pid then
[02:27:29] <jmkasunich> hi guys, I'm back
[02:27:31] <cradek> hi
[02:27:35] <petev> hi
[02:27:47] <petev> jmk, to recap where we are
[02:27:52] <SWPLinux> I suspect that FF0=1 and P=100 may cause rather faster swings than the TP outputs
[02:27:56] <SWPLinux> hi jmk
[02:28:01] <petev> the problem occurs during the final move in state 18
[02:28:13] <petev> this only happens if HOME_OFFSET != 0
[02:28:31] <petev> cradek ran a sim without PID and the commanded position looked ok
[02:28:45] <petev> I suspected the PID earlier when looking at state 13
[02:28:58] <petev> but I wasn't sure if cmd_pos was output directly
[02:29:01] <jmkasunich> ok, state 17 (final move start) sets free_pos_cmd... that is the INPUT to the free mode planner
[02:29:28] <jmkasunich> a step change there yeilds a vel and accel limited trapezoidal move a the output of the planner
[02:29:35] <petev> what is the cmd_pos in state 13?
[02:29:39] <SWPLinux> hi jmk
[02:29:42] <SWPLinux> oops
[02:30:26] <jmkasunich> petev: which cmd_pos?
[02:30:30] <jmkasunich> we gots too many of them
[02:30:43] <petev> line 1577 in control.c
[02:30:52] <petev> sorry, pos_cmd
[02:31:04] <petev> HOME_SET_SWITCH_POSITION state
[02:31:09] <jmkasunich> lemme update, my 1577 doesn't seem to match up
[02:31:50] <jmkasunich> you are looking at latest CVS?
[02:32:02] <petev> I think so, let me check
[02:32:31] <petev> no, looks like it was a bit old
[02:32:43] <petev> 1578
[02:33:50] <jmkasunich> joint->pos_cmd is the output of the free mode TP
[02:34:13] <petev> where does it end up? does it get on the hal pin?
[02:34:25] <jmkasunich> stand by... looking for a doc
[02:34:34] <petev> BTW, I have my base period the same as the servo period. I didn't see any reason to have it faster with a servo setup
[02:34:50] <jmkasunich> I _think_ thats OK
[02:35:10] <jmkasunich> to rule it out you might try making base period 1/2 of servo period
[02:35:13] <jmkasunich> but thats a long shot
[02:35:21] <petev> ok
[02:35:49] <jmkasunich> http://www.linuxcnc.org/docs/EMC2_Developer_Manual.pdf
[02:35:54] <jmkasunich> figure 3.1
[02:36:00] <jmkasunich> will make things a lot easier to understand
[02:36:35] <jmkasunich> back in a minute
[02:39:01] <petev> so if I read that correctly, it looks like that position will be sent to the PIDs when the free mode is selected in state 17 ?
[02:39:27] <petev> so won't that jump in cmd position cause the output of the PIDs to change too quickly?
[02:40:44] <jmkasunich> free mode is in effect thru the entire homing process
[02:41:39] <jmkasunich> lets look at state 13 first
[02:41:49] <petev> ok
[02:42:05] <jmkasunich> offset is the amount of adjustment needed to make the current position = HOME_OFFSET
[02:42:17] <petev> yes
[02:42:32] <jmkasunich> it is added to both pos_cmd and pos_fb, so there is no following error
[02:42:47] <jmkasunich> its subtracted from motor_offset, so the actual outputs to HAL don't change
[02:42:56] <petev> but pos_fb gets updated from enc, no?
[02:43:08] <jmkasunich> and its added to free_pos_cmd so the free planner won't try to move
[02:43:15] <jmkasunich> enc?
[02:43:19] <petev> encoder
[02:43:40] <jmkasunich> motor_pos_fb is coming from the encoder
[02:43:50] <SWPLinux> and to the PID ...
[02:44:06] <jmkasunich> pos_fb is motor pos with motor-offset subtracted out
[02:44:25] <petev> and that happens every servo cycle?
[02:44:41] <jmkasunich> the code in that diagram executes every servo cycle
[02:45:29] <petev> so what happens when state 17 commands the move?
[02:45:49] <jmkasunich> at the point where "do_homing()" runs, the subtract of motor-offset from motor-pos-fb has already taken place, but the add of motor-offset to pos-cmd has not
[02:46:22] <jmkasunich> so state 13 corrects pos_fb, pos_cmd, and motor_offset
[02:46:46] <jmkasunich> later on, at the end of the control code, motor_offset is added to pos_cmd to make motor_pos_cmd
[02:47:13] <jmkasunich> the next effect of state 13 is a step on pos_fb and pos_cmd (to the desired position based on home switch) but no step in the signal going to the motor
[02:47:36] <petev> I follow the concept
[02:47:55] <petev> so what happens when the final move starts?
[02:47:59] <jmkasunich> this problem happens even when you are NOT homing to an index, right?
[02:48:12] <petev> yes, but only with a final move
[02:48:18] <petev> without the final move, there is no problem
[02:49:10] <jmkasunich> after the pause times out, the free mode planner command gets set to the home position, the free mode velocity limit is set to the machine limit, and the free mode planner is enabled
[02:49:32] <petev> what about the accel limit?
[02:49:36] <jmkasunich> at which point pos_cmd (output of free mode planner) should do a accel and vel limited move until it matches free_pos_cmd
[02:49:46] <jmkasunich> thats already set to the machine limit and never changes
[02:50:17] <jmkasunich> free mode vel changes, because the free mode planner is used for search move, latch move, jogs, etc
[02:50:31] <petev> hmm, I clearly see accel violations at the drive, thought the vel never gets a chance to see where it will settle
[02:50:55] <petev> I guess I need to put a ddt on the PID output
[02:50:55] <jmkasunich> have you looked with halscope at motor-pos-cmd, and/or pos-cmd?
[02:51:02] <jmkasunich> no!
[02:51:02] <petev> yes
[02:51:07] <jmkasunich> don't look at the pid output
[02:51:16] <petev> why?
[02:51:17] <jmkasunich> look at the command to the PID
[02:51:31] <petev> the drive sees the PID output, not the cmd
[02:51:44] <jmkasunich> do you have your PID properly tuned?
[02:51:59] <petev> it is not very agressive at all
[02:52:09] <petev> which is something else I wanted to talk to you about later
[02:52:18] <petev> right now PID output is in ips
[02:52:23] <jmkasunich> then why do you think its causing wild accels?
[02:52:30] <petev> and the DAC and drive are scaled accordingly
[02:52:32] <jmkasunich> unless its command contains wild accels
[02:52:38] <petev> FF1 is set to 1
[02:52:42] <petev> and a mild P
[02:52:46] <petev> no I or D
[02:52:57] <petev> I get accel violations at the drive
[02:52:59] <jmkasunich> mild P = ? number
[02:53:05] <petev> 100
[02:53:19] <petev> I removed the drive accel limits and used current limits
[02:53:33] <jmkasunich> so 1" of error will cause 100 ips of velocity command out of the PID
[02:53:36] <petev> with the drive I could acel at 25 ips with about 3 A current
[02:53:47] <jmkasunich> ips^2 you mean?
[02:53:56] <petev> yes
[02:54:08] <petev> I set the current limit to 12.5 A and emc would still trip it on the final move
[02:54:15] <jmkasunich> I gathered from reading back that you aren't actually at the EMC machine when you are talking to us?
[02:54:21] <petev> so it's accel is way past 25 ipss
[02:54:41] <petev> no, the emc machine is not on the network yet
[02:54:45] <petev> I'm working on that
[02:54:52] <jmkasunich> so its gonna be a pain in the ass to do any testing?
[02:54:56] <petev> I can take the notebook out there if it will help
[02:55:06] <jmkasunich> you talk to us, then hike out to the machine, then hike back..
[02:55:13] <jmkasunich> we'll never get anywhere that way
[02:55:23] <petev> yeah, but if we need to test a lot, I'll setup the NB
[02:55:25] <petev> not a problem
[02:55:31] <jmkasunich> please do
[02:55:42] <petev> ok, so what do you want to test and I'll set it up
[02:56:01] <jmkasunich> it would be nicer if you could post halscope pics, but we'll make do
[02:56:10] <jmkasunich> several tests come to mind
[02:56:28] <jmkasunich> try turning off FF1 first, see if that makes a difference
[02:56:44] <jmkasunich> then we'll move on from there based on that result
[02:56:50] <petev> when I was playing with PID tuning, it didn't quite behave as I expected
[02:57:09] <jmkasunich> what did you use for command while tuning? siggen or something>?
[02:57:10] <petev> with FF1 off, tracking pretty much sucked no matter what I set
[02:57:34] <petev> no, didn't do anything rigourous yet as the belts are still off
[02:57:51] <petev> just checking for oscillations and using the jog wheel
[02:57:55] <jmkasunich> I had the mazak scaled the way you have yours scaled (PID out = ips), and IIRC both P and I gains are a few thousand
[02:58:03] <jmkasunich> so I'm not surprized tracking is weak
[02:58:07] <SWPLinux> I think cradek found that ff1 in the 0.01 range had a rather large effect
[02:58:14] <SWPLinux> on NIST-lathe, I think
[02:58:16] <petev> even the slightest amount of D causesed oscillation
[02:58:38] <jmkasunich> I think the mazak has D set to 8 or something
[02:58:59] <petev> I had P all the way up to 5000 and it didn't make much difference with FF1 enabled
[02:59:19] <jmkasunich> well, right now we're chasing too many variables
[02:59:30] <petev> without FF1, there was noticably more oscillations, but tracking wasn't a whole lot better
[02:59:39] <jmkasunich> gotta pin it down, which means we gotta stop talking and start testing
[02:59:39] <petev> agreed
[03:00:04] <petev> so do you think PID is a problem when tuned so mildly?
[03:00:14] <jmkasunich> I don't know what to think, I need data
[03:00:24] <petev> ok, tell me what you want
[03:01:02] <jmkasunich> halscope monitoring home_state, pos_cmd, and motor_pos_cmd, set to trigger when state becomes 18
[03:01:11] <jmkasunich> FF=1
[03:01:13] <jmkasunich> do a home
[03:01:17] <petev> already did that
[03:01:22] <petev> what info do you want?
[03:01:25] <jmkasunich> and since you can't post the halscope pic, describe it to us
[03:01:46] <jmkasunich> what is the value of pos_cmd immediately prior and immediately after the trigger?
[03:01:51] <petev> so everything looks normal, but emc gets a following error in state 18
[03:02:02] <petev> and the drive indicates excessive accel
[03:02:06] <jmkasunich> what is the value of pos_cmd immediately prior and immediately after the trigger?
[03:02:22] <petev> ok, that is a bit of a problem
[03:02:26] <jmkasunich> why?
[03:02:30] <petev> hal scope seems to have a bug or two
[03:02:41] <petev> the cursor seems to get out of sync with the sample
[03:02:56] <petev> it would change depending which way I moved the mouse on approach
[03:03:07] <petev> cursor on the same spot, but two different results
[03:03:17] <jmkasunich> even if you zoom in?
[03:03:29] <petev> I was zoomed all the way to 1 msec
[03:03:32] <petev> the sample rate
[03:03:54] <petev> also, it looke like only 3 digits to the right of the decimal are displayed
[03:04:02] <jmkasunich> I rarely use the cursor, so I can't vouch for it, although I don't think I've ever seen that
[03:04:04] <petev> which may not be enough
[03:04:10] <jmkasunich> I just read the scope like a regular scope
[03:04:19] <jmkasunich> use vertical scale to get it on screen
[03:04:25] <petev> ok, I can try that
[03:04:30] <jmkasunich> then if needed, use offset to get it close to the center
[03:04:32] <jmkasunich> then scale it bigger
[03:04:45] <petev> let me setup the NB and make another run
[03:05:00] <jmkasunich> you can use offset to allow a scale of 1u-inch per div even if the value of the signal is 1000 inchs
[03:05:04] <jmkasunich> es
[03:12:44] <_petev> ok, I have it setup
[03:12:55] <_petev> u said you wanted to trigger on state=18?
[03:13:00] <jmkasunich> yeah
[03:13:10] <jmkasunich> it goes from 13 to 18, right?
[03:13:21] <_petev> how do I do that in hal scope?
[03:13:23] <jmkasunich> so you can set the trigger level to 15 and rising, and should be good to go
[03:13:25] <_petev> 13 is never seen
[03:13:31] <_petev> I think it runs in the loop
[03:13:36] <_petev> ok
[03:13:47] <jmkasunich> well, it goes from something low to 17 or 19, right?
[03:13:59] <jmkasunich> 17 or 18, sorry
[03:14:10] <jmkasunich> so set it just under 17
[03:14:33] <jmkasunich> "how to do in halscope" meaning what buttons to push?
[03:14:42] <jmkasunich> trigger is on the right hand side
[03:14:47] <_petev> I got that
[03:15:40] <_petev> ok, u want the pos cmd/fb ?
[03:16:05] <jmkasunich> home-state, pos-cmd, motor-pos-cmd, and motor-pos-fb
[03:16:53] <_petev> ok, let me setup with those
[03:17:00] <jmkasunich> cradek: you did testing with sim_axis?
[03:17:05] <cradek> yes
[03:17:20] <cradek> http://timeguy.com/cradek-files/emc/stillfine.png
[03:17:30] <jmkasunich> and that has the ddts and sim switches in it
[03:17:40] <cradek> yes
[03:17:53] <jmkasunich> ok, purple is state
[03:18:14] <jmkasunich> green is xvel = ddt of motor-pos-cmd
[03:18:21] <jmkasunich> blue is accel?
[03:18:23] <cradek> yes
[03:18:37] <jmkasunich> oh, green is not xvel
[03:18:45] <jmkasunich> red/pink is xvel
[03:18:51] <jmkasunich> green is what? the switch?
[03:18:53] <cradek> cradek> green=switch, purple=state, cyan=acc, red=vel
[03:18:58] <jmkasunich> ok
[03:19:31] <jmkasunich> so when the switch opens, you get decel to stop, pause, then accel to rapid rate for the offset move
[03:19:55] <_petev> ok, there is an offset between the motor cmd and the joint cmd
[03:20:04] <jmkasunich> having the ddts in there certainly make this easier to read... position is gonna be harder
[03:20:14] <_petev> joint cmd and fb look pretty much the same
[03:20:14] <jmkasunich> joint cmd meaning pos-cmd?
[03:20:21] <_petev> let me zoom way in
[03:20:29] <_petev> these are the pin names
[03:20:38] <_petev> motor-pos-cmd
[03:20:51] <_petev> joint-pos-cmd
[03:21:04] <_petev> I assume that's what you whanted?
[03:21:12] <jmkasunich> right
[03:21:28] <jmkasunich> sorry, the hal name and the source variable name don't quite match
[03:21:44] <jmkasunich> joint-pos-cmd is the hal pin for pos_cmd the variable
[03:22:11] <jmkasunich> (which means that drawing is in error, bummer)
[03:22:45] <_petev> well I think I got the right pins
[03:23:05] <jmkasunich> you do. I would expect joint-pos-cmd to make a step change when going thru step 13
[03:23:06] <_petev> any how, I don't see any diff between motor-pos-cmd and motor-pos-fb
[03:23:09] <jmkasunich> motor-pos-cmd should not
[03:23:16] <_petev> but emc throws a following error
[03:23:17] <jmkasunich> good, that means PID works ;-)
[03:23:28] <_petev> and the drive see excessive accel
[03:23:55] <jmkasunich> what is the actual value of motor-pos-cmd at that point?
[03:24:30] <_petev> according to the cursor, it's -0.034 +/-
[03:24:47] <jmkasunich> and there is no step change of any kind?
[03:25:26] <_petev> very gradual with the level of zoom I'm at, it's changing like -0.034, -0.035, ...
[03:25:36] <jmkasunich> ok
[03:25:43] <_petev> so one thou per msec
[03:25:50] <_petev> or 1 ips
[03:25:52] <jmkasunich> 1 inch per sec
[03:25:53] <jmkasunich> right
[03:25:54] <_petev> not very fast
[03:26:05] <jmkasunich> 60 ipm
[03:26:10] <jmkasunich> not crawling
[03:26:21] <_petev> yeah, but that's cutting speed ;-)
[03:26:30] <_petev> nothing that should cause a problem without belts
[03:26:42] <_petev> I ran much higher tests with the drive
[03:26:50] <jmkasunich> thats not the point
[03:26:53] <_petev> so I know the motor setup is capable of it
[03:26:59] <jmkasunich> look at cradek's pic:
http://timeguy.com/cradek-files/emc/stillfine.png
[03:27:05] <jmkasunich> the bottom trace is velocity
[03:27:05] <_petev> well, it does rule out the motor setup
[03:27:40] <jmkasunich> you see the search move (positive), then it ramps to a stop. pauses, then the latch move (negative), ramps to a stop, pauses, then the final move (also negative, faster)
[03:28:00] <jmkasunich> you need to be able to see the same thing on you machine if you hope to understand whats going on
[03:28:08] <_petev> yes, but not much faster
[03:28:11] <jmkasunich> taking the derivative manually sucks though
[03:28:23] <_petev> I have more of a delta between my latch and rapid speed
[03:28:24] <jmkasunich> not much faster, because thats how its configured
[03:28:38] <_petev> ok, so first
[03:28:53] <_petev> where is emc detecting the FE when it's not visible in hal scope?
[03:29:03] <_petev> is hal scope limiting displayed digits?
[03:29:05] <jmkasunich> ok, lets figure that out
[03:29:18] <jmkasunich> we need another channel
[03:29:22] <_petev> second, why does the drive indicate the excessive accel?
[03:29:24] <_petev> ok
[03:29:35] <jmkasunich> if you have it configured for 4, click on the button at top right of the screen,and change to 8
[03:30:06] <_petev> ok, what do yo wnat to add?
[03:30:08] <jmkasunich> three new channels actually... axis.N.f-error, axis.N.f-error-lim, and axis.N.f-errored
[03:30:42] <jmkasunich> trigger on f-errored going true
[03:31:01] <_petev> are those params?
[03:31:05] <jmkasunich> yes
[03:33:36] <_petev> hmm, the ferror is right when the state goes to 0
[03:33:59] <jmkasunich> the ferror is a red herring then
[03:33:59] <_petev> so it looks like it's after the final move?
[03:34:10] <jmkasunich> of course you get a following error after your amp trips out
[03:35:32] <jmkasunich> Its not completing the final move, the amp is tripping, emc tried to keep going, then says "hey, you're not keeping up"
[03:35:38] <_petev> strange thing is the amp is not set to trip out
[03:35:44] <_petev> it is only limiting right now
[03:35:50] <_petev> so it never faults
[03:35:53] <jmkasunich> I thought you said it was tripping?
[03:36:21] <jmkasunich> limiting is the same thing, if it can't keep up with the commands that EMC is sending out, its gonna ferror
[03:36:48] <_petev> I can set the amp to do different things
[03:36:54] <_petev> emc is getting an FE
[03:37:04] <_petev> the amp is just limiting the accel to 25 ips
[03:37:07] <_petev> ipss
[03:37:13] <_petev> emc is set to 20 ipss
[03:37:26] <_petev> so it shouldn't cause a problem if things are correct
[03:37:37] <jmkasunich> if EMC asks for more than 25ipss, then the amp will limit it, the fb will fall behind the command, and emc will error out
[03:37:52] <jmkasunich> the ferror is a symptom only, happens well after the problem
[03:37:59] <_petev> yes, but if emc is working, it shouldn't ask for more than 20 ipss
[03:38:01] <jmkasunich> so lets forget it and concentrate on the problem
[03:38:13] <_petev> ok, I see FE at 0.003
[03:38:17] <jmkasunich> right - the problem is an apparent excessive accel NOT an ferror
[03:38:23] <jmkasunich> so we need to look at accel
[03:38:35] <_petev> but motor-cmd and fb are the same according to hal scope
[03:38:45] <_petev> so how did FE get to 0.003?
[03:38:50] <jmkasunich> the same within 0.003? even after the point that it trips?
[03:39:09] <_petev> it hasn't tripped yet at that point
[03:39:19] <_petev> I'm just wondering why the numbers don't add up
[03:39:37] <jmkasunich> me too - I'd give a lot to be able to look at the scope with my own two eyes
[03:39:38] <_petev> I haven't seen any diff between cmd/fb in hal scope
[03:39:46] <cradek> cmd and fb are never the same - you would have no pid output without some error
[03:39:46] <jmkasunich> what scale are you at?
[03:39:54] <_petev> ff1
[03:39:59] <jmkasunich> (for cmd and fb)
[03:39:59] <_petev> using the cursor
[03:40:10] <_petev> let me try and magnify
[03:40:12] <jmkasunich> a pox on cursors
[03:41:35] <_petev> well I thought that would be more accurate
[03:41:43] <jmkasunich> what would?
[03:43:08] <_petev> the cursors
[03:43:16] <_petev> even at 5m gain I don't see a diff
[03:43:37] <jmkasunich> but ferror is at 0.003
[03:43:49] <jmkasunich> I assume ferror is getting worse over time
[03:44:31] <jmkasunich> after all, it trips eventually
[03:44:32] <jmkasunich> ferror should also be a bit noisy/fuzzy due to encoder counts, etc
[03:44:40] <jmkasunich> you have 100K counts per inch, right?
[03:44:45] <_petev> yes, let me confirm that without cursor
[03:44:45] <_petev> yes, that's correct
[03:44:45] <_petev> and appears to be ramping slowly
[03:45:08] <_petev> yes
[03:45:27] <_petev> 2500 lines *4 * 5tpi * 2:1
[03:45:46] <_petev> it doesn't look noisy at all
[03:46:11] <_petev> slight ramp, then state goes to 0, and FE drops to 0.001
[03:46:23] <jmkasunich> if you change the ferror scale to 50u/div, you should start to see individual encoder counts
[03:46:51] <jmkasunich> but 50u/div will push 0.003 offscale
[03:46:52] <_petev> let my try and zoom closer
[03:47:45] <_petev> it's not noisy, pretty steady ramp
[03:48:11] <jmkasunich> you can click the offset button (under the vertical scale and pos sliders) and set an offset of 0.003, so the trace will be centered around zero even when you crank the gain up
[03:48:24] <_petev> I can't seem to get enough offset to see it at 50u though
[03:48:34] <_petev> let me try
[03:49:02] <jmkasunich> scale down until you see the trace, then not the level (cursor _might_ be handy there), then click the offset button, enter that value in the dialog
[03:49:18] <jmkasunich> that should shift the trace down, so the value you entered is center-of-screen
[03:49:30] <jmkasunich> then you can scale up lots without it going off-screen
[03:49:54] <_petev> why is the pos slider different than offset?
[03:50:10] <jmkasunich> pos slider moves the trace up and down a max of one screen width
[03:50:16] <jmkasunich> its used to position the trace on the screen
[03:50:27] <jmkasunich> offset can subtract out thousands of divisions of offset
[03:50:38] <jmkasunich> (try that on a real scope..... ;-)
[03:50:46] <_petev> but they seem to be separate offsets
[03:50:58] <_petev> so it's hard to zero the pos once you change it
[03:51:05] <jmkasunich> using pos and offset is a pain
[03:51:43] <_petev> so I tried pos first, and now I have no idea what it is set to
[03:51:49] <jmkasunich> I suggest setting scale low (like 1M/div), offset to zero, use pos to center the trace, then don't touch pos again
[03:52:32] <_petev> anyhow, at 50u, the ramp is very smooth, I can see a nice stair step
[03:52:42] <jmkasunich> it would be nice to have a "set pos to screen midpoint" button
[03:52:44] <_petev> it is building until the time when state goes to 0
[03:53:03] <jmkasunich> "smooth stairstep" ? thats a new one
[03:53:11] <jmkasunich> also very confusing to the reader
[03:53:16] <jmkasunich> if its stairstepping, its not smooth
[03:53:37] <_petev> I mean the stair step is monotonic, it's not noisy
[03:53:42] <jmkasunich> ok
[03:53:56] <_petev> anyhow, the cursor reading may be all wrong
[03:53:57] <jmkasunich> is each step 10u inches?
[03:54:06] <_petev> at this res, it reads 0.001 everywhere
[03:54:14] <_petev> I don't think it shows enough resolution
[03:54:21] <jmkasunich> the cursor has issues ignore it
[03:54:41] <jmkasunich> at 50u/div, 10u encoder steps are 1/5 of a division, you can see that with your eyes
[03:54:56] <_petev> there is about 10 div between the max FE and when state goes to 0
[03:55:03] <jmkasunich> I've been using scopes for 25 years, and scopes with cursors for a much shorter time, I don't use the cursors much
[03:55:23] <jmkasunich> the screen is only 10 div high?
[03:55:37] <_petev> yeah, I have it centered nicely ;-)
[03:55:56] <jmkasunich> if its in the center, how can it be 10 div from anything?
[03:56:30] <_petev> from largest FE to when state goes to 0
[03:56:40] <_petev> this is the range of FE
[03:57:01] <_petev> when state goes to 0, FE drops way down
[03:57:22] <_petev> let me try and zoom the cmd/fb
[03:57:29] <jmkasunich> state goes to zero when it trips, at that point it stops calculating FE, instead it forces command to equal feedback
[03:57:41] <jmkasunich> so ferror will go to zero at the moment of trip
[03:58:35] <_petev> ok, so there are about 10 div of FE before that
[03:59:04] <jmkasunich> 10 div at what scale?
[03:59:14] <_petev> but It doesn't look like the diff between cmd/fb matches that
[03:59:18] <_petev> 50u
[03:59:28] <jmkasunich> so 500u inches at the moment it trips
[03:59:30] <cradek> jmkasunich:
http://timeguy.com/cradek-files/emc/labels.png
[03:59:35] <jmkasunich> does that match up with your config?
[03:59:49] <jmkasunich> cradek: pretty
[03:59:53] <jmkasunich> how'd you do that?
[03:59:59] <cradek> SMOP
[04:00:05] <cradek> should I check it in?
[04:00:05] <_petev> my min FE is 0.001
[04:00:09] <jmkasunich> you da man
[04:00:12] <jmkasunich> of course check it in
[04:00:15] <_petev> and FE is 0.005
[04:00:23] <_petev> so it seems well within that limit
[04:00:28] <jmkasunich> strange
[04:00:44] <_petev> also, FE seems to be delayed one cycle
[04:00:47] <jmkasunich> well, you were also capturing f-error-lim, right?
[04:00:54] <_petev> it is stil increasing when the delta is not
[04:01:00] <_petev> yes
[04:01:01] <jmkasunich> take a look at f-error-lim
[04:01:08] <jmkasunich> it should be between 0.001 and 0.005
[04:01:14] <cradek> I've wanted that since day 1, and it was only 4 lines of code
[04:01:52] <jmkasunich> f-error-lim should reach 0.005 at max speed, and be 0.001 at zero speed
[04:02:03] <jmkasunich> and the error should occur when f-error exceeds f-error-lim
[04:02:08] <tomp> nice labeled traces
[04:02:13] <jmkasunich> the error will be indicated by f-errored going true
[04:02:45] <_petev> it looks like it correlates with ferror lim if I got the scale and offests right
[04:03:03] <cradek> hm, I think it's leaking pango layouts though
[04:03:08] <cradek> whatever tf those are
[04:03:28] <_petev> it looks like it must be on a decel, as the ferror lim is decreasing
[04:03:46] <jmkasunich> interesting
[04:04:01] <jmkasunich> I think its time we got a couple ddt blocks in your hal config
[04:04:15] <jmkasunich> so we can measure velocity and accel directly
[04:04:17] <_petev> yeah, I was thinking that 2 hours ago ;-)
[04:04:25] <jmkasunich> messing around with offsets gets old fast
[04:04:32] <_petev> the limit is way above the ferror
[04:04:35] <jmkasunich> so how come you didn't put them in then?
[04:04:41] <_petev> but one is going up, and the other down
[04:04:55] <_petev> because I started talking with you ;-)
[04:05:15] <jmkasunich> you're saying that at the moment f-errored goes true, the absolute value of f-error is less than f-error-lim?
[04:05:27] <jmkasunich> with both traces having the same scale, offset, and position settings?
[04:05:44] <_petev> no, they cross at that point, but for the bulk of the move, it is well below
[04:06:00] <jmkasunich> well, that means its working like its supposed to
[04:06:05] <_petev> same as far as I can tell, and the cross point correlates with errored
[04:06:25] <_petev> yes, but it seems as if the error is on decel, not accel
[04:06:28] <_petev> that is new info
[04:06:39] <_petev> I assumed it was accel
[04:07:02] <jmkasunich> we need to look at the commanded vel and accel now
[04:07:12] <jmkasunich> we're either exceeding limits, or we're not
[04:07:17] <jmkasunich> if we are, its a bug
[04:07:19] <_petev> so you want the ddt on the PID outputs?
[04:07:25] <jmkasunich> no
[04:07:30] <_petev> on axis output?
[04:07:32] <jmkasunich> what is this fixation with pid output ;-)
[04:07:33] <jmkasunich> yes
[04:07:43] <_petev> I want to see what the drive see
[04:07:56] <_petev> since it is indicating excessive accel
[04:08:12] <jmkasunich> ok, we'll put 3 ddts in
[04:08:27] <_petev> axis (2), pid (1) ?
[04:08:30] <SWPLinux> incidentally, when you recompile so you get cradek's nice labels, if you change TIP_FORMAT in hal/utils/scope_vert.c, you can increase the resolution of the value reading
[04:08:31] <jmkasunich> two on motor-pos-cmd, and one on pid output
[04:08:57] <SWPLinux> I'm sure it would have been more than 4 lines if I had ever done it - nice job cradek
[04:09:27] <_petev> ok, I have to get a memory stick and make some edits
[04:09:40] <cradek> SWPLinux: I think it'll be 5 lines before I get it right
[04:09:45] <SWPLinux> heh :)
[04:09:54] <SWPLinux> don't forget the comment ;)
[04:11:07] <cradek> fixed
[04:11:22] <cradek> * cradek <- not a gtk programmer
[04:11:48] <SWPLinux> me either, that's why I - err - floated to other things when I started that task
[04:12:30] <SWPLinux> oh, and I meant to say scope_disp.c, not scope_vert.c
[04:12:40] <petev> any particular position you want the ddts in thread order?
[04:12:50] <jmkasunich> put them at the end
[04:12:55] <petev> ok
[04:13:08] <jmkasunich> the vel one should be before the accel one, since the latter processes the former's output
[04:13:16] <petev> sure
[04:18:27] <petev> can I use a net command with only one pin?
[04:18:34] <jmkasunich> yes
[04:18:49] <cradek> goodnight
[04:18:56] <petev> gn
[04:18:59] <jmkasunich> leaving us so soon?
[04:19:07] <jmkasunich> (goodnight)
[04:19:18] <SWPLinux> night chris
[04:24:48] <_petev> another strange thing
[04:24:57] <jmkasunich> now what?
[04:25:17] <_petev> when I start emc again after the homing error, axis pops up a dialog that say it cannot home until machine is out of estop and on
[04:25:30] <_petev> so seems like something got left behind from the previous run
[04:25:53] <jmkasunich> I believe following error causes an estop
[04:25:55] <_petev> this is with a complete exit of GUI and re-start
[04:25:57] <jmkasunich> so you will have to reset that
[04:26:07] <SWPLinux> emc should always require that right after startup
[04:26:20] <SWPLinux> it should never start with estop reset afaik
[04:26:37] <jmkasunich> wait, you mean as soon as it comes up it pops the dialog? before you give it any commands?
[04:26:38] <_petev> that is usually the case, but sometimes it has started without needing the soft e-stop reset
[04:26:49] <_petev> but this dialog only happens after the homing failure
[04:27:00] <_petev> jmk, yes
[04:27:07] <SWPLinux> it should always require F1/F2 before homing (or any other motion)
[04:27:18] <_petev> should being the key word
[04:27:24] <_petev> but it doesn't
[04:27:48] <jmkasunich> SWPLinux: yes, we all agree on that.... but if I understand pete, its acting like he pressed home the instant the gui comes onto the screen
[04:27:51] <_petev> so where is state maintained between loads?
[04:27:55] <jmkasunich> (before he does f1 f2)
[04:27:55] <SWPLinux> this is on an RT system, right?
[04:28:05] <_petev> of course
[04:28:18] <_petev> jmk, that's correct
[04:28:28] <_petev> and only when the previous run failed to home
[04:28:41] <_petev> but I exited everything, even made a new hal file this time
[04:28:49] <_petev> so where is that being saved?
[04:28:56] <jmkasunich> and emc is completely shutting down? (are you invoking it from the command line, or from an icon?)
[04:29:08] <_petev> both
[04:29:21] <_petev> first time from command line to check hal file, then icon
[04:29:35] <SWPLinux> (more shoulds) - emc shouldn't start up if the previous run hasn't shut down ...
[04:29:43] <_petev> it didn't copletely load the first time due to hal error in my file
[04:30:07] <jmkasunich> I think you have ghosts
[04:30:07] <_petev> also, axis doesn't even lt you try to home if the machine is not on
[04:30:20] <_petev> so it really seems like an error msg is stored somewhere
[04:30:39] <_petev> it^let
[04:30:51] <jmkasunich> I don't know what the kernel -> user error message transfer path is, so I can't rule that out
[04:31:12] <SWPLinux> isn't it NML or shmem?
[04:31:26] <jmkasunich> when you get the homing error dialog, do you dismiss it (and any that follow it) before shutting down axis?
[04:33:15] <_petev> yes, but I don't get that error on the previous run that fails
[04:33:22] <_petev> I only get an FE dialog
[04:33:25] <_petev> and I dismiss it
[04:33:34] <jmkasunich> I have no clue
[04:33:46] <jmkasunich> its after midnight here, and I can only focus on one problem at a time
[04:34:02] <jmkasunich> do you have the ddts in?
[04:39:02] <petev> u there?
[04:39:07] <jmkasunich> yeah
[04:39:10] <petev> I lost server connection in the shop
[04:39:13] <jmkasunich> oh
[04:39:14] <petev> won't let me back on
[04:39:24] <jmkasunich> fun with wireless
[04:39:23] <petev> anyhow, the PID accel is 3.2K
[04:39:38] <petev> and the cmdAcc is 600K
[04:39:42] <petev> something seems crazy
[04:40:05] <jmkasunich> the commanded velocity is changing by 600 ips in a single sample?
[04:40:28] <petev> let me log out here and see if it frees my nick for the shop
[04:41:21] <jmkasunich> hi!
[04:41:26] <petev> ok, I'm on again in the shop
[04:42:03] <petev> ok, cmdVel is negative
[04:42:18] <petev> goes from 0 to -600
[04:42:29] <petev> then back to 0
[04:42:31] <jmkasunich> in one period?
[04:42:35] <petev> yeah
[04:42:40] <petev> -600 for one sample
[04:42:42] <jmkasunich> ok, that smells like a step change of position
[04:42:50] <petev> right
[04:42:58] <jmkasunich> stepping 0.6 will result in a vel of 600
[04:43:05] <jmkasunich> (with a 1KHz servo rate)
[04:43:34] <petev> so where the hell is that coming from?
[04:43:37] <jmkasunich> that kind of a step should be clearly visible with halscope - scope the ddt input, assuming its there, work your way back
[04:43:58] <petev> let me look at the cmdPos
[04:44:08] <jmkasunich> if its coming out of motor-pos-cmd, how come you didn't see it eariler?
[04:44:56] <petev> the cmdPos drops from 600m to 0 in one step
[04:45:15] <jmkasunich> cmdPos is the signal driven by pin axis.N.motor-pos-cmd?
[04:47:05] <petev_> just lost connection in the shop again
[04:47:21] <SWPLinux> have you tried setting FF1 to 0 yet?
[04:47:26] <petev_> let's make a game plan and I'll get more data and we can continue tomorrow so you can sleep
[04:47:29] <jmkasunich> how much cat5 do you have laying around?
[04:47:40] <petev_> yeah, was thinking about that
[04:47:45] <jmkasunich> that sounds like a good plan, I'm fading
[04:47:49] <petev_> I think there's a spool in the shed
[04:47:57] <jmkasunich> if you can get the emc box online, it would be an enormous help
[04:48:08] <petev_> I ordered a usb wifi today
[04:48:09] <jmkasunich> you can pastebin messages, and imagebin scope screenshots
[04:48:18] <petev_> yeah, that will help
[04:48:30] <petev_> so what we know is there is a step on the decel
[04:48:42] <petev_> and it's coming from the cmdPos from axis
[04:48:58] <jmkasunich> what was that step, with respect to home state?
[04:49:10] <petev_> hang on, I have to go check
[04:49:10] <jmkasunich> when going to state 18? or 100mS later? or ...?
[04:50:06] <SWPLinux> you only need a position step of 0.0006 to get a 0.6 PID output when FF1=1 (at 1 KHz)
[04:50:47] <SWPLinux> (position or feedback, actually)
[04:50:49] <petev_> ok, this is starting to make sense
[04:50:57] <petev_> it is right at the start of state 17
[04:51:03] <SWPLinux> err - nevermind. position command only for FF
[04:51:11] <petev_> that is right after the setting of the position in state 13
[04:51:18] <petev_> so something is glitching
[04:51:40] <jmkasunich> this is motor-pos-cmd, not joint-pos-cmd, that shows the step?
[04:51:54] <petev_> yes, it is the input to the PID
[04:51:56] <jmkasunich> joint-pos-cmd _should_ show the step, motor-pos-cmd should not
[04:52:06] <SWPLinux> I was wondering exactly how the decision is made as to which command position is output - the free planner position or the coordinated planner position
[04:52:08] <petev_> I'm not looking at joint pos
[04:52:25] <jmkasunich> petev_ just makin sure
[04:52:28] <petev_> the hal file says motor-pos, but let me double check
[04:52:43] <petev_> it is correct
[04:52:50] <SWPLinux> it's motor-pos, unless you changed that very recently ;)
[04:52:53] <jmkasunich> SWPLinux: free mode vs. coord mode... aka manual vs auto/mdi when seen from the GUI
[04:53:27] <jmkasunich> ok guys, I'm fading fast
[04:53:45] <SWPLinux> I had noticed the variables like free_tp_enable and free_tp_active
[04:53:46] <jmkasunich> petev_ if you can get a net connection to that box for tommorrow it would be great
[04:53:46] <petev_> anything you want me to look into for tomorrow?
[04:53:54] <jmkasunich> I should be around all evening tomorrow
[04:53:54] <petev_> I'll try
[04:53:56] <petev_> ok
[04:54:35] <jmkasunich> SWPLinux: free_tp_enable is set by any code (such as homing) that has changed free_pos_cmd and now wants the planner to start moving
[04:54:49] <jmkasunich> free_tp_active means it is moving (output pos != input pos)
[04:55:20] <petev_> hah, that was my shop connection
[04:55:26] <petev_> that timeout is too long
[04:56:00] <SWPLinux> ok, but all this homing stuff is done in the same "machine state", so auto/manual can't be the only thing deciding the output
[04:56:22] <SWPLinux> (at least, I'd think that the home sequence would all be in the same machine state)
[04:57:21] <jmkasunich> I don't follow
[04:57:33] <jmkasunich> the entire home sequence (and all jogging) is done in free mode
[04:57:36] <petev_> SWPadnos, I think its in free mode the whole time
[04:57:40] <jmkasunich> the free tp is used for jogging too
[04:57:41] <SWPLinux> nevermind - I'll take a look at get_pos_cmds (or wherever the actual pin is updated)
[04:57:45] <petev_> you can only home in manual mode
[04:58:17] <petev_> so this should probably show in the sim, no?
[04:58:28] <jmkasunich> what should show in the sim?
[04:58:42] <petev_> the pos step
[04:58:59] <jmkasunich> cradek posted a scope image hours ago showing that it doesn't happen in sim
[04:59:17] <petev_> yeah, but it's one sample, and he wasn;t zoomed in
[04:59:19] <jmkasunich> believe me, if we could reproduce this, we wouldn't be talking to you
[04:59:26] <SWPLinux> it could be happening, but you only need a 0.0006 change in command pos to get that 0.6 PID output step
[04:59:26] <petev_> maybe he didn't see it
[04:59:41] <jmkasunich> SWPLinux: you're smoking something I think
[04:59:49] <SWPLinux> heh - not tonight, thank you : )
[05:00:04] <jmkasunich> well, somebody is miscommunicating
[05:00:22] <jmkasunich> pete says there is a 0.6 (not 0.0006) change in the POSITION command
[05:00:25] <jmkasunich> not the PID output
[05:00:35] <jmkasunich> at least I sincerely hope he was talking about the position command
[05:00:38] <petev_> right, the PID output was huge
[05:00:52] <petev_> the pid acc change was 3.2K
[05:01:03] <SWPLinux> hmmm
[05:01:22] <petev_> just a little beyond the limits ;-)
[05:01:42] <SWPLinux> ok, so maybe I should be smoking something tonight ;)
[05:02:01] <jmkasunich> petev_ the code in state 13 only runs once, you could put some rtapi_prints in there...
[05:02:06] <jmkasunich> crap, no you can't
[05:02:16] <jmkasunich> rtapi_print (which uses printk) can't print floats
[05:02:31] <petev_> maybe a conditional and a print?
[05:02:43] <jmkasunich> you can muliply by 1 million and print a long
[05:02:58] <SWPLinux> fake it - manually separate the int and fraction parts, and print them %d.%d ...
[05:03:09] <jmkasunich> just mult by a million
[05:03:15] <SWPLinux> too easy ;)
[05:03:26] <jmkasunich> that covers +/-2000 inches with microinch resolution
[05:03:51] <petev_> I'll type cast it to long and let jmk convert in his head ;-)
[05:04:11] <jmkasunich> (long)(foo*1e6)
[05:04:14] <SWPLinux> only if you print it as a pointer
[05:04:22] <SWPLinux> in octal
[05:04:46] <jmkasunich> I'd print the values of every variable accessed in step 13, at the beginning and end of that step
[05:05:13] <jmkasunich> you might want to do a print or two in step 17 too
[05:05:20] <petev_> I wonder if it would happen on the first move after home with home_offset=0 ?
[05:05:33] <jmkasunich> step 18 lasts too long, you'd print a few hundred lines unless you add conditionals
[05:05:38] <petev_> yeah, I think step 17 would be interesting
[05:05:46] <petev_> as it doens't happen if 17 isn't used
[05:06:19] <jmkasunich> 17 is always used
[05:06:27] <petev_> I don't think so
[05:06:30] <jmkasunich> it may command a zero length move, but it _is_ used
[05:06:41] <petev_> let me check
[05:06:52] <jmkasunich> state 13 unconditionally transferes to 17
[05:07:05] <jmkasunich> line 1583
[05:07:06] <petev_> yes, you're right
[05:07:55] <petev_> I'll try and get more data for tomorrow and maybe get the machine on the net
[05:08:05] <jmkasunich> 17 delays until the previous move (latch move) comes to a stop (free_tp_active == 0), then waits for the delay
[05:08:23] <jmkasunich> don't want to print during that, it will fill up the buffer
[05:08:33] <jmkasunich> print starting at 1654
[05:09:03] <petev_> ok
[05:09:07] <jmkasunich> did you say you never see it in state 17?
[05:09:11] <SWPLinux> 1654 is inside state 17 in my copy of the code
[05:09:26] <jmkasunich> it looks to me like the decel and delay periods should be showing state = 17
[05:09:28] <SWPLinux> duh - nevermindd
[05:09:30] <SWPLinux> -d
[05:10:05] <jmkasunich> petev_: you have a USB memory stick by any chance?
[05:10:25] <petev_> yes
[05:10:30] <jmkasunich> scope screenshot (gimp can do that, its on ubuntu by default) -> USB -> doze box on the net -> imagebin
[05:10:44] <jmkasunich> for tomorrow, I really need to crash now
[05:11:15] <petev_> ok, gn
[05:11:39] <petev_> let me try a capture
[05:12:05] <petev_> how do I use gimp, I have never used it before?
[05:12:34] <SWPLinux> don't bother, just hit print-screen and make up a filename
[05:12:46] <petev_> ok
[05:12:52] <petev_> let me try it
[05:12:52] <jmkasunich> SWPLinux: print-screen prints the whole screen, gimp lets you capture a window
[05:12:57] <SWPLinux> oops - alt-printscreen for just the active window
[05:13:11] <jmkasunich> oh, didn't know about that
[05:13:16] <SWPLinux> no need for gimp
[05:13:35] <jmkasunich> cool
[05:13:42] <SWPLinux> yep :)
[05:14:22] <_petev> ok, this lame industrial kb has no print screen key
[05:14:24] <SWPLinux> hmm. I'd bet that if you can mount an FTP / website like a filesystem (which I'm pretty sure is possible), you could save the screenshot directly to the web
[05:14:29] <SWPLinux> heh
[05:14:50] <SWPLinux> well, there's gimp ;)
[05:14:58] <_petev> are there any hot keys for linux print screen?
[05:15:08] <SWPLinux> it's probably configurable - one sec
[05:15:41] <SWPLinux> yep - System -> Preferences -> Keyboard Shortcuts
[05:16:06] <SWPLinux> click on the "take screenshot of a window" line, and press the new key combo you want to use
[05:16:28] <jmkasunich> if you need to use gimp... its under graphics... once loaded, File->Acquire->Screenshot, then you can pick single window, whole screen, etc
[05:16:42] <jmkasunich> it opens the shot in a window, SaveAs saves it
[05:17:41] <_petev> trying gimp, the kb shortcut is "print", duh
[05:18:05] <SWPLinux> just change it - to something like ctrl-alt-p
[05:18:39] <_petev> crap, it captured with all the gimp stuff on top
[05:19:06] <jmkasunich> I think there is a "delay for X seconds" option
[05:19:26] <jmkasunich> set it for 5, then click in the scope window so it comes into the foreground
[05:20:31] <_petev> ok, got it
[05:21:07] <_petev> what format does gimp save?
[05:21:14] <_petev> png?
[05:21:35] <jmkasunich> it can save all kinds
[05:21:40] <jmkasunich> png is a good choice
[05:21:58] <jmkasunich> gimp is like photoshop or paintshop pro or whatever...
[05:22:21] <SWPLinux> redefining the window capture key may be a better choice, especially if you're memory constrained on that machine
[05:24:12] <_petev> uploading...
[05:24:46] <_petev> hmm, pastebin says more than 10% binary, file ignored
[05:24:57] <SWPLinux> use imagebin for images
[05:25:12] <SWPLinux> http://www.imagebin.org I believe
[05:25:46] <SWPLinux> minus the www, I guess
[05:27:54] <_petev> sheesh, I don't know where it put it, I uploaded, but see nothing
[05:28:28] <SWPLinux> is it <256kB?
[05:28:56] <_petev> yes
[05:29:06] <_petev> is there a delay before the site updates?
[05:29:17] <_petev> nick=petev
[05:31:54] <SWPLinux> I don't see it in the 50 most recent posts
[05:32:11] <_petev> I know, or if you search on my nick
[05:32:19] <_petev> very strange
[05:32:34] <SWPLinux> indeed
[05:33:09] <SWPLinux> hmm. I wonder if they have a problem with the format you saved in
[05:33:33] <SWPLinux> they add the images to a database so they can limit the total number of images and the duration any one is kept
[05:33:36] <_petev> png?
[05:33:49] <SWPLinux> well, it shouldn't be a problem, but one never knows :)
[05:34:35] <_petev> let me log my other machine out of my mailbox and freakin email it
[05:34:42] <SWPLinux> heh
[05:35:04] <SWPLinux> it's about bedtime for me as well - don' t hurry on my account
[05:35:16] <petev_> ok, no problem
[05:35:21] <petev_> thought u might want to see it
[05:35:46] <SWPLinux> I do want to see it, but I'm getting a bit tired. I think I haven't recovered from last week's trip yet
[05:35:56] <_petev> i'm sending it
[05:36:10] <SWPLinux> OK. I'll take a look
[05:39:20] <petev_> u get it?
[05:39:39] <SWPadnos> nope
[05:39:56] <petev_> must be on it's way
[05:40:03] <petev_> it's not in the outbox anymore
[05:40:46] <tomp> 256k limit, it silently trashes big ones
[05:40:57] <SWPadnos> it should arrive in a few minutes
[05:41:01] <petev_> it's only 53k
[05:43:34] <petev_> there yet?
[05:43:34] <SWPadnos> nope
[05:43:34] <petev_> hmm
[05:43:37] <SWPadnos> spadnos sover net ??
[05:43:52] <petev_> spadnos@sover.ne
[05:43:56] <petev_> t
[05:44:17] <SWPadnos> well, smtp isn't an instant transport ...
[05:47:06] <petev_> anything?
[05:47:16] <SWPadnos> nope
[05:47:24] <petev_> wow, something is slow
[05:47:42] <SWPadnos> seems that way
[05:47:56] <petev_> I wish HAL scope could save it's trace info to a file
[05:47:59] <SWPadnos> I think maybe I'll go to bed before 2:00 tonight :)
[05:48:08] <SWPadnos> yeah - that would be an excelelnt thing
[05:48:10] <petev_> then others could zoom, pan, etc.
[05:48:18] <petev_> ok, gn
[05:48:24] <SWPadnos> I think fenn was working on that for a bit, but I'm not sure how far he got
[05:48:45] <petev_> hopefully you will get the email by tomorrow ;-)
[05:48:50] <SWPadnos> heh
[05:49:07] <SWPadnos> good night. I'll take a look then, and maybe we can get to the bottom of the matter in the evening with jmk
[05:49:12] <petev_> ok
[15:44:31] <skunkworks> logger_dev: bookmark
[15:44:30] <skunkworks> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emcdevel/2007-05-03.txt
[16:17:12] <cradek> jepler: did I unwittingly require gtk 2?
[16:20:15] <jepler> cradek: no, I wittingly required it long ago
[16:20:27] <jepler> cradek: but yes, pango is gtk2-only
[16:20:41] <cradek> ok
[16:21:12] <cradek> In my flailing around looking for docs, I saw something that said everything else is obsolete for drawing text
[16:21:31] <jepler> the gtk folks love to label their old APIs obsolete
[18:17:08] <cradek> jepler: that wouldn't be hard to add
[18:18:22] <jepler> accurate velocity in the stat buffer? I would rather have that, than the bad estimate
[18:20:36] <cradek> I'll do the back end
[18:20:55] <cradek> (it'll be in machine units)
[18:24:10] <jepler> so it'll give <dx,dy,dz,da,db,dc> ?
[18:24:39] <cradek> no, dxdydz only
[18:24:44] <cradek> I think
[18:24:51] <jepler> I'm sure that's fine too
[18:25:15] <jepler> but I mean as opposed to just the magnitude of the velocity
[18:26:38] <cradek> oh, no I was doing tangential velocity only, it's very easy
[18:27:02] <cradek> is dx,dy,dz useful for something?
[18:28:14] <cradek> the other thing I'd like to see in halscope is a continuous mode, where the trace goes across the screen as it continuously samples, wiping out the previous trace as it goes
[18:28:20] <cradek> do you know how hard that is?
[18:28:40] <jepler> no, I don't.
[18:29:01] <jepler> magnitude is fine too
[18:29:35] <cradek> ok, (slowly) checking it in
[18:29:41] <cradek> I'll try to figure out how to put it on a hal pin too
[18:30:30] <cradek> done
[18:30:39] <cradek> totally untested!
[18:30:45] <jepler> hooray untested
[18:30:47] <jepler> did it compile?
[18:30:54] <cradek> ummmm
[18:31:02] <cradek> let me check that :-)
[18:31:10] <cradek> 300 MHz you know
[18:31:46] <cradek> yes it compiles
[18:50:02] <cradek> at first glance emcmotStatus->current_vel seems to work right (I made it a hal param too)
[18:52:24] <jepler> what about in the free planner?
[18:52:44] <cradek> hmm good question
[18:53:56] <jepler> well I know the answer
[18:54:03] <jepler> it shows 0
[18:54:07] <cradek> I suppose I can add it
[18:54:10] <cradek> yeah I knew that much
[19:03:28] <jepler> cradek: with that change the DRO "Vel:" is much better -- the estimate doesn't "wobble around"
[19:03:34] <cradek> nice
[19:03:45] <cradek> does it change when you change displayed units?
[19:05:15] <jepler> yes it shows 1524 (mm/sec) instead of 60 (in/sec) on the long G1s in the splash gcode
[19:06:33] <jepler> er, /min
[19:06:52] <cradek> does it always go to 0 when you stop?
[19:07:10] <jepler> I saw it stick at nonzero when I hit F1 (I think)
[19:08:35] <cradek> this change I'm working on may fix that
[19:09:26] <jepler> so far it's consistently dropped to 0 at a normal exit (M2)
[19:12:31] <cradek> free mode done
[19:19:22] <cradek> I bet teleop mode is not right
[19:22:50] <cradek> bbl
[19:23:38] <jepler> looks like axis won't show velocity when it's showing joint positions
[19:25:52] <SWPadnos> hmmm. will this work for non-trivkins machines?
[19:27:26] <cradek> SWPadnos: free mode won't be right I guess
[19:27:43] <cradek> coord will I think
[19:28:01] <SWPadnos> I haven't looked at the patches - is the vel based on the cartesian motions (pre-kins)?
[19:28:16] <cradek> yes when in coordinated mode
[19:28:29] <SWPadnos> ok, then it shouldn't matter (for coord mode)
[19:31:05] <jepler> cradek: I still don't get a nonzero velocity when I am jogging in cartesian mode, whether on stepper-xyza or scara
[19:38:17] <jmk2> cradek, jepler: re velocity during jogs..
[19:38:36] <jmk2> if you want that, you'll need to calc it in joint space, not cartesean space
[19:38:46] <jmk2> cartesean space doesn't exist in free mode
[19:40:13] <jmk2> * jmk2 vanishes
[19:41:17] <skunkworks> cradek: Jepler: - works cool. Now 15ipm is 15ipm :)
[19:41:35] <skunkworks> had to run the installed version just to be sure what I was seeing
[19:54:28] <cradek> I did calc it in joint space ... worked for me
[19:54:40] <cradek> oh
[19:54:54] <cradek> oh in cartesian mode with nontrivkins you mean?
[19:55:08] <cradek> err do we call that world mode?
[19:56:52] <cradek> that jmk appearance was odd...
[19:57:24] <SWPadnos> he probably saw the commits, then popped on from his work laptop
[19:57:45] <cradek> I think he sits at work reloading the irc logs all day (hi jmk!)
[19:57:47] <cradek> haha
[19:57:55] <SWPadnos> heh
[19:58:05] <alex_joni> * alex_joni thinks so too
[19:58:12] <alex_joni> lots of people reading the logs
[19:58:14] <alex_joni> hi people
[19:58:18] <cradek> hi alex!
[19:58:33] <alex_joni> cradek: now that my cover is busted.. don
[19:58:36] <alex_joni> cradek: now that my cover is busted.. don't hold back
[19:59:06] <cradek> wow something happened to the warm weather
[20:00:49] <alex_joni> did it vanish?
[20:00:54] <cradek> yes
[20:01:47] <petev> cradek, did you get my emails(2) from last night?
[20:02:16] <cradek> I think so
[20:03:16] <petev> I caught a step in the pos cmd at the end/start of homing states 13/17
[20:03:37] <cradek> can you reproduce it on one of the sim configs yet?
[20:03:41] <petev> I don't see it on sim when run on the same model MB
[20:03:50] <petev> I'm going to try sim on the machine itself
[20:03:54] <cradek> MB?
[20:03:58] <petev> mother board
[20:04:02] <cradek> oh
[20:04:07] <petev> I setup another emc for testing
[20:05:04] <petev> it's very strange that it happens right when all the offsets are adjusted
[20:05:26] <petev> the joint-pos-cmd step looks fine, but the one on motor-pos-cmd is not right
[20:05:52] <cradek> strange indeed
[20:20:51] <cradek> hmm, it still doesn't work, wonder what I'm doing wrong
[20:32:11] <cradek> can one of you tell me what obvious thing I'm missing for teleop mode please?
[20:32:33] <alex_joni> cradek: in teleop there is a vel prescription
[20:32:41] <alex_joni> why not use that directly?
[20:32:56] <cradek> because it's not the "current" velocity
[20:33:39] <cradek> you mean the requested teleop vector right?
[20:34:05] <alex_joni> yeah
[20:34:27] <cradek> I want it to show the result of all the limits like accel
[20:34:30] <alex_joni> that doesn't take into account accel phases and all
[20:34:32] <alex_joni> right
[20:44:57] <cradek> well it looks right to me, so I'm leaving it :-)
[20:59:01] <alex_joni> cradek: it also looks right from where I'm looking
[20:59:38] <cradek> alex_joni: I'm convinced it is right - the only unfortunate glitch is that it doesn't work
[20:59:54] <alex_joni> cradek: details, details
[21:00:17] <cradek> I made sure that COORD_FLAG is false, so it's not the else that keeps it from running
[21:38:15] <_petev> cradek, u still there?
[21:38:19] <cradek> yes
[21:38:30] <_petev> I have loosened up some of the amp limits to get more data
[21:38:44] <_petev> I think the error has something to do with starting position
[21:38:58] <_petev> I can see a negative step to 0 in pos-cmd
[21:39:20] <_petev> then I see a nice 2nd or 3rd order s ramp
[21:39:40] <cradek> so it's wrong for one servo cycle?
[21:39:44] <_petev> so it's like the machine wasn't where emc thought it was before the free mode move started
[21:39:56] <_petev> yes, one cycle step in the output
[21:40:11] <_petev> then a nice ramp as you would expect
[21:40:42] <_petev> the size of the step appears to be somehow related to the switch hysteresis (how long I hold it pressed for)
[21:40:46] <cradek> cool it sounds like you're close to finding it
[21:41:01] <_petev> I don't know about that, but I did get some new info
[21:41:24] <_petev> that code seems overly complicated to me, but it's probably straight forward to jmk
[21:42:28] <_petev> I think I should get this one on the usb stick for jmk to see
[21:43:50] <cradek> yes getting him pictures may be the fastest way to a solution :-)
[21:48:04] <cradek> wtf, now I don't get velocity readout while jogging a trivkins either
[21:51:59] <cradek> AHA
[21:52:11] <cradek> motion.current-vel (the hal pin) does work in world mode
[21:52:19] <cradek> it's somewhere later, in task or AXIS
[21:52:25] <_petev> cradek, how are err msgs communicated to the GUI?
[21:52:30] <cradek> I knew that code was right!
[21:52:35] <cradek> _petev: the error nml channel
[21:52:50] <_petev> is there any storage across re-starts of EMC?
[21:53:13] <cradek> not that I know of
[21:53:35] <_petev> after I get a homing error, I will get an err dialog the next time I run emc that says it can't home until the machine is out of estop and on
[21:53:48] <_petev> this is right on startup without even trying to home
[21:54:01] <_petev> so something seems to be left behind from the previous run
[21:54:12] <cradek> bizarre
[21:54:15] <_petev> this happens with a full exit of the GUI and a re-start
[21:54:31] <cradek> * cradek loans _petev a rubber chicken to wave over the monitor
[21:54:41] <_petev> and the EMC related X apps are still unstable, but none of the other X apps seem to have a problem
[21:54:43] <SWPadnos> it's possible that some buffer is left around for a bit, and goes undetected by the runscript (which tries to find a running instance)
[21:54:57] <_petev> NML buffer?
[21:54:59] <SWPadnos> but I don't have any idea how that could be
[21:55:25] <SWPadnos> sure - similar to the problems people have in Windows when they exit a program and the window goes away, but the process is still there
[21:55:44] <_petev> hmm
[21:55:46] <SWPadnos> but again, I have no idea of what mechanism might allow that to happen on Linux
[21:56:04] <_petev> I have no idea how the NML stuff is implemented either
[21:56:23] <_petev> I thought on a local connection, it was a direct buffer to buffer copy
[21:56:27] <cradek> SWPadnos: yay, thanks for volunteering to debug it!
[21:56:39] <_petev> I wonder if all the RT stuff is not exiting
[21:56:53] <_petev> EMC doesn't complain about it on the re-start
[21:57:01] <SWPadnos> sure - as soon as I get my big machine working RT again :)
[22:15:05] <_petev> Ok, I think the bug count is rising
[22:15:21] <_petev> I just took the home offsets out to see how far things would get
[22:15:36] <_petev> so the home position is 0 as is the min limit for the axis
[22:15:51] <_petev> due to PID noise the axis read -0.001
[22:16:02] <_petev> so emc says a soft limit has been exceeded
[22:16:21] <_petev> the machine remains on, but you can't move the axis in any mode, even with limits overriden
[22:16:25] <SWPadnos> hmmm. I think that's correct but annoying behavior
[22:16:36] <_petev> so what the hell are you supposed to do?
[22:16:38] <SWPadnos> except that last line
[22:16:52] <_petev> well that's how it is working
[22:16:54] <SWPadnos> (I wrote that before the overriden limits comment)
[22:16:58] <_petev> ok
[22:19:39] <_petev> even the HAL jog inputs don't move it
[22:20:15] <SWPadnos> hmmm. I don't have enough actual machine operating experience to have any useful suggestions
[22:20:45] <SWPadnos> I'm assuming that a coordinate change wouldn't affect that situation
[22:20:52] <SWPadnos> (like the touch-off funciton in AXIS)
[22:21:05] <_petev> I tired MDI, and it at least complained about the soft limit
[22:21:22] <_petev> using manual mode silently ignores you
[22:30:11] <_petev> well I can make moves at full rapid speeds no problem once the machine is homed
[22:36:28] <_petev> well something is strange with the err channel. The min sw err msg seems to be stuck in there and just keeps coming up when emc is started and there is no way to get rid of it. I'm going to try tkemc and see if there is any difference
[22:37:33] <_petev> tkemc had no problem and did not display the err msg, so it must be something in the axis nml interface
[23:51:13] <SWPLinux> hmmm. it looks like switching to perspective mode in the AXIS preview uses the "original" viewport size to calculate scaling
[23:51:12] <SWPLinux> or something like that
[23:52:11] <cradek> ?
[23:52:45] <SWPLinux> you know how when you go from an orthogonal mode to perspective, by middle-dragging the preview, the scale changes
[23:53:30] <cradek> yes
[23:53:35] <cradek> it's a bit craptacular
[23:53:40] <SWPLinux> if I do that with axis at its minimum size, I get a preview plot that's N pixels wide
[23:53:59] <SWPLinux> I get what looks like the same N pixels wide when I maximize the window to 1920x1100-ish
[23:54:22] <SWPLinux> the P and Z toolbar buttons work fine, it's the middle-drag perspective change that does this
[23:54:26] <cradek> I think it only auto scales/centers when you use the icons or switch the view to "P" with the keyboard
[23:55:08] <cradek> please feel free to fix, I'm not sure what it should do exactly
[23:55:29] <SWPLinux> I'm reasonably sure of what I'd like (sort of), but I have no idea how to fix it :(
[23:55:59] <SWPLinux> I think I looked through that code some months ago, and the perspective scaling is done in a library call, and I haven't delved into the libraryyet
