#linuxcnc-devel Logs

Oct 17 2017

11:21 AM skunkworks: I think I am going blind
11:23 AM skunkworks: http://electronicsam.com/images/KandT/testing/limit3/
11:23 AM skunkworks: in the spread sheet are 2 datasets - the first one is a run away - the second set is correct behavior
11:23 AM skunkworks: I logged a bunch of internal variables. (anything starting with int)
11:23 AM skunkworks: I - for the life of me cannot see what is going on.
11:25 AM cradek: https://github.com/LinuxCNC/linuxcnc/issues/240 ?
11:25 AM skunkworks: yes
11:27 AM skunkworks: in the first dataset - you can see it shoots right by the in value and keeps right on going
11:37 AM skunkworks: changing if ( min_v < -maxv ) to if ( min_v <= -maxv ) changes the direction of runaway. (so it doesn't seem to be trying to get to the input value
11:37 AM skunkworks: sorry wrong
11:38 AM skunkworks: if ( in_v > data.old_v ) to if ( in_v >= data.old_v )
11:40 AM cradek: it's not clear to me how limit3 should work
11:40 AM cradek: especially now that the constraints are pins
11:41 AM cradek: I wonder does limit2 even work right?
11:41 AM skunkworks: well - it works as in it doesn't run away.
11:41 AM skunkworks: atleast it hasn't for me
11:46 AM skunkworks: I think there was some discussion a while back - don't expect limit3 to work if you change the constraint pins.
11:46 AM skunkworks: I could try an older version of limit3..
11:47 AM skunkworks: before the change to pins
11:47 AM cradek: does it always involve linking and unlinking the input?
11:52 AM seb_kuzminsky: cradek: unlinking is how the OP found the bug, but it's not required
11:52 AM seb_kuzminsky: see the branch named "2.7-limit3-issue-240"
11:52 AM cradek: I think it's possible for it to work if you don't change the constraints while it's running
11:53 AM seb_kuzminsky: it's enough to present a certain pattern of values on the input pin
11:53 AM cradek: ok good (?)
11:54 AM skunkworks: I have not changed the constraint pins. Only unhooking the input. It bit me when I was just changing the output from whatever to 0 in one servo cycle.
11:54 AM skunkworks: (step change)
11:59 AM skunkworks: I am not seeing how it gets into the state of runaway
12:02 PM seb_kuzminsky: skunkworks: here's how i repro'd it: https://github.com/LinuxCNC/linuxcnc/commit/6d11b7140dd8375d73b0bdca2c0211a7084e16cc#diff-ea363456d43a9d750132eeb3a573c882
12:03 PM skunkworks: I can get it to do it pretty easily using the example in the bug report
12:03 PM skunkworks: that is the data in the spreadsheet shows
12:04 PM skunkworks: http://electronicsam.com/images/KandT/testing/limit3/limit3logging.ods
12:04 PM skunkworks: the first dataset has the run-away
12:06 PM seb_kuzminsky: if you have a way to show a limit3 bug that's not covered by that branch, could you add it? as another test in tests/limit3/
01:00 PM skunkworks: the parameter version does the same thing
04:16 PM andypugh: blocks?
04:40 PM cradek: I think that is what the hal framework was called when it was still separate from emc
04:53 PM jepler: originally, a large number of components were implemented within a single HAL component, called "blocks".
04:53 PM jepler: after implementing comp, I split each of the blocks to separate components, mostly implemented in comp
04:54 PM cradek: that's even more true than what I said
04:54 PM jepler: e.g., git show v2.0.0:src/hal/components/blocks.c
04:55 PM jepler: so this conversion is a likely time for programming errors to have been introduced inadvertently
04:55 PM jepler: (not sure if that's what anybody was suggesting)
07:56 PM skunkworks: blocks.c looks pretty identical to limit3 code