Back
[00:44:52] <skunkworks> logger[psha]:
[00:44:53] <logger[psha]> skunkworks: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2015-01-02.html
[02:37:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam 0e6f34f 06linuxcnc 10src/Makefile 03src/emc/motion/cycle-time.c 10src/emc/motion/mot_priv.h 10src/emc/motion/motion.c Motion: move cycle time management code out to its own file * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0e6f34f
[02:37:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam 61e0c52 06linuxcnc 10src/emc/motion/command.c Motion: better debug output * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=61e0c52
[02:37:31] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam f3e44ef 06linuxcnc 10(5 files in 2 dirs) start adding a Standalone Motion test program * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=f3e44ef
[02:38:47] <KGB-linuxcnc> 03Sebastian Kuzminsky 052.7 2863486 06linuxcnc Merge remote-tracking branch 'origin/2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=2863486
[02:40:58] <KGB-linuxcnc> 03Sebastian Kuzminsky 05master 5631d61 06linuxcnc Merge remote-tracking branch 'origin/2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5631d61
[02:46:00] <linuxcnc-build_> build #1012 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/1012 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:46:27] <linuxcnc-build_> build #1203 of 1404.rip-wheezy-rtpreempt-amd64 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1404.rip-wheezy-rtpreempt-amd64/builds/1203 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:48:33] <linuxcnc-build_> build #670 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/670 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:48:35] <linuxcnc-build_> build #523 of 1402.rip-wheezy-rtpreempt-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1402.rip-wheezy-rtpreempt-i386/builds/523 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:49:04] <linuxcnc-build_> build #1012 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/1012 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[02:52:45] <linuxcnc-build_> build #1042 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/1042 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:15:48] <linuxcnc-build_> build #2865 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2865 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[03:16:04] <seb_kuzminsky> well...
[07:46:09] <KGB-linuxcnc> 05dgarr/lib_for_halfiles 916fb81 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=916fb81
[07:46:23] <KGB-linuxcnc> 05dgarr/hallib 0780025 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=0780025
[07:46:38] <KGB-linuxcnc> 05dgarr/v2_hallib 5636ed0 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5636ed0
[07:47:14] <KGB-linuxcnc> 05dgarr/moveoff 4f598a9 06linuxcnc 04. branch deleted * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=4f598a9
[07:48:07] <KGB-linuxcnc> 03Dewey Garrett 052.7 564f227 06linuxcnc 10(6 files) apps/xhc-hb04: use hallib for cfg files * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=564f227
[08:19:50] <pcw_home> Another modest proposal: expose ferror limits as normal hal pins
[08:30:48] <dgarr> pcw_home: halcmd show pin ini.0.\*ferror
[08:30:50] <dgarr> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commitdiff;h=e5858b2f054a0cfaf6b773ad22d572d490e58322
[08:31:20] <pcw_home> can you set it that way?
[08:31:37] <dgarr> yes
[08:33:01] <dgarr> for example: $ sim_pin ini.0.ferror
[08:33:30] <dgarr> bbl
[08:33:35] <pcw_home> This is in reference to someones problem on the forum (they want wide ferror limits before machine is homed)
[08:39:52] <seb_kuzminsky> pcw_home: i dont understand why they would want that
[08:39:56] <seb_kuzminsky> maybe i should read the forum
[08:41:36] <pcw_home> Yeah its a funny combined homing/limit switch issue (limit switch prevents drive motion in limit direction)
[08:42:02] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.7/sam 5578da6 06linuxcnc 10src/emc/sam/Submakefile sam: add missing build deps * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5578da6
[08:42:03] <pcw_home> they want to retain this for safety (cant blame them)
[08:42:21] <seb_kuzminsky> mhmm
[08:42:29] <pcw_home> but it look like dgarr's method will work
[08:42:41] <seb_kuzminsky> yeah his 'ini in hal' stuff is cool
[08:43:20] <seb_kuzminsky> err, you made another feature request on irc yesterday, and nobody implemented it yet, and i'm afraid it'll get buried and forgotten
[08:43:35] <seb_kuzminsky> could you put it on the bug tracker?
[08:43:40] <pcw_home> i just changed the ferror limits on a running system and generated a ferror
[08:43:41] <pcw_home> halcmd setp ini.0.min_ferror .00000
[08:43:55] <seb_kuzminsky> yay?
[08:44:05] <pcw_home> Yay!
[08:44:41] <seb_kuzminsky> err, in the feature-requests section,
http://sf.net/p/emc/feature-requests
[08:44:51] <seb_kuzminsky> bbl breakfast
[08:46:16] <pcw_home> bbl
[08:57:59] <linuxcnc-build_> build #1046 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/1046 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[09:16:17] <seb_kuzminsky> ah yeah
[09:16:33] <seb_kuzminsky> that failure is because i didn't mock up rtapi_get_clocks() for arm
[09:45:48] <cradek> pcw_home: if they REALLY cannot add a home switch, which is the obvious correct solution, they should use index-only homing
[10:05:04] <linuxcnc-build_> build #2869 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/2869 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[10:09:39] <KGB-linuxcnc> 03Dewey Garrett 052.7 53cf457 06linuxcnc 10configs/sim/axis/moveoff/moveoff_base.inc moveoff sim demos:fix home sequence for all demos * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=53cf457
[10:16:50] <pcw_home> But index only still needs a home switch and the combined home/limit is the problem (as long as they wish to retain the servo drives built in protections)
[10:17:10] <cradek> no
[10:17:15] <cradek> index-only means it uses only the index
[10:17:41] <cradek> you position it by hand between index pulses
[10:18:00] <cradek> so you can home to index without using (or having) any switches at all
[10:18:01] <seb_kuzminsky> the "homing sequences" documentation does not show that mode:
http://linuxcnc.org/docs/2.7/html/config/ini_homing.html#_homing_sequence
[10:18:25] <pcw_home> Oh sure but that a bit awkward (this is apparently a large and fast machine)
[10:18:40] <cradek> seb_kuzminsky: it's in section 3
[10:19:06] <seb_kuzminsky> cradek: right, i see it there
[10:19:09] <cradek> pcw_home: I hear lots of commercial machines use that system (I've only used it on a rotary table)
[10:19:29] <cradek> I think we added it because stuart wanted it because his guys were used to aligning marks to home
[10:19:56] <cradek> you just jog so the marks are aligned, and then poke home
[10:20:22] <seb_kuzminsky> i'm often surprised by what real machinists think is a good idea
[10:20:30] <pcw_home> It does look like it can be done with ini poking
[10:22:32] <cradek> heh
https://www.youtube.com/watch?v=dJFXcgObUlk
[10:23:37] <cradek> seb_kuzminsky: if the marks are near the center of travel, you might be able to avoid a lot of slow searching on a big machine
[10:23:55] <pcw_home> Yeah i was thinking that
[10:24:08] <cradek> smashing into limit switches that disable the amps and turn on braking, in normal usage, just seems really stupid to me
[10:24:23] <cradek> those are emergency systems
[10:24:54] <cradek> it seems like it would be kind of violent, if nothing else
[10:25:19] <cradek> how does it reenable the amp smoothly when it's now out of position?
[10:25:51] <pcw_home> I does simplify things (less troublesome switches and wiring, switches get tested regularly)
[10:26:34] <pcw_home> the amp is only enabled for motion away from the switch at this point
[10:27:06] <cradek> oh I see
[10:27:33] <cradek> so at least the velocity loop stays active
[10:27:41] <pcw_home> but theres a bug thunk obviously when the limit is hit...
[10:27:54] <cradek> yeah
[10:28:33] <cradek> sometimes when retrofitting, people are resistant to making the machine work better than before
[10:28:45] <pcw_home> they wanted to disable the limits but making them a few MM is safer
[10:29:08] <cradek> I don't understand that mindset
[10:29:16] <pcw_home> Yeah but it is often difficult to add switches that were not designed in
[10:29:22] <cradek> I fixed a bug in my vmc by moving sensors around on the toolchanger
[10:30:10] <cradek> I understand the original control would sometimes get the wrong tool and then (possibly) crash it, and it was not hard to see why when figuring out the carousel sensors
[10:31:20] <cradek> I'll stop offering advice to not even the right person now :-)
[10:32:08] <pcw_home> If they had a problem like that you would think they would put a _lot_ of effort into fixing it
[10:32:38] <cradek> yeah, I don't understand it. the fix was easy.
[10:33:03] <cradek> stuart said on theirs, they'd just check each tool change, and if it got too confused they'd change tools manually until they could reboot it
[10:34:19] <cradek> it's just clearly broken (it has two sensors, but they're not in quadrature, and it assumed it always went the commanded direction and there were no extra edges, even though it was using dumb contactors to run and brake a 3 phase motor
[10:34:23] <cradek> )
[10:34:58] <cradek> so I moved one (tap two holes) and got quadrature
[10:36:41] <pcw_home> must not have thought of quadrature
[10:38:58] <pcw_home> Some Fadals have the home index system (I think they expect the controller is never turned off so this is only done rarely)
[10:40:08] <seb_kuzminsky> CNC Workshop in June! I hope to see you all there!
[10:40:18] <pcw_home> I'm still amazed that the Fanuc absolute encoders will count on battery backed power alone
[10:59:22] <cradek> pcw_home: they must not be optical?
[10:59:25] <rob_h> pcw_home, the mitsubishi also do that.. if you move the machine with the control off, it alarms on power up and you have to rehome/zero it all
[11:24:00] <pcw_home> cradek: they _are_ optical which makes it all the more amazing
[11:29:37] <pcw_home> They draw about 20 uA battery power when idle but this goes up to a few mA if you turn the shaft
[11:29:38] <pcw_home> so I think they just pulse the LEDs/analog/ count circuitry for a few 10s of usec and then sleep a few ms,
[11:29:40] <pcw_home> but then lower the sleep time based on velocity, much more sophisticated than I expected
[11:32:46] <pcw_home> rob_h: the fanuc encoders are even better, as long as you do not lose battery power, you never need to rehome
[12:12:50] <rob_h> yea just mits control even some fanucs depends on setup, do a grid shift postion base and compare encoder to prdited postion so kinda check to see if machine is in its known postion to encoder counts
[12:13:22] <rob_h> and yea mitss if u turn on and off u never have to home the machine just press start.. so much nicer having absolute encoders on cnc
[13:48:58] <KimK> Their medium-sized battery (What, 6 "D" Ni-Cads? A group of small gel-cells? I forgot.) will only retain position with the power off for seven days. After that you have to rehome everything. So it covers 99% percent of failures. Some failures are human-introduced though, and those are hard to protect against. ("Me?! I thought *you* were going to turn it back on!")
[13:55:13] <cradek> I thought it was your turn to buy the D cells
[13:55:34] <KimK> Ha!
[13:57:23] <Tom_itx> KimK, have you guys started running 2.6 on anything over there yet?
[13:58:21] <KimK> I don't think so. I'll check later.
[13:58:49] <Tom_itx> just curious if anybody is running it on hardware yet
[13:58:56] <seb_kuzminsky> Tom_itx: i am
[13:59:03] <seb_kuzminsky> well, i was, until i upgraded to 2.7
[13:59:16] <Tom_itx> is 2.7 stable enough to use?
[13:59:28] <Tom_itx> i'm gonna need to upgrade when my 7i90 card comes
[13:59:31] <cradek> I use 2.6 regularly
[13:59:43] <Tom_itx> apparently it's not supported under 2.5.x
[14:00:05] <cradek> I thought everyone was using 2.6
[14:00:13] <seb_kuzminsky> Tom_itx: i've not run into any problems with 2.7 for a while now, and nothing bad ever
[14:00:15] <cradek> it's way along in the bugfix/stabilizing stage
[14:00:43] <Tom_itx> it's not the .iso image is it? that's still 2.6 right?
[14:00:52] <seb_kuzminsky> there's an iso for 2.6 and one for 2.7
[14:00:59] <Tom_itx> oh
[14:01:03] <Tom_itx> wasn't aware of that
[14:01:22] <Tom_itx> i was just gonna build it from source
[14:01:40] <seb_kuzminsky> we haven't announced the 2.7 iso widely yet, i was planning to do that with the 2.7.0~pre3 release, coming up any day now
[14:01:48] <seb_kuzminsky> building from source works too :-)
[14:01:51] <Tom_itx> will 2.7 upgrade with the package manager?
[14:02:02] <Tom_itx> or just 2.6
[14:02:12] <seb_kuzminsky> the package manager will never upgrade 2.X to 2.Y, that's by design
[14:02:24] <seb_kuzminsky> it'll upgrade 2.X.Y to 2.X.Z for both 2.6 and 2.7
[14:02:42] <seb_kuzminsky> you can get 2.7 packages from either linuxcnc.org or from the buildbot
[14:02:56] <seb_kuzminsky> http://linuxcnc.org/docs/2.7/html/getting-started/index.html#_getting_linuxcnc
[14:03:25] <seb_kuzminsky> does that make sense? is that the question you were asking?
[14:03:51] <Tom_itx> the update page says it will update from 2.5 to 2.6...
[14:03:58] <Tom_itx> with package manager
[14:04:12] <seb_kuzminsky> you can, but you need to take some manual steps, it won't happen automatically
[14:04:33] <seb_kuzminsky> instructions for 2.6 -> 2.7 are here:
http://linuxcnc.org/docs/2.7/html/getting-started/index.html#_updating_linuxcnc
[14:05:28] <seb_kuzminsky> something analogous works for 2.5 -> 2.6, those instructions are here:
http://wiki.linuxcnc.org/cgi-bin/wiki.pl?UpdatingTo2.6
[14:05:28] <Tom_itx> any config changes from 2.5.x to 2.7?
[14:05:38] <seb_kuzminsky> yeah, some
[14:05:48] <Tom_itx> the TP i'm aware of
[14:05:54] <seb_kuzminsky> the 2.5->2.6 page lists those config changes, and the 2.6->2.7 page lists those
[14:06:09] <Tom_itx> k
[14:06:26] <KimK> And speaking of changes, Hi Seb, just the guy I was looking for. Now that the 5i22 is being handled in hm2 as two separate cards (5i22-1, 5i22-1.5), that changes the created items right? old: ...5i22.0.read becomes new: ...5i22-1.5.0.read (for example)?
[14:06:32] <seb_kuzminsky> hi kim!
[14:06:45] <seb_kuzminsky> ah, not quite
[14:06:53] <seb_kuzminsky> mesa makes two versions of the 5i22
[14:07:15] <seb_kuzminsky> the 5i22-1 has a 1 mega-gate fpga, the 5i22-1.5 has a 1.5 meg one
[14:07:29] <seb_kuzminsky> so they have different firmwares
[14:07:34] <seb_kuzminsky> but other than that they're the same
[14:07:54] <KimK> So when called in hal they're both still just 5i22?
[14:08:00] <seb_kuzminsky> the hal objects don't reflect the fpga size, right
[14:08:08] <KimK> OK, thanks.
[14:08:08] <seb_kuzminsky> they're both called hm2_5i22.X.mumble
[14:08:34] <KimK> OK, thanks! I'll go mumble.
[14:08:54] <seb_kuzminsky> heh
[14:09:18] <seb_kuzminsky> i have a 5i22-1 in my bridgeport because i needed an extra io connector
[14:09:26] <seb_kuzminsky> this was before sserial expansion
[14:10:07] <Tom_itx> all the new mesa cards load the bit file in eeprom right?
[14:10:22] <seb_kuzminsky> i think so, yeah
[14:10:23] <Tom_itx> opposed to an ini config line
[14:10:29] <seb_kuzminsky> that seems to be the way peter's going lately
[14:12:05] <KimK> Who's our resident ClassicLadder expert, cmorley?
[14:13:31] <Tom_itx> so i assume loading the proper [HOSTMOT2] driver= will first look at the ini and if it doesn't find it, then looks at the card firmware?
[14:14:37] <seb_kuzminsky> Tom_itx: if you load a hostmot2 driver with config="firmware=some/file.bit", then it'll try to flash that bitfile
[14:15:02] <Tom_itx> even if it's loaded with the mesa utility?
[14:15:03] <seb_kuzminsky> if your config line doesn't specify a firmware, it assumes the board already has its firmware from some other mechanism
[14:15:08] <Tom_itx> ok
[14:15:27] <seb_kuzminsky> usually that's the board loading its own firmware from an on-board eeprom
[14:15:46] <Tom_itx> so specify the board= but leave the config= empty or left out
[14:16:13] <PCW> flash may not be quite the right term (if the firmware is specified it will try and program the FPGA with that firmware)
[14:16:13] <seb_kuzminsky> you might want other things in the config= line, but you dont need to have a firmware= part in it
[14:17:18] <PCW> and the firmware line will cause a failure (I think) with flash EEPROM cards since they cannot be written directy
[14:17:30] <Tom_itx> so still specify num_pwmgens etc and not rely on that from the bitfile
[14:18:01] <Tom_itx> i figured the bit file would specify all that
[14:18:15] <PCW> No, its read from the FPGA
[14:18:32] <PCW> nothing pokes at the bitfiles
[14:18:56] <PCW> (well mesaflash reads the header)
[14:19:00] <Tom_itx> so load the bitfile with mesaflash but still specify num_pwmgens num_encoders etc in the config= line?
[14:19:15] <PCW> thats always been true
[14:19:19] <mozmck1> Been playing a little with cairo, and made a little fancier round LED. Patch here if anyone wants to see it:
http://pastebin.com/7wn3w8pt
[14:19:21] <Tom_itx> and any unused is GPIO
[14:19:31] <Tom_itx> ok
[14:19:53] <PCW> none of that changes with flash EEPROM FPGA cards
[14:20:08] <Tom_itx> good to know. i've not owned one yet
[14:20:38] <PCW> The only thing that changes is that you cannot specify the firmware on the command line
[14:20:45] <Tom_itx> right
[14:20:45] <seb_kuzminsky> mozmck1: do you have a screenshot?
[14:21:07] <PCW> less lumpy LED?
[14:21:32] <mozmck1> hmm, I could probably make one right quick. If you apply that you can run without rebuilding and see it in the gladevcp sim config.
[14:30:00] <mozmck> hmm, net quit for a minute.
[14:33:59] <mozmck> logger[psha]: ?
[14:33:59] <logger[psha]> mozmck: Log stored at
http://psha.org.ru/irc/%23linuxcnc-devel/2015-01-02.html
[14:34:42] <mozmck> seb_kuzminsky:
http://ibin.co/1mnFAeSpPk7Z
[14:47:17] <skunkworks> oh,,, pretty
[14:57:34] <KGB-linuxcnc> 03Norbert Schechner 052.6 28436b5 06linuxcnc 10lib/python/gladevcp/combi_dro.py combi_dro - bug in set forground color attribut * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=28436b5
[15:00:17] <KGB-linuxcnc> 03Norbert Schechner 052.6 07c1fdc 06linuxcnc 10src/emc/usr_intf/gmoccapy/gmoccapy.glade 10src/emc/usr_intf/gmoccapy/gmoccapy.py 10src/emc/usr_intf/gmoccapy/release_notes.txt gmoccapy_1_4_1 - added support to select number of digits * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=07c1fdc
[15:02:20] <KGB-linuxcnc> 03Norbert Schechner 052.7 944be60 06linuxcnc Merge branch '2.6' into 2.7 * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=944be60
[15:02:59] <KGB-linuxcnc> 03Norbert Schechner 05master 218fe70 06linuxcnc Merge branch '2.7' * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=218fe70
[16:07:25] <Tom_itx> are there config changes from 2.5 to 2.6? or just 2.6 to 2.7?
[16:09:20] <Tom_itx> i note the instructions say to go from 2.5 -> 2.6 -> 2.7
[16:21:30] <mozmck> Tom_itx: I think there is new config stuff for the new TP in 2.7
[16:21:54] <cradek> that all works by default
[16:22:03] <mozmck> ah, ok
[16:22:04] <seb_kuzminsky> Tom_itx: there 2.5 -> 2.6 config changes are detailed in the wiki link i sent you above
[16:22:25] <seb_kuzminsky> mozmck: are the new LEDs the ones on top? Prepared Tool, Current Tool, and System?
[16:22:31] <mozmck> yes
[16:22:32] <Tom_itx> yep, i was looking at that
[16:22:51] <seb_kuzminsky> very shiny :-)
[16:22:52] <Tom_itx> can't jump from 2.5 to 2.7 though
[16:23:23] <seb_kuzminsky> Tom_itx: yeah, that's not recommended
[16:24:13] <seb_kuzminsky> we take care to detail the changes users need to do when going from each version to the next, so it's easy to go sequentially through a couple of versions
[16:24:21] <Tom_itx> is the RTAI better in wheezy than lucid?
[16:24:36] <Tom_itx> yeah i'm ok with that
[16:24:38] <seb_kuzminsky> it's better on some systems, worse on some
[16:24:43] <Tom_itx> ok
[16:25:02] <seb_kuzminsky> and there seems to be no way to predict how a particular system will behave, you have to just try it
[16:25:25] <Tom_itx> i'll run the latency test from the SSD with wheezy and see
[16:25:36] <seb_kuzminsky> good thing for us cradek made a Live system on the standard Live/Install Image, so you can try it out without jeopardizing any existing install on the system
[16:25:45] <Tom_itx> does the hdd access affect the latency test?
[16:25:51] <seb_kuzminsky> nope, not at all
[16:25:54] <Tom_itx> ok
[16:25:55] <seb_kuzminsky> err
[16:25:58] <seb_kuzminsky> it shouldnt
[16:26:00] <seb_kuzminsky> heh
[16:26:04] <Tom_itx> i've got wheezy on the ssd
[16:26:40] <seb_kuzminsky> mozmck: do you want your led changes in 2.7?
[16:26:47] <Tom_itx> maybe i can be up and running next week again
[16:26:49] <PCW> for a step/dir machine with a hardware stepgen, latency is not terribly important
[16:27:24] <Tom_itx> good numbers make me feel better though!
[16:27:26] <mozmck> seb_kuzminsky: oh, I don't know - if people like them better that is fine with me.
[16:28:13] <mozmck> I am learning some cairo for a project, and that's what I wound up working on that looked fairly easy.
[16:28:34] <PCW> 50 usec is probably ok with stock configs (and 2 ms latency is ok with PID stepgen, DPLL and 250 hz servo thread)
[17:26:03] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/use_hallib 5b07e47 06linuxcnc 10(66 files in 35 dirs) hallib: manage halfiles formerly copied by make * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=5b07e47
[17:26:04] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/use_hallib 40896e7 06linuxcnc 10(67 files in 29 dirs) hallib: add most-used halfiles * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=40896e7
[17:26:04] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/use_hallib 6eeafa3 06linuxcnc 10lib/hallib/README lib/hallib/README: update and reorganize * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=6eeafa3
[17:26:05] <KGB-linuxcnc> 03Dewey Garrett 05dgarr/use_hallib 96660b3 06linuxcnc 10(15 files) smithy configs: use as HALFILE not POSTGUI_HALFILE * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=96660b3
[18:02:06] <skunkworks> why am I getting this? I don't remember having issues before
[18:02:08] <skunkworks> http://pastebin.ca/2896009
[18:02:50] <skunkworks> I am just trying to pull robs latest changes.
[18:03:42] <seb_kuzminsky> "git pull" means "git fetch && git merge"
[18:04:06] <seb_kuzminsky> the merge step needs your current branch to have a tracking branch, so it knows what to merge with
[18:04:19] <seb_kuzminsky> what branch are you on, and what's its tracking branch?
[18:04:52] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-rob$ git branch
[18:04:54] <skunkworks> * github-robE/feature/spiral-arc-handling
[18:06:02] <seb_kuzminsky> git branch -vv
[18:06:14] <seb_kuzminsky> that'll show what each of your local branches is tracking, if anything
[18:08:10] <seb_kuzminsky> if your branch is not set up to track, you can add that with 'git branch --set-upstream remote/somebranch'
[18:08:29] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-rob$ git branch -vv
[18:08:30] <skunkworks> * github-robE/feature/spiral-arc-handling d237a26 Merge branch '2.7'
[18:08:31] <seb_kuzminsky> err, 'git branch --set-upstream mybranch remote/somebranch
[18:08:32] <skunkworks> master d237a26 [origin/master: behind 25] Merge branch '2.7'
[18:08:33] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-rob
[18:08:47] <seb_kuzminsky> right
[18:08:52] <skunkworks> I guess that is what it says.. :)
[18:09:01] <seb_kuzminsky> so the lack of [something: behind somewhat] on your branch means there's no tracking
[18:09:34] <seb_kuzminsky> did you intend to name your branch beginning with "github-robE/"?
[18:09:58] <seb_kuzminsky> that looks like it might collide with a remote name, and a remote-tracking branch
[18:10:18] <skunkworks> that was the name I used for robs github
[18:11:01] <seb_kuzminsky> so github-robE is the name of the remote, right? you can run "git show -n github-robE" and get info about rob's repo on github?
[18:11:13] <seb_kuzminsky> if so, your local branch should not have that in the name
[18:11:43] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-rob$ git show -n github-robE
[18:11:44] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-rob$
[18:12:17] <seb_kuzminsky> hm
[18:12:37] <seb_kuzminsky> what's 'git remote' say for it?
[18:13:22] <skunkworks> skunkworks@skunkworks-Studio-XPS-1645:~/linuxcnc-rob$ git remote
[18:13:24] <skunkworks> github-robE
[18:13:25] <skunkworks> origin
[18:13:35] <seb_kuzminsky> wat
[18:14:00] <seb_kuzminsky> oh
[18:14:05] <skunkworks> I already built the /feature/spiral-arc-blending.. I just want to get the latest
[18:14:10] <seb_kuzminsky> i meant 'git remote show -n github-robE'
[18:14:22] <seb_kuzminsky> but now we know you have that remote
[18:14:38] <seb_kuzminsky> so you should rename your local branch, lest madness perch on your skulltop
[18:15:07] <seb_kuzminsky> git branch -m $OLD $NEW
[18:15:11] <skunkworks> http://pastebin.ca/2896026
[18:15:28] <seb_kuzminsky> yep, good
[18:15:38] <seb_kuzminsky> rename your local branch so it doesn't hide rob's branch
[18:15:44] <skunkworks> I could just start over... :)
[18:15:47] <seb_kuzminsky> then set your local branch to track rob's branch
[18:15:53] <skunkworks> ok
[18:15:54] <seb_kuzminsky> then pull
[18:16:03] <skunkworks> so - what was the issue?
[18:16:42] <seb_kuzminsky> you accidentally created a local branch with the exact same name as your local remote-tracking branch (ie the one in your repo that is an exact copy of the branch in rob's repo)
[18:17:11] <seb_kuzminsky> because you put "github-robE/" at the beginning of your branch name, and that collides with the name you have for rob's remote
[18:17:54] <seb_kuzminsky> normally when you create a local branch from a remote-tracking branch, it sets the local branch up to automatically track the remote-tracking branch
[18:18:23] <seb_kuzminsky> but in this case, i bet git noticed that it would have set your local branch up to track itsef (since local branch names take precedence over remote-tracking branches) and helpfully skipped that step for you
[18:35:27] <skunkworks> ah- normally I name the branch... I was lazy and thought - it shouldn't matter
[18:35:46] <skunkworks> it does!
[21:19:37] <skunkworks> the runtests fail on uspace also.. I think I may have not been in the right location the first time.
[21:21:27] <Tom_itx> what's the status of the ethernet mesa boards? are they ready for mainstream or still in the testing phase?
[21:37:27] <skunkworks> they are supported in 2.7 and on..
[21:37:47] * skunkworks is comfortable with them..
[21:38:13] <skunkworks> you need to make sure whatever nic you use plays well with uspace.
[21:48:16] <skunkworks> (rt_preempt
[22:31:10] <Tom_itx> someone was looking for it on the store site but it's not there yet
[22:31:24] <Tom_itx> made me wonder how it was coming along
[22:33:19] <skunkworks> it?
[22:33:32] <skunkworks> I am testing a 7i80
[22:33:47] <Tom_itx> well one of the ether cards
[22:34:02] <skunkworks> there are a few ethernet mesa boards
[22:34:22] <skunkworks> the 7i80 is pretty much the ethernet version of the 5i20
[22:35:11] <Tom_itx> 7I92 maybe it was...
[22:35:33] <Tom_itx> not too many IO on it
[22:36:39] <skunkworks> we plan on using the 7i80 for either the lathe or the matsurra.. (which ever one dies or gets too annoying...)