#linuxcnc-devel | Logs for 2016-06-29

[01:40:15] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #94: Axis GUI "Calibrate" window needs axis calibrations too 02https://github.com/LinuxCNC/linuxcnc/issues/94
[02:23:18] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #95: Axis GUI: spurious Teleop commands when idle 02https://github.com/LinuxCNC/linuxcnc/issues/95
[02:28:19] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #96: Task Abort loop on joint soft limit 02https://github.com/LinuxCNC/linuxcnc/issues/96
[02:36:37] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15SebKuzminsky opened issue #97: joint vs axis soft limits 02https://github.com/LinuxCNC/linuxcnc/issues/97
[06:25:34] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler commented on issue #94: ("calibrate" is inherited from tklinuxcnc and is a standlone Tk program) 02https://github.com/LinuxCNC/linuxcnc/issues/94#issuecomment-229324292
[06:27:28] <jepler> mozmck: it's a very, very long-winded way to make a long-running 'loadusr' command give the user some troublehshooting information:
[06:27:31] <jepler> While waiting for 'wrongname', component 'example' loaded.
[06:27:34] <jepler> Did you specify the correct name via 'loadusr -Wn'?
[07:22:44] -linuxcnc-github:#linuxcnc-devel- [13linuxcnc] 15jepler opened pull request #98: Improve the 'halcmd loadusr' message when component is failing to load (06master...06jepler/master/halcmd-cplusplus) 02https://github.com/LinuxCNC/linuxcnc/pull/98
[09:42:07] <KGB-linuxcnc> 03Dewey Garrett 05master 3e93bfa 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py don't set_motion_teleop() unless needed #95 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=3e93bfa
[10:04:08] <linuxcnc-build> build #2476 of 1405.rip-wheezy-armhf is complete: Failure [4failed compile] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/1405.rip-wheezy-armhf/builds/2476 blamelist: Dewey Garrett <dgarrett@panix.com>
[10:10:21] <jepler> funny, gitweb implicitly criticizes you for commiting "at night", which includes 05:58 local time
[10:10:36] <jepler> <span xmlns="http://www.w3.org/1999/xhtml" class="atnight">05:58</span>
[10:11:23] <linuxcnc-build> build #4296 of 0000.checkin is complete: Failure [4failed] Build details are at http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4296 blamelist: Dewey Garrett <dgarrett@panix.com>
[10:35:57] <seb_kuzminsky> dgarr: that build failure is because the buildbot is overheating, not because anything you did wrong
[10:36:00] <seb_kuzminsky> pdflatex -interaction=batchmode Master_Documentation_es.tex
[10:36:03] <seb_kuzminsky> Segmentation fault
[10:36:59] <ikcalB> seb_kuzminsky: how strong should a reasonable build machine be?
[10:37:18] <seb_kuzminsky> depends how impatient you are
[10:37:32] <seb_kuzminsky> i think 2 gigs of ram is required these days
[10:37:40] <seb_kuzminsky> thanks, boost
[10:38:00] <ikcalB> for linuxcnc purposes. im asking, because I'm buying a new server for my home. that's be a coreDuo, 6G RAM or so
[10:38:25] <ikcalB> "s/'s/'d/"
[10:38:44] <seb_kuzminsky> that sounds like it'll be plenty powerful to develop on
[10:39:52] <ikcalB> I might be willing to run a linuxcnc buildbot/mirror/.. on that one. interested?
[10:40:30] <seb_kuzminsky> oh! cool, yes, i'm interested in that!
[10:40:58] <seb_kuzminsky> i wonder how much of the buildbot script pile expects to run locally to the buildmaster now days
[10:41:24] <ikcalB> atm we're renovating, meaning a lot of offtime - maybe end of summer / begin of autumn I'd be prepared. (also need fresh OS disks (SSDs i.e.)) everything else, running in btrfs raid1
[10:42:09] <ikcalB> that configuration thing I'd be really interested in - atm a complete noob in that regard
[10:47:14] <archivist> running a buildbot slave is fine till someone decides to turn up the build speed (no of parallel)
[10:47:46] <seb_kuzminsky> the buildbot currently runs parallel make with 1.5x as many jobs as the machine has CPUs
[10:47:53] <ikcalB> archivist: why would that be a problem?
[10:47:58] <seb_kuzminsky> each buildslave runs in a 2-cpu virtual machine
[10:48:12] <seb_kuzminsky> on a well provisioned hypervisor
[10:48:19] <seb_kuzminsky> so it all works out
[10:50:13] <archivist> ikcalB, I was running it on my cnc and my server with a database system on the buildbot, they used to grind my server to a halt at times
[10:51:09] <ikcalB> i see. that's just one aspect - as this'd be my home network, I'd be greeatly interested in security ;)
[10:51:16] <archivist> something like -j6 iirc on a system serving the web and me on irc etc
[11:22:56] <jepler> there are a few specific source files which allocate >250MB RAM while building, so there's a big relationship between -j# and the amount of memory required
[11:23:32] <jepler> looks like one of them is nearly 500MB, total memory allocation reported by -fstats
[11:23:51] <mozmck> I run -j8, but I also have 20Gb mem on my machine
[11:24:15] <jepler> I use -j15 on a 12-thread machine with 16GB and it's fine, but I can't use -j4 on a 4-thread ARM with 2GB RAM. -j2 is OK
[11:24:25] <mozmck> interesting.
[11:25:24] <mozmck> I have a 16 thread workstation ($50 auction special) with 12GB and it has no problems either with -j16
[11:26:19] <jepler> ugh. the 500MB number is for gcc 4.7.2 (debian wheezy). on 4.9.2 (debian jessie), the biggest is over 900MB
[11:27:06] <mozmck> is -fstats a gcc option?
[11:27:20] <jepler> yes, not in clang though
[11:27:26] <jepler> make EXTRA_DEBUG=-print-stats
[11:28:04] <mozmck> I've not used clang - seems like from what I've read gcc has kept up and is not behind clang in anything really
[11:28:45] <seb_kuzminsky> clang has better static analysis, http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/index.html
[11:28:47] <jepler> At $DAY_JOB we find the results of the clang static-analyzer to be useful, and gcc doesn't really have an equivalent right now.
[11:28:56] <jepler> and I was just going to look for the link seb_kuzminsky shared
[11:29:05] <mozmck> I see.
[11:30:10] <mozmck> maybe I can run the clang static analyzer and then compile with gcc.
[11:31:18] <jepler> http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/report-03QdrE.html#EndPath
[11:31:33] <jepler> so circa line 2448 it needs to return early if there are no components
[11:32:07] <jepler> http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/report-7ZY1uZ.html#EndPath
[11:32:16] <jepler> looks like this one should be addressed too
[11:33:09] <jepler> mozmck: the downside of "scan-build" is that it makes compile times much longer, and renders technologies like ccache useless
[11:33:25] <mozmck> Looks like some useful information though
[11:33:30] <jepler> yeah it is
[11:34:01] <jepler> at $DAY_JOB we don't aim for zero scan-build diagnostics, but we do investigate each new diagnostic from scan-build and often make fixes based on them
[11:34:45] <jepler> I actually have a script which looks at two days' reports on buildbot for new diagnostics, bisects them, and e-mails the committer the information about it
[11:35:11] <seb_kuzminsky> nice
[11:35:20] <seb_kuzminsky> robotic nagging to go with the robotic code review :-)
[11:35:36] <jepler> otherwise, like with linuxcnc, somebody will only go looking rarely
[11:35:46] <jepler> but even if you remember to go looking once you encounter a crash in a particular source file, it can be a huge help
[11:35:55] <jepler> "oh clang already told me I was doing something obvously wrong here"
[11:38:18] <jepler> you may also find that certain checkers emit diagnostics you're not interested in looking at. For instance, we -disable-checker deadcode.DeadStores because this is a common practice that we're not going to address right away
[11:39:24] <jepler> also that checker encourages you to change code to have worse style IMO. Consider this one: http://buildbot.linuxcnc.org/clang/master-rt/v2.8.0-pre1-2240-g3e93bfa/report-N3HORD.html#LN1814
[11:39:45] <jepler> now ideally you'd do something besides open-code a loop to find the index of greatest eigenval
[11:40:13] <jepler> but given that you're going to do *that*, I believe it's better for the last 'if' statement to still assign eigenval, so that the form of each if statement is the same
[11:42:07] <CaptHindsight> are there any freelance C devs that are familiar with Linuxcnc as well as CAM, post processors, printer drivers etc out there?
[11:42:59] * jepler shivers with cold: printer drivers !?
[11:43:19] <jepler> I'm sure if I tried real hard I could remember the epson control codes from the '90s!
[11:43:42] <archivist> I bet very few apart from me and capt have done printer drivers
[11:43:57] <seb_kuzminsky> i once wrote an octagonal chess board in postscript, does that count?
[11:44:17] <CaptHindsight> well an understanding of how print heads space nozzles, and how motion gets synced to lasers, inkjets etc
[11:44:52] <jepler> oh you mean things you would understand to write printer firmwares? Or has this knowledge been pushed out of the printers into the "real computers" now?
[11:44:58] <archivist> fscking random jumble of nozzles, that I do remember
[11:45:12] <CaptHindsight> random jumble of nozzles
[11:45:31] <archivist> offsets and spacing and buffers
[11:46:06] <CaptHindsight> you handle some in it in an fpga
[11:46:18] <archivist> we did it in code
[11:47:22] <CaptHindsight> but you still need to go from some image format or table of data and jumble it into some format the printheads require
[11:48:36] <CaptHindsight> one example is Linuxcnc to control and inkjet printer that prints DNA strands
[11:48:47] <archivist> my last one was in ARM C for a got at Olivetti printer which we shoved HP heads in
[11:49:04] <CaptHindsight> the users aren't EE's, ME's and have never seen G-code
[11:49:53] <CaptHindsight> you jet one of eight fluids (in 8 separate banks of inkjet nozzles) onto a glass slide
[11:50:38] <CaptHindsight> you do this 100-1000 times over itself with different fluids every layer
[11:50:41] <jepler> sounds fun! but it's above my pay grade
[11:50:55] <CaptHindsight> I need to write a user friendly front end
[11:51:34] <seb_kuzminsky> a gui for printing gooey dna
[11:52:03] <jepler> also, we can print dna strands and the problem is the UI isn't friendly enough. welcome to the 21st century
[11:52:19] <CaptHindsight> heh
[11:52:30] <seb_kuzminsky> 1st world CS problem
[11:52:53] <archivist> isnt a command line good enough?
[11:53:04] <CaptHindsight> the biologist knows GACT
[11:53:57] <archivist> I assume you mean this http://www.uvm.edu/genomics/software/gact/
[11:55:01] <archivist> rofl they cant manage online docs
[11:56:12] <CaptHindsight> http://www.ncbi.nlm.nih.gov/pmc/articles/PMC507883/
[11:56:22] <CaptHindsight> POSaM: a fast, flexible, open-source, inkjet oligonucleotide synthesizer and microarrayer
[11:58:31] <CaptHindsight> they kludged some boards together for motion control http://www.ncbi.nlm.nih.gov/pmc/articles/PMC507883/bin/gb-2004-5-8-r58-s1.pdf
[12:00:11] <CaptHindsight> they used the software that came wit the Compumotor servo controller and something by national Instruments to generate the printhead pulses
[12:04:15] <CaptHindsight> archivist: similar to that conversion tool, but that only targets the microarrayers by Illumina
[12:05:10] <CaptHindsight> microarrayers are like pick and place with a matrix of nozzles for fluids
[12:09:13] <CaptHindsight> Linuxcnc with some custom M codes can handle >90% of what this needs
[12:10:23] <archivist> mebe
[12:10:24] <CaptHindsight> what is needs is a g-code generator and a way to sync motion to the printhead buffer
[12:10:33] <CaptHindsight> is/it
[12:11:39] <CaptHindsight> I've already synced Linuxcnc to printheads but they were two independent systems
[12:12:00] <archivist> well I remember flight time and errors in the nozzle alignments to fixup in code too
[12:12:10] <CaptHindsight> the printhead buffer would use the gated encoder signals as a clock
[12:13:15] <archivist> that only works where the spacing is regular and the same as your encoder
[12:13:51] <CaptHindsight> jetting DNA fluids is a bit more simple since there is no grey scaling or interpolating going on
[12:14:25] <CaptHindsight> yeah, the drops for DNA are in the same place every time
[12:14:41] <CaptHindsight> you just put drops on top of previous drops
[12:14:57] <CaptHindsight> with wash and dry cycles in between
[12:15:49] <archivist> not sure how we add the laser diode drop checking that doc mentions
[12:16:47] <CaptHindsight> an external input
[12:17:11] <CaptHindsight> like QC when you machine apart
[12:17:23] <CaptHindsight> it goes back over the bad area
[12:19:31] <CaptHindsight> this only XY scans
[12:19:38] <jepler> hm, Eagle (PCB software) has been sold to Autodesk. One more reason I should use Free software next time I make a PCB.
[12:19:38] <CaptHindsight> so motion planning is simple
[12:20:02] <seb_kuzminsky> jepler: i used kicad last time, it was great (but i'm not a power user)
[12:21:29] <CaptHindsight> archivist: the drop checker is like having an indicator go over a path that was just machined to QC and then deciding if it should make another pass or go on to the next path
[12:21:52] <archivist> kicad seems to be actively developed, but the schematic needs a revamp
[12:22:21] <archivist> CaptHindsight, been looking at http://www.uvm.edu/genomics/software/gact/
[12:22:35] <ikcalB> DipTrace atm is a good windows alternative - free for small projects, cheap for private use
[12:22:36] <archivist> wrong this http://www.ncbi.nlm.nih.gov/pmc/articles/PMC507883/figure/F3/
[12:22:44] <ams-w> Active g codes and m codes are decided right at RS274 interpreter level, this is way before it passes through emctaskmain and then gets executed.
[12:23:11] <ikcalB> also started to use kicad, it is REALLY becoming useful!! many things need revamp, but as I said, especially the push n shove router is likeable
[12:23:11] <archivist> jepler, I have the founder flag on the #kicad channel :)
[12:23:19] <jepler> archivist: nice
[12:24:51] <ams-w> I tried a 5 line g code
[12:25:19] <ams-w> Which has m3 on line 3 and line 4 had error
[12:25:38] <ams-w> File did not got executed but active g codes were altered
[12:26:57] <ams-w> Active g codes (if are queue busters) can be updated from within emccanon
[12:27:17] <ams-w> Is this a right way ?
[12:29:13] <archivist> ams-w, not sure what you are asking or trying to do
[12:33:38] <archivist> CaptHindsight, a hack of http://linuxcnc.org/docs/html/man/man9/streamer.9.html ?
[12:35:14] <CaptHindsight> maybe
[12:40:31] <CaptHindsight> archivist: the g-code generator would be mostly a set of subroutines that match the print, wash and drying to make G, A, T and C
[12:41:58] <archivist> g code to scan but something else to produce the dot patterns
[12:43:05] <CaptHindsight> that could be outside of Linuxcnc, a buffer that gets drops aligned to the planned motion
[12:43:42] <archivist> I get the impression unidirectional would be ok to avoid flight time and head accuracy
[12:44:06] <CaptHindsight> but yeah, the g-code generator would also have to generate bitmaps for the buffer
[12:44:41] <archivist> nah I think the bitmaps should be elsewhere
[12:44:45] <CaptHindsight> yeah just X-Y scan at all right angles, print would only be in say Y axis
[12:51:28] <CaptHindsight> archivist: https://ibin.co/2mM02TarMu3R.jpg block diagram of the original electronics
[12:52:29] <CaptHindsight> now replaced by Mesa boards and a custom printhead FPGA board
[12:55:06] <archivist> while {do the test spit and capture the result, fire the C to write the bit pattern, spit the dots}
[12:59:58] <CaptHindsight> this came up about a year ago in another channel where many of the devs work with GRBL, repraps and other silliness
[13:00:33] <CaptHindsight> they even wanted to replace the mesa cards with something cheaper and less flexible
[13:01:18] <CaptHindsight> but since I don't wish to vomit, I'm not going that direction
[13:05:44] <CaptHindsight> archivist: http://www.bioinformatics.org/pogo/Lombardi073.tgz http://bioinformatics.org/cgi-bin/cvsweb.cgi/pogo/ http://www.bioinformatics.org/pogo/Arrayer092.tgz
[13:06:02] <archivist> I can think of a possible improvement to the drop detector, have an a-d and get the waveform from the sequence of drops, one then gets size/fluid changes
[13:06:51] <CaptHindsight> the Epson heads are low cost, that's about it
[13:07:11] <CaptHindsight> the drop detector is really for detecting missing drops
[13:07:32] <CaptHindsight> we have much better heads but thats for V2.0
[13:08:37] <CaptHindsight> archivist: lets take this to the linuxcnc channel vs the dev channel
[13:08:56] <CaptHindsight> we are just noise in here now
[15:51:19] <seb_kuzminsky> huh, i think i found a workaround for the rtai 5 hangs i've been seeing
[15:51:29] <seb_kuzminsky> fingers crossed
[16:12:48] <andypugh> I assume there is no legal reason that I can’t tell Machinekit that they are welcome to adapt and use my LinuxCNC patches? In fact I rather supsect that I couldn’t even deny them permission?
[16:14:33] <seb_kuzminsky> your assumptions are both correct
[16:18:27] <andypugh> OK. Though I really do wish that Machinekit had better support and we saw less of their users on our forums, where sometimes we spend days puzzled until it turns out that they are running MK on a BBB
[16:20:14] <andypugh> Does anyone know if MK is JA-based? I stopped following the project after MAH told me to bugger off.
[16:20:30] <seb_kuzminsky> dont know, dont care
[16:21:54] <andypugh> I care a bit, because of users and some of the other devs, like Zulton who is doing the decent thing and patching both.
[16:22:28] <seb_kuzminsky> yeah, i appreciate the work zultron's doing, that's all top notch
[16:27:22] <andypugh> So…. Sticky tools. Should I do do something?
[16:28:27] <andypugh> I rather suspect that nearly every user leaves their tool in the spindle at the end of the day, and would prefer the system to come back up set for that spindle, and the same offsets.
[16:28:54] <andypugh> Or maybe I am just a sloven?
[16:29:22] <seb_kuzminsky> i sure do that
[16:30:15] <andypugh> I think it is almost as simple as putting #5400 in the sefault vars file.
[16:30:22] <andypugh> (default)
[16:30:23] <seb_kuzminsky> how does multispindle deal with the random-tool-changer pocket 0 thing now? i guess each spindle must get its own pocket?
[16:30:49] <seb_kuzminsky> and for nonrandom you'll need a numbered parameter for each spindle?
[16:31:27] <seb_kuzminsky> how does that interact with cutter comp and tlo and things? do they all take an extra argument to specify which spindle is your reference?
[16:31:37] <andypugh> seb_kuzminsky: It doesn’t deal with it. Partly why multispindle is not even a candidate for 2.8. That and finding other #parameters for the other tools
[16:32:17] <seb_kuzminsky> ah ok, your question is just about single-spindle sticky tools, sorry
[16:32:22] * seb_kuzminsky gets confused a lot
[16:33:09] <andypugh> Yes, at the moment, sticky-tools is monotool only, and yet to be solved for multispindle
[16:33:49] <andypugh> mutlispindle at the moment only expects to not break spindle.0 behaviour.
[16:34:29] <seb_kuzminsky> probably 5400-5413 need to be persistent, right?
[16:34:34] <andypugh> I am rather expecting cutter-comp to only ever work for spindle.0
[16:34:45] <seb_kuzminsky> or 5401-5413 could be reloaded from the tool table based on 5400 at startup?
[16:35:05] <andypugh> Yes, something like that
[16:36:04] <seb_kuzminsky> that seems reasonable to me
[16:36:27] <seb_kuzminsky> i sometimes use m61 to remind my machine at bootup what tool i left in the spindle the night before
[16:36:38] <andypugh> I have not looked at the implementation details yet, I have just seen a perfectly sensible forum question to which I was forced to give a really convoluted answer, and then realised that it would suit me to have an option to build-in sticky tools too
[16:37:33] <andypugh> (It was one of those “How can you be happy with this answer, it should be so much simpler” situations)
[16:37:37] <seb_kuzminsky> i sometimes remove the tool after shutting the machine down (manual tc), i guess it would wake up wrong in that case because i did stuff while it was asleep
[16:37:54] <seb_kuzminsky> andypugh: we have a few of those in our software... :-/
[16:38:15] <andypugh> Yeah, can’t solve anything that happens when the software isn’t running.
[16:38:28] <andypugh> I can’t get my tools out if LinuxCNC isn’t running
[16:39:12] <andypugh> seb_kuzminsky: We should have a list of “it shouldn’t be this hard” features.
[16:39:19] <seb_kuzminsky> i think we should pick one behavior (remember the tool, or dont), and not have an option to switch between them
[16:39:34] <seb_kuzminsky> easier to test, easier to understand users bug reports
[16:39:58] <andypugh> OK… I agree but it’s more scary :-)
[16:39:58] <seb_kuzminsky> andypugh: jog while paused! oh wait i really meant change tools and touch off while paused!
[16:41:12] <seb_kuzminsky> bbl, time to go celebrate independence day a few days early
[16:41:32] <seb_kuzminsky> we celebrate by shooting our guns in the air and throwing tea in the nearest body of water
[16:47:33] <andypugh> Ours might be 23rd of June. Or it might be Disaster Day. No way to know yet.
[16:47:44] <andypugh> seb: http://wiki.linuxcnc.org/cgi-bin/wiki.pl?This_Should_Be_Easier
[16:48:48] <andypugh> Need to figure out where to link it, or it’s a dead page. But it feels like a different thing to bugs or feature requests.
[17:06:10] <cradek> I like that idea
[17:06:31] <skunkworks> grinding the matsuuras spindle taper. (with a dremel)
[17:06:52] <skunkworks> a 6 inch long tool is down to less than .001 runout - used to be .006
[17:07:16] <cradek> I hesitate to tell anyone that I wrote (hacked in) this persistent tool feature many years ago for a customer
[17:07:37] <cradek> his machine was nonrandom but he wanted persistence
[17:08:11] <cradek> I think it made the pocket number of the loaded tool negative or somesuch asinine thing, and restored it at startup (including the g43 offset)
[17:09:20] <cradek> I agree with seb that whenever possible we should do only the right thing and not make the right thing an option just because we are scared, because proliferation of options makes testing impossible
[17:09:55] <cradek> and frankly "forget about the loaded tool" probably isn't a thing anyone ever wanted or wrote on purpose
[17:10:26] <cradek> my vmc is random and so it remembers the tool, but I always unload the tool before shutting down anyway
[17:10:53] <cradek> (fwiw)
[17:16:27] <andypugh> if you unload the tool, it’s all good anyway. I think it might turn out to be what my employer calls a “surprise and delight feature” Something that folk were not expecting, but like.
[17:16:50] <cradek> which thing would be surprise and delight?
[17:17:59] <andypugh> Turning on the machine, issuing your habitual G6 TN G43 to load the tool you left in there, and not being prompted to change the tool and press OK
[17:18:12] <cradek> ah yeah
[17:18:37] <cradek> http://timeguy.com/cradek-files/emc/0001-Persistent-toolchanger.patch
[17:18:52] <cradek> probably applies to 2.5ish, fails badly to apply on masterp
[17:18:54] <cradek> master
[17:19:37] <cradek> (please don't try to use as-is because I really don't think it should be another option)
[17:20:21] <skunkworks> I would also like linuxcnc to remember what tool was in the spindle. I figured I would have it remember then run some sort of gcode scrip after homing is done
[17:20:53] <skunkworks> I had found a hal componant that saved a pins value I think
[17:21:12] <andypugh> cradek: That seems to store the tool-in-spindle in a special pocket? (I only scanned it quickly)
[17:21:14] <skunkworks> then I found another example that just wrote to the var file
[17:21:28] <cradek> no it apparently marks it with L1 in the tool table
[17:21:33] <cradek> "loaded" I suppose I was thinking
[17:21:52] <cradek> but random thinks of the spindle as a special pocket 0
[17:27:42] <andypugh> If I ever get back to the tooltable database work then tool-in-spindle becomes an explicit feature of the database.
[17:28:25] <cradek> do you think we could then remove m61 (and all its code in io?)
[17:28:48] <cradek> bleh, my customer wanted this added to iov2
[17:29:10] <cradek> (speaking of being scared and making testing hard)
[17:29:49] <andypugh> M61 should still work, but I don’t think it ever belonged in IO. Actually I am not sure that iocontrol ever belonged in LinuxCNC
[17:30:43] <cradek> I don't even know what face to make in response to that
[17:32:39] <andypugh> The things it does belong, it does useful things.
[17:32:43] <cradek> I bet separate io over an nml interface made a lot more sense pre-hal, because you could abstract there
[17:32:53] <cradek> brb
[17:35:12] <andypugh> Something that I wanted to do back when I was working on the tool database was have a loadable HAL component “field” NML messages. That’s mainly why I stopped. At the time MAH was going to relace NML with 0MQ and that was going to let HAL components act on not-NML messages.
[17:35:55] <skunkworks> https://www.youtube.com/watch?v=2BFTifZgQVs
[17:38:29] <andypugh> That’s mildy brave
[17:39:01] <andypugh> I tried that making an ER32 collet chuck and could not get the taper right.
[17:45:39] <skunkworks> andypugh: we figured we could not make it worse
[18:33:36] <PCW__> The 4.1.27-rt30 kernel seems to run well on older (CoreDuo) and newer (N3150) hardware
[18:33:38] <PCW__> maybe its a good default choice for Preempt-RT dists (will test on mode hardware)
[18:33:51] <PCW__> s/mode/more/
[18:52:53] <CaptHindsight> skunksleep: lots of wear inside the spindle? or was it just poorly made?
[19:08:17] <jepler> for me, 4.1 had better rt performance than 4.4 or 4.6 on a newish i7, but I believe that's because I only did 4.1 tests without nvidia graphics enabled.
[19:12:58] <PCW__> I think its the first 4.1.x kernel that worked on my N3150
[19:35:10] <jepler> ah that's good news then
[19:38:18] <PCW__> there's something a bit different with the N3XXX graphics than seems to make it picky (at least on the Zotac)
[20:00:52] <skunkworks> zlog
[20:41:19] <jepler> seb_kuzminsky: hey where is the public half of the key you use to sign http://highlab.com/~seb/linuxcnc/ ?
[20:41:31] <jepler> W: GPG error: http://highlab.com jessie Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY EF0D730CE9AD3D5D
[20:45:00] <PCW__> well crap 4.1.27-rt30 crashed after a couple hours up on the n3150
[20:45:54] <PCW__> back to 4.4 on the n3150
[20:46:42] <skunkworks> 4.4.9-rt17 #1 SMP PREEMPT RT Sun May 15 20:22:00 CDT 2016 x86_64 GNU/Linux
[20:47:56] <skunkworks> no crashes - but it doesn't lock the screen after 5 minutes like it should. (I don't know if that all happed at the same time or unrelated..)
[20:48:30] <skunkworks> have not tried the latest
[20:48:58] <skunkworks> PCW__, how is it going? the matsuura has been up for probably months now - no issues. we just leave it on
[20:49:28] <PCW__> I think this is N3150/Zotac specific 4.4.16 had been up more than a month also without issue
[20:50:39] <PCW__> busy ATM trying to build up a reasonable amount of stock so we are not building every other month or so
[20:51:21] <PCW__> first time building 1000 5I25s at once
[20:53:40] <skunkworks> well - you are popular :)
[20:54:40] <PCW__> just too much purchasing work to do in small batches
[21:16:06] <cradek> that's very good news
[21:44:22] <skunkworks> PCW__, The panel interface - If I use the ones that don't have the pull ups - I need to use 3.3v?
[22:00:10] <seb_kuzminsky> jepler: http://highlab.com/~seb/linuxcnc/dists/archive-signing-key.gpg
[22:00:23] <seb_kuzminsky> i hid it in plain sight and then didnt tell anyone
[22:01:00] <seb_kuzminsky> http://i.imgur.com/A40o10Q.gif
[22:34:24] <pcw_home> skunkworks: (should you read this later) yes the analog inputs (no pullups/pulldowns)
[22:34:26] <pcw_home> can be pulled down to gnd or pulled up to 3.3V, they are 3.3V max inputs