Back
[09:57:09] <skunkworks> pcw_home, as I was drifting off to sleep I was thinking about your pll you are working on.. From what I gathered it is so - the (lets say the 7i80) can just send linuxcnc the data without being asked for it. So - how does it know when to send it when the jitter of the servo cycle can be + and - of the target period
[10:04:42] <pcw_home> The current (R14) firmware ist still completely master slave (or equivalent PC term)
[10:04:44] <pcw_home> but it can delay parsing of packets either with a time delay or waiting for a selected DPLL timer
[10:04:45] <pcw_home> so for a 2 packet mode, when the HostMot2 write packet is sent, that packet has:
[10:04:47] <pcw_home> 1. write (output) data
[10:04:49] <pcw_home> 2. wait for DPLL
[10:04:50] <pcw_home> 3. read commands
[10:05:52] <pcw_home> This does require that you read everthing you may need (since the read command is from the previous cycle)
[10:07:01] <pcw_home> DPLL jitter shoud be in the couple or uSec region assuming quite bad host jitter (say 120 usec)
[10:07:12] <pcw_home> couple of uSec
[10:09:49] <pcw_home> the DPLL does 2 things:
[10:09:49] <pcw_home> 1. Sample time jitter reduction
[10:09:50] <pcw_home> 2. Allow read pretrigger to absorb wire/parsing delays
[10:09:51] <pcw_home> and delays of slow hardware (sserial, SSI,BISS.Fanuc,SPI etc etc)
[11:03:33] <seb_kuzminsky> linuxcnc-build: force build --branch=master checkin
[11:03:34] <linuxcnc-build> build #1353 forced
[11:03:34] <linuxcnc-build> I'll give a shout when the build finishes
[12:02:04] <seb_kuzminsky> ok, the buildbot is building again
[12:02:20] <seb_kuzminsky> not the right fix, but a bandaid to get things moving again :-/
[12:05:30] <linuxcnc-build> Hey! build checkin #1353 is complete: Success [3build successful]
[12:05:30] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1353
[12:32:13] <jepler> seb_kuzminsky: thanks for your work on buildbot
[12:34:44] <IchGuckLive> jepler: what is changing i see lots of failues is there some new
[12:42:45] <mhaberler> jepler: Hi - I've gotten rid of the static _setup; but then again I dont get the segfault; would you do me the favor of trying this branch?
[12:43:01] <mhaberler> (g.l.o anti-static)
[12:43:51] <mhaberler> I am not sure if this will actually fix the segfault (I do hope though)
[13:07:38] <IchGuckLive> micges: i uploaded the english version
http://www.youtube.com/watch?v=zLXDc1aFmxg
[13:11:31] <andypugh> I _think_ you could halcmd the same HAL file as was used to load the gamepad originally, if it was in a separate file.
[13:11:55] <andypugh> (My gamepad tends to disappear sometimes too)
[13:12:18] <seb_kuzminsky> linuxcnc-build: force build --branch=v2.5_branch checkin
[13:12:18] <linuxcnc-build> build forced [ETA 1h01m55s]
[13:12:19] <linuxcnc-build> I'll give a shout when the build finishes
[13:12:20] <IchGuckLive> you only need to reload the connections not the halfile
[13:12:37] <IchGuckLive> and also you cand use the nice direction signes in the halcmd
[13:12:48] <andypugh> halcmd -f gamepad.hal (and then have HALFILE=gamepad.hal in the INI)
[13:13:25] <IchGuckLive> i try
[13:14:01] <IchGuckLive> the hint is that you need to initial the usb first then relconnect it
[13:14:07] <andypugh> There is no real advantage, except that if you update there is only one file to edit.
[13:14:12] <IchGuckLive> if you do in one step in one file it wont work
[13:14:29] <andypugh> Even with loadusr -W ?
[13:14:50] <IchGuckLive> need to rey this also
[13:15:21] <IchGuckLive> try B)
[13:16:17] <micges> IchGuckLive: glad it works
[13:16:32] <IchGuckLive> ;-)
[13:19:26] <IchGuckLive> andypugh: no it neads a timelaps from loadusr to connect the pins
[13:19:50] <IchGuckLive> therfore the loadustr gamepad is in the main ini
[13:20:49] <andypugh> Interesting. Because it works in a single file the first time round, and -W is meant to wait until the component has finished loading.
[13:21:37] <IchGuckLive> i tryed in the sim mashine not in the real
[13:21:54] <IchGuckLive> maybe realtime kernal acts the other way
[13:22:17] <IchGuckLive> im off for today wife calling BY
[14:28:18] <linuxcnc-build> Hey! build checkin #1354 is complete: Success [3build successful]
[14:28:18] <linuxcnc-build> Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1354
[15:01:32] <skunkworks> PCW, micges, mesa flash working on 12.04 64bit
http://pastebin.ca/2460941
[15:01:48] <skunkworks> Have not tried to flash it though... ;)
[15:04:15] <PCW> If it can communicate at all, everything should work, its just standard socket stuff
[15:04:16] <PCW> (PCI access may or may not work on a 64 bit host however)
[15:04:40] <PCW> (5I25, 6I25 etc)
[15:10:49] <skunkworks> I think mhaberler has a 5i25 working on 64 bit.. (I think)
[15:11:31] <mhaberler> I would have to plug the 5i25 into the amd, but I could try
[15:11:37] <mhaberler> any research issues here?
[15:12:10] <skunkworks> you had a video of the mesa card running - what system was that?
[15:12:19] <mhaberler> an atom
[15:12:39] <skunkworks> what os?
[15:12:49] <mhaberler> any os these days ;)
[15:13:01] <skunkworks> heh - 32/64?
[15:13:07] <mhaberler> 32
[15:13:21] <skunkworks> ah. PCW is wondering if it will work on 64
[15:13:47] <mhaberler> well I can try, not sure anybody did so far
[15:14:46] <skunkworks> right - I have only done the rtnet stuff in 64bit
[15:15:07] <skunkworks> bbl
[15:15:38] <PCW> Just wondering if the PCI access scheme will work on 64 bit (I would expect mesaflash Ethernet access to work on pretty much anything)
[15:15:52] <mhaberler> right, that needs a look
[15:16:23] <micges> skunkworks: that's great
[15:16:39] <micges> I don't have any 64 bit system atm
[15:44:44] <mhaberler> ubc3 runs the hm2-stepper config with an 5i25 just fine on an amd64, os=3.10.4 rt-preempt
[15:45:16] <cradek> awesome
[15:46:00] <mhaberler> were there any problems with that? probably just no amd rtai kernel, I guess?
[15:46:04] <cradek> we've seen hm2 stepgen being kind of brittle in the face of big latencies - do you see that?
[15:46:21] <mhaberler> how would I tickle that?
[15:47:05] <cradek> that's a good question, I don't remember even what the symptoms were
[15:47:10] <PCW> rt-preempt ought to :-)
[15:47:27] <cradek> PCW: do you remember how the problem shows up?
[15:47:46] <PCW> following errors
[15:47:56] <PCW> wacky motion
[15:48:05] <cradek> so it just falls behind, or is it weirder?
[15:48:54] <mhaberler> note this rt-preempt kernel is pretty good as far as rt-preempt kernels go, barely above 20-25uS latency
[15:49:13] <PCW> You wont see a problem there
[15:49:37] <cradek> wow, that is good
[15:51:20] <mhaberler> no following errors, and nothing suspicious in the log
[15:51:38] <cradek> mhaberler: any progress (or new obstacles) on jogging?
[15:52:36] <PCW> Basically the issue is with the hm2 stepgen driver is that the hardware stepgen has better short term
[15:52:38] <PCW> timing than the host but the driver does these huge velocity corrections based on the assumption
[15:52:40] <PCW> that the servo period is constant
[15:52:41] <mhaberler> nothing fundamental; I've switched to the ja3 branch and it is a complex merge which I need to redo because I goofed somewhere
[15:53:59] <jepler> mhaberler: I apologize that I haven't taken the time to review that code you sent me the other day. If I don't have time today, I am afraid I won't have time before the weekend. :-/
[15:54:08] <mhaberler> sure!
[15:54:21] <mhaberler> that one has been around so long a week dont matter
[15:54:51] <jepler> as for putting the jog-while-paused work on ja3, you might at least check whether rebasing it would go better than merging
[15:54:55] <mhaberler> actually if you have a peek - the patch is rather minimal except for interpmodule.cc which is a wasteland of wraooers
[15:55:06] <mhaberler> I tried both
[15:55:18] <mhaberler> it's just a single file, and I need to do it more carefully
[15:55:18] <jepler> well let me give it ten minutes since I'm here
[15:56:14] <mhaberler> I would really be curious if the segfault is gone; I am not totally sure if the gcodemodule unload triggers the dtor, or what else
[15:56:22] <jepler> (though at the moment I can't access the machine where I routinely saw the crash, it's suspended)
[15:56:30] <mhaberler> ha
[15:58:18] <andypugh> PCW: What is the difference between readin 0x7100 and 0x7600 ?
[16:00:13] <PCW> reading 0x7100 just reads the DPLL accumulator, reading 0x7600 reads the accumulator _and_ syncs the DPLL
[16:00:50] <andypugh> OK, so it makes sense to only read one of them. Grand.
[16:01:02] <PCW> so unless you need it for timing something, a single read of 0x7600 is all thats needed
[16:01:50] <andypugh> As for dpll being first, as things stand the modules are parsed and registered for read-write in the order that they appear in the idrom.
[16:02:17] <PCW> OK I can put it first
[16:03:15] <PCW> Still cant get the funuc stuff to work though the DPLL timer start fanuc read works with my windows test fixture
[16:04:30] <PCW> I also fixed a few bugs (SSI,Fanuc,BISS were all triggered off the wrong edge of the timer so off by 1/2 servo period)
[16:04:49] <micges> PCW: what was the test you did to see 64Hz I/O frequency on windows? ping or some scripted test?
[16:05:02] <micges> PCW: (with 7i80
[16:05:09] <PCW> just my dpll test loop
[16:05:41] <micges> from python?
[16:05:47] <PCW> it may be driver specific (some 1G card it this machine)
[16:05:56] <PCW> Pascal
[16:06:03] <micges> ah ok
[16:07:18] <PCW> also global busy bits for BISS, SSI, Fanuc have changed so they are gated with DAV
[16:08:10] <PCW> so the hardware says its busy if a transfer is in progress or the data is stale (already been read)
[16:08:59] <mhaberler> PCW: identical result with xenomai 3.5.7/amd64 ; just reboot, _no rebuild_, ha
[16:09:38] <andypugh> PCW: What frequency do you end up with the fanuc runnning at?
[16:09:43] <PCW> Thats great!
[16:10:07] <PCW> On linuxcnc? 2 KHz
[16:10:30] <PCW> but its not running for some reason (no request pulse)
[16:11:50] <PCW> the timer start bit is set. and the DPLL is running, will have to raw read some other registers to see whats gone wrong
[16:13:09] <skunkworks> logger[mah]:
[16:13:09] <logger[mah]> skunkworks: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-10-01.html
[16:14:47] <JT-Shop> changing K from 0.050 to 0.750 does not give the expected Z depth change but does break the tap very fast and very lout
[16:14:48] <JT-Shop> d
[16:15:54] <andypugh> You needed a coarser tap.
[16:17:02] <JT-Shop> very much, or just change Z like I wanted to
[16:17:26] <PCW> andypugh: which bitfile are you testing with? I'll make up a fresh one
[16:17:30] <JT-Shop> I did get everyone on the network now... windoze was causing the problem somehow
[16:18:06] <PCW> not terribly surprising
[16:18:33] <andypugh> PCW: Currently working with mixedabs.bit
[16:21:47] <PCW> on what FPGA card?
[16:22:03] <andypugh> 6i25
[16:23:22] <jepler> mhaberler: I am scratching my head as to how your solution fixes the zero-initialization of the contents of _setup, but I didn't see any problems that seemed to be the result of lack of initialization (unlike my change)
[16:24:09] <mhaberler> because I explicitly call the constructed ctor?
[16:24:40] <jepler> well my understanding of C++ was that it didn't make a difference, the zero-arg constructor is the one you get by default
[16:24:43] <mhaberler> (to be honest: not sure either ..)
[16:25:13] <mhaberler> maybe we should look at the .s file
[16:40:48] <jepler> well I just spent some time with my copy of stroustroup but was unenlightened
[16:41:28] <jepler> absent chapter and verse I would feel *better* with the hundred or so zero-initializations it would be necessary to write
[16:41:33] <jepler> but if it's testing OK I can live with it
[16:43:08] <jepler> here's my assertion and test that exercises it:
http://emergent.unpythonic.net/files/sandbox/test-gcodemodule-invariant.patches.mbox
[16:43:14] <jepler> fails on 10.04 before your changes, passes afterwords
[16:43:15] <jepler> bbl
[16:53:39] <jepler> Stroustrup 10.4.2 "Default Constructors" states that in the default constructor of a class type, its base classes and its members of class type are initialized, and a field of e.g., type int is not
[16:54:10] <jepler> there's not a constructor defined for setup_struct, so what we get is the default constructor
[16:55:20] <jepler> (that's paraphrasing _The C++ Programming Language Special Edition_
[16:55:22] <jepler> )
[16:55:24] <jepler> bbl really this time
[17:05:59] <mhaberler> that test is neat, I'll steal it
[17:23:06] <mhaberler> I've merged master into ja3, should I push that?
[18:57:03] <rellenberg> Hi everyone. I'm Rob Ellenberg, and I posted the proposal a few days back about queue lookahead.
[18:57:26] <rellenberg> I'm new to IRC, so I just figured I'd jump on and see if anyone had questions or comments about the idea
[18:57:26] <andypugh> Hi. Is it finished yet :-?
[18:57:33] <rellenberg> lol, if only
[18:57:42] <micges> rellenberg: hi
[18:58:06] <andypugh> pcw_home: Does 7uS dither in the DPLL seem right?
[19:00:26] <andypugh> Ah, not dither, that's the offset. By tweaking the base frequency it is down to zero.
[19:00:57] <andypugh> rellenberg: You are maybe a little late to catch mah, or any other euros.
[19:02:18] <rellenberg> Ok, good to know
[19:02:37] <cradek> hey, welcome
[19:02:48] <rellenberg> Do you guys do periodic meetings via IRC?
[19:03:17] <cradek> yes for official decisions. but for the real work it's ad-hoc.
[19:03:55] <cradek> pardon my phone typing...
[19:04:51] <cradek> see the Meeting* pages on wiki.linuxcnc.org if you are interested in that process. we recently started doing that.
[19:05:38] <rellenberg> Thanks! I'd at least like to follow the decisions so I don't end up stepping on toes with my code
[19:07:06] <cradek> you won't unless you get really wild... the only consideration to keep in mind is it's easier for people to evaluate changes if you do one thing at a time on a branch. we love our feature branches for integration.
[19:08:36] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll 06a4e89 06linuxcnc 10docs/man/man9/hostmot2.9 10src/hal/drivers/mesa-hostmot2/hm2_dpll.c 10src/hal/drivers/mesa-hostmot2/hostmot2.h * Triggering on the right function, better defaults, some pin changes, and docs
[19:09:34] <cradek> I'm going to head home so I have a keyboard. think you'll be around for a bit?
[19:09:54] <rellenberg> I'll be on till about 8:30 EST tonight
[19:10:46] <andypugh> Whereas I will be here until 0055 BST. Which is now. Night all!
[19:16:07] <KGB-linuxcnc> 03andy 05ssi-fanuc-biss-dpll c76e9a9 06linuxcnc 10src/hal/drivers/mesa-hostmot2/abs_encoder.c * Spotted a copy and paste error.
[19:25:16] <cradek> aha, a keyboard!
[19:26:34] <cradek> rellenberg: about toes: I wrote the current planner and I'm tickled that you are improving or replacing it. So no worries there, and I'll help you however I can.
[19:27:48] <rellenberg> Nice work! There's a lot of clever tricks in there
[19:28:45] <cradek> ah, thank you. None of us are too thrilled with its performance, but it has let thousands (?) of machines run correctly for years, so I am happy about that much.
[19:28:50] <rellenberg> I noticed there was a feature request a year or so back about an S-curve planner
[19:29:19] <cradek> yes people want jerk limiting, but without better lookahead that would pull our speeds down even more.
[19:29:31] <rellenberg> That makes sense
[19:29:40] <rellenberg> we need to get the machines moving fast enough for it to matter
[19:29:42] <cradek> my gut says vanishingly few people would actually benefit from jerk limiting
[19:29:53] <cradek> yes you're right
[19:29:56] <rellenberg> I agree, it seems like polish for most CNC's
[19:30:20] <rellenberg> It would matter more for delta robots and rapid prototypers, i suppose
[19:30:24] <cradek> people like to compare bullet lists, and that's a bullet that some systems have. it doesn't mean it should be a priority for us.
[19:30:45] <cradek> or the opposite: very massive machines that are capable of high acceleration
[19:31:04] <rellenberg> ahh, good point, machines that could hurt themselves
[19:31:13] <cradek> I have one that might benefit a tiny bit (I turned down the acceleration a lot on my VMC because I didn't like how much it made the floor move)
[19:31:33] <cradek> but the real-world difference in machining time that causes? negligible.
[19:31:57] <cradek> and everything will last longer with it turned down...
[19:32:05] <rellenberg> Are a lot of industrial machines running LCNC?
[19:32:48] <cradek> it's hard to know that. I know of a lot of them. hundreds or thousands though? I can't say.
[19:32:57] <cradek> way more than tens, haha
[19:33:26] <cradek> we sure do have a lot of hobbyists with smallish stepper machines
[19:34:05] <cradek> about your questions:
[19:34:33] <cradek> 1a, we've talked a little about chunking on the list -- motion currently takes one message at a time, and each move that gets queued is a message
[19:35:07] <cradek> with the current messaging interface: if canon knew there were 100 messages ready, it could always communicate that fact to motion and then start sending them.
[19:36:25] <cradek> but it's normal to have just one move and expect the planner to execute it - MDI is the obvious case - there are also many other cases where a running gcode program waits for the queue to empty out so certain things can sync (IO, probing, etc)
[19:36:45] <rellenberg> Ahh, that makes sense
[19:37:26] <rellenberg> I've tweaked the algorithm a bit to make it run efficiently for one new move
[19:37:29] <cradek> 1b, on some machines the servo cycle is already quite heavily loaded, in particular nontrivkins machines. a puma robot I was working on had the servo thread so full the gui stuff could hardly run.
[19:38:13] <cradek> hobbyists often use old, underpowered hardware (and quite often for more than the obvious reason: old hardware tends to have the best realtime performance)
[19:38:45] <rellenberg> So old single-core machines that lack the muscle to do a lot of computations
[19:38:53] <cradek> 2- no. 3- I don't know 4- see all the above, ha
[19:39:27] <cradek> even new ones. the intel d525 was the go-to for people wanting to buy new hardware for linuxcnc use -- that is what was in this puma robot I'm thinking of. it was an atom board, not super fast.
[19:40:18] <cradek> and today people are getting more and more interested in VERY low powered machines like raspberry pi. the 3d printer crowd has started this trend and it's contagious.
[19:41:11] <cradek> these machines can't run our standard opengl UI for crap, and so these users are sometimes reverting to our very old (late 90s era) UIs.
[19:41:35] <cradek> just some things to think about
[19:42:05] <cradek> you could certainly add SOME processing to the servo thread and be fine. but if you want to double its typical run time I'd be very worried.
[19:42:28] <rellenberg> That's definitely good to know
[19:42:57] <rellenberg> In the motion code, I saw that the trajectory planner and servo can theoretically run at different rates, yes?
[19:43:15] <cradek> yes, and in the very old days people had to do that for iterative-solving kins
[19:43:36] <rellenberg> right, before closed-form solvers
[19:43:39] <cradek> there is a cubic interpolator layer in there
[19:43:49] <rellenberg> so we could afford to coarsen the output of TP a little
[19:43:53] <cradek> it is almost always no-op for our users today
[19:44:46] <cradek> yes and no - for spindle synchronized motion like tapping, you can't coarsen it because you add delay
[19:44:58] <cradek> for a wood router - you bet you could
[19:46:06] <cradek> when I added rigid tapping is when it became the custom to set servo and traj cycles the same
[19:47:17] <rellenberg> Ok, that makes sense
[19:49:29] <rellenberg> The reason it has to go in the motion module now is because the last few queue'd moves have to be replanned slightly
[19:49:30] <cradek> ok I've talked enough. now how can I help? questions?
[19:50:13] <cradek> by last do you mean oldest or newest?
[19:50:24] <rellenberg> the newest, sorry
[19:51:18] <rellenberg> so a new move gets stuck on the end of the queue, which means what used to be the last move doesn't need to end with zero final velocity
[19:52:09] <cradek> ah I see - each move is "last" in turn. am I correct that any moves can become the last if motion is aborted - you may have to continue to process many moves in order to get stopped while staying on the path - a thing we currently don't have to do
[19:52:42] <rellenberg> yeah, an unplanned stop gets messier
[19:53:20] <rellenberg> But as we had mentioned in that email thread, we don't need a new plan in that case
[19:53:22] <cradek> well it sounds like in the worst case, you'll end up running all the queue, which always gives you a safe stop
[19:53:30] <rellenberg> yes
[19:53:45] <rellenberg> and each step backwards is also safe
[19:54:11] <rellenberg> the limiting factor is the delta-V in each move (since we can't slow down or speed up during a blend)
[19:54:12] <cradek> I'm with you
[19:54:45] <cradek> that worries me. in many programs (well today) everything is constantly a blend
[19:55:10] <rellenberg> yeah, that's the limiting case
[19:55:25] <rellenberg> I tried to run the math to do acceleration during blends, but that optimization is way messier
[19:56:04] <rellenberg> There is one answer; we could force the blend to be no more than a fraction of the total length
[19:56:15] <rellenberg> say if a blend can't be more than 1/3 of a move
[19:56:27] <rellenberg> then we'll always have at least 1/3 of the move to accelerate
[19:56:33] <cradek> it seems like this will lead to a lot of jerking
[19:57:11] <cradek> you'll have +j and -j for every move that makes up part of the accel
[19:57:11] <rellenberg> yeah, it would stutter as it hit each blend
[19:58:10] <cradek> I am not sure how that would work on a real machine but I suspect it would affect part finish and - uh - sound "weird" if nothing else
[19:58:52] <cradek> if you have limited jerk it would be a lot less violent, but that's a huge ball of wax
[19:59:19] <cradek> it's surprising how much harder the math gets when you add that constraint...
[19:59:44] <rellenberg> limited jerk? yeah it looks like a real pain
[19:59:48] <rellenberg> 7 cases? fuuuuuu
[20:01:00] <cradek> did you see that ja3-jerklimit branch with yishin's work?
[20:01:30] <rellenberg> I looked through the araisrobot repository a week or so ago
[20:01:34] <cradek> I think he was close to having jerk limiting work right
[20:01:52] <cradek> but with no new lookahead ... like we said before
[20:02:21] <cradek> I isolated his planner changes and put them in ja3-jerklimit in git.linuxcnc.org
[20:02:35] <rellenberg> ahh, cool, I'll have to look through that branch
[20:02:41] <cradek> but how close that is to araisrobot today I have no idea
[20:03:03] <rellenberg> Are there any obvious problems with that branch?
[20:03:11] <rellenberg> i.e. could i build and run it on my machine?
[20:03:36] <cradek> yes - it badly violates at least the jerk and accel constraints
[20:03:43] <cradek> in some cases
[20:04:15] <cradek> it doesn't handle spindle-sync and maybe doesn't handle aborts - I don't remember
[20:04:20] <cradek> it was very much a work in progress
[20:04:31] <rellenberg> I noticed there were graphs showing the accel violation on the feature req. page
[20:05:05] <cradek> http://en.araisrobo.com/linuxcnc/g64-max-blending
[20:06:41] <rellenberg> How did those graphs get plotted btw? is there debug output from the motion module?
[20:07:11] <cradek> aha,
http://thread.gmane.org/gmane.linux.distributions.emc.devel/6364
[20:07:21] <cradek> I believe this thread is the last he and I interacted
[20:07:40] <cradek> those plots are from halscope, which lets you plot any signal available in HAL
[20:08:03] <cradek> it works a lot like an o'scope, so you can set it up to trigger on a position or accel, and plot for a while
[20:08:29] <cradek> it is a very wonderful thing
[20:08:46] <rellenberg> that's slick! I'll definitely put that to use
[20:10:09] <cradek> in that thread I suggested some cases he should validate - you might like to read that too, even though your cases will be less bad without the 7 states
[20:10:55] <rellenberg> Definitely, I'll have a look over those
[20:12:06] <cradek> also be aware of the sim/lathe sample config, which has simulated spindle encoder feedback. you can test tapping and threading with it.
[20:12:25] <cradek> oops it's sim/axis/lathe now
[20:12:37] <rellenberg> awesome, that will be very helpful
[20:14:01] <cradek> do you have hardware running linuxcnc already?
[20:14:21] <rellenberg> yes, a sherline CNC mill
[20:14:33] <rellenberg> it's not much, but it's using a probotix board and steppers
[20:14:34] <cradek> ah, cool, I like their stuff.
[20:15:20] <rellenberg> it's a nice little machine. I got mine as a trashpick
[20:15:28] <rellenberg> it does surprisingly well within its bounds
[20:15:33] <cradek> I have a sherline lathe with little dc servo motors on it
[20:16:06] <Tom_itx> cradek, what size servos did you use on it?
[20:16:11] <Tom_itx> i've got their little mill
[20:16:13] <Tom_itx> with steppers
[20:16:14] <cradek> and the first lathe to cut a thread with linuxcnc was a sherline in my basement
[20:16:50] <cradek> Tom_itx:
http://timeguy.com/cradek-files/cnc/lathe/DSCN6295.JPG
[20:16:58] <cradek> these little pittmans
[20:17:00] <Tom_itx> probably not something i'd update any time soon
[20:17:38] <cradek> a few pictures here:
http://timeguy.com/cradek/cnc/lathe
[20:17:38] <Tom_itx> it would be fun to try and set up a servo system though
[20:17:59] <cradek> this doesn't see much use anymore but it worked/works nicely
[20:18:18] <rellenberg> a good testbed if nothing else
[20:18:31] <cradek> rellenberg: my little vmc running linuxcnc/touchy:
http://timeguy.com/cradek-files/emc/jr.jpg
[20:18:53] <cradek> heh "little" - I had to raise the ceiling
[20:19:14] <Tom_itx> that's a nice size
[20:19:20] <Tom_itx> that kind is it?
[20:19:27] <Tom_itx> what*
[20:19:49] <rellenberg> wow, toolchanger and everything
[20:19:58] <Tom_itx> my friend had to do the same thing wiht his first Fadal in his garage
[20:20:09] <Tom_itx> cat 40?
[20:20:23] <cradek> it's a mori-seiki MV Jr
[20:20:39] <Tom_itx> aww that's a nice machine
[20:20:44] <cradek> it has direct drive minertia motors so it's fast
[20:20:45] <Tom_itx> they're rugged
[20:20:57] <cradek> yeah and all linear rails. it's awesome
[20:21:46] <cradek> so I have done all sizes, heh, the biggest machine I've helped with is at MPM
[20:21:55] <Tom_itx> what do you make with it?
[20:22:05] <Tom_itx> oh you helped them retro some?
[20:22:13] <cradek> oh I fix stuff around the house... y'know
[20:22:17] <Tom_itx> yep
[20:22:37] <cradek> yeah I've helped on quite a few projects there
[20:22:54] <Tom_itx> are you nearby?
[20:23:17] <Tom_itx> that's my home town
[20:23:38] <cradek> 3-400 miles
[20:23:51] <cradek> so, yeah, sorta
[20:24:49] <cradek> tool changes etc:
http://www.youtube.com/watch?v=eWitrmtqZ7I tapping:
http://www.youtube.com/watch?v=9HLKXeWqTF0
[20:24:52] <Tom_itx> i think kimk was from nebraska and he's been there a while now
[20:25:00] <cradek> yes he was from omaha
[20:25:14] <Tom_itx> my original home town :)
[20:26:15] <cradek> rellenberg: what part of the world are you in?
[20:26:35] <rellenberg> Philadelphia
[20:26:52] <Tom_itx> i just wish i had room for a VMC
[20:27:13] <cradek> ah, too far to invite you over for a beer
[20:27:17] <skunkworks> rellenberg: Welcome aboard!
[20:27:29] <skunkworks> isn't matt around there?
[20:27:41] <cradek> he's in maryland I think?
[20:27:42] <rellenberg> too bad, I'm limited by motorcycle range
[20:30:34] <rellenberg> thanks anyway!
[20:30:45] <cradek> well come anytime, but motorcycle means you get coffee, not beer, haha
[20:31:13] <cradek> like grandmas say, I like both equally
[20:31:15] <rellenberg> lol, yeah, good point
[20:31:21] <rellenberg> at the same time?
[20:31:33] <cradek> eww
[20:31:51] <cradek> coffee and whiskey, you bet. not sure about coffee and beer.
[20:32:25] <rellenberg> lol, yeah, depends on the beer, though
[20:32:36] <rellenberg> porter perhaps
[20:34:24] <skunkworks> rellenberg: I think there are alot of big iron running linuxcnc.
http://www.youtube.com/watch?v=39q6kvrSBSk
[20:36:49] <rellenberg> that's a good size machine
[20:37:06] <cradek> squeeeeeeeeeeeee
[20:37:12] <skunkworks> :)
[20:37:12] <rellenberg> can't discount the big guys
[20:37:55] <cradek> love how bold it is running that tap in there
[20:38:10] <rellenberg> unfortunately I've gotta run, got a meeting tonight. it was good to meet you guys, and thanks for all the help!
[20:38:19] <rellenberg> I'll be on periodically, hopefully with good news
[20:38:41] <cradek> terrific
[20:38:45] <cradek> yell anytime I can help
[20:38:52] <cradek> it was good to finally meet you
[20:39:16] <rellenberg> will do, I'm looking forward to developing with you
[20:39:18] <rellenberg> ttyl
