Back
[00:12:56] <CIA-2> EMC: 03eric-johnson 07master * r070c93935bea 10/src/ (emc/usr_intf/emcrsh.cc hal/utils/halrmt.c): Make socket address reusable
[06:24:00] <alex_joni> micges_work: I'm sorry about what happened ...
[06:24:52] <micges_work> thanks
[10:38:39] <micges> micges is now known as micges_cutter
[10:38:47] <micges_cutter> alex_joni: around?
[10:39:36] <micges_cutter> got some problems with emc with mesa stepgens
[10:41:15] <micges_cutter> when I hit estop when jogging at 9000mm/min, I can't enable machine becouse joint pos cmd is 1.5 mm further that motor pos cmd(fb)
[10:44:41] <alex_joni> sounds like stepgen pos doesn't get reset properly
[10:45:01] <alex_joni> is the stepgen.enable conected to axis.xx.enable ?
[10:45:37] <micges_cutter> yes
[10:45:51] <alex_joni> hmmm, then I'm not sure what to suggest
[10:45:55] <alex_joni> what version/firmware ?
[10:46:02] <micges_cutter> latest
[10:46:30] <alex_joni> did it work with older versions?
[10:47:01] <micges_cutter> I don't know
[10:47:08] <micges_cutter> letme check
[10:51:19] <alex_joni> can you do a halcmd show after the estop?
[10:51:23] <alex_joni> before re-enabling
[10:51:27] <alex_joni> filter by that stepgen
[10:51:37] <alex_joni> (I want to see pos-cmd, pos-fb, enable, etc)
[10:52:51] <micges_cutter> after each stepgen enable pos cmd and fb is rising about 0.6 mm
[10:53:25] <micges_cutter> ok
[10:55:53] <micges_cutter> http://pastebin.com/BhbhDZN9
[10:58:35] <micges_cutter> seems to me that stepgen must change pos-fb after enable
[10:59:49] <micges_cutter> after first enable hit:
http://pastebin.com/pfLkFxrS
[10:59:58] <SWPadnos> micges_cutter, what happens if you manually turn a motor while EMC2 is in Machine on" state? (F2)
[11:00:28] <SWPadnos> err, nevermind, nothing will happen
[11:00:32] <SWPadnos> (silly me)
[11:00:39] <micges_cutter> :)
[11:00:50] <SWPadnos> you could simulate that, but it's a pain
[11:01:19] <micges_cutter> have only 2h to dig it :|
[11:01:38] <SWPadnos> motion should update its command position to whatever the feedback position is, as long as it's not in the "machine on" state
[11:01:53] <micges_cutter> and it is
[11:02:06] <micges_cutter> wrong pos must be from stepgen
[11:02:24] <SWPadnos> halscope should tell you that
[11:02:46] <SWPadnos> high speed motion -> estop, with the signals alex suggested
[11:03:26] <SWPadnos> one screenshot triggered on enable going low, another when enable goes high
[11:03:33] <SWPadnos> (stepgen enable)
[11:13:10] <micges_cutter> I don't know how to use trigger (will learn later)
[11:13:19] <micges_cutter> but I've got this
[11:14:05] <alex_joni> it would be nice if seb would be around...
[11:14:07] <micges_cutter> after enable axis.1.pos-fb is rising (pos-cmd is not rising) and after 4ms ferror is triggered
[11:14:07] <JT-Dev> anyone tried to use a classicladder compare with two floats? I doesn't seem to work for me
[11:14:32] <alex_joni> micges_cutter: sounds like the stepgen still continues
[11:14:57] <micges_cutter> I think so
[11:16:42] <JT-Dev> it will see a change from 1 to .9 but in the watch window it just shows up as 1 and 0 but won't compare properly when the two floats are say .9 and .8
[11:17:48] <micges_cutter> on older checkout (~4months) there is also same happened
[11:18:21] <JT-Dev> with classicladder?
[11:18:36] <SWPadnos> I wonder if the stepgen rate setting gets set to 0 on disable
[11:18:42] <SWPadnos> or on enable, for that matter
[11:22:34] <SWPadnos> yep, it sure does
[11:22:39] <micges_cutter> it's negative here and it's rising about ~40k on first enable
[11:23:20] <micges_cutter> it's not set to 0
[11:23:47] <alex_joni> SWPadnos: where did you see if it's set?
[11:24:52] <SWPadnos> stepgen.c line 284
[11:25:01] <SWPadnos> hostmot2 stepgen, of course
[11:25:34] <alex_joni> step_rate_reg[i] = 0 ?
[11:25:46] <SWPadnos> yep, I'd assume that sets the rate for that stepgen to 0
[11:27:19] <SWPadnos> ah. but what it doesn't do is set old_position_cmd to position_cmd while it's disabled
[11:27:32] <alex_joni> right, was just looking at that
[11:28:29] <SWPadnos> maybe line 107 should be duplicated as line 285.5
[11:28:57] <alex_joni> hmm.. but hm2_stepgen_instance_position_control() should get called
[11:29:13] <SWPadnos> oh. interesting. velocity feedback needs to be set to 0 as well
[11:29:34] <SWPadnos> parts of it are needed, yes
[11:29:54] <SWPadnos> but explicitly setting things to zero is more obvious code
[11:30:28] <alex_joni> ah, it doesn't get called
[11:30:32] <SWPadnos> no
[11:30:45] <micges_cutter> vel-fb is set high when disabled
[11:30:48] <SWPadnos> set rate to 0 or call the calculating routine(s)
[11:30:53] <alex_joni> it only gets called from instance_prepare_tram_write
[11:31:02] <alex_joni> which for disabled stepgens doesn't get called
[11:31:06] <SWPadnos> right, which only gets called if enabled
[11:31:10] <SWPadnos> right
[11:31:11] <alex_joni> right
[11:31:15] <SWPadnos> right
[11:31:19] <alex_joni> micges_cutter: simple fix
[11:31:24] <SWPadnos> bloody well right
[11:31:40] <alex_joni> micges_cutter: look for src/hal/drivers/mesa-hostmot2/stepgen.c
[11:32:06] <SWPadnos> I'd add the code at line 285, don't cause stepgen_instance_prepare_tram_write to be called
[11:32:07] <alex_joni> hm2_stepgen_prepare_tram_write() (line 285 or so)
[11:32:14] <alex_joni> add 2 lines:
[11:32:52] <alex_joni> s->old_position_cmd = (*s->hal.pin.position_cmd);
[11:33:01] <SWPadnos> now that you said "simple fix", I'm worried :)
[11:33:24] <alex_joni> simple fix to try...
[11:34:01] <SWPadnos> also (*s->hal.pin.velocity_fb) = 0;
[11:34:06] <micges_cutter> ok
[11:34:09] <SWPadnos> hmmm
[11:34:14] <alex_joni> hmmm indeed
[11:34:21] <SWPadnos> why the parens where they are?
[11:34:32] <alex_joni> clarity :D
[11:34:38] <SWPadnos> well, no, not really
[11:34:47] <SWPadnos> maybe it's my lack of caffeiene
[11:35:09] <SWPadnos> (I copied from line 109, I didn't make that stuff up ;) )
[11:35:14] <alex_joni> maybe even set: (*s->hal.pin.dbg_ff_vel) = 0;
[11:35:28] <alex_joni> and dbg_vel_error
[11:35:52] <SWPadnos> those are a PITA though, isn't there a debug parameter that controls when they're available?
[11:36:01] <SWPadnos> (or are the vars there anyway?)
[11:36:07] <alex_joni> I think they are there anyway
[11:36:11] <SWPadnos> ok
[11:36:17] <SWPadnos> just no HAL pins/params created
[11:36:34] <alex_joni> at least the stepgen_instance_position_contrl() writes to the anytime
[11:36:43] <alex_joni> I think the HAL pins/params are always too
[11:36:49] <SWPadnos> ok
[11:36:53] <micges_cutter> there is no 's' in that scope
[11:37:02] <SWPadnos> oh, right
[11:37:31] <alex_joni> hm2_stepgen_instance_t *s = &hm2->stepgen.instance[i];
[11:37:37] <micges_cutter> I know
[11:37:42] <SWPadnos> replace s with hm2->stepgen.instance[i]
[11:37:56] <SWPadnos> well then, why complain? :)
[11:38:01] <alex_joni> indeed
[11:38:23] <micges_cutter> sorry 'I know' was not purposed here ;)
[11:39:11] <alex_joni> micges_cutter: np
[11:39:23] <alex_joni> it would be best to test this with the machine off ;)
[11:40:41] <SWPadnos> heh
[11:41:18] <micges_cutter> hmm emc hang's up :|
[11:41:33] <SWPadnos> hmm
[11:41:45] <SWPadnos> that's not right
[11:42:26] <alex_joni> try keeping only the old_postion_cmd = ... line
[11:42:27] <SWPadnos> can you pastebin the function hm2_stepgen_prepare_tram_write?
[11:42:32] <micges_cutter> yep restore old code and works
[11:42:38] <SWPadnos> as modified
[11:43:39] <micges_cutter> http://pastebin.com/ZnKYNtyv
[11:44:06] <SWPadnos> that can't be it
[11:44:10] <SWPadnos> there's still an "s" there
[11:45:46] <micges_cutter> ah yes
[11:46:59] <SWPadnos> maybe this:
http://pastebin.com/SUDjXfi5
[11:48:50] <micges_cutter> this will compile but not fixing issue:
http://pastebin.com/GcrSUPGA
[11:49:07] <SWPadnos> no *
[11:49:17] <SWPadnos> use this
http://pastebin.com/SUDjXfi5
[13:01:03] <SWPadnos> alex_joni, I didn't know what the number was at the time. I've since seen the bug report :)
[15:13:25] <JT-Work_> JT-Work_ is now known as JT-Work
[19:15:13] <robh__> Hi, G83 does not seem to obay the R point in the cycle, it retracts to the Z and not the R on the pecks, seems line 162 in interp_cycles.cc should be - cycle_traverse(block, plane, x, y, r);
[21:39:43] <micges> robh__: pastebin.com your code please
[21:50:19] <SWPLinux_> SWPLinux_ is now known as SWPLinux
[22:27:25] <robh__> micges, still about?
[22:28:16] <micges> I'm gonna sleep soon
[22:28:27] <micges> paste link and I will look tomorrow
[22:29:34] <robh__> http://pastebin.com/42X62NMJ here just shows the G83 change, i tested with G code and it gave proper motion as exspected, dont know if this is correct change for it or not
[22:29:55] <robh__> yes i will sleep soon too, 11:30pm here
[22:39:14] <micges> good night all
[22:50:58] <alex_joni> good night all
[22:51:35] <alex_joni> robh__: after changing g-code things, it's really usefull to run the runtests and see if anything is wrong