Back
[14:00:21] <Tom_itx> storms must have knocked it off
[14:00:54] <skunkworks> jepler, but that isn't there anymore?
[14:08:41] <jepler> that one's there at the moment. it's the 4.1.0-0.bpo.2 that they removed. they'll eventually remove the 4.4 one as well, when they go to kernel 4.5 or later in debian testing.
[14:08:45] <jepler> https://packages.debian.org/search?keywords=linux-image-rt-amd64
[14:08:53] <jepler> so it is not good to suggest in general to users :-/
[14:59:25] <seb_kuzminsky> we could grab one and stick it in the deb archive at wlo
[15:10:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 0786060 06linuxcnc 10lib/hallib/sim_lib.tcl sim_lib.tcl improve compatibility with twopass JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0786060
[15:10:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 4670057 06linuxcnc 10(44 files in 6 dirs) iocontrol-removed sim config: move to orphans JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4670057
[15:10:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 e339b4b 06linuxcnc 10(35 files in 10 dirs) configs/sim/axis/*.ini cleanups JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e339b4b
[15:10:10] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 4d34a39 06linuxcnc 10(70 files in 29 dirs) configs/sim/axis/* some subdirs cleanup JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4d34a39
[15:10:13] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 0126b46 06linuxcnc 10src/emc/ini/initraj.cc 10src/emc/usr_intf/axis/scripts/axis.py initraj.cc: report reason for failure JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0126b46
[15:10:17] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 bedae33 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py message/exit if no [TRAJ]COORDINATES JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bedae33
[15:10:21] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 5417b04 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py: fail if no [RS274NGC]PARAMETER_FILE JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5417b04
[16:43:15] <jepler> rebooted with non-rt kernel, virtualbox packages removed, no permanent harm done
[16:49:34] <skunkworks_> zlog
[17:40:38] <jepler> skunkworks_: what gcode did you run to get the following error on ethernet with my branch?
[17:42:04] <skunkworks_> jepler, the splash screen does it. (it is the shuttles of the config are so high)
[17:42:29] <skunkworks_> if you jog the axis faster than a few hundred inches per minute - it does it too
[17:45:16] <jepler> OK, I'm not seeing that but I've modified my branch substantially compared to what you tested
[17:45:23] <jepler> I should go back to what you tested and see if I error there
[17:45:56] <jepler> oh yeah it ferrors right away there
[18:00:04] <JT-JA13> yea moving things in JA
[18:15:02] <PCW> skunkworks_: assuming everything else is correct, you can get the lowest following error with tuning:
[18:15:04] <PCW> P= 1000 (at 1 ms servo thread) and FF2= seconds from position read to velocity write
[18:15:06] <PCW> P= 1/servo thread period is the same as what the driver tries to do (correct error in next period)
[18:16:47] <jepler> hm I seem to have written myself a 'fail after 2^16 cycles' bug too
[18:18:40] <skunkworks_> PCW, sure - I was just running the config you had created
[18:18:46] <PCW> it runs for a minute, ship-it!
[18:18:57] <jepler> hm2/hm2_7i92.0: error finishing read! iter=65541)
[18:19:04] <jepler> it's always an error on iter=65541
[18:19:07] <skunkworks_> it worked fine on master - not on jeplers branch
[18:19:23] <skunkworks_> (so it was jeplers fault) ;)
[18:19:32] <jepler> yeah I think the version skunkworks_ tested had a bug that meant it was always one one read response packet behind
[18:20:33] <PCW> Yeah almost anything will work for P, but if you are fussy you can get the errors < 5 u inch or so or so
[18:21:22] <PCW> 5 more than 2^16?
[18:22:37] <jepler> PCW: yes
[18:22:57] <jepler> it's because things go wrong starting at 2^16 and the error counter takes 5 increments to reach its limit
[18:23:03] <jepler> and I think I just spotted it, hopefully
[18:24:37] <jepler> yup that must have been it
[18:26:09] <jepler> .. because I'm not doing anything at the other layers of linuxcnc, a .1% packet loss still causes following errors very readily
[18:27:08] <PCW> One thing ive though would be a good idea is some sanity checking of the RX packet (like always reading the HM2 cookie as the last read)
[18:27:09] <PCW> though I guess if there is RX packet sequence checking that does pretty much the same thing
[18:29:50] <PCW> I would think ( perhaps naively ) that is the following error was wider than velocity*servo_period that a single packet loss would not cause a following error
[18:30:00] <PCW> that if the
[18:31:51] <jepler> https://emergent.unpythonic.net/files/sandbox/ferror-after-lost-packet.png
[18:32:41] <jepler> the offset between command and fb is because both were in "ac couple" mode so their offsets differ
[18:34:06] <jepler> by "merely" opening up ferror by a factor of 10, no more ferrors
[18:34:22] <PCW> what velocity?
[18:35:24] <jepler> I think 1200in/min
[18:35:55] <jepler> when a packet goes astray, position-fb ends up being held for 1ms, which gives a PID / following error of +-.02
[18:36:06] <PCW> right
[18:36:47] <jepler> so opening FERROR up from .005 to .05 suffices
[18:37:10] <andypugh> F-error may only need to be a big as limit to hard stop dimension. :-)
[18:38:30] <jepler> when 2 packets in a row go missing, ferror goes up to +-.04
[18:38:39] <jepler> so ferror of 0.5 would give you "fail after 3 lost packets in a row"
[18:39:13] <jepler> er, 0.05
[18:40:10] <PCW> of course for velocity mode and the stepgen, the actual error is much less (and accel dependent)
[18:40:26] <jepler> yes
[18:41:40] <jepler> my captures have tended to be in the cruise phase of a long rapid move
[18:41:47] <PCW> you sort of want a "dont check ferror" input to motion if it were not such a effective foot gun
[18:42:10] <andypugh> seb_kuzminsky: Where are we with
https://github.com/LinuxCNC/linuxcnc/pull/55 ?
[18:43:19] <andypugh> They are talking CNC Glue-Guns on the other channel.
[18:44:43] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss e98788c 06linuxcnc 10docs/man/man9/hm2_eth.9 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: detect lost reads and writes * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e98788c
[18:44:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 0bc365a 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: fix array-vs-pointer thinko * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0bc365a
[18:44:44] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 546f823 06linuxcnc 10src/hal/drivers/mesa-hostmot2/lbp16.h hm2_eth: make macros more robust * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=546f823
[18:44:47] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 3fd1907 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h hm2_eth: read-request-packet is not just a sequence of lbp16_cmd_addr * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3fd1907
[18:44:51] <KGB-linuxcnc> 03Jeff Epler 05jepler/master/eth-packet-loss 9efa581 06linuxcnc 10src/hal/drivers/mesa-hostmot2/hm2_eth.c 10src/hal/drivers/mesa-hostmot2/hm2_eth.h 10src/hal/drivers/mesa-hostmot2/lbp16.h hm2_eth: detect late read packets * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=9efa581
[18:45:14] <jepler> skunkworks_: if you feel like it, I think this branch is worth testing again. let me know.
[18:45:17] <jepler> afk for dinner
[19:14:53] <seb_kuzminsky> andypugh: i couldn't get it to build on RTAI or uspace, and the OP never responded to my questions about his build environment
[19:20:15] <skunkworks_> jepler, I will this weekend
[19:20:16] <skunkworks_> thanks
[19:22:51] <andypugh> seb_kuzminsky: I will chase him
[20:33:47] <PCW> eth-packet-loss running at 4 Khz on the H97
[20:34:48] <PCW> I'llhave to dig out my series transformer/function gen error inserter
[20:42:01] <andypugh> PCW: Reproducing faults can be so hard… In the day job customers keep literally melting engines. I can drain out all the water, put a car on the dyno with wind-speed fans turned off and run with my foot to the floor and still not manage to melt anything.
[21:03:45] <PCW> Hard to know what a realistic torture test requires
[21:06:27] <PCW> The eth-packet-loss branch is working well on the Zotax at 2 KHz at 50% read timeout (occasional bogus PID error spikes but it carries on without serious trouble)
[21:07:58] <PCW> so timing out on read and discarding the stale RX packet on the next cycle seem to be working correctly
[21:08:03] <jepler> I've been introducing packet loss with the iptables packet filter running on the linuxcnc machine
[21:08:20] <jepler> one of the commit messages describes how to set that up
[21:08:44] <PCW> I am just running the machine too fast :-)
[21:09:02] <andypugh> PCW: Yes, I can only assume that customers are somehow not hitting our safeguards but finding a corner of the variable space where they can still make enough engine heat.
[21:09:56] <andypugh> (we work in a 13 variable space with 5 noise factors, it’s mathematically intractable)
[21:10:49] <PCW> do the ECUs have any logging capability?
[21:13:59] <PCW> jepler: Looks really good, more robust by a large factor
[21:15:15] <PCW> probably should have a accumulated timeout and lost packet count for debugging purposes
[21:16:48] <PCW> might actually improve average performance as you can run a faster thread because occasional timeouts are not harmfull
[21:17:25] <PCW> bbl Dinner!
[21:45:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 5509e60 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py allow absence of MAX_FEED_OVERRIDE JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5509e60
[21:45:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 a669fa8 06linuxcnc 04configs/sim/axis/acc_test.ini 04configs/sim/axis/medium.ini 03configs/sim/axis/orphans/acc_test.ini 03configs/sim/axis/orphans/medium.ini orphan unsupported sim configs JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=a669fa8
[21:45:08] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 196319c 06linuxcnc 10configs/sim/axis/README 03configs/sim/axis/minimal_xyz.ini minimal_xyz.ini sim config (min config items) JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=196319c
[21:45:12] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 c5e9aca 06linuxcnc 10(7 files in 4 dirs) docs fix some axis to joint hal references JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=c5e9aca
[21:45:16] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes13 b03b2f8 06linuxcnc 10docs/src/getting-started/updating-linuxcnc.txt updating-linuxcnc.txt add Sim configs section JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b03b2f8
