Back
[09:33:54] <mozmck> pcw_home: I'm getting about 22.6 max latency reported by latency-histogram on my DC7800 with my 3.18.9-rt5 patch. I'll probably try some different config options and see if I can get it better.
[09:34:58] <mozmck> pcw_home: You mentioned a $6 RTK8139 ethernet card - where would I find those? I assume the card is a different brand than that.
[09:37:27] <micges_> /nick micges
[09:38:05] <jepler> mozmck: this one popped up on amazon and is showing me the price $6.50:
http://smile.amazon.com/RTL8139D-Ethernet-Adapter-Controller-100Mbps/dp/B00B5T32PK/
[09:38:37] <mozmck> jepler: thanks! I had just found that one. Looks like it comes straight from china.
[09:38:58] <mozmck> I wonder if there is a low-profile options for these SFF computers?
[09:39:49] <jepler> it sure will if you just remove the bracket
[09:40:23] <jepler> the $25ish(?) intel gigabit nics all come with a regular and a short bracket but I don't see any indication that this card will come with one
[09:41:55] <jepler> [another RTL8139 board] > The product box contains very few items. Of course it contains the ST100SLP Ethernet adapter, as well as an installation manual and an installation floppy diskette. Yes, you heard me correctly; installation "DISKETTE".
[09:42:01] <mozmck> here's one that looks like it might be rtk8139:
http://www.amazon.com/StarTech-com-Profile-Ethernet-Network-ST100SLP/dp/B00006JI5H/
[09:42:22] <mozmck> low profile and still pretty cheap
[09:43:30] <mozmck> heh, looks like you were looking at the same one :)
[09:48:20] <mozmck> Hmm, this one looks interesting:
http://www.amazon.com/Protronix-Gigabit-Ethernet-Profile-Controller/dp/B008UG5588/ RTL8169SC chipset, and has gigabit as well.
[10:09:03] <pcw_home> mozmck: 22.6 usec latency is fine (even 100 or so is fine at 1 KHz)
[10:14:33] <pcw_home> also a quick check to compare driver/MAC latency is to just ping the FPGA card:
[10:14:34] <pcw_home> sudo chrt ping 10.10.10.10 -i .001 > pingtimes
[10:15:00] <pcw_home> sorry
[10:15:01] <pcw_home> sudo chrt 99 ping 10.10.10.10 -i .001 > pingtimes
[10:18:44] <mozmck> I'll try that - thanks!
[10:26:57] <pcw_home> BTW the Intel MAC on the DC7800 is excellent
[10:27:34] <mozmck> good to know.
[10:27:39] <pcw_home> better than newer intel MACs for mysterious reasons
[10:28:31] <pcw_home> it does need the IRQ coalescing turned off or its terrible though
[10:28:42] <mozmck> how do I do that?
[10:29:43] <pcw_home> sudo ethtool -C ethN rx-usecs 0
[10:30:20] <mozmck> hmm, is this a one-time thing? or each reboot
[10:31:11] <pcw_home> each reboot
[10:31:13] <pcw_home> (that means it hangs around 0 usecs in the ISR waiting for a possible new packet)
[10:32:26] <mozmck> Is that something that can be run on all ethernet cards?
[10:32:59] <pcw_home> Only some drivers have that feature (or at least have it exposed to ethtool)
[10:33:19] <mozmck> that could be a pain for distribution
[10:33:21] <pcw_home> rtk drivers dont have it
[10:33:46] <pcw_home> its not harmful if it fails
[10:34:10] <mozmck> ok, so we could put it in a startup script then it sounds like.
[10:36:36] <pcw_home> you can see the effect very easily with ping
[12:54:52] <mozmck> PCW: Interesting, in your config CPU frequency scaling is enabled. I figured that would be bad for realtime.
[13:03:50] <PCW> I think its disabled in he BIOS on all systems I have but not sre who is in control in that case
[13:04:18] <PCW> tell me if you get improved latency by changing that
[13:05:11] <mozmck> pcw_home: did you try different schedulers? I see you used cfq, but I put in deadline
[13:05:31] <mozmck> changing it to allow cpu freq scaling?
[13:06:14] <mozmck> I don't know if there is a setting in the bios for this DC7800 for that. I also turned off most of the PM stuff in the kernel.
[13:07:00] <mozmck> One thing you have set is CONFIG_RCU_BOOST=y which looks like a good option for realtime according to the help
[14:00:11] <PCW> I think since it may need to work on a a laptop I left it up to BIOS settings
[14:00:13] <PCW> Deadline scheduler sounds good (thats new from 3.14 or so)
[14:01:39] <PCW> not sure if the linuxcnc RT tasks need to be changed also (I think chrt can do this at least to test)
[14:30:19] <kwallace3> Digging a little deeper into probe errors:
http://www.wallacecompany.com/probe/
[14:31:57] <kwallace3> No errors yet, but I have a very small sample
[14:33:43] <skunkworks> is that steel?
[14:46:06] <mozmck> PCW: I'm going to try with the cfq scheduler and see if there's a difference. Only problem is that I should test one change at a time, and that would take forever!
[14:48:16] <mozmck> PCW: this looks like a potentially useful page:
http://wiki.linuxaudio.org/wiki/system_configuration
[15:16:31] <archivist> kwallace3, is that green an oil or corrosion on the three contact pins
[15:19:33] <KGB-linuxcnc> 03Norbert Schechner 052.6 cee32b2 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_5_3_1 - bug in ignore limits solved * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=cee32b2
[15:19:59] <KGB-linuxcnc> 03Norbert Schechner 052.7 d7ccecb 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=d7ccecb
[15:20:31] <KGB-linuxcnc> 03Norbert Schechner 05master 7d10243 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=7d10243
[15:25:35] <kwallace3> archivist, I don't know what it was. It was pretty tough. I used a small steel brush to get it off, but it didn't work very well. I then used fine lapping powder on a rag to get it off.
[15:26:52] <archivist> looks a bit like the colour of corroded nickel plate
[15:27:17] <mozmck> Hmm, GNU/systemd anyone?
http://distrowatch.com/weekly.php?issue=20150330#community
[15:32:03] <kwallace3> The pins seem like steel drill rod. I don't know what it could do other than rust. It must be coolant, but I haven't used any fluids on this mill yet. I got the probe from Tormach for testing. It seems it's testing me.
[15:34:10] <kwallace3> This link had some interesting bits, such as how different platings work and wetting current:
http://www.allaboutcircuits.com/vol_4/chpt_4/2.html
[15:43:10] <archivist> kwallace3, might be worth using a contact spray, was something I would always have with me during my TV and Radio repair days
[15:43:39] <archivist> Electrolube was the main UK maker of it
[15:43:51] <skunkworks> I wonder if anyone has heard from Mr Padnos
[15:45:12] <archivist> http://www.electrolube.com/products/contact-lubricants.html
[15:45:55] <skunkworks> the touch probes we just got have some sort of oilyness in them.
[15:46:39] <archivist> I should clean mine and lube it
[15:47:40] <skunkworks> kwallace3: is there any seals?
[15:49:27] <kwallace3> No seals.
[15:50:10] <archivist> odd, mine has
[15:52:12] <kwallace3> http://www.tormach.com/product_tts_passive_probe.html
[15:53:55] <kwallace3> DeoxIT is the magic electronics fluid I'm aware of.
http://www.caig.com/
[15:54:02] <andypugh> archivist: somewhere I have an old-school Electrolube dispenser, where the bottle has like a ball-pen cap that extracts a thin straw as you pull it off. And the bottom of the (plastic) bottle is a pressed-in metal cap.
[15:55:04] <KGB-linuxcnc> 03Michael Haberler 052.7 022579c 06linuxcnc 10src/emc/ini/initraj.cc 10src/emc/nml_intf/emc.hh 10src/emc/task/taskintf.cc initraj.cc: fix a type error with arcBlendGapCycles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=022579c
[15:55:04] <KGB-linuxcnc> 03Chris Radek 052.7 bf3a6d2 06linuxcnc 10src/emc/motion/motion.h Finish fixing type error, previous commit * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=bf3a6d2
[15:55:04] <KGB-linuxcnc> 03Michael Haberler 05v2.5_branch 13c89b5 06linuxcnc 10src/hal/hal_lib.c hal/library/hal_link: fix fatal memory corruption bug on linking pin to a signal * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=13c89b5
[15:55:07] <KGB-linuxcnc> 03Chris Radek 052.6 abf34dd 06linuxcnc Merge branch 'v2.5_branch' into 2.6 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=abf34dd
[15:55:10] <KGB-linuxcnc> 03Chris Radek 052.7 4b1bd2c 06linuxcnc 10src/hal/hal_lib.c Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4b1bd2c
[15:55:14] <KGB-linuxcnc> 03Chris Radek 05master 048366b 06linuxcnc 10src/emc/task/taskintf.cc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=048366b
[15:55:40] <archivist> andypugh, there were pens too iirc
[15:57:24] <archivist> still have some EML 200 spray
[16:01:33] <kwallace3> Hmm..."Maintenance
[16:01:33] <kwallace3> •
[16:01:33] <kwallace3> Open contacts of the passive probe can corrode over or become contaminated, thus reducing reliability.
[16:01:33] <kwallace3> Please refer to Tormach service bulletin 37 (SB0037_Reconditioning_the_Passive_Probe_0412A.PDF) for maintenance
[16:01:33] <kwallace3> procedures.
[16:01:34] <kwallace3> "
[16:02:10] <archivist> oops
[16:08:25] <cradek> kwallace3: odd - whatever that is looks like it's there on purpose
[16:17:27] <archivist> !seen swpadnos
[16:17:28] <the_wench> last seen in 2013-10-31 00:54:44GMT 838:59:59 ago, saying Quit: ChatZilla 0.9.90.1 [Firefox 24.0/20130910160258]
[16:17:47] <skunkworks> wow
[16:18:24] <skunkworks> doesn't seem like it was that long ago
[16:18:56] <archivist> getting older, time flies!
[16:19:24] <seb_kuzminsky> nice find, cradek
[16:20:38] <skunkworks> seb_kuzminsky: so far no new bugs.. (that I have seen or run into) with 2.7
[16:20:51] <andypugh> https://www.linkedin.com/profile/view?id=38347420
[16:20:59] <seb_kuzminsky> skunkworks: cradek reported that pause doesn't take effect until the end of the current move
[16:21:28] <cradek> I just tested that (today!) in 2.6 and 2.5 and to my surprise it has never worked how I expected
[16:21:34] <skunkworks> heh
[16:21:36] <cradek> and ... that's not what I reported
[16:21:48] <cradek> pause doesn't work (at all) while stepping
[16:22:04] <andypugh> That seems, on balance, wrong.
[16:22:15] <cradek> run pause step step step step (now while a long step is moving) pause
[16:22:17] <seb_kuzminsky> oh, well i was close, it had to do with pausing!
[16:22:28] <cradek> that pause does nothing, continues the step
[16:23:06] <skunkworks> hmm - can't say I noticed that - cradek you say the behaviour has always been that way?
[16:23:13] <skunkworks> *never tried that
[16:23:16] <cradek> I only tested as far back as 2.5
[16:24:26] <cradek> seb_kuzminsky: we've got to figure out what to do about the state tag changes
[16:25:15] <cradek> seb_kuzminsky: in mk there are a several subsequent fixes that assuage my "can that even work?" feeling a bit
[16:25:42] <cradek> seb_kuzminsky: I'd hate to diverge from pp/mk too much in this regard
[16:25:52] <seb_kuzminsky> i havent been following that branch, can you clue me in?
[16:25:54] <cradek> seb_kuzminsky: maybe state tag restore should go in master?
[16:26:07] <seb_kuzminsky> this is for tracking active gcodes?
[16:26:10] <cradek> well it does two things
[16:26:30] <cradek> yes it makes active gcodes look right during program run, instead of them showing the readaheadded state
[16:26:33] <cradek> I am sure we want that
[16:27:08] <cradek> but now what happens when you abort? it's a little surprising that you suddenly have the readaheadded state showing as active gcodes, and more importantly active in the mdi interpreter
[16:27:22] <jepler> the redheaded step-state?
[16:28:06] <cradek> so upon abort what re's done is take the queued state that is currently being shown during program run, and use it to assemble some gcode and execute it, to try to smush the interpreter back into the expected state
[16:28:53] <cradek> but that's hard, because there's all sorts of mysterious state that isn't literally shown in the active gcodes
[16:29:29] <skunkworks> things like G64's P and Q's?
[16:29:55] <cradek> like imagine cutter comp, where your tool isn't on the path, or a g10 command that's been applied but you haven't moved one of the axes yet, or who knows what else
[16:30:26] <cradek> yes g64 pq, g43.1, g43.2, I bet we could think of a whole list of potential troubles
[16:30:35] <seb_kuzminsky> yeah, sounds like we do want that first part
[16:31:01] <cradek> after the state-tag branch we have, he's done something about ccomp in machinekit: force a G40 after abort in some situations
[16:31:53] <cradek> I feel bad because I thought/wondered about all this stuff and then did nothing, haven't even tried it
[16:33:38] <seb_kuzminsky> well thanks for looking at it now
[16:33:57] <cradek> seems like you need to pick your poison: either try to unroll/restore or not, and both have their problems
[16:34:15] <skunkworks> heh - sounds like stuff that should be configurable.. What states do you want to keep/throw out.
[16:34:37] <seb_kuzminsky> seems like you need to keep ccomp on
[16:34:49] <cradek> skunkworks: only if you want to make it totally untestable
[16:34:57] <skunkworks> cradek: sure
[16:35:46] <seb_kuzminsky> what if you're deep in a slot, ccomp is on, and you abort? if the abort turns off ccomp, now you can't move or you'll gouge the wall of the slot you're in
[16:36:00] <cradek> seb_kuzminsky: if it's on (motion has been comped) when you abort but in readahead it's off, you're screwed
[16:36:23] <cradek> either way you better not try to mdi in that situation, jeez
[16:36:40] <cradek> maybe abort should just do the equivalent of m2
[16:37:09] <seb_kuzminsky> you're only screwed if the readahead ccomp state gets forced upon the interpreter
[16:37:30] <seb_kuzminsky> i'm arguing that abort should not touch the ccomp state
[16:37:35] <cradek> yes there is no ccomp state other than the readahead one
[16:39:11] <cradek> mk/fc4417e057 seems to always run a G40 when aborting
[16:39:28] <cradek> if you're not bold enough to run M2, I think that's an improvement
[16:39:51] <seb_kuzminsky> what all does m2 do?
[16:39:57] <cradek> I often mdi M2 myself, after aborting, if using a program with ccomp -- otherwise everything is goofy
[16:40:12] <cradek> http://www.linuxcnc.org/docs/html/gcode/m-code.html#sec:M2-M30
[16:40:19] <seb_kuzminsky> heh thx
[16:41:14] <cradek> frankly I don't know what it should do, even aside from doing it being hard
[16:43:21] <seb_kuzminsky> maybe g40 is ok if you warp the controller's notion of the controlled point to the actual location of the controlled point, without having to do a ccomp exit move later
[16:43:31] <seb_kuzminsky> that would let you jog up out of your slot
[16:43:58] <cradek> if you jog (switch modes), your position will get synched up
[16:44:15] <cradek> much harder is if you mdi a g0 z1
[16:44:34] <cradek> should that move straight up, or diagonally so you're back on the nominal path?
[16:44:53] <jepler> didn't command X, so X shouldn't move
[16:44:57] <cradek> yeah I bet you'd expect straight up
[16:45:13] <cradek> but if you program the equivalent of g40 / g0 z1 you'd need a diagonal move
[16:45:35] <jepler> a Z only move can be an exit move?
[16:45:36] <cradek> it's possible re's change causes the diagonal move (I didn't try it)
[16:45:47] <cradek> the move after a g40 is the exit move
[16:45:58] <jepler> I didn't know that
[16:46:04] <cradek> it has special requirements
[16:46:10] <cradek> (can't be an arc is one)
[16:46:21] <seb_kuzminsky> i'm suggesting to cancel the g40 exit move after an abort
[16:46:55] <seb_kuzminsky> so that the DRO warps to where the uncompensated tool is, and g0 z0 or jog will raise it straight up out of the slot
[16:46:55] <cradek> well, this is all from my fuzzy memory
[16:47:05] <jepler> the hikey 64-bit arm developer board was supposed to go on sale today, but either it didn't, or all their distributors ran out of stock immediately
[16:47:06] <cradek> I'm stirring together my fuzzy memory and what I'm guessing re's code does :-P
[16:47:31] <seb_kuzminsky> there maybe other situations in which the ccomp exit move is helpful after an abort, but i can't think of any right now
[16:47:45] <jepler> it's a terrible board, though, besides having a aarch64-capable CPU
[17:03:36] <andypugh> if sending an mdi command via the python interface, is there a way to tell if c.wait_complete is true because the command finished, or true because the operater pressed “stop”?
[17:29:16] <jepler> andypugh: doubt i
[17:29:17] <jepler> t
[17:34:09] <andypugh> Hmm, that’s a bit awkward if one wants to stream g-code direct from Python
[17:34:36] <andypugh> (you can’t stop it. You can stop the current line, but then it just runs the next one..)
[18:33:03] <andypugh> Actually, it is even stranger than that.
[18:33:48] <andypugh> command.wait_complete returns 1 when complete, or -1 indefinitely if you press the “stop” button.
[19:13:08] <andypugh> I think I found a recipe:
[19:13:38] <andypugh> while True:
[19:13:38] <andypugh> v = c.wait_complete(0.5)
[19:13:40] <andypugh> s.poll()
[19:13:41] <andypugh> if v == 1:
[19:13:42] <andypugh> break
[19:13:44] <andypugh> if s.state == 1 and v == -1: # stop pressed
[19:13:44] <andypugh> print "I think you pressed stop"
[21:43:37] <linuxcnc-build> build #3095 of 1101.rip-hardy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1101.rip-hardy-rtai-i386/builds/3095 blamelist: Michael Haberler <git@mah.priv.at>
[21:44:24] <skunksleep> Zlog
[21:44:39] <skunksleep> zlog
[22:24:50] <linuxcnc-build> build #3099 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/3099 blamelist: Michael Haberler <git@mah.priv.at>