Back
[00:06:29] -!- PCW_ has quit [Remote host closed the connection]
[00:18:54] -!- rob_h has quit [Quit: Leaving]
[00:32:06] -!- dnaleromj has quit [Ping timeout: 276 seconds]
[00:32:36] -!- dnaleromj [dnaleromj!~dnaleromj@user-69-1-6-88.knology.net] has joined #linuxcnc-devel
[00:39:54] -!- kingarmadillo has quit [Ping timeout: 276 seconds]
[01:05:22] -!- skunkworks__ [skunkworks__!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[02:28:54] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 fff202e 06linuxcnc 10src/emc/motion/command.c 10src/emc/motion/control.c 10src/emc/motion/mot_priv.h motion/ fix mistakenly retained check_stuff() JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=fff202e
[02:28:54] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 767b54a 06linuxcnc 10share/axis/tcl/axis.tcl axis.tcl restore removed set_mode_from_tab call JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=767b54a
[02:28:54] <KGB-linuxcnc> 03Dewey Garrett 05joints_axes14 b536f9c 06linuxcnc 10src/emc/usr_intf/axis/scripts/axis.py axis.py del unneeded set_motion_teleop instance JA * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=b536f9c
[02:41:38] -!- kingarmadillo has quit [Ping timeout: 244 seconds]
[03:05:34] -!- skorasaurus has quit [Ping timeout: 240 seconds]
[03:50:37] <mozmck> this might be an interesting alternative to libreadline with it's license issues:
https://github.com/antirez/linenoise
[04:06:10] -!- dgarr [dgarr!~dgarrett@184-98-142-4.phnx.qwest.net] has joined #linuxcnc-devel
[04:06:38] <dgarr> seb_kuzminsky: It looks like users trying to get buildbot scratch debs using synaptic don't get the most recent one available:
[04:06:38] <dgarr> https://forum.linuxcnc.org/forum/47-hal-examples/30818-gantry-hal-example?start=20#75100
[04:07:23] -!- dgarr has quit [Client Quit]
[05:25:49] <KGB-linuxcnc> 03Sebastian Kuzminsky 05seb/2.6/statbuffer-g5x-abort e6d2216 06linuxcnc 10(6 files) add a test to reproduce the preview-strangeness reported by Zultron * 14http://git.linuxcnc.org/?p=linuxcnc.git;a=commitdiff;h=e6d2216
[05:48:16] <linuxcnc-build> build #2320 of 1403.rip-wheezy-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1403.rip-wheezy-amd64/builds/2320 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:49:21] <linuxcnc-build> build #2320 of 1400.rip-wheezy-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1400.rip-wheezy-i386/builds/2320 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:50:35] <linuxcnc-build> build #4159 of 1300.rip-precise-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1300.rip-precise-i386/builds/4159 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:51:34] <linuxcnc-build> build #788 of 1520.rip-jessie-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1520.rip-jessie-amd64/builds/788 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:52:47] <linuxcnc-build> build #4161 of 1202.rip-lucid-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1202.rip-lucid-amd64/builds/4161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:53:08] <linuxcnc-build> build #4161 of 1306.rip-precise-amd64 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1306.rip-precise-amd64/builds/4161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:53:57] <linuxcnc-build> build #4161 of 1200.rip-lucid-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1200.rip-lucid-i386/builds/4161 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:53:57] <linuxcnc-build> build #788 of 1500.rip-jessie-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1500.rip-jessie-i386/builds/788 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:55:16] <linuxcnc-build> build #1986 of 1401.rip-wheezy-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1401.rip-wheezy-rtai-i386/builds/1986 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[05:58:10] <linuxcnc-build> build #3370 of 1301.rip-precise-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1301.rip-precise-rtai-i386/builds/3370 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:09:24] <linuxcnc-build> build #4169 of 1201.rip-lucid-rtai-i386 is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/1201.rip-lucid-rtai-i386/builds/4169 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:09:24] <linuxcnc-build> build #4173 of 0000.checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/0000.checkin/builds/4173 blamelist: Sebastian Kuzminsky <seb@highlab.com>
[06:15:38] -!- kwallace [kwallace!~kwallace@162.222.30.254] has parted #linuxcnc-devel
[06:23:08] -!- ve7it has quit [Remote host closed the connection]
[06:46:29] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[06:47:32] -!- teepee has quit [Ping timeout: 244 seconds]
[06:47:34] teepee_ is now known as teepee
[06:56:29] -!- cmorley has quit [Quit: Leaving.]
[07:55:24] -!- Komzpa has quit [Ping timeout: 276 seconds]
[07:59:52] -!- Mathnerd314 has quit [Ping timeout: 244 seconds]
[08:30:38] -!- kalxas has quit [Changing host]
[09:19:36] -!- ivansanchez has quit [Remote host closed the connection]
[09:28:17] -!- b_b has quit [Changing host]
[10:00:47] -!- Daerist has quit [Quit: Leaving]
[10:19:10] -!- gaute has quit [Ping timeout: 250 seconds]
[10:58:04] -!- skunkworks__ has quit [Ping timeout: 260 seconds]
[11:45:39] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[11:54:13] -!- ktchk [ktchk!~eddie6929@n219079127085.netvigator.com] has joined #linuxcnc-devel
[12:08:28] <jepler> The value of drive-through contributions
https://lwn.net/SubscriberLink/688560/3c94df68e5d5b56d/
[13:00:53] <skunkworks> ugh..
http://www.cnczone.com/forums/uncategorised-cam-discussion/307546-cnc-software-3.html#post1888876
[13:03:44] -!- patsy has quit [Quit: Pull the pin and count to what?]
[13:08:15] <archivist> do you educate people like that or leave the incorrect statement out there...
[13:11:03] <skunkworks> I have failed at explaining it atleast 3 times now
[13:11:48] <pcw_home> Mach centric blindspots? (I think he thinks LinuxCNC is step/dir at its base like Mach3)
[13:11:50] <pcw_home> his stuff about the Gecko is misleading as well (all you can do is widen the already too wide error limits)
[13:12:21] <skunkworks> right
[13:12:59] <skunkworks> and visually looking at the in position led means his machine is running great
[13:13:58] <pcw_home> Well its all he's got since at base Mach3 is open loop and at base linuxcnc was designed around closed loop
[13:15:15] <pcw_home> this does remind me, it would be nice to have 2 ferror threshold in linuxcncs, one for warning and one for stop
[13:32:33] <skunkworks> Hmm - sounds interesting.. I bet that could be done with hal?
[13:33:00] <pcw_home> Yes it could
[13:39:33] <pcw_home> I suspect in most machining situations, a machine fault from a following error is pretty
[13:39:35] <pcw_home> disastrous so that argues for quite wide limits to avoid nuisance trips
[13:39:36] <pcw_home> but a warning limit (and perhaps having the peak ferror recorded) would be good for machine
[13:39:38] <pcw_home> maintenance
[13:40:45] <archivist> that makes me think of tap breakage alarm and tool wear measuring
[13:53:04] -!- kalxas has quit [Ping timeout: 240 seconds]
[13:54:12] kalxas_ is now known as kalxas
[14:08:55] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[14:10:42] <jepler> part of the calculus would be: how much less ruined is work / vise / table / etc after a 1mm following error vs a .01mm following error?
[14:13:09] <jepler> let alone 10mm
[14:35:34] -!- kwallace [kwallace!~kwallace@162.222.30.254] has joined #linuxcnc-devel
[14:38:55] -!- racicot has quit [Quit: Z-Pulley - Later]
[14:39:23] -!- Mathnerd314 [Mathnerd314!~quassel@supertux/Mathnerd314] has joined #linuxcnc-devel
[15:10:20] <pcw_home> To me, there seem to be 2 purposes for following error limits (and it seems like the limit sizes should be different)
[15:10:21] <pcw_home> 1. Safety / machine fault detection
[15:10:23] <pcw_home> 2. Performance monitoring (perhaps with peak ferror recording)
[15:21:53] -!- ivansanchez has quit []
[16:14:02] <mozmck> Well, I got a simple rfl to do something. It fails in a different way than the normal one...
[16:14:43] -!- CaptHindsight has quit [Ping timeout: 250 seconds]
[16:14:55] <cradek> yay?
[16:15:31] <pcw_home> failing in a different way is progress
[16:15:47] <skunkworks> have you slept?
[16:15:47] <mozmck> heh, I'm apparently missing something that needs to be cleared out.
[16:15:57] <mozmck> Yes, I slept :-)
[16:16:54] <mozmck> I may need to figure out exactly how external file o-word subs are executed.
[16:16:58] <skunkworks> I would have used a goto jump.
[16:17:08] <mozmck> There's one in there ;-)
[16:17:28] <skunkworks> ;) Just read my REM statements
[16:18:42] <pcw_home> At least you got a change, I just spent 1/2 an hour trying to fix some Xilinx RAM compile warnings, result: exact same warnings
[16:19:11] -!- md-2 has quit [Quit: Leaving...]
[16:19:49] <mozmck> heh, not familiar with xilinx much (yet), but certainly familiar with going around in circles.
[16:21:11] <skunkworks> pcw_home, there is a thread on the forum about ethercat - the guy switched from a e1000e compatable nic (intel) to a realtech and it solved his issue.
[16:21:23] <pcw_home> Apparently you can infer any type of dual ported RAM you like but it always make one with 2 read and 2 write ports even if you only need 1read/1write (and complains about the unconnected output port)
[16:22:24] <pcw_home> skunkworks: the H97 MB has a E1000 compatible NIC and has no issues
[16:22:43] <skunkworks> maybe it is certain series.
[16:22:58] <pcw_home> but its a newer one ( a 211 I think)
[16:25:48] <jepler> ethercat's hardware needs are different from hm2_ethernet too
[16:26:15] <pcw_home> I think Ive heard of firmware bugs in the early E1000s
[16:29:19] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[16:43:01] -!- CaptHindsight has quit [Ping timeout: 240 seconds]
[16:46:19] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[16:51:33] <pcw_home> what specific MAC chip do you have trouble with ?
[16:51:34] <pcw_home> the DC7800 I use has a Intel 82566DM which works OK ( I Guess all Intel 1Gbe MACs show up as PRO/1000)
[17:00:06] -!- Komzpa has quit [Ping timeout: 276 seconds]
[17:13:09] <skunkworks> This is a 82579lm
[17:13:20] <skunkworks> (but it is also a laptop)
[17:19:50] -!- b_b has quit [Remote host closed the connection]
[17:21:15] <pcw_home> Yeah, still suspicious that is some funny power saving feature
[17:21:23] <pcw_home> that its
[17:21:33] <skunkworks> right
[17:21:52] -!- kalxas has quit [Quit: Goodbye]
[17:28:00] -!- ktchk [ktchk!~eddie6929@n219079127085.netvigator.com] has parted #linuxcnc-devel
[17:31:29] -!- skunkworks__ [skunkworks__!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[17:49:13] <mozmck> So my SRFL is barfing on the first line with no G-code, because there is no state information :-/
http://pastie.org/10853722
[17:53:13] <mozmck> which means I probably can't call Interp::read without modification
[18:00:08] <mozmck> Here's what I've done so far.
https://github.com/mozmck/linuxcnc-mirror/commit/28420306f9a32ceb70669efd2bd5e0c33f9ce873?diff=split
[18:00:36] <mozmck> I was hoping to be able to do this all in task, but it looks like it won't be that easy.
[18:01:52] <mozmck> I was trying to just have Interp read the lines to update the file position, but it does too much checking while it reads.
[18:04:07] <mozmck> Any ideas on a better method?
[18:08:04] <mozmck> hmm, I could make simpleRunFromLine global, and in Interp::read() I could simply not call parse_line() if it's set - no telling what side effects that will have.
[18:12:51] <cradek> can you give me an example of what you mean by first line with no gcode?
[18:15:04] <cradek> mozmck: one early comment: I get lost in your diff because of the whitespace changes in emctaskmain - it sure was bad before, but it'd be better that if you must fix it, to do that in a separate commit that makes no functional change.
[18:15:54] <mozmck> The gcode is in the pastie link: line 8 of the Gcode is X8.845 Y0.375
[18:16:18] <cradek> ah yep, I'd expect that to be an error in SRFL
[18:16:23] <cradek> I think that is the right behavior
[18:16:26] <mozmck> Yes, I notice the whitespace is not handled well be github's diff viewer
[18:16:40] <cradek> you would need to MDI G0 or G1 first, before you SRFL that
[18:16:43] <mozmck> Meld shows it much nicer
[18:17:14] <mozmck> yes, but I was SRFL'ing (???) from line 27, so it should have just skipped over line 8
[18:17:21] <cradek> mozmck: my feedback about changing it is the same, regardless of how tools show it
[18:17:26] <cradek> oh! I misunderstood then
[18:17:49] <mozmck> I'm going to try my idea in Interp::read() - I think it might work.
[18:17:56] <cradek> if we want to make "srfling" a word I propose that we can do that :-)
[18:18:50] <mozmck> I'll try to make the whitespace a separate commit. One problem with that though, is I wrapped most of the function in an else{ } block, which means I had to change the whitespace as part of that anyhow.
[18:19:25] <cradek> oh yeah, then it's unavoidable (unfortunately)
[18:19:25] <skunkworks> srfl?
[18:19:37] <mozmck> maybe we can call it "snurfling" to make it easier to pronounce :-)
[18:19:37] <cradek> I didn't see that in the first 50 lines or so and I have up trying to understand that block
[18:19:46] <cradek> gave
[18:20:36] <mozmck> Yeah. I have an if { } at the top that adds the SRFL stuff, and an else{ } that does the standard stuff
[18:20:48] <mozmck> skunkworks: simple-run-from-line
[18:21:29] <skunkworks> ah
[18:21:49] <cradek> i.e. start at the specified line after doing nothing else first
[18:22:31] <cradek> it has so many ways to bite you, but it's possible to give an implementation that does exactly what the instructions say :-)
[18:23:29] <mozmck> It is a separate NML command, and also python srfl_auto(), so it will not be used unless you specifically use that command. You could have both in a GUI to give users a choice.
[18:24:23] <mozmck> To test I'm simply modifying axis.py line 2040 from c.auto() to c.srfl_auto()
[18:41:31] <mozmck> So I added my flag to emcglb.h and emcglb.c, and it compiles fine but I get this: ImportError: /mnt/data1/Projects/linuxcnc/linuxcnc-dev/lib/librs274.so.0: undefined symbol: simpleRunFromLine
[18:41:56] <mozmck> when loading axis and hal_manualtoolchange
[18:43:05] -!- kingarmadillo has quit [Ping timeout: 260 seconds]
[19:17:38] -!- GJdan has quit [Remote host closed the connection]
[19:40:32] -!- CaptHindsight has quit [Quit: Leaving]
[19:46:40] <mozmck> Hmm, looks like I might have it working.
[19:46:51] <skunkworks> ooh...
[19:49:40] <mozmck> pretty neat :-)
[19:52:26] -!- skunkworks__ has quit [Ping timeout: 258 seconds]
[20:00:52] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:01:56] <mozmck> https://github.com/mozmck/linuxcnc-mirror/commit/7b4b5f51d88054b0a157c73853900b23d7d322aa
[20:03:00] <mozmck> I'm going to be testing this more thoroughly here. Please feel free to review this (and even make suggestions! ;-) )
[20:03:53] <mozmck> I did this on the 2.7 branch because that is what I need to use for now, but I would expect it might should go on master instead when finished.
[20:05:38] -!- CaptHindsight [CaptHindsight!~2020@unaffiliated/capthindsight] has joined #linuxcnc-devel
[20:08:31] -!- yonatham has quit [Remote host closed the connection]
[20:12:51] <seb_kuzminsky> mozmck: i agree, it should go in master instead of 2.7
[20:13:15] <seb_kuzminsky> you're of course welcome to put it in a feature branch off 2.7, and the buildbot will test it and make debs for you
[20:13:23] <seb_kuzminsky> just dont merge it into 2.7
[20:14:04] <mozmck> ok - I build my own debs here - that's pretty trivial
[20:14:31] <mozmck> What I haven't messed with is running tests (much less writing or even understanding them!)
[20:15:04] <mozmck> How do I run the tests?
[20:15:28] <jepler> scripts/runtests, or just runtests after you . rip-environment
[20:15:41] <mozmck> thanks
[20:17:15] <jepler> by default it runs them all, which takes a fair bit of time. You can run just specific tests by giving the path(s) on the commandline
[20:24:34] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[21:15:01] -!- skorasaurus has quit [Ping timeout: 250 seconds]
[21:21:01] -!- KimK has quit [Ping timeout: 240 seconds]
[21:25:04] -!- kingarmadillo has quit [Ping timeout: 240 seconds]
[21:26:27] -!- ve7it [ve7it!~LawrenceG@S010648f8b3c3bc3b.pk.shawcable.net] has joined #linuxcnc-devel
[21:34:16] -!- KimK [KimK!~Kim__@ip68-102-66-31.ks.ok.cox.net] has joined #linuxcnc-devel
[21:39:52] -!- skunkworks__ [skunkworks__!~skunkwork@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:42:03] <mozmck> Is there a way to delete branches on github?
[21:45:08] <jepler> git push has a "--delete" flag which deletes remote branches and tags instead of creating/updating them
[21:46:05] <jepler> you can also 'git push :branch-or-tag-to-delete'
[21:46:08] <jepler> git --help push
[21:46:24] <mozmck> ok. It would be nice if there was a way to have just a few branches in a linuxcnc fork, instead of 170+
[21:46:41] <jepler> github seriously sucks with respect to its branch management
[21:46:54] <mozmck> similar to a local clone where you only have the branches you are interested in tracked locally.
[21:46:58] <jepler> and yes, the fact that when you fork you get all the branches that the forked-from repository had at that time is one of them
[21:47:07] <jepler> this is bad design of github, not bad design of git
[21:47:32] <jepler> https://github.com/blog/1377-create-and-delete-branches
[21:47:33] <mozmck> Yes. I'm looking at gitlab, and they have a delete button by each branch
[21:47:39] <jepler> apparently there's also a delete branch on the github web ui if that's how you roll
[21:48:01] <mozmck> interesting, I didn't see that.
[21:49:36] <mozmck> Now I wonder if I can "pull" a branch from the web UI instead of pulling to the PC and pushing to github?
[22:10:48] -!- teepee_ [teepee_!~teepee@unaffiliated/teepee] has joined #linuxcnc-devel
[22:12:26] -!- teepee has quit [Ping timeout: 272 seconds]
[22:12:26] teepee_ is now known as teepee
[22:19:13] -!- andypugh [andypugh!~andypugh@cpc14-basl11-2-0-cust1010.20-1.cable.virginm.net] has joined #linuxcnc-devel
[22:27:47] <andypugh> Any thoughts of the zeroth spindle being controlled by motion.spindle-speed-out if num_spindles is not present as a modparam, and spindle.0.speed-out if the modparam is present? I confess I don’t especially like the kludge.
[22:28:25] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has joined #linuxcnc-devel
[22:29:58] <mozmck> I guess that is to keep from breaking existing configs?
[22:32:32] <andypugh> Yes
[22:33:02] <andypugh> If I roll it into JA then it isn’t an issue. We expect that to break configs.
[22:33:14] <mozmck> that's what I was about to say.
[22:33:32] <mozmck> And if JA merges into master before the next release...
[22:36:14] -!- BeachBumPete [BeachBumPete!~IceChat9@2601:585:8200:7a40:d0d5:13c1:9dae:52c] has parted #linuxcnc-devel
[22:41:29] <JT-Shop> are you going to do a num_spindles=n like num_dio and num_aio?
[22:41:42] <JT-Shop> with default at 1 spindle
[22:41:50] <JT-Shop> just thinking out loud...
[22:44:44] <andypugh> Yes.
[22:47:21] <JT-Shop> cool
[22:56:03] -!- kingarmadillo has quit [Ping timeout: 258 seconds]
[23:04:54] -!- JT-Shop has quit [Remote host closed the connection]
[23:05:59] -!- JT-Shop [JT-Shop!~john@198.45.191.246] has joined #linuxcnc-devel
[23:12:45] <jepler> argh
[23:12:50] <jepler> please consider NOT basing this on ja
[23:13:03] <jepler> it is like blackmailing everyone: you have to accept ja to accept unrelated feature X
[23:13:43] <jepler> and it also means: to accept ja you have to accept feature X
[23:13:58] <jepler> (well depending just how you structure your work, that may or may not be true)
[23:14:29] <jepler> afk
[23:18:58] <andypugh> jepler: Am I allowed to break existing configs?
[23:19:08] <seb_kuzminsky> in master, yes
[23:19:35] * seb_kuzminsky is jepler wearing a glue-on beard
[23:20:39] <cradek> allow me to add my voice to this chorus...
[23:20:46] <seb_kuzminsky> i agree with jepler - best practice is to not put unrelated features in a single feature branch
[23:21:18] <andypugh> Multi-spindles doess feel JA-ish to me.
[23:21:41] <seb_kuzminsky> does it use some feature that JA adds, that's not present in master?
[23:22:00] <andypugh> I am not saying that either is a necessary condition for the other, but it has a similar feel.
[23:22:35] <cradek> but it seems plausible that we could choose to merge them at different times
[23:22:52] <seb_kuzminsky> that's sure a nice freedom/ability to have
[23:23:08] <andypugh> Well, it would be a lot more elegant if it could rely on the pin-renaming macro, rather than futz about with two different styles of spindle control pins.
[23:23:44] <seb_kuzminsky> is the pin-renaming macro a feature that JA adds?
[23:24:02] <andypugh> Yes.
[23:24:52] <seb_kuzminsky> in that case i suggest rebasing ja so that the pin-renaming macro is at the beginning of the branch (right on top of master), merging just that feature into master, and basing the multi-spindle work on that new master
[23:25:02] <seb_kuzminsky> there are some other things in ja that need a rebase still
[23:25:27] <seb_kuzminsky> that would serve two goals: start merging JA into master in small, manageable chunks, and keep unrelated features on separate branches
[23:25:52] <andypugh> And retrospectively invent an INI file version < 1.0 ?
[23:26:36] <seb_kuzminsky> i dont understand what you mean
[23:26:52] <seb_kuzminsky> maybe because i dont really know what the pin-renaming macro is
[23:26:54] <cradek> oh you're talking about the config autoconverter?
[23:27:00] <andypugh> Yes
[23:27:23] <cradek> you could just break configs for now - avoid falling down a deeper rabbit-hole
[23:27:31] -!- rob_h [rob_h!~robh@2a02:c7f:5603:bc00:c1f1:78c8:e34e:8339] has joined #linuxcnc-devel
[23:27:32] <cradek> we break configs (in minor ways) for new major versions all the time
[23:27:40] <seb_kuzminsky> true
[23:27:51] <cradek> but if it turns out the next major version has both multipspindle and ja, we can make the autoconverter autoconvert both
[23:28:00] <andypugh> Breaking every config that uses a spindle might be a tiresome support burden.
[23:28:15] <andypugh> :-/
[23:28:18] <seb_kuzminsky> i broke every hm2 config once or twice, it wasn't that bad
[23:28:35] <seb_kuzminsky> i wrote down the simple change needed in the "Updating your config" part of our docs
[23:28:39] <andypugh> I contend that more configs have spindles than use hm2..
[23:28:48] <seb_kuzminsky> sure
[23:29:03] <seb_kuzminsky> i agree
[23:29:08] <andypugh> And the typical hm2 user is less nooby than the typical spindle user.
[23:29:10] <cradek> we can tie the branches together later if we decide to - there's no reason to do that as the first step
[23:29:49] <seb_kuzminsky> bbl
[23:29:50] <cradek> ok, that's all my opinions - in the end, the guy doing the work gets to decide how to do it
[23:30:34] <cradek> andypugh: I think it'll be a cool feature
[23:30:36] <andypugh> Also (not a great reason) all the physical machines I would be testing on run JA.
[23:30:45] <cradek> I'm off to make music, whee
[23:30:52] <cradek> bbl too
[23:31:03] <andypugh> But testing on sims probably works
[23:32:44] <andypugh> I think that my interest in multispindle is based on completion-anxiety with the lathe project, it’s pretty much at the point where it can bu used, and I get to find out if it’s a decent machine or not.
https://picasaweb.google.com/108164504656404380542/Holbrook#6289136113588913554
[23:51:05] -!- rob_h has quit [Ping timeout: 260 seconds]
[23:51:32] -!- pandeiro has quit [Remote host closed the connection]