Back
[07:59:51] <jepler> it's not presently possible to build a live debian 7.0 image with linux-image-rt (i.e., RT_PREEMPT kernel) :(
http://lists.debian.org/debian-kernel/2013/02/msg00172.html
[08:17:37] <skunkworks> Do you mean for a livecd like we have with ubuntu?
[08:40:00] <skunkworks> mhaberler, zultron, running overnight.
[08:40:02] <skunkworks> http://imagebin.org/263190
[08:41:38] <skunkworks> idle=poll, audio disabled. I tried 2 video cards I had here but both had hdmi and seemed to cause latency issues when there should have been a sound. (like a screenshot)
[08:41:59] <mhaberler> hm, I'm still before my first coffee - looks acceptable?
[08:42:43] <skunkworks> yes. >10us
[08:42:46] <skunkworks> heh
[08:42:48] <skunkworks> <10us
[08:43:49] <skunkworks> so this is using the onboard video. (it does have hdmi also onboard but doesn't seem to cause issues)
[08:44:00] <mhaberler> well that's very good then, congratulations!
[08:44:37] <mhaberler> you are going to use parport steppers?
[08:47:56] <skunkworks> Not at the moment. but I needed atlead workable realtime for the 7i80. (initally - this thing was giving >500us latency.
[08:48:02] <skunkworks> atleast
[08:48:54] <skunkworks> but this seems like it would do really good software stepgen
[08:48:57] <mhaberler> well, different RTOS, similar causes - I'm really looking forward to having RT separated out so we dont have to deal this pattern anymore
[08:49:13] <mhaberler> right, looks doable
[08:51:35] <skunkworks> Do you mean so realtime is on a external black box?
[08:56:00] <skunkworks> as long as the realtime kernal is still an option (be it rtai, xenomai, rt_preempt) Knowing it might take a little elbow grease to get a stable system - I am all for it.
[08:56:50] <mhaberler> eventually
[08:57:10] <mhaberler> I'm working on it; the beaglebone would be a candidate for such an 'outboard'
[08:57:17] <mhaberler> (outhouse ;-?)
[08:57:27] <skunkworks> heh
[08:57:47] <mhaberler> meaning for UI's it doesnt matter where they run, any platform really does it
[08:58:36] <mhaberler> well I'm delighted to see that result nevertheless, somehow your board combos seem to be the more challenging ones
[08:59:46] <alex_joni> jepler:
http://lists.debian.org/debian-kernel/2013/02/msg00261.html
[08:59:46] <skunkworks> yes.
[09:00:22] <skunkworks> ah - so you are saying separate the gui from the realtime more cleanly. so the could be run on 2 different systems. but could still be all run on one if wanted.
[09:10:27] <mhaberler> zultron just appeared armed with a coffee mug, too and sends congratulations!
[09:10:51] <mhaberler> yes, distributed just would be an option
[09:12:03] <skunkworks> awesome
[09:13:52] <skunkworks> heh - I added a normal dual head video card (no hdmi) and I get overruns. Don't breath on it!
[09:14:26] <skunkworks> maybe a pcie issue. who knows. I am just glad I can do some testing
[09:20:50] <mhaberler> the current style of doing things is just a bit too fickle for casual use
[09:21:12] <mhaberler> make sure you post a comment on the wiki, including chipset and necessary magic
[09:22:05] <zultron> skunkworks, what chipsets in the problem video cards?
[09:23:20] <zultron> Congrats, by the way, nice latency numbers!
[09:23:53] <mhaberler> I'd be interested in any results with the 7i80 too; I tried micges rtnet setup and that worked fine, giving figures around 50uS
[09:24:34] <skunkworks> ati 5450, geforce 7300, geforce 8400 ;)
[09:24:44] <mhaberler> now if we would find a hero to make the 7i80 run with the netmap fast ethernet stack..
[09:24:56] <skunkworks> mhaberler, I was getting 50us pings also
[09:25:03] <mhaberler> the ati is the onboard chipset?
[09:25:06] <skunkworks> (if that is what you are talking about)
[09:25:09] <mhaberler> yes
[09:25:16] <zultron> Hmm, I'm a little surprised. I've had pretty good luck with my ATI cards, though they're mostly older than that.
[09:25:38] <skunkworks> mhaberler, it is the amd apu processors. is that ati? I think so
[09:25:58] <mhaberler> I think amd bought ati
[09:26:00] <zultron> AMD acquired ATI sometime back, so yes.
[09:26:09] <mhaberler> (not it helps them out of the pits)
[09:28:26] <zultron> skunkworks, are you using rtnet v. 0.9.13, the released version? Or did you grab the git snapshot?
[09:28:41] <skunkworks> http://pastebin.ca/2414801
[09:28:54] <skunkworks> that is the onboard video
[09:28:57] <skunkworks> zultron
[09:29:29] <skunkworks> git clone git://rtnet.git.sourceforge.net/gitroot/rtnet/rtnet rtnet-0.9.13
[09:29:46] <skunkworks> when I looked at the readme it said 0.9.12
[09:29:48] <skunkworks> when I looked at the readme it said 0.9.13
[09:29:50] <skunkworks> sorry
[09:30:21] <jepler> alex_joni: yes I see they talked about solving it, but it looked like the result was that nobody in the thread planned to do anything until post-wheezy:
http://lists.debian.org/debian-kernel/2013/02/msg00251.html
[09:30:40] <jepler> alex_joni: though we sure could do as suggested, build a -rt kernel with aufs enabled and see whether it works
[09:30:56] <zultron> Thanks. I'm considering whether to package rtnet.
[09:31:07] <skunkworks> zultron, ooooh.
[09:31:53] <zultron> Also considering whether to spend a few hours beating my big toe with the 3 lb. sledge, similarly painful.
[09:32:27] <mhaberler> it's not a sledge, it's a "motivator"
[09:33:06] <mhaberler> jepler: are you chasing the pagefault cause? (aufs/rt)
[09:33:12] <jepler> mhaberler: no, this is unrelated
[09:33:16] <mhaberler> ah
[09:34:02] <jepler> mhaberler: I was playing with debian-live, a raft of scripts for building "live" debian images. I built one with the linux-image-rt kernel but it couldn't mount its root filesystem due to missing support for aufs, the union filesystem used for live debian
[09:34:13] <mhaberler> aja
[09:34:18] <zultron> Yuck yuck! That's right, I meant to name my 3 lb. sledge 'the persuader'. Right now I call it 'Fiat Tool #1'.
[09:35:45] <mhaberler> I need to record Stuarts quote for posteriority (seems to be a Yankee Engineering principle): "built to plain, beat to fit, paint to match"
[09:37:05] <jepler> mhaberler: as far as "page faults" go, I have not measured page faults in the realtime threads after fixing the dlopen RTLD_NOW flag. I don't know whether that change has been incorporated in your branches though:
http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=commit;h=72e6856c6884b9c8761d24bb5f8e77fbb0a3ee76
[09:38:09] <jepler> mhaberler: I also discussed briefly with zultron(?) that reporting of page faults should be rewritten to use RUSAGE_THREAD instead of RUSAGE_SELF, though I did not offer a patch.
[09:38:30] <jepler> because we know page faults are expected to occur in the main thread of rtapi_app, the part that needs no realtime guarantees
[09:38:46] <mhaberler> right, I'll pick that up as soon as I'm back
[09:38:55] <mhaberler> thanks, that was one of the grey areas
[09:38:55] <jepler> ok, I'm glad I got it on your radar
[09:39:28] <mhaberler> (Phoenix seems to be a Bermuda triangle for me, stranded twice there in transit :-)
[09:39:45] <cradek> where are you now?
[09:40:54] <mhaberler> Austin, in the John Morris asylum; missed the Lufthansa connection yesterday
[09:40:56] <zultron> He's at my place. Could be worse....
[09:41:25] <jepler> I also have in a non-patched branch a not-ready-for-use change to the 'threads' component that has it create some pins and functions that show the page fault count. I'm unsure whether calling getrusage() in a realtime thread is OK or makes you lose realtime, and it needs to be #ifdef'd for userspace realtime models
[09:41:32] <mhaberler> I've already explored the sofa of a closed Starbucks at Phenix for overnight stay..
[09:41:46] <cradek> yikes.
[09:41:51] <jepler> .. and possibly implemented in motion as well, since the 'threads' component isn't creating the threads in a typical linuxcnc setup (vs a halrun setup)
[09:41:52] <zultron> logger[mah], need a bookmark for the RUSAGE_THREAD stuff.
[09:41:52] <logger[mah]> zultron: Log stored at
http://linuxcnc.mah.priv.at/irc/%23linuxcnc-devel/2013-07-02.html
[09:42:23] <jepler> mhaberler: as for your travel troubles .. yuck.
[09:42:45] <mhaberler> jepler: what do you think about the watchdog/charge pump signal idea from threads?
[09:43:26] <mhaberler> I need to adress the Xenomai 'switch domains due to rt delay' event somehow, and exiting isnt the brightest of all ideas
[09:43:44] <jepler> mhaberler: I think it's interesting, and I think it could fit in with this code I was talking about in the threads component
[09:43:52] <mhaberler> but if we already have RT-specific pins I could add an estop output
[09:44:09] <mhaberler> yes, that looks like it'd be easier to use and comprehend
[09:44:39] <cradek> is that domain switch out of realtime permanent for the life of the program, or can you recover?
[09:44:49] <mhaberler> unfortnately irreversible
[09:45:10] <mhaberler> other than with rt-preempt where you get slapped but it keeps trying
[09:45:47] <mhaberler> probably I should consult the xenomai list, I dont assume I'm the first one to discover that
[09:45:54] <jepler> thinking aloud: rtapi_task_new can't create hal-level entities like pins and functions
[09:46:10] <mhaberler> yes, layer violation :-/
[09:46:13] <jepler> .. but we could provide a hal-level wrapper of rtapi_task_new (hal_task_new) which calls rtapi_task_new and then creates some hal-level items
[09:46:23] <jepler> like this "all is well in realtime" charge pump pin
[09:46:28] <cradek> if the hardware read/write threads stop, all hardware watchdogs should fire shortly
[09:46:33] <mhaberler> well we do, hal_create_thread methinks
[09:46:34] <jepler> and then just switch all the callers over to it, because they're all at the hal level
[09:46:52] <jepler> oh so there is
[09:47:02] <mhaberler> if I'm not mistaken both threads module and motion use the hal thread interface
[09:47:16] <jepler> you're right
[09:47:31] <mhaberler> actually I'm not sure the lowlevel interface to rtapi threads is used outside of hal_lib.c at all
[09:47:38] <mhaberler> but that'd be easy to grep
[09:47:49] <jepler> ok so there is a place to put this without layer violation
[09:48:05] <mhaberler> right, thats the way to do it
[09:48:44] <mhaberler> ok, one issue less..
[09:48:48] <jepler> now they cause problems - they can no longer be owned by the calling
[09:48:48] <jepler> component, and they can't be owned by the hal_lib because it isn't
[09:48:48] <jepler> actually a component.
[09:48:59] <jepler> err missing the first line: /* These params need to be re-visited when I refactor HAL. Right
[09:49:17] <jepler> so I guess I need to recreate jmk's thought process on why that is the case
[09:49:21] <mhaberler> yep, ownership of comps is a bit hokey
[09:49:49] <jepler> a thread-creating component *can* be unloaded without deleting the thread
[09:49:53] <jepler> but in practice it's not...
[09:49:59] <mhaberler> IMO there should be a 'context' (which is userland hal pids plus an pseudo-pid for kernel), and comps be pegged to a context
[09:50:12] <mhaberler> I have a different interface to create halthreads already, unmerged
[09:50:22] <mhaberler> replace threads by a sysfs file op
[09:50:33] <mhaberler> and with userland, a rtapi_app command
[09:50:57] <jepler> in that case we're back to not having a component to hang a pin on
[09:51:07] <mhaberler> so both motion thread gen and the threads module eventually could be put to rest and replaced by halcmd primitives
[09:51:28] <mhaberler> yes, rt needs to own a comp proper
[09:51:59] <mhaberler> where do you see a problem with that?
[09:52:22] <mhaberler> it might be the hal_lib module becomes a comp
[09:53:38] <jepler> It's not so much that I see a specific problem, but that it seems like it makes more sense to not write the pin-adding code now but see how it shakes out later on
[09:53:50] <mhaberler> Actually there are objects in HAL which shouldnt be 'owned' by a comp to start with, and threads is one of them
[09:54:02] <jepler> that must be why hal_create_thread doesn't have a comp_id argument
[09:54:37] <mhaberler> another one is shm segs used for ringbuffers; ringbuffers live beyond comps which started them but a shmseg needs to be owned by a comp
[09:55:26] <mhaberler> but it is a very far-reaching change to meddle with the compid ownership concept, so I rather muddle through
[09:55:59] <jepler> linuxcnc 2.6 is sure what is on my mind, which stops me thinking about long range plans
[09:56:26] <jepler> while I get the impression you focus much more on linuxcnc 3000
[09:56:46] <mhaberler> the problem turned up with cross-linking pins and ringbuffers, and that wont be in 2.6
[09:56:49] <mhaberler> yes
[10:01:50] <zultron> mhaberler, I haven't been following the Xenomai list. Any talk yet about scheduling the next release?
[10:02:42] <mhaberler> I need to catch Gilles in a quiet moment.
[11:09:51] <CaptHindsight> http://www.kickstarter.com/projects/pirate3d/the-buccaneer-the-3d-printer-that-everyone-can-use "We considered using the newly launched BeagleBone Black, which has everything we need. However, 3D printer firmware for the BeagleBone system is still in its formative stages and we will want to work on this further to improve it."
[11:11:12] <CaptHindsight> $347 printer with $100 just for the electronics
[11:25:04] <CaptHindsight> so if you can stuff 3 stepper divers and few 2A mosfets onto a BBB for $75 it would be adopted by just about every glue gun printer
[11:26:57] <CaptHindsight> Linuxcnc still needs an easy to use UI for those
[11:26:59] <ssi> yea that's been obvious for awhile :)
[11:27:12] <ssi> it's amazing how much money the ramps or similar stack costs
[11:27:19] <ssi> for how little raw horsepower you get :)
[11:28:21] <CaptHindsight> BBB + stepper and heater drivers <$75
[11:29:05] <ssi> there are a couple pieces of hardware like that already
[11:29:09] <ssi> replicape, bebopr
[11:29:28] <CaptHindsight> people seem to think $45 for the BBB + >$100 for stepper and heater drivers = >$145 is going to sell
[11:29:49] <ssi> I dunno that you're gonna get it down to $30
[11:30:18] <CaptHindsight> ~$50
[11:30:29] <ssi> that'd be $95
[11:30:41] <CaptHindsight> $50 fot total BOM
[11:30:45] <CaptHindsight> fot/for
[11:31:03] <CaptHindsight> the BBB is overpriced
[11:31:27] <ssi> feel free to buy something cheaper
[11:31:31] <ssi> I think it's pretty reasonable
[11:31:48] <CaptHindsight> not buying, making
[11:31:51] <ssi> BBB costs less than an arduino mega, which is what most existing ggg stacks are based on
[11:32:03] <ssi> I have no interest in trying to replicate BBB
[11:32:09] <ssi> lot of work for no good reason
[11:32:33] <ssi> someone else already has done that work, has the volume economy in place, and charges a reasonable price for it
[11:32:40] <ssi> the only thing I might like to see is a BB-grey
[11:32:48] <ssi> for $35, without the hdmi framer and emmc
[11:33:19] <CaptHindsight> AM335x is $12 in China
[11:33:38] <CaptHindsight> A10 and the A20 is ~$6
[11:33:55] <ssi> that's a different product
[11:34:47] <CaptHindsight> not sure what your point is
[11:34:55] <ssi> point is it has nothing to do with the cost of a BBB
[11:35:18] <ssi> it's not like you can just build a BBB but use an A10 instead
[11:35:24] <ssi> and magically save $6/unit
[11:35:25] <CaptHindsight> you can make an equivalent BBB + stepper driver board for ~$50
[11:35:41] <ssi> call me when they're on sale
[11:36:16] <CaptHindsight> heh, I'll put your 1 board in a special box
[11:36:25] <ssi> cool
[11:36:39] <ssi> I'm serious... if you come up with such a thing, I'll happily buy them
[11:36:58] <ssi> but it's mostly more work than it's worth
[11:37:15] <CaptHindsight> well to sell to the DIYers
[11:37:30] <CaptHindsight> we make boards for OEM's
[11:38:32] <CaptHindsight> we work in different worlds
[11:39:24] <ssi> I guess I still can't quite divine the essence of your... argument? point? complaint?
[11:39:30] <ssi> from the string of half-sentences
[11:39:46] <CaptHindsight> no argument
[11:39:52] <ssi> if you think such a product should exist, can exist, and is within your abilities, then by all means, produce it
[11:40:04] <CaptHindsight> ok, thanks
[11:40:22] <ssi> the way your first statements were... "phrased"... made it sound like you thought that a BBB plus some addon bits could run a 3d printer for $75 total
[11:40:33] <CaptHindsight> just pointing out opportunities
[11:40:47] <ssi> and once you've spent $45 on a BBB, I don't think $30 is enough left over to spin a board, populate it with drivers, and make enough profit on the cape to make it worthwhile
[11:41:15] <ssi> and if you're talking about building something with an allwinner chip, well you're not exactly building a BBB now are you?
[11:41:23] <CaptHindsight> all in one board, the BBB is too high priced currently
[11:41:53] <ssi> if you took the BBB schematic and BOM, deleted the hdmi framer and the emmc, and did a layout on a board with five or six 4988s and a couple mosfets, you could make a pretty nice little printer controller
[11:42:05] <ssi> but I dunno if you'd be able to hit the $75 target without significant volume
[11:42:29] <ssi> and I'm not sure that having one board that does it for $100 vs two boards that do it for $125 is really a cost effective way to spend all that effort of designing a new BBB
[11:43:05] <ssi> I say leverage the work that circuitco already did, and the volume pricing they already have, and focus on making a quality GGG peripheral as cheaply as possible
[11:43:18] <ssi> ...which is what replicape, etc is
[11:44:24] <CaptHindsight> all what effort? to redesign an am3359 board?
[11:44:29] <ssi> yes
[11:44:47] <CaptHindsight> few days
[11:44:51] <ssi> if that's your dayjob and you can do it quickly and efficiently, more power to you
[11:45:01] <ssi> maybe there's gold in that hole
[11:45:10] <CaptHindsight> not for DIY
[11:45:45] <pcw_home> as a OEM printer controller that makes sense
[11:45:53] <ssi> sure
[11:46:00] <ssi> but you're then competing with printrboard and others
[11:46:10] <ssi> probably have a better product, MAYBE you can make it cheaper
[11:46:12] <CaptHindsight> it still needs an easy to user UI
[11:47:14] <ssi> personally, I want to get to where we have reasonably inexpensive BBB capes for controlling servo systems
[11:47:33] <CaptHindsight> this would be for >100K pcs, into the millions for appliance manufacturers
[11:49:16] <CaptHindsight> it would be nice to see Linuxcnc in something by Haier, if they haven't already gone down another path
[11:53:32] <CaptHindsight> but I don't get the impression that many here would be happy with that
[12:18:10] <seb_kuzminsky> CaptHindsight: i would be happy if more companies sold linuxcnc solutions, as long as they were good citizens of the community
[12:18:23] <seb_kuzminsky> several companies already do (Smithy, Sherline, probably others)
[12:21:27] <CaptHindsight> but to a company that sells toaster ovens? :)
[12:25:18] <CaptHindsight> the problem is it ends up like ARM phones and tablets, u-boot was around for a decade but everyone decided to close the bootloader and firmware
[12:26:27] <CaptHindsight> if Linuxcnc makes it into OEM 3D printers in China there's no knowing what version of the code will end up actually shipping
[12:27:12] <jepler> if you're saying they're all bad actors who will not comply with the GPL, then they can die in a fire
[12:27:28] <CaptHindsight> not all, but some
[12:29:00] <CaptHindsight> some ARM soc vendors only ship their working Linux kernel and driver source under NDA
[12:31:40] <jepler> I am aware of this and I am aware that it's gnu.org's viewpoint that this is a GPL violation. I am not sure what good it does to bring it up in this context. Unless you just want to raise my blood pressure.
[12:32:08] <seb_kuzminsky> let's see if we can make jepler pop!
[12:32:18] <jepler> I already said "die in a fire"..
[12:32:22] <jepler> are you sure I haven't popped?
[12:33:48] <CaptHindsight> there's no way to control what OEM's might do with Linuxcnc there, one the other hand there a sea of developers there that do comply
[12:34:16] <jepler> yay it's lunchtime
[12:35:41] <CaptHindsight> we'll just have to see what happens
[12:58:30] <mhaberler> andypugh: which branch are you working off, master?
[12:59:34] <mhaberler> I assume this should be a python module able to receive/send the iocontrol-specific NML messages so it can be plugged in instead of iocontrol but as a hal python usercomp?
[13:13:45] <KimK> jepler: I am told you wrote the new MPG program restart features for touchy, thanks very much. Where is the new touchy, in master? Anything special we would have to do to try it out? I saw you're at lunch now, I'll check back later.
[13:23:56] <cradek> I don't see that in any branch. maybe he's not happy with it yet.
[13:44:55] <jepler> KimK: I did not push it
[13:44:58] <jepler> it's half done on my laptop
[13:45:15] <jepler> I forget just what I was dissatisfied about
[13:45:25] <cradek> then it's 80% done
[13:45:49] <jepler> 80% is the same as half? I never got the hang of percentages in school.
[14:09:34] <seb_kuzminsky> 50% is less done than 80%, but 80% is not more done than 50%
[14:09:49] <seb_kuzminsky> err wtf did i just type
[14:09:54] <ssi> :D
[14:10:05] <ssi> hey seb, this is some MAGIC C syntax I've never seen before
[14:10:05] <ssi> static int ioaddr_hi[HM2_7I43_MAX_BOARDS] = { [0 ... (HM2_7I43_MAX_BOARDS-1)] = 0 };
[14:10:12] <ssi> what's with that [0 ... ] mess?
[14:10:15] <ssi> hahaha
[14:11:38] <seb_kuzminsky> ssi:
http://gcc.gnu.org/onlinedocs/gcc/Designated-Inits.html
[14:12:06] <ssi> whoa
[14:12:09] <ssi> mind blown :D
[14:12:16] <seb_kuzminsky> it means "every entry from 0 to HM2_MAX_BOARDS-1 is initialized to 0"
[14:12:20] <ssi> yea got it
[14:12:22] <ssi> thanks :D
[14:12:26] <seb_kuzminsky> yeah that doesn't look much like C does it?
[14:12:33] <ssi> nothing I've seen before
[14:12:42] <seb_kuzminsky> "what is this, one of those newfangled interpreted languages??"
[14:12:50] <ssi> although I just learned about the .foo struct initializers a couple weeks ago
[14:12:58] <ssi> I haven't exactly done a ton of C recently
[14:19:03] <psha> seb_kuzminsky: btw why not just {0}?
[14:21:33] <psha> i can't find link but as i recall all unspecified elements are zeroed
[14:21:38] <psha> at least for struct that's for sure
[14:24:24] <ssi> there are other cases where it sets the first two to a concrete value and then the rest to zero
[14:29:16] <psha> yep, that's where such initializers are important
[14:29:41] <psha> however first to values - rest to zeroes are still covered by more simple clause = {1, 2, 3}
[14:31:22] <psha> s/to/two/
[14:40:56] <ssi> ok I have the skeleton of a BCC hm2 driver
[14:41:05] <ssi> now I just gotta figure out how to make it dance :D
[14:41:21] <ssi> i'll likely start with programming... programming is done with I2C and SPI
[20:33:57] <skunkworks> dad may have scored big at a school auction...
http://www.electronicsam.com/images/emco/emco.JPG
[20:35:10] <Tom_itx> no kidding
[20:37:26] <jepler> skunkworks: you should see if cradek doesn't want to take one of those lathes off your hands. I think he needs a little lathe for his basement.
[20:37:53] <skunkworks> jepler: I thought he had one about that size?
[20:37:58] <kwallace> That's quite a find.
[20:38:46] <jepler> skunkworks: I don't know what happened to his sherline, but I know he was eyeing those two smallish cnc lathes at stuart's a couple weeks ago
[20:38:59] <skunkworks> yah - those where cool.
[20:39:06] <Tom_itx> i didn't get to see the small lathes
[20:39:12] <Tom_itx> what were they?
[20:39:55] <skunkworks> in the non air-conditioned part - where the new to them Cincinnati was being put together.
[20:40:08] <Tom_itx> ahh i saw that but missed the lathes
[20:40:16] <jepler> Tom_itx: they were not functional
[20:40:19] <Tom_itx> guess i'll have to swing by sometime and take another peek
[20:40:38] <skunkworks> kinda like these ;)
[20:41:04] <skunkworks> I wish they had the cool tool turrets - but they have the quick change ones.
[20:41:08] <Tom_itx> skunkworks, how beat up are they since they've been abused at a school?
[20:41:09] <skunkworks> beggers...
[20:41:20] <kwallace> They were close to the roll-up door. I recall them being the same EMCO lathes but in gray?
[20:41:26] <skunkworks> no clue - dad just sent me the pictures
[20:41:45] <skunkworks> I think they where branded southbend or something like the...
[20:41:56] <skunkworks> or am I remembering wronge
[20:42:48] <skunkworks> yes - southbend magnaturn. I think those are a bit heavier...
[20:42:59] <skunkworks> magnaturn 612
[20:44:23] <kwallace> Why am I getting 5 Volts on my 6i25 pins when the manual says the pull-ups are supplied with 3.3V?
[20:49:40] <jepler> kwallace: "W3 also selects the pull-up resistor voltage, When 5V I/O tolerance mode is
[20:49:43] <jepler> selected, the I/O pull-up resistors are powered from 5V
[20:49:46] <jepler> "
[20:49:59] <jepler> -- 6i25 manual page 2 under "5V I/O Tolerance"
[20:50:59] <kwallace> Okay, I missed that part. Thanks.
[20:51:42] <jepler> welcome
[20:52:10] <kwallace> I'm much better at reading schematics than text.
[20:52:26] <Tom_itx> when you power up a machine, should the logic supply come online before the driver voltages are enabled?
[20:56:18] <jepler> that sounds perilously close to a safety question, and so I wouldn't listen to any answer I got for free on the internet :-/
[20:58:15] <Tom_itx> well it's got to do with a problem i'm having once in a while
[20:58:30] <Tom_itx> and i'm smart enough to take free advice as such
[20:59:12] <Tom_itx> on power up once in a while an axis won't run
[20:59:18] <Tom_itx> not always the same axis
[20:59:35] <Tom_itx> gecko driven steppers on a 7i43 7i47 setup
[20:59:46] <Tom_itx> all shielded wiring
[21:00:01] <Tom_itx> 45v 18A supply
[21:00:22] <Tom_itx> on a sherline
[21:00:47] <Tom_itx> shut down and repower it and it's fine
[21:01:24] <Tom_itx> it's a linear supply
[21:01:53] <Tom_itx> i'm just trying to sort it out
[21:02:55] <kwallace> A Gecko per axis or the G540?
[21:03:19] <Tom_itx> no i'm using 203v
[21:03:35] <Tom_itx> x 3
[21:06:35] <kwallace> I don't know about the 203V but I just read the description "The G203V is Geckodrive's toughest drive and was designed with the intention of creating an indestructible stepper controller."
[21:06:39] <skunkworks> it would be cool to scope the output of the mesa board to see if you are getting output. (to see if it is mesa/linuxcnc side vs gecko/power)
[21:07:14] <kwallace> Maybe they are going into fault mode?
[21:07:23] <Tom_itx> i could watch the leds on the mesa card
[21:07:55] <Tom_itx> at first i thought it might be the connectors on the geckos
[21:08:01] <Tom_itx> i'm not real wild about those
[21:10:59] <jepler> you're talking about the power sequencing of the 203v or of some other component?
[21:11:19] <jepler> the 203v manual sure doesn't mention any power sequencing requirement
[21:11:26] <jepler> is there an error indicator on the 203v in this condition?
[21:11:53] <Tom_itx> i have the leds where i can't really watch them but i could move em
[21:12:51] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/cnc/psu/control1.jpg
[21:13:02] <Tom_itx> there's a pic of the box midway thru the wiring
[21:13:09] <jepler> hm the 203v doesn't have a separate logic power supply does it
[21:13:15] <Tom_itx> no
[21:13:34] <Tom_itx> i'm using a SMPS off a centertap of one of the xfrmrs
[21:13:49] <Tom_itx> otherwise it would be too high for the SMPS input
[21:14:26] <jepler> in this condition the linuxcnc dro for the affecte axis will change?
[21:14:30] <jepler> affected
[21:14:35] <Tom_itx> it keeps moving
[21:14:57] <Tom_itx> well the preview window anyway, i haven't watched the DRO but it would be the same
[21:15:25] <jepler> yes
[21:16:03] <Tom_itx> and it's not just one axis or it would be easier to figure out
[21:17:12] <Tom_itx> i'm using it mostly for learning linuxcnc right now so it's not critical
[21:17:35] <jepler> the 7i43's parallel port cable was removed for that photo?
[21:17:45] <Tom_itx> probably
[21:18:00] <Tom_itx> that was an early pic, alot of that isn't there now
[21:18:41] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/cnc/psu/control7.jpg
[21:18:44] <jepler> next time the problem presented itself I'd want to make sure the 7i47 is delivering the signals I expect
[21:18:58] <jepler> if you have one of those logic probes that can show high/low/pulsing that would be a good tool
[21:19:07] <Tom_itx> i have a saleae
[21:19:09] <jepler> clip on to gnd and probe at the screw of the screw terminal
[21:19:12] <jepler> that's even better
[21:19:43] <jepler> just verify if enable, step and dir are working as expected .. depending on the answer the problem is either in the amp or before the amp
[21:20:00] <Tom_itx> i think the leds pulse when stepping don't they? you wouldn't be able to see single pulses but they would glow
[21:22:26] <jepler> LEDs on the 7i47? I am not familiar with that board to be able to say
[21:22:44] <jepler> the manual seems to indicate there are indicators for the inputs but not for the outputs?
[21:23:18] <Tom_itx> yeah that's probably right.. i can't recall without looking again
[21:23:57] <Tom_itx> i'll set up the logic probe on each of the axis and wait for it to happen i guess
[21:25:37] <jepler> I guess you can't open it up without cutting the power?
[21:25:40] <jepler> pfft safety
[21:26:03] <ssi> defeat that mechanism immediately! :D
[21:27:37] <Tom_itx> well i got your ilowpass working on the pendant tonight at least
[21:29:05] <jepler> cool
[21:29:11] <jepler> jon e is wild about it
[21:31:03] <jepler> http://www.geckodrive.com/g203v-troubleshooting
[21:31:06] <jepler> if you had the LEDs you could read this
[21:31:36] <Tom_itx> well i could pull the heatsink off the door and watch em
[21:32:35] <jepler> reading how the disable works (described as having >1VDC between 'common' and 'disable' makes me think that you do need to make sure the disable signal of +5V is present before applying driver power to the 203v. otherwise the drive will enable while waiting for the logic to start..
[21:33:26] <jepler> but I am not answering a safety question
[21:34:14] <ssi> is it possible to reconfigure them to enables instead?
[21:34:24] <ssi> I know I've had problems in the past getting mesa gear to properly run a disable
[21:34:47] <ssi> the AMC drives have /INHIBIT lines, but you can open them up and remove a shunt to turn them into /ENABLE lines
[21:35:05] <jepler> I don't see anything in the gecko documentation to indicate this is possible
[21:35:18] <ssi> unfortunate
[21:35:29] <ssi> enable is much safer :)
[21:35:44] <ssi> (since safety is the topic this evening)
[21:35:49] <jepler> no it's not!
[21:36:18] <skunkworks> Should I put limit switches on my machine?
[21:36:23] <skunkworks> what about estops?
[21:36:25] <ssi> is it not?
[21:36:33] <skunkworks> ;)
[21:36:42] <jepler> I don't answer safety questions, so if I'm talking it must not be about safety
[21:36:50] <ssi> heh
[21:37:07] <jepler> protip: use a pendulum-mounted chainsaw instead of a traditional estop button
[21:37:32] <CaptHindsight> anyone ever work with one of these bridgport clones?
http://www.birminghammachines.com/Manual%20Machines/Mills/Birmingham%20mills.htm
[21:38:11] <CaptHindsight> all the parts are a slightly different size so they aren't interchangeable except for the drawbar and collets
[21:45:37] <ssi> ok that was cool
[21:45:41] <ssi> trying to do some git gymnastics
[21:46:11] <ssi> I forked jepler's github repo earlier, and pushed some new code to my fork
[21:46:27] <ssi> but it's for the BBB, and I realized when I tried to build on the BBB that jepler's mirror doesn't have any of that stuff from the mah repo
[21:46:57] <ssi> so I went over to my mah clone, and created a new branch for my new stuff, and added my github fork as a remote, and cherrypicked the commit
[21:47:00] <ssi> super cool
[21:49:38] <jepler> git is cool
[21:49:46] <ssi> yeah definitely
[21:49:56] <ssi> I'm just trepidatiously trying to do some stuff without breaking anything :)
[21:49:56] <jepler> I hear we need to use its collaboration features smarter :-/
[21:50:33] <ssi> well as I've been vocalizing heavily on maillist, there's a lot of things it can do that most of us don't really know how to do, and it's scurry when you don't know how :)
[21:55:55] <ssi> now for my least favorite part... hacking the makefile :/
[21:56:25] <jepler> sigh, everyone hates the build system so bad
[21:56:29] * jepler <-- implemented it
[21:56:39] <jepler> I just need a thicker skin I guess
[21:56:46] <ssi> again... don't understand it, scared of breaking it!
[21:57:08] * ssi pats jepler
[21:58:56] <jepler> anyway goodnight
[21:59:28] <ssi> gnight
[22:54:07] <zultron> I did a lot of work to clean up CFLAGS and LDFLAGS in the build system for the universal build branch. Unfortunately, it got a bit hairier at the same time when it learned how to build for multiple RT thread flavors and multiple kernels per kernel flavor in a single run.
[22:55:17] <zultron> If we decide to split off BLOCS/Machinekit, I have a cmake configuration mostly done that vastly simplifies things. :)
[22:56:19] <ssi> i have a suspicion machinekit is going to help a lot with overall code tidiness
[22:56:28] <ssi> although it'll certainly be some work to get there
[22:59:59] <zultron> Hopefully it'll be 'just work', though. I don't predict it'll be rocket science, but most of the 'small' projects I've taken on end up needing weeks to complete.
[23:12:06] <memleak> Hello!
[23:12:35] <memleak> I'm having a problem compiling the v2.5_branch for linuxcnc with a 2.6 RTAI kernel (gave up on 3.x for now)
[23:14:01] <memleak> I'm getting those undefined references to rt_shm_alloc and rt_shm_free but after I applied this fix:
http://cache.gmane.org//gmane/linux/real-time/rtai/25820-001.bin in rtapi I get the same errors
[23:15:21] <memleak> Before I modified hal/Submakefile now it looks like i need to modify rtapi/Submakefile but the fix for hal/Submakefile doesn't fix rtapi/Submakefile
[23:16:19] <memleak> rtai_ulapi.c:565, 108, 443, and 479 undefined references to those two functions
[23:21:28] <memleak> Back to v2.4 branch...
[23:22:32] <memleak> zultron: do you have a link to the clean up you did with the CFLAGS and LDFLAGS?
[23:26:58] <memleak> same issue with v2.4 branch..
[23:31:13] <ssi> so I'm trying to write a new hm2 driver, and I'm not sure I understand how the driver gets ahold of the config string
[23:31:22] <ssi> I'm doing this:
[23:31:22] <ssi> static char *config[HM2_BCC_MAX_BOARDS];
[23:31:22] <ssi> RTAPI_MP_ARRAY_STRING(config,HM2_BCC_MAX_BOARDS, "config string(s) for the BCC board(s) (see hostmot2(9) manpage)");
[23:31:48] <ssi> but it behaves thusly: halcmd: loadrt hm2_bcc config="foo"
[23:31:48] <ssi> Unknown parameter `config=foo' (corrupt array type information): 1-(4)s
[23:32:03] <ssi> hm maybe there's a clue in "corrupt array type information"
