Back
[07:20:02] <jthornton> skunksleep,
https://www.youtube.com/watch?v=isTD6bDF_LI
[07:20:06] <jthornton> here is another video
[07:33:57] <malcom2073> I know it's plastic, but seriously? Fingers?
[07:33:58] <malcom2073> :P
[07:34:19] <malcom2073> Nice tool post
[08:04:09] <archivist> good ol stringy plastic
[09:20:06] <mozmck> skunkworks: the threading saga on the mach list goes on...
[09:24:14] <mozmck> https://youtu.be/NPwnOZ2gNJ0
[10:31:41] <seb_kuzminsky> that looks, great, mozmck
[10:33:55] <jepler> at this point I think the only video needed in the threading thread is a rickroll
[10:55:09] <pcw_home> Did you see my suggestion for repeating FIFO reads? ( probably a very old idea )
[10:59:03] <pcw_home> I think I like the push/pop read pointer best since if you dont use the feature it behaves like a standard FIFO
[10:59:05] <pcw_home> and you dont need to worry about pointer sizes/masks etc
[11:08:32] <pcw_home> whether this is really worth bothering with, I don't Know
[11:08:34] <pcw_home> I can see a use case for high speed streaming output ( laser modulation )
[11:08:35] <pcw_home> streaming input, not sure where you would use that
[11:09:26] <jepler> pcw_home: yes I did, thanks
[11:10:31] <jepler> pcw_home: I agree, I don't think it would be burning too many bridges to start with only output FIFOs supported
[11:12:06] <jepler> but probably figuring out the details of recovering from lost packets in general should be done first
[11:12:23] <pcw_home> Yes
[11:12:59] <jepler> it's easy to simulate lost packets with iptables so that'll be nice
http://code.nomad-labs.com/2010/03/11/simulating-dropped-packets-aka-crappy-internets-with-iptables/
[11:14:39] <pcw_home> Yeah thats needed for testing
[11:15:16] <jepler> pid and motion will both need "no position feedback update was available" inputs, and internal logic added to mask following errors / avoid winding up I-terms. and motion would need to treat too many consecutive missed feedbacks as a fault.
[11:16:16] <pcw_home> I dont think Ive ever seen a dropped packet in my testing but it a benign electrical environment
[11:16:24] <jepler> same here
[11:17:21] <pcw_home> Yeah for PID a freeze input (and internal support) is probably all thats needed
[11:18:33] <jepler> and the 120ms(?) max wait time for a read packet has to be greatly reduced
[11:18:58] <jepler> one problem with that was that the thread period is not known way down in the hm2_eth read response function
[11:19:41] <jepler> and FIFO-type components within hostmot2 will need to recover from a lost write packet
[11:19:42] <pcw_home> thats an issue because it probably needs to be set to some reasonable fraction of the servo thread period
[11:20:50] <jepler> doing it as a fraction of servo period is one possibility
[11:20:59] <jepler> doing it by adding up the transmission and processing times is another
[11:21:03] <pcw_home> On sserial we measure the remote response time , and pad it for timeouts
[11:22:24] <jepler> if your period is 1ms or 10ms, but the turnaround time is 100us either way, then using 20% of 10ms is silly
[11:23:26] <pcw_home> but its not terribly harmful either
[11:23:29] <jepler> yes
[11:24:56] <pcw_home> a reasonable timeout is worst case latency (of all servo thread functions) related
[11:25:59] <jepler> in other words, you have to make the timeout low enough that actually hitting it doesn't make you miss a realtime delay
[11:27:11] <pcw_home> yes and long enough that you dont get false timeouts from host latency
[11:29:05] <pcw_home> in which case you would get the late packet on the next thread
[11:35:09] <pcw_home> on this system ( DC7800/E8500 ) there are rare 120 or so usec added delays in hm2_read
[11:35:11] <pcw_home> rare being say one or twice a week. This also happens in motion-command-handler
[11:35:12] <pcw_home> but much more rarely, so it is rather difficult to know the total thread time
[11:35:14] <pcw_home> which is why a percentage of the thread period seems like a simple starting point
[11:36:08] <pcw_home> (My H97 system does not have this behavior)
[11:57:30] <jepler> OK, so add dealing with a packet that arrived but late to the list of things to handle
[11:58:14] <pcw_home> slowly inventing TCPIP
[12:00:54] <pcw_home> I wonder what other systems do? (LIke Ethernet Powerlink)
[12:00:55] <pcw_home> or do they just say fix your noise issues
[14:53:34] <skunksleep> jthornton: thanks!
[14:56:45] <skunksleep> mozmck: I am trying hard not to reply.. Steve is in fine form.
[15:02:03] <skunksleep> https://groups.yahoo.com/neo/groups/mach1mach2cnc/conversations/messages/148845
[15:17:38] <skunksleep> mozmck: very cool. That thing flies too.
[15:31:53] <skunksleep> http://www.linuxcnc.org/index.php/english/forum/20-g-code/29685-g76-pause-in-z-during-exit-taper-linux-cnc-270
[15:32:15] <skunksleep> Can someone test this on sim?
[15:32:28] <skunksleep> I cannot right now
[15:56:05] <Tom_itx> skunksleep, did you get the latest sherline rigid tapping vid?
[15:58:43] <skunksleep> I think I posted it
[15:59:03] <skunksleep> Or was there another one?
[16:01:09] <skunksleep> Yes I think I got your new one
[16:14:45] <jepler> skunksleep: I tested that on sim/axis/lathe.ini and I don't see a dip in zvel during the thread cutting. Tested with 2.7 branch, describes as v2.7.0-29-g0037cae halscope
http://emergent.unpythonic.net/files/sandbox/master-sim-lathe-thread-taper.png
[16:17:16] <jepler> I did a second plot with xpos so it was clearer where in the plot the taper was. it's all within the portion where Zvel is constant
[16:21:38] <jepler> http://emergent.unpythonic.net/files/sandbox/master-sim-lathe-thread-taper2.png
[16:22:46] <andypugh> I have never quite figured out the little wiggle that X does.
[16:23:08] <skunksleep> That looks perfect
[16:23:43] <jepler> I don't know what the waggle at the start is either!
[16:24:10] <skunksleep> jepler: thank you
[16:24:31] <jepler> skunksleep: welcome
[16:24:48] <andypugh> It always does it. I think it is to make the entry moves always the same. But as the entry waits for index, so is exact-stop (assumption) I don’t think it is neceesary.
[16:25:41] <jepler> oh is it something the g76 cycle is doing?
[16:27:02] <andypugh> Interesting thing today. I made a new config for milling in the horizontal spindle. That means a simple swap of Y and Z. But as the new Y (old Z) runs in the opposite direction it turns out that I had to change the sign of the D-gain
[16:27:19] <andypugh> jepler: Yes, the wiggle is a G76 thing.
[16:28:13] <andypugh> (and, thinking about it, I needed to flip X, not Z really. I have a right-handed coordinate sytem but Y positive _towards_ the table is just confusing.
[16:31:45] <skunksleep> What are you going to machine?
[16:32:02] <andypugh> skunksleep: A foundry pattern.
[16:32:16] <andypugh> It’s to big to do any other way.
[16:32:43] <andypugh> But a horizontal spindle is pretty good at machining the sides of a bix.
[16:32:50] <andypugh> (box)
[16:33:09] <andypugh> Well, I anticipate it being good at it.
[16:33:36] <andypugh> I guess tomorrow I get to clean and dry the machine ready for covering it in MDF chips. :-/
[16:39:33] <skunksleep> Yeck
[16:40:24] <andypugh> Maybe I will keep a vacuum cleaner on it, if I can stand the noise.
[17:57:17] <Tom_itx> zlog_
[21:39:19] <skunkworks> interesting
http://www.linuxcnc.org/index.php/english/forum/20-g-code/29685-g76-pause-in-z-during-exit-taper-linux-cnc-270#63044
[21:45:16] <jepler> if he re-minimizes a test case I'll be happy to scope it again
[21:52:11] <skunkworks> I see a little blip
[21:52:13] <skunkworks> http://imgur.com/TIhO41K
[21:52:23] <skunkworks> This is sim
[21:52:37] <skunkworks> when x starts pulling out.
[22:01:34] <jepler> looking at my plot again you can see an absolutely tiny blip
[22:01:39] <jepler> but maybe some setting can make it a bigger blip
[22:01:45] <jepler> what did you do to produce your plot?
[22:02:22] <skunkworks> 2.7.0 v2.7.0-27-g69fc2dd
[22:02:27] <skunkworks> sim axis lathe
[22:02:30] <jepler> my blip is way under 5ms in duration and 50milli-inches-per-second(?) in amplitude
[22:03:44] <jepler> on some runs the general noisyness in Zvel is much higher than in others
[22:03:53] <skunkworks> that is small
[22:04:10] <skunkworks> does 2.6 do it? I am running out of testing time again
[22:04:34] <jepler> here's a nasty noisy Zvel trace
http://emergent.unpythonic.net/files/sandbox/master-sim-lathe-thread-taper3.png
