Back
[00:02:03] -!- atom1 has quit [Quit: Leaving]
[00:02:50] -!- Nick001-Shop has quit [Remote host closed the connection]
[00:15:58] -!- stsydow has quit [Remote host closed the connection]
[00:18:51] -!- zzolo has quit [Quit: zzolo]
[00:21:49] -!- rob_h has quit [Ping timeout: 246 seconds]
[00:26:24] _BJFreeman is now known as BJfreeman
[00:36:39] -!- jfire has quit [Quit: Leaving.]
[00:40:09] -!- psha has quit [Quit: Lost terminal]
[00:46:09] -!- BJfreeman has quit [Ping timeout: 252 seconds]
[00:47:21] _BJFreeman is now known as BJfreeman
[00:57:25] -!- hashfail has quit [Write error: Connection reset by peer]
[00:57:25] -!- pjm_ has quit [Write error: Connection reset by peer]
[00:59:17] -!- apel has quit [Excess Flood]
[00:59:28] -!- PCW has quit [Ping timeout: 248 seconds]
[01:00:03] -!- jthornton_ [jthornton_!~john@99.198.67.11] has joined #linuxcnc-devel
[01:00:52] -!- Brandonian has quit [Read error: Connection reset by peer]
[01:00:52] Brandonian_ is now known as Brandonian
[01:00:54] -!- mattiasb has quit [Ping timeout: 246 seconds]
[01:00:54] -!- jthornton has quit [Read error: Connection reset by peer]
[01:01:00] -!- archivist_herron has quit [Ping timeout: 246 seconds]
[01:01:21] -!- gonzo_ has quit [Ping timeout: 246 seconds]
[01:01:21] -!- Aero-Tec2 has quit [Ping timeout: 246 seconds]
[01:01:50] -!- JT-Shop-2 [JT-Shop-2!~John@99.198.67.11] has joined #linuxcnc-devel
[01:02:53] -!- |1li has quit [Read error: Connection reset by peer]
[01:03:56] -!- PCW_ has quit [Ping timeout: 256 seconds]
[01:10:33] -!- Aero-Tec3 has quit [*.net *.split]
[01:10:33] -!- pjm has quit [*.net *.split]
[01:10:33] -!- JT-Shop has quit [*.net *.split]
[01:10:34] -!- fatpandas has quit [*.net *.split]
[01:10:35] -!- erictheise has quit [*.net *.split]
[01:10:35] -!- jef79m has quit [*.net *.split]
[01:10:36] -!- XiXora_ has quit [*.net *.split]
[01:10:36] -!- mal`` has quit [*.net *.split]
[01:10:36] -!- gene78 has quit [*.net *.split]
[01:10:36] -!- louis___ has quit [*.net *.split]
[01:10:36] erictheise_ is now known as erictheise
[01:10:37] jef79m_ is now known as jef79m
[01:11:13] -!- mal`` [mal``!~mal``@li125-242.members.linode.com] has joined #linuxcnc-devel
[01:11:33] XiXora__ is now known as XiXora_
[01:12:32] -!- uwe_mobile__ has quit [Ping timeout: 256 seconds]
[01:13:41] -!- hashfail_ has quit [Ping timeout: 256 seconds]
[01:14:56] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:19:43] <skunkworks> dad may have scored big at a school auction...
http://www.electronicsam.com/images/emco/emco.JPG
[01:20:56] <Tom_itx> no kidding
[01:23:12] <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.
[01:23:39] <skunkworks> jepler: I thought he had one about that size?
[01:23:44] <kwallace> That's quite a find.
[01:24:32] <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
[01:24:45] <skunkworks> yah - those where cool.
[01:24:52] <Tom_itx> i didn't get to see the small lathes
[01:24:58] <Tom_itx> what were they?
[01:25:41] <skunkworks> in the non air-conditioned part - where the new to them Cincinnati was being put together.
[01:25:54] <Tom_itx> ahh i saw that but missed the lathes
[01:26:02] <jepler> Tom_itx: they were not functional
[01:26:05] <Tom_itx> guess i'll have to swing by sometime and take another peek
[01:26:24] <skunkworks> kinda like these ;)
[01:26:50] <skunkworks> I wish they had the cool tool turrets - but they have the quick change ones.
[01:26:54] <Tom_itx> skunkworks, how beat up are they since they've been abused at a school?
[01:26:55] <skunkworks> beggers...
[01:27:06] <kwallace> They were close to the roll-up door. I recall them being the same EMCO lathes but in gray?
[01:27:12] <skunkworks> no clue - dad just sent me the pictures
[01:27:31] <skunkworks> I think they where branded southbend or something like the...
[01:27:41] <skunkworks> or am I remembering wronge
[01:28:34] <skunkworks> yes - southbend magnaturn. I think those are a bit heavier...
[01:28:45] <skunkworks> magnaturn 612
[01:29:19] -!- sumpfralle has quit [Read error: Operation timed out]
[01:30:09] <kwallace> Why am I getting 5 Volts on my 6i25 pins when the manual says the pull-ups are supplied with 3.3V?
[01:33:58] -!- mhaberler [mhaberler!~mhaberler@63.68.157.172] has joined #linuxcnc-devel
[01:35:26] <jepler> kwallace: "W3 also selects the pull-up resistor voltage, When 5V I/O tolerance mode is
[01:35:29] <jepler> selected, the I/O pull-up resistors are powered from 5V
[01:35:32] <jepler> "
[01:35:45] <jepler> -- 6i25 manual page 2 under "5V I/O Tolerance"
[01:36:45] <kwallace> Okay, I missed that part. Thanks.
[01:37:28] <jepler> welcome
[01:37:56] <kwallace> I'm much better at reading schematics than text.
[01:38:12] <Tom_itx> when you power up a machine, should the logic supply come online before the driver voltages are enabled?
[01:38:22] -!- mhaberler has quit [Client Quit]
[01:38:45] -!- skunkworks has quit [Ping timeout: 248 seconds]
[01:40:23] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[01:42:04] <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 :-/
[01:44:01] <Tom_itx> well it's got to do with a problem i'm having once in a while
[01:44:16] <Tom_itx> and i'm smart enough to take free advice as such
[01:44:58] <Tom_itx> on power up once in a while an axis won't run
[01:45:04] <Tom_itx> not always the same axis
[01:45:21] <Tom_itx> gecko driven steppers on a 7i43 7i47 setup
[01:45:32] <Tom_itx> all shielded wiring
[01:45:47] <Tom_itx> 45v 18A supply
[01:46:08] <Tom_itx> on a sherline
[01:46:33] <Tom_itx> shut down and repower it and it's fine
[01:46:43] -!- danielfalck has quit [Ping timeout: 264 seconds]
[01:47:10] <Tom_itx> it's a linear supply
[01:47:39] <Tom_itx> i'm just trying to sort it out
[01:48:41] <kwallace> A Gecko per axis or the G540?
[01:49:05] <Tom_itx> no i'm using 203v
[01:49:20] <Tom_itx> x 3
[01:52:21] <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."
[01:52:25] <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)
[01:53:00] <kwallace> Maybe they are going into fault mode?
[01:53:09] <Tom_itx> i could watch the leds on the mesa card
[01:53:41] <Tom_itx> at first i thought it might be the connectors on the geckos
[01:53:47] <Tom_itx> i'm not real wild about those
[01:53:59] -!- micges has quit [Quit: Leaving]
[01:56:45] <jepler> you're talking about the power sequencing of the 203v or of some other component?
[01:57:05] <jepler> the 203v manual sure doesn't mention any power sequencing requirement
[01:57:12] <jepler> is there an error indicator on the 203v in this condition?
[01:57:38] <Tom_itx> i have the leds where i can't really watch them but i could move em
[01:58:37] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/cnc/psu/control1.jpg
[01:58:48] <Tom_itx> there's a pic of the box midway thru the wiring
[01:58:55] <jepler> hm the 203v doesn't have a separate logic power supply does it
[01:59:01] <Tom_itx> no
[01:59:20] <Tom_itx> i'm using a SMPS off a centertap of one of the xfrmrs
[01:59:35] <Tom_itx> otherwise it would be too high for the SMPS input
[02:00:12] <jepler> in this condition the linuxcnc dro for the affecte axis will change?
[02:00:16] <jepler> affected
[02:00:21] <Tom_itx> it keeps moving
[02:00:43] <Tom_itx> well the preview window anyway, i haven't watched the DRO but it would be the same
[02:01:11] <jepler> yes
[02:01:49] <Tom_itx> and it's not just one axis or it would be easier to figure out
[02:02:58] <Tom_itx> i'm using it mostly for learning linuxcnc right now so it's not critical
[02:03:21] <jepler> the 7i43's parallel port cable was removed for that photo?
[02:03:31] <Tom_itx> probably
[02:03:46] <Tom_itx> that was an early pic, alot of that isn't there now
[02:04:27] <Tom_itx> http://tom-itx.dyndns.org:81/~webpage/cnc/psu/control7.jpg
[02:04:30] <jepler> next time the problem presented itself I'd want to make sure the 7i47 is delivering the signals I expect
[02:04:44] <jepler> if you have one of those logic probes that can show high/low/pulsing that would be a good tool
[02:04:53] <Tom_itx> i have a saleae
[02:04:55] <jepler> clip on to gnd and probe at the screw of the screw terminal
[02:04:58] <jepler> that's even better
[02:05:29] <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
[02:05:46] <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
[02:08:12] <jepler> LEDs on the 7i47? I am not familiar with that board to be able to say
[02:08:30] <jepler> the manual seems to indicate there are indicators for the inputs but not for the outputs?
[02:09:04] <Tom_itx> yeah that's probably right.. i can't recall without looking again
[02:09:43] <Tom_itx> i'll set up the logic probe on each of the axis and wait for it to happen i guess
[02:10:52] -!- DaveCVI has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Nine out of ten l33t h4x0rz prefer it]
[02:11:23] <jepler> I guess you can't open it up without cutting the power?
[02:11:26] <jepler> pfft safety
[02:11:49] <ssi> defeat that mechanism immediately! :D
[02:12:01] -!- Servos4ever has quit [Quit: ChatZilla 0.9.90 [SeaMonkey 2.14.1/20121129191050]]
[02:13:23] <Tom_itx> well i got your ilowpass working on the pendant tonight at least
[02:14:10] -!- Laremere has quit [Ping timeout: 246 seconds]
[02:14:29] -!- Brandonian has quit [Quit: Brandonian]
[02:14:51] <jepler> cool
[02:14:57] <jepler> jon e is wild about it
[02:16:49] <jepler> http://www.geckodrive.com/g203v-troubleshooting
[02:16:52] <jepler> if you had the LEDs you could read this
[02:17:22] <Tom_itx> well i could pull the heatsink off the door and watch em
[02:18:21] <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..
[02:19:12] <jepler> but I am not answering a safety question
[02:20:00] <ssi> is it possible to reconfigure them to enables instead?
[02:20:10] <ssi> I know I've had problems in the past getting mesa gear to properly run a disable
[02:20:33] <ssi> the AMC drives have /INHIBIT lines, but you can open them up and remove a shunt to turn them into /ENABLE lines
[02:20:51] <jepler> I don't see anything in the gecko documentation to indicate this is possible
[02:21:04] <ssi> unfortunate
[02:21:15] <ssi> enable is much safer :)
[02:21:30] <ssi> (since safety is the topic this evening)
[02:21:35] <jepler> no it's not!
[02:22:04] <skunkworks> Should I put limit switches on my machine?
[02:22:09] <skunkworks> what about estops?
[02:22:11] <ssi> is it not?
[02:22:13] -!- danielfalck [danielfalck!~danielfal@static-50-53-220-68.bvtn.or.frontiernet.net] has joined #linuxcnc-devel
[02:22:19] <skunkworks> ;)
[02:22:28] <jepler> I don't answer safety questions, so if I'm talking it must not be about safety
[02:22:36] <ssi> heh
[02:22:52] <jepler> protip: use a pendulum-mounted chainsaw instead of a traditional estop button
[02:23:18] <CaptHindsight> anyone ever work with one of these bridgport clones?
http://www.birminghammachines.com/Manual%20Machines/Mills/Birmingham%20mills.htm
[02:23:56] <CaptHindsight> all the parts are a slightly different size so they aren't interchangeable except for the drawbar and collets
[02:31:23] <ssi> ok that was cool
[02:31:26] <ssi> trying to do some git gymnastics
[02:31:57] <ssi> I forked jepler's github repo earlier, and pushed some new code to my fork
[02:32:13] <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
[02:32:43] <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
[02:32:46] <ssi> super cool
[02:35:23] <jepler> git is cool
[02:35:32] <ssi> yeah definitely
[02:35:42] <ssi> I'm just trepidatiously trying to do some stuff without breaking anything :)
[02:35:42] <jepler> I hear we need to use its collaboration features smarter :-/
[02:36:19] <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 :)
[02:41:41] <ssi> now for my least favorite part... hacking the makefile :/
[02:42:11] <jepler> sigh, everyone hates the build system so bad
[02:42:15] * jepler <-- implemented it
[02:42:25] <jepler> I just need a thicker skin I guess
[02:42:32] <ssi> again... don't understand it, scared of breaking it!
[02:42:54] * ssi pats jepler
[02:44:42] <jepler> anyway goodnight
[02:45:14] <ssi> gnight
[03:05:50] -!- skunkworks has quit [Remote host closed the connection]
[03:06:20] -!- Cylly has quit [Ping timeout: 256 seconds]
[03:10:04] -!- erictheise_ has quit [Quit: erictheise_]
[03:20:01] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[03:36:31] -!- erictheise_ has quit [Quit: erictheise_]
[03:39:53] <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.
[03:41:03] <zultron> If we decide to split off BLOCS/Machinekit, I have a cmake configuration mostly done that vastly simplifies things. :)
[03:42:05] <ssi> i have a suspicion machinekit is going to help a lot with overall code tidiness
[03:42:13] <ssi> although it'll certainly be some work to get there
[03:45:45] <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.
[03:49:43] -!- mattiasb has quit [Ping timeout: 264 seconds]
[03:56:12] -!- Brandonian has quit [Client Quit]
[03:57:50] -!- memleak [memleak!~memleak@unaffiliated/memleak] has joined #linuxcnc-devel
[03:57:52] <memleak> Hello!
[03:58:21] <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)
[03:58:26] -!- BJfreeman has quit [Quit: had a good time]
[03:59:47] <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
[04:01:07] <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
[04:02:05] <memleak> rtai_ulapi.c:565, 108, 443, and 479 undefined references to those two functions
[04:02:35] -!- jerryitt has quit [Quit: Leaving.]
[04:02:55] -!- danielfalck has quit [Ping timeout: 264 seconds]
[04:07:14] <memleak> Back to v2.4 branch...
[04:08:18] <memleak> zultron: do you have a link to the clean up you did with the CFLAGS and LDFLAGS?
[04:12:15] -!- |1li has quit [Read error: Connection reset by peer]
[04:12:44] <memleak> same issue with v2.4 branch..
[04:16:58] <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
[04:17:08] <ssi> I'm doing this:
[04:17:08] <ssi> static char *config[HM2_BCC_MAX_BOARDS];
[04:17:08] <ssi> RTAPI_MP_ARRAY_STRING(config,HM2_BCC_MAX_BOARDS, "config string(s) for the BCC board(s) (see hostmot2(9) manpage)");
[04:17:19] -!- Valen has quit [Quit: Leaving.]
[04:17:34] <ssi> but it behaves thusly: halcmd: loadrt hm2_bcc config="foo"
[04:17:34] <ssi> Unknown parameter `config=foo' (corrupt array type information): 1-(4)s
[04:17:49] <ssi> hm maybe there's a clue in "corrupt array type information"
[04:20:21] -!- skorasaurus has quit [Ping timeout: 248 seconds]
[04:24:52] -!- vladimirek has quit [Remote host closed the connection]
[04:26:46] -!- PetefromTn has quit [Read error: Connection reset by peer]
[04:27:53] -!- zzolo has quit [Quit: zzolo]
[04:30:18] -!- PetefromTn has quit [Client Quit]
[04:39:20] -!- L33TG33KG34R has quit [Read error: Connection reset by peer]
[04:42:52] -!- danielfalck [danielfalck!~danielfal@static-50-53-1-104.bvtn.or.frontiernet.net] has joined #linuxcnc-devel
[04:55:22] <ssi> got it... something's changed between the version of hm2_7i43 I based this skeleton on and the current code tree i'm working in
[04:55:54] <ssi> I had #define HM2_BCC_MAX_BOARDS (4), and the parens were flipping out the rtapi module parser
[04:59:29] -!- kwallace [kwallace!~kwallace@smb-91.sonnet.com] has parted #linuxcnc-devel
[05:02:53] -!- Fox_Muldr has quit [Ping timeout: 256 seconds]
[05:07:43] -!- |1li has quit [Quit: Leaving]
[05:14:55] -!- mattiasb has quit [Ping timeout: 276 seconds]
[05:20:21] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[05:21:25] -!- dhoovie has quit [Ping timeout: 246 seconds]
[05:45:17] -!- psha has quit [Quit: Lost terminal]
[05:56:41] -!- FinboySlick has quit [Quit: Leaving.]
[05:58:19] <memleak> im gettin sleepy, good night all
[05:58:20] -!- memleak has quit [Quit: Leaving]
[06:00:39] -!- ve7it has quit [Remote host closed the connection]
[06:00:51] -!- qrp has quit [Ping timeout: 250 seconds]
[06:39:24] -!- stsydow has quit [Remote host closed the connection]
[06:43:27] -!- f1oat has quit [Client Quit]
[06:45:25] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[06:52:12] -!- DJ9DJ has quit [Changing host]
[07:03:26] -!- qrp has quit [Quit: Page closed]
[07:07:48] s1dev is now known as s1dev|away
[07:08:39] s1dev|away is now known as s1dev
[07:10:48] -!- bedah has quit [Ping timeout: 240 seconds]
[07:27:47] -!- mozmck has quit [Ping timeout: 252 seconds]
[07:30:40] _BJFreeman is now known as BJfreeman
[07:32:29] -!- vladimirek has quit [Remote host closed the connection]
[07:54:56] XiXora_ is now known as XiXora
[08:02:46] -!- ddd has quit [Client Quit]
[08:24:35] -!- rob_h [rob_h!~rob_h@2.124.43.146] has joined #linuxcnc-devel
[08:37:05] -!- Valen has quit [Ping timeout: 256 seconds]
[08:43:02] -!- Jymmm has quit [Ping timeout: 256 seconds]
[08:47:21] -!- mozmck [mozmck!~moses@client-204.235.45.143.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[09:01:42] -!- _stn has quit [Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]]
[09:26:45] -!- BJfreeman has quit [Quit: had a good time]
[10:17:46] jthornton_ is now known as jthornton
[10:25:09] -!- sumpfralle has quit [Ping timeout: 248 seconds]
[10:31:44] -!- b_b has quit [Changing host]
[10:47:58] -!- skunkworks [skunkworks!~skunkwork@68-115-41-210.static.eucl.wi.charter.com] has joined #linuxcnc-devel
[10:48:40] <KGB-linuxcnc> 03jthornton 05v2.5_branch b538aa7 06linuxcnc 10docs/src/examples/mpg.txt
[10:48:40] <KGB-linuxcnc> Docs: fix example code
[10:48:40] <KGB-linuxcnc> Thanks to Tom for spotting this and fixing the example
[10:48:40] <KGB-linuxcnc> Signed-off-by: John Thornton <jthornton@gnipsel.com>
[10:57:03] <jthornton> odd the terminal window hung up after Total 6 (delta 5), reused 0 (delta 0) and seems to be waiting on something
[11:02:09] -!- b_b has quit [Changing host]
[11:13:59] -!- Simooon has quit [Quit: Leaving]
[11:29:43] -!- Valen has quit [Quit: Leaving.]
[11:30:27] <linuxcnc-build> build #1137 of lucid-amd64-sim is complete: Failure [4failed compile runtests] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1137 blamelist: John Thornton <jthornton@gnipsel.com>
[11:36:10] -!- putnik has quit [Changing host]
[11:39:48] -!- Kenneth_Lerman [Kenneth_Lerman!~chatzilla@24-151-1-146.static.nwtn.ct.charter.com] has joined #linuxcnc-devel
[11:42:01] <linuxcnc-build> build #1134 of checkin is complete: Failure [4failed] Build details are at
http://buildbot.linuxcnc.org/buildbot/builders/checkin/builds/1134 blamelist: John Thornton <jthornton@gnipsel.com>
[11:55:18] -!- psha[work] [psha[work]!~psha@195.135.238.205] has joined #linuxcnc-devel
[11:56:20] -!- md-2 has quit [Remote host closed the connection]
[12:03:26] <jepler> ssi: it's a difference in how loadrt parameters work between kernel 2.6+ and userspace, hm2_7i43 when running in kernelspace wouldn't encounter a problem; in a userspace thread model it would
[12:05:22] -!- Felix29 [Felix29!Felix@c-71-193-105-131.hsd1.in.comcast.net] has joined #linuxcnc-devel
[12:20:57] -!- dhoovie|2 has quit [Read error: Connection reset by peer]
[12:22:28] -!- dhoovie has quit [Ping timeout: 246 seconds]
[12:36:23] -!- md-2 has quit [Remote host closed the connection]
[12:50:33] -!- jfrmilner has quit [Quit: bye]
[12:53:29] -!- stsydow has quit [Remote host closed the connection]
[13:16:31] -!- Felix29 has quit []
[13:20:44] -!- AndrewLv has quit [Client Quit]
[13:21:15] <skunkworks> he also got
http://electronicsam.com/images/emco/terco.JPG
[13:21:47] <skunkworks> oops
[13:28:08] <jthornton> I got a strange error after my last push that I don't understand.
http://pastebin.com/gvXXVWcU
[13:30:49] <cradek> error: error in sideband demultiplexer
[13:30:50] <cradek> uhhh
[13:31:46] <jthornton> what the heck is that?
[13:31:49] <cradek> b538aa7 did get pushed
[13:31:52] <cradek> I have no idea, sorry
[13:32:09] <jthornton> ok, if it got pushed I'll ignore the error on this end
[13:32:14] <jthornton> thanks for looking
[13:32:23] <cradek> http://git.linuxcnc.org/gitweb?p=linuxcnc.git;a=log;h=refs/heads/v2.5_branch
[13:33:45] <jthornton> I didn't even think of looking on the git log, I focused too much on the error
[13:40:19] _BJFreeman is now known as BJfreeman
[13:44:59] <ssi> jepler: that makes sense
[13:48:27] -!- qrp has quit [Quit: Page closed]
[14:19:21] -!- Nick001 has quit [Ping timeout: 256 seconds]
[14:24:39] <seb_kuzminsky> argh
[14:25:03] <seb_kuzminsky> the buildbot failure looks like the old linuxcncrsh problem again, but running with cradek
[14:25:26] <seb_kuzminsky> cradek's unbehiddening patch there's new info:
[14:25:34] <seb_kuzminsky> http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1137/steps/runtests/logs/stdio
[14:25:37] <seb_kuzminsky> search for linuxcncrsh
[14:25:55] <seb_kuzminsky> "Not starting new LinuxCNC"
[14:26:11] <seb_kuzminsky> that's the linuxcnc script not starting linuxcnc because it thinks it's already running
[14:26:21] -!- obnoxiousorc has quit [Quit: Page closed]
[14:27:33] <jepler> back here at build 1133, the build was killed for "1200 seconds without output"
[14:27:36] <jepler> http://buildbot.linuxcnc.org/buildbot/builders/lucid-amd64-sim/builds/1133/steps/runtests/logs/stdio
[14:27:40] <jepler> that sure could leave the lock file
[14:27:57] <jepler> .. and that log has interesting information too
[14:28:00] <jepler> it goes off the rails because:
[14:28:00] <jepler> Issuing EMC_TASK_PLAN_EXECUTE -- (+509,+280, +9,m100\032p0\032q0,)
[14:28:01] <jepler> Can't issue MDI command when not homed
[14:28:01] <jepler> emc/task/emctaskmain.cc 2185: error executing command 509:EMC_TASK_PLAN_EXECUTE
[14:28:04] <jepler> emcTaskIssueCommand() returning: -1
[14:28:30] <seb_kuzminsky> i gotta run, but i'll look at this later today
[14:28:35] <jepler> you're a champ.
[14:28:38] <seb_kuzminsky> seems like two problems
[14:28:52] <seb_kuzminsky> i'm a chump for putting this failing test in there in the first place...
[14:28:53] <seb_kuzminsky> laters
[14:29:05] <jepler> so 'sleep 2' isn't necessarily enough to get linuxcnc homed I guess?
[14:34:22] -!- JT-Shop-2 has quit [Read error: Connection reset by peer]
[14:34:23] -!- jthornton has quit [Read error: Connection reset by peer]
[14:34:49] -!- JT-Shop-2 [JT-Shop-2!~John@99.198.67.11] has joined #linuxcnc-devel
[14:34:53] -!- jthornton [jthornton!~john@99.198.67.11] has joined #linuxcnc-devel
[14:37:48] -!- Valen has quit [Quit: Leaving.]
[14:43:27] JT-Shop-2 is now known as JT-Shop
[14:52:25] -!- bithin has quit [Quit: Page closed]
[14:52:27] <alex_joni> cradek:
http://stackoverflow.com/questions/9592908/error-in-sideband-demultiplexer-with-a-git-post-receive-hook
[14:53:36] <cradek> I kind of figured one of the hooks failed, but I couldn't find anything in my logs about what or why
[14:54:09] <alex_joni> might be the KGB hook?
[14:54:17] <cradek> KGB-linuxcnc: knock knock
[14:54:17] <KGB-linuxcnc> cradek: My master told me to not respond.
[14:54:27] <cradek> well it's alive
[14:54:39] <cradek> it might have been buildbot too
[14:54:39] <alex_joni> if it's a one-off.. forget it :)
[14:54:41] * cradek shrugs
[14:54:56] <cradek> thanks for finding that answer
[14:55:45] -!- Nick001-Shop has quit [Ping timeout: 246 seconds]
[14:55:47] Nick001-Shop_ is now known as Nick001-Shop
[14:56:15] <alex_joni> I found a technical explanation too
http://git.661346.n2.nabble.com/error-error-in-sideband-demultiplexer-td6473787.html
[14:58:25] -!- psha[work] has quit [Quit: Lost terminal]
[14:58:31] <cradek> "the XXXX hook exited with an error or before reading all its stdin"
[14:59:06] -!- Brandonian has quit [Quit: Brandonian]
[14:59:21] <cradek> EVEN if you know it's talking about hooks, it's still a lousy error message that makes you guess what went wrong
[14:59:32] <JT-Shop> I've only seen it the one time
[15:04:57] -!- kwallace [kwallace!~kwallace@smb-142.sonnet.com] has joined #linuxcnc-devel
[15:05:10] -!- mattiasb has quit [Ping timeout: 252 seconds]
[15:10:35] -!- jmckenna has quit [Read error: Connection reset by peer]
[15:18:46] -!- fomox has quit [Ping timeout: 276 seconds]
[15:25:13] -!- BJfreeman has quit [Quit: had a good time]
[15:25:47] -!- mattiasb has quit [Ping timeout: 260 seconds]
[15:26:58] <kwallace> Is it just me or is searching for information on IC part numbers totally polluted?
[15:28:20] _BJFreeman is now known as BJfreeman
[15:30:51] <skunkworks> you have to wade through the crap
[15:31:10] <cradek> yeah, it's not you
[15:32:15] <kwallace> I found it:
http://www.pericom.com/products/signal-switch-multiplexers/?part=PI5C16211
[15:33:56] <kwallace> I found this chip on the 6i25 and assume I can use these specs as a guide for the I/O pins?
[15:35:33] <CaptHindsight> for signal characteristics possibly if there are no other components between the package pins and the connectors
[15:36:47] <CaptHindsight> but signal numbering on the Pin Config diagram and what the PCB uses might be completely different
[15:40:44] <kwallace> I'm just trying to get an idea what the 6i25 I/O sink and source currents might be. Crud, this chip is a switch and not a driver, so is the wrong place to look.
[15:41:12] <skunkworks> kwallace, ask peter :)
[15:41:32] <cradek> I'd figure his manuals were good enough to tell you - no?
[15:42:39] -!- psha [psha!~psha@213.208.162.67] has joined #linuxcnc-devel
[15:44:02] <skunkworks> I don't see it in the manual
[15:44:12] <kwallace> The only thing I have pulled from the manual is information on voltage tolerance and pull-ups, which don't shed light on sink current.
[15:45:04] <skunkworks> it should be atleast as good as a printer port sinking :)
[15:49:13] <kwallace> Which usually is 3ma. Until I hear otherwise, I'll have to go with that. Thank you.
[15:59:55] -!- ve7it [ve7it!~LawrenceG@S01060014d19d0b68.pk.shawcable.net] has joined #linuxcnc-devel
[16:01:56] <jepler> I also don't spot a specification of sink current in the 6i25 manual
[16:02:30] -!- mattiasb has quit [Ping timeout: 264 seconds]
[16:04:03] <pcw_home> 24 mA sink/source
[16:05:03] <pcw_home> (Max, the output drive is programmable)
[16:05:17] <jepler> pcw_home: thank you
[16:05:21] <jepler> did we overlook it in the manual?
[16:05:29] <jepler> or is it bitfile programmable?
[16:05:47] <pcw_home> Yes its programmable in th ebitfile
[16:05:51] <jepler> gotcha
[16:06:09] <pcw_home> ~4 to 24 mA IICRC
[16:06:44] <pcw_home> default for external I/O pins in our UCF files is 24 mA
[16:08:31] <seb_kuzminsky> pcw_home: speaking of "programmable in the bitfile", we should talk about hostmot2 firmware building at some point
[16:08:36] <pcw_home> NET "IOBITS<0>" LOC = "P132" | IOSTANDARD=LVTTL | SLEW=SLOW | DRIVE=24;
[16:09:13] <seb_kuzminsky> the hm2 buildbot is up and running, it's building the vhdl source in git and producing debs containing bitfiles that i haven't tested yet
[16:09:25] -!- Kup has quit [Read error: Connection reset by peer]
[16:09:25] <pcw_home> Thats would be great to get the buildbot synced to the latest
[16:09:51] <kwallace> So, I can count on at least 4ma which is plenty to control optos, LEDs and driver ICs. Thanks Peter.
[16:10:02] <seb_kuzminsky> yeah, agreed!
[16:10:25] <seb_kuzminsky> i'd be happy to help you get set up with git some night (not now, i'm at work)
[16:10:40] <seb_kuzminsky> do you do your development on windows or linux? (or something else?)
[16:10:59] <pcw_home> kwallace all of our standard configs are set for 24 mA on the I/O pins
[16:10:59] -!- mattiasb has quit [Ping timeout: 256 seconds]
[16:11:11] <pcw_home> Windows
[16:11:21] <pcw_home> not that it matters much
[16:11:49] <pcw_home> I actually made a batch file to build all the 7I80 varients
[16:11:54] <seb_kuzminsky> it only impacts which git client you use
[16:12:54] <seb_kuzminsky> hey, the git folks are providing .exe files (installers?) directly, i didn't know that!
http://git-scm.com/download/win
[16:13:08] <seb_kuzminsky> bbl
[16:13:22] <pcw_home> bye
[16:13:25] -!- BJfreeman has quit [Quit: had a good time]
[16:17:10] <jepler> pcw_home: is current ISE able to take advantage of multiple cores while building a single firmware?
[16:17:45] <jepler> pcw_home: one of the neat things about my linux build scripts is that as long as you have enough RAM you can start 1 firmware build for each core in a multi-core system
[16:18:00] <jepler> .. i am not aware of how to do that with batch files, though it sure could be a hole in my knowledge
[16:26:49] <pcw_home> I think its possible but I did not do it (also not sure it would help much with only4 G of RAM)
[16:26:50] <pcw_home> i just let it run, took a few hours to do ~20 bitfiles
[16:31:28] -!- mackerski has quit [Quit: mackerski]
[16:31:36] <jepler> I did this in a 4GB, 4-core machine though that was also with an older version of ise
[16:31:50] -!- mozmck has quit [Quit: Leaving.]
[16:31:56] <jepler> I assume now that 4GB+ machines are the norm their memory usage has grown accordingly
[16:32:09] -!- PetefromTn has quit [Remote host closed the connection]
[16:32:56] -!- mozmck [mozmck!~moses@client-204.235.45.143.wcfltx.partnershipbroadband.com] has joined #linuxcnc-devel
[16:33:41] <jepler> my memory is that I could build 48 firmwares in something like 80 wall minutes
[16:33:46] <pcw_home> Not sure, the install size is huge now but i dont think they mess with place&route much, its more FPGA size dependent
[16:35:19] <pcw_home> also really depends on how full the FPGA is (80% might be 5 minutes, 95% migh be 40)
[16:52:04] -!- Heinz_60 has quit [Quit: HydraIRC -> http://www.hydrairc.com <- Go on, try it!]
[16:52:16] -!- mourner has quit [Quit: mourner]
[16:57:43] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[17:02:06] -!- pjm_ has quit [Read error: Connection reset by peer]
[17:06:10] -!- tmcw has quit [Remote host closed the connection]
[17:11:29] -!- md-2 has quit [Remote host closed the connection]
[17:34:10] -!- mhaberler has quit [Quit: mhaberler]
[17:38:05] -!- andypugh [andypugh!~andy2@cpc16-basl9-2-0-cust685.20-1.cable.virginmedia.com] has joined #linuxcnc-devel
[17:45:40] -!- fomox has quit [Ping timeout: 276 seconds]
[17:46:09] -!- erictheise_ has quit [Quit: erictheise_]
[17:48:57] -!- IchGuckLive has quit [Quit: ChatZilla 0.9.87 [Firefox 20.0/20130329043827]]
[17:50:27] -!- md-2 has quit [Ping timeout: 260 seconds]
[18:09:46] -!- syyl_ws has quit [Quit: Verlassend]
[18:12:08] -!- micges [micges!~micges@acsn203.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[18:22:18] -!- sumpfralle has quit [Ping timeout: 264 seconds]
[18:24:17] -!- zzolo has quit [Quit: zzolo]
[18:31:34] -!- PCW has quit [Ping timeout: 252 seconds]
[18:31:41] PCW_ is now known as PCW
[18:35:56] -!- skorasaurus has quit [Quit: WeeChat 0.3.7]
[18:51:47] -!- FinboySlick has quit [Quit: Leaving.]
[18:53:42] -!- sumpfralle has quit [Read error: Connection reset by peer]
[18:56:34] -!- sumpfralle1 has quit [Ping timeout: 246 seconds]
[19:12:46] -!- tmcw has quit [Remote host closed the connection]
[19:13:35] -!- FinboySlick has quit [Remote host closed the connection]
[19:23:16] <andypugh> How wedded are we to TOOL_CHANGE_QUILL_UP and TOOL_CHANGE_AT_G30?
[19:25:04] <andypugh> I find myself wondering if tool change position should be a tool database property. And, for that matter, if spindle positioning should be a toolchanger-defined action.
[19:26:11] <cradek> I'd hope any more flexible system would replace those settings (and still be able to do the same things)
[19:26:18] <cradek> but I'm not sure if that's what you are asking
[19:28:02] <skunkworks> the tool table application would look at those ini file configs and set the correct fields for each tool. :)
[19:29:07] <skunkworks> oh - that would not work. G30 is during program run settable. Hmm what would be
[19:29:10] <andypugh> I don't think you caan determine G30 from the INI.
[19:29:59] <skunkworks> would you be able to set the location as vars?
[19:30:15] <andypugh> I guess that TOOLCHANGE_AT_G30 lets you alter the tool change position in the G-code.
[19:30:26] <andypugh> I am not sure I see that as an advantage.
[19:30:37] <cradek> heh
[19:32:04] <cradek> it's nice that once you get your tools and workpiece loaded, you can move the machine to where it looks safe (like the turret can spin without smashing those long drills into the work) but not much farther, and then do g30.1 and it the tool change location is quickly and easily set to there
[19:32:16] <andypugh> I guess I will just leave the code there, it doesn't actually do any harm.
[19:35:09] <andypugh> This piece of wool I am pulling shows no signs of stopping unravelling...
[19:35:34] <cradek> I bet
[19:39:10] <andypugh> I think iocontrol is doomed.
[19:41:39] <cradek> yay
[19:42:35] <cradek> especially on a lathe job, tool change motion can take a big chunk of the time - it's nice to be able to easily change it
[19:42:59] <cradek> you can leave the spindle going too, so you don't have to wait for it to stop and start
[19:45:43] <andypugh> Short term I am thinking in terms of loadable HAL modules that watch the NML messages and act on tool requests. Then manual / random / turret is a matter of which toolchanger module you load.
[19:46:29] <andypugh> (iocontrol is likley to pre-decease NML)
[19:47:23] <skunkworks> is there an easy way to output a pulse evertime the base thread runs? Like I was outputting a step pulse every base period?
[19:47:42] <andypugh> skunkworks: charge pump?
[19:47:51] <cradek> that'd be every other
[19:48:07] <andypugh> (though I think that might toggle it every _other_ base thread.
[19:48:18] <skunkworks> right
[19:48:32] <andypugh> supply and reset?
[19:48:33] <skunkworks> could I setup a stepgen to do it?
[19:49:04] <cradek> I think you'd just put parport.write and parport.reset in your thread and set some pin high
[19:49:19] <cradek> only the parport doublestep hackery will be capable of doing this
[19:49:25] <skunkworks> right
[19:49:38] <skunkworks> *with the stepgen in doublestep
[19:49:50] <jepler> no you would just feed it '1' (from supply or setp)
[19:49:52] <cradek> you don't need or want stepgen as far as I can see
[19:49:59] <cradek> right
[19:50:07] <jepler> (or an existing enable signal if it should be enabled)
[19:50:20] <andypugh> cradek: You need to set it high every base thread, so possibly use a suitable setp-ed and2?
[19:50:38] <cradek> it'll stay high
[19:50:45] <jepler> right, nothing will drive the signal low
[19:50:50] <skunkworks> jepler, what - what?
[19:50:56] <jepler> nothing will drive the hal signal low
[19:51:12] <jepler> but when stepgen is in the reset mode, a consistent high signal will give one pulse every cycle
[19:51:28] <cradek> you mean parport
[19:51:31] <andypugh> Ah, OK, reset is purely at the hardware register level?
[19:51:36] <skunkworks> high signal to what? That is what I am wondering.
[19:51:38] <jepler> right, parport not stepgen
[19:51:42] <skunkworks> oh
[19:51:44] <skunkworks> duh
[19:51:45] <skunkworks> ok
[19:51:49] <cradek> setp parport.xx-out 1
[19:51:50] _BJFreeman is now known as BJfreeman
[19:51:59] <jepler> and setp parport.xx-reset 1
[19:52:09] <cradek> addf parport.write; addf parport.reset
[19:52:18] -!- md-2 has quit [Ping timeout: 264 seconds]
[19:52:19] <jepler> er, -out-reset
[19:52:31] <cradek> pseudohal
[19:52:49] <skunkworks> wait - so all ouput pins of the parallel port do that in reset mode?
[19:53:12] <andypugh> Yes, it's a parport thing, not a stepgen thing.
[19:53:18] <skunkworks> oh - it is pin by pin?
[19:53:24] <andypugh> yes
[19:53:48] <skunkworks> cool
[19:55:05] <skunkworks> These emco compact 5 'pc's seem to use the printer port as a normal step/dir interface other than they latch whenever they want the data read.
[19:56:23] <skunkworks> there is some hackery where they cut out the latch ic and jump through. (for mach) but I think I could just set the latch each time
[19:57:02] <jepler> playing with openscad and slic3r targeting linuxcnc gcode (no glue gun hardware to drive yet though).
http://emergent.unpythonic.net/files/sandbox/axis-slic3r.png
[19:57:43] <jepler> this file is ~95k lines and loads/animates fine. of course, I have nvidia proprietary opengl drivers installed..
[19:57:50] <skunkworks> wow - that is pretty
[19:57:55] -!- syyl_tb has quit [Client Quit]
[19:58:51] <skunkworks> *each base sycle.
[19:58:53] -!- chron0 has quit [Ping timeout: 245 seconds]
[19:58:54] <skunkworks> base
[19:58:56] <jepler> it is using the alpha blended gcode option, which lets you make some sense of very tight gcodes like that
[19:58:57] <skunkworks> heh
[19:59:01] <skunkworks> cycle
[19:59:01] <jepler> oh you mean your scope is pretty?
[19:59:21] <skunkworks> no - your screenshot.
[20:02:19] <andypugh> jepler: That looks like part of a Rostock. I suspect you have a bootstrap / catch-22 / chicken and egg problem.
[20:02:21] -!- skunkworks has quit [Read error: Connection reset by peer]
[20:02:38] -!- mattiasb has quit [Ping timeout: 245 seconds]
[20:03:27] -!- chillly has quit [Quit: Leaving]
[20:04:29] <jepler> andypugh: that's why you start by spending like a thousand bucks..
[20:04:33] <jepler> (quite right)
[20:10:56] -!- alpha1125 has quit [Quit: Computer has gone to sleep.]
[20:13:43] -!- mattiasb has quit [Ping timeout: 260 seconds]
[20:15:55] <jepler> the only delta-type extruder I've found where you just by all the pieces from one website is the "rostock max", but most of the reviews of it are not thrilled---at least in the original version, the extruder was not very good, particularly at retracts
[20:16:26] <jepler> the other thing is that the arms are apparently fragile, so many people replace the mounts with magnetic mounts
[20:17:07] <jepler> .. the parts shown are part of a magnetic mount that would use steel bals on the ends of rods and washer/ring-shaped magnets pressed into the cartridge and the platform
[20:17:28] <jepler> (which is not quite the same as any of the other magnetic redesigns I've found)
[20:17:56] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[20:18:08] <jepler> but .. still not sure I want to spend a thousand bucks on a 3d printer right now
[20:18:21] <jepler> delta-types are on my mind because I'd eventually convert it to linuxcnc so I can play with nontrivkins
[20:18:37] <seb_kuzminsky> jepler: that's very cool
[20:19:21] <seb_kuzminsky> are you runnign slic3r on linux? i heard it sucks :-/
[20:19:32] <jepler> I started with slic3r because that's what charles used
[20:19:44] <seb_kuzminsky> it's what everyone uses, apparently
[20:19:48] <jepler> I don't have any comparative experience yet
[20:20:04] <jepler> last time I played around I tried a different one and it had an even more bewildering array of configuration options
[20:20:16] <seb_kuzminsky> there's been work in freecad lately that may be applicable - section views through your solid
[20:20:27] <jepler> interesting
[20:20:40] <seb_kuzminsky> we'll see where it goes
[20:21:04] <seb_kuzminsky> a bunch of folks at the boulder hackspace are all fired up to convert our 3d printers to linuxcnc now :-)
[20:31:50] -!- EDocToor has quit [Quit: Leaving]
[20:35:03] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[20:37:54] -!- vladimirek has quit [*.net *.split]
[20:37:54] -!- micges has quit [*.net *.split]
[20:37:54] -!- JT-Shop has quit [*.net *.split]
[20:37:54] -!- jfire has quit [*.net *.split]
[20:38:58] <jepler> do you have enough experience with stl -> gcode software to suggest what I should look at after slic3r?
[20:39:14] Jymmmm is now known as Jymmm
[20:39:42] <jepler> slic3r is made of perl !?
[20:40:02] -!- bedah has quit [Quit: Ex-Chat]
[20:42:01] <seb_kuzminsky> only for subtractive machining. I've had success with pycam for stl -> gcode, but i dont think it does additive fabrication
[20:42:02] -!- vladimirek [vladimirek!~vladimire@95.105.250.72] has joined #linuxcnc-devel
[20:42:03] -!- micges [micges!~micges@acsn203.neoplus.adsl.tpnet.pl] has joined #linuxcnc-devel
[20:42:03] -!- JT-Shop [JT-Shop!~John@99.198.67.11] has joined #linuxcnc-devel
[20:42:38] -!- mattiasb has quit [Ping timeout: 245 seconds]
[20:42:48] <seb_kuzminsky> lol, the #sparkfun topic consists of this link:
http://i.qkme.me/3qt516.jpg
[20:52:54] -!- md-2 has quit [Ping timeout: 256 seconds]
[21:03:18] <skunkworks> yeck. Maybe it won't be that easy.
http://www.nxp.com/documents/data_sheet/74HC_HCT374_CNV.pdf
[21:03:48] -!- DJ9DJ has quit [Quit: bye]
[21:05:06] <skunkworks> there has to be a setup and hold time before the clock. Hmm - we are talking ns here. I wonder if it is an issue.
[21:05:48] <skunkworks> I could suppose set the printer port pins individually. instead of -all
[21:05:56] -!- mattiasb has quit [Ping timeout: 256 seconds]
[21:06:12] <skunkworks> maybe
[21:07:16] <skunkworks> or I could just bypass the chip.. but it would be cool to have a plug and play solution with linuxcnc.
[21:07:37] <skunkworks> this is the only reference I have
http://www.maxton.com/ebay/emco/EMCO%20Compact%205PC%20Conversion%20to%20Mach3.pdf
[21:07:48] <skunkworks> (that article is a bit scary_
[21:07:49] -!- syyl_tb has quit [Ping timeout: 246 seconds]
[21:08:23] -!- md-2 has quit [Remote host closed the connection]
[21:10:07] <skunkworks> at plug and play seems doable..
[21:10:30] -!- stsydow has quit [Remote host closed the connection]
[21:13:26] -!- tmcw has quit [Remote host closed the connection]
[21:17:56] -!- chillly has quit [Quit: Leaving]
[21:18:52] -!- skunkworks has quit [Ping timeout: 276 seconds]
[21:19:54] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:27:05] <andypugh> FWIW slicing an STL is 3 lines of codein Octave
[21:27:58] -!- skunkworks has quit [Ping timeout: 276 seconds]
[21:35:47] -!- fomox has quit [Ping timeout: 276 seconds]
[21:37:23] -!- sumpfralle2 has quit [Ping timeout: 256 seconds]
[21:39:45] -!- mattiasb has quit [Ping timeout: 248 seconds]
[21:40:59] -!- zzolo has quit [Quit: zzolo]
[21:41:22] -!- skunkworks [skunkworks!~chatzilla@str-broadband-ccmts-ws-26.dsl.airstreamcomm.net] has joined #linuxcnc-devel
[21:42:25] <skunkworks> heh I can't write each pin individually... the write function runs once per base period duh
[21:43:13] <andypugh> It doesn't have to..
[21:43:53] <andypugh> I ahve never tried this, but there is a fair chance you can addf it twice.
[21:44:14] <skunkworks> heh - the question is - can I set the clock and input at the same time.
[21:44:19] <andypugh> But that may be jumping too soon into implementation.
[21:44:28] <skunkworks> I resemble that remark
[21:45:29] <andypugh> I think you might need to look at the "reset" function and make something that does something similar when you want to.
[21:45:33] -!- servos4ever has quit [Quit: ChatZilla 0.9.85 [SeaMonkey 2.0.11/20101206162726]]
[21:45:53] <andypugh> A HAL component that toggles one parport pin is pretty trivial.
[21:46:48] <andypugh> component skunk "shortest comp evah!"
[21:46:50] <andypugh> ;;
[21:47:01] <jepler> error: no license specified
[21:47:06] <andypugh> outb(0,0x378)
[21:47:07] <jepler> error: must have at least one pin or parameter or something
[21:48:01] <andypugh> jepler: You removed the requirement to have a function, do the same for pins. But the license is a good call.
[21:48:44] <jepler> skunkworks: use a negative-going pulse to get your setup and hold
[21:48:53] <jepler> that involves also setting xx-out-invert
[21:49:24] <jepler> then you get your setup and hold requirements of the rising edge of the CP pin of 74374 because it happens a configurable time (e.g., min 2000ns) after the data is stable
[21:49:46] <skunkworks> damn
[21:49:57] <skunkworks> that is elegant...
[21:50:04] <jepler> I hope what I said is accurate too
[21:50:38] <skunkworks> heh
[21:51:43] <skunkworks> hmm - I need to think about this. time for a nap
[21:53:08] <skunkworks> I could still use the stepgen in reset mode - just set the reset mode for the stepgen to be longer than the clock pin I am using. (am I understanding it right?)
[21:53:26] <jepler> right, this is for using the reset mode
[21:54:50] <skunkworks> wow - that might work
[21:54:51] <skunkworks> :)
[21:55:09] <skunkworks> jepler: thank you
[21:55:18] <jepler> welcome
[21:55:40] <andypugh> jthornton:
http://youtu.be/FVB_rxerfEs
[21:56:36] -!- Brandonian has quit [Quit: Brandonian]
[21:57:10] -!- mattiasb has quit [Ping timeout: 246 seconds]
[22:03:27] -!- Nick001-Shop has quit [Quit: ChatZilla 0.9.90 [Firefox 21.0/20130511120803]]
[22:03:59] -!- jfire has quit [Quit: Leaving.]
[22:07:31] -!- `Nerobro has quit [Read error: Connection reset by peer]
[22:09:53] -!- morfic has quit [Ping timeout: 240 seconds]
[22:13:45] -!- jerryitt has quit [Quit: Leaving.]
[22:14:38] BJfreeman is now known as Guest16491
[22:14:46] _BJFreeman is now known as BJfreeman
[22:15:35] -!- Guest16491 has quit [Ping timeout: 252 seconds]
[22:24:44] <skunkworks> how does the reset work with 2 different .reset times? oh - I suppose .reset function just waits until the longest time elapses? reseting the different set of pins along the way?
[22:24:50] -!- f1oat [f1oat!~f1oat@AMontsouris-553-1-46-236.w92-151.abo.wanadoo.fr] has joined #linuxcnc-devel
[22:26:20] <andypugh> it might run twice, if there are two of them. What a complex concept.
[22:27:19] <andypugh> On entry the reset function first checks that the time hasn't already elapsed, and if it has, it exits imediately.
[22:27:30] -!- BJfreeman has quit [Quit: had a good time]
[22:28:06] <andypugh> Otherwise it waits. While it is waiting the entire computer stops, as I understand it. You probably want to avoid long reset times.
[22:32:03] -!- jmckenna has quit [Quit: bye bye!]
[22:32:59] -!- psha has quit [Quit: Lost terminal]
[22:33:39] <jepler> skunkworks: I thought there was a single .reset time for all pins
[22:34:33] -!- f1oat has quit [Quit: Leaving]
[22:35:16] <andypugh> I am too lazy to check the code, but it might be one reset time for each reset instance?
[22:36:15] <andypugh> (That could only work if the rest instances share a mask). So perhaps it is explicitly singleton. At the moment. :-)
[22:38:22] -!- mhaberler [mhaberler!~mhaberler@extern-186.stiwoll.mah.priv.at] has joined #linuxcnc-devel
[22:49:08] -!- jfire has quit [Quit: Leaving.]
[22:51:11] -!- Vq has quit [*.net *.split]
[22:52:30] -!- stsy has quit [Remote host closed the connection]
[22:54:57] <andypugh> seb_kuzminsky: For 2.6, how about setting it up to email me any time someone uses G10 L1, L10 or L11 in actual G-code outside MDI or a probe?
[22:56:24] <andypugh> Because that is a nasty corner-case in the distinction between readahead state and machine state.
[22:56:57] <mhaberler> I had been discussing this with cradek a loong time ago; cradek: around?
[22:58:10] <skunkworks> jepler: then my question is how does reset reset pins when they have different reset times?
[22:58:29] <mhaberler> actually the hairy usage condition can be narrowed down a bit: if a 'G10 xxx' is used and the interp is _not_ in a synced state
[22:58:47] <andypugh> It makes life easier if any G10 synchs the queue. I reckon nobody would even notice.
[22:58:56] <mhaberler> nb: post-probe it's in a synced state
[22:59:02] <mhaberler> that's an interesting idea
[22:59:37] <mhaberler> maybe this could in fact solve the issue
[22:59:57] <andypugh> I have used LinuxCNC for years and never explictly used a G10
[23:00:45] <andypugh> I guess that touch-off has effectively done the same thing, but that's not coordinated.
[23:01:03] <mhaberler> well t/o forces a sync post close/timeout
[23:01:20] <andypugh> You are most unlikely to use any G10 in the middle of a profiling move...
[23:01:27] <mhaberler> so post-probe the interp is synced when the next op begins
[23:03:18] <mhaberler> trying to think through if we have a simple condition which can trap that situation; unfortunately there's no 'synced' property
[23:04:03] <mhaberler> one can address the question from a different angle:
[23:04:28] <mhaberler> is the semantics of g-code program identical if readahead is disabled
[23:04:44] <andypugh> Yes.
[23:04:49] <mhaberler> (ignoring blending for now)
[23:05:02] <andypugh> But the performance might reduce.
[23:05:08] <mhaberler> right
[23:05:51] <mhaberler> if that were the case, then a user would be free to sprinkle queuebuster ops into the program and still get the same result (except blending and maybe ncd)
[23:06:07] <andypugh> So, who expects velocity to be constant through a tool or offset change? I would guess at "nobody"
[23:06:41] <zultron> mhaberler, still on US time, I see?
[23:06:44] <mhaberler> yes
[23:06:48] <mhaberler> badly so ;)
[23:07:01] <mhaberler> andy: did you see this one:
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=configs/sim/remap/stop-lookahead/README;h=436e134403b699c0ba18e392c721e1bd15d14d1c;hb=d2f30b299c61986fa5ba398a478b78a778872cf3 ?
[23:07:19] <mhaberler> this is essentially a bust-queue-on-demand code
[23:07:50] <mhaberler> (it works wonders when reading an arbitrary hal pin value ;)
[23:08:15] <andypugh> I rather suspect that as long as we support infinite lookahead through G1, G2, G3 and S and stop dead on any other G-code all the users would be happy.
[23:08:57] <mhaberler> do we have any other dead bodies of that sort other than G10?
[23:09:00] <andypugh> No, I hdn't seen that, I don't think
[23:10:39] <andypugh> Not that I have spotted so far, but have only even looked at the userpace stuff for a few months. Everything I have done up to now is nice clean, linear, easy, realtime kernel code.
[23:10:44] <mhaberler> if we can elevate G10 to mean G10, followed by such a G103, this would take out several moving parts
[23:11:20] <mhaberler> what is the line of thought from 'nice and clean' to 'kernel' ;-?
[23:11:51] <andypugh> I think it is easier than that, move G10 to join the other must-synch codes in the BigSwitch?
[23:12:03] <mhaberler> right
[23:12:08] <skunkworks> jepler: if it doesn't work with 2 different reset times - I could just use the reset for the clock(inverted) and run the stepgen in non-reset - normal mode. (this is only 2000ish steps per inch so slow)
[23:12:10] <mhaberler> not much to it
[23:12:16] <mhaberler> no, even easier
[23:12:32] <mhaberler> interp returns interp_execute_finish after a g10, not an interp_ok
[23:12:38] <mhaberler> task handles the rest
[23:12:52] <andypugh> kernel code is nice an clean. Limited, awkward, but you know where you are.
[23:13:42] <andypugh> Ah, yes. <crosses problem off list>
[23:14:33] <mhaberler> I think g92 needs consideration too
[23:14:56] <mhaberler> in particular g92.1,2,3
[23:15:22] -!- zzolo has quit [Quit: zzolo]
[23:15:37] <andypugh> Again, I doubt anyone would moan if it broke constant velocity. And redahead is all about constant velocity.
[23:16:37] <mhaberler> that I dont understand, what breaks cv?
[23:17:29] <andypugh> I find it hard to imagine that even a Babbage Engine couldn't keep up with a milling machine. Considering that the workpiece has metal where the Babbage Engine has air in the cams.
[23:18:39] <andypugh> My point is that if the tool point motion stutters due to lack of readehead through a G92, nobody would be surprised.
[23:19:02] <mhaberler> I guess yes
[23:19:16] <andypugh> Whereas they do complain if it stutters between G1 and G2.
[23:20:09] <andypugh> (and, they have, and in some cases with good cause, and some cases unfairly.
[23:21:37] <andypugh> G1 to G2 non-tangetially probably should stutter, and likewise if the R is small. I am not clear which of those conditions was true in Steve Blackmore's code, or neither.
[23:22:54] <mhaberler> does peter jensen hang out here? Dan Falck just pointed me to this:
http://nraynaud.github.io/webgcode/
[23:23:39] <mhaberler> andy - I think until proven wrong we could just as well assume G10 and g92.x can be made queuebusters without ill effect
[23:23:59] <mhaberler> we need to get Chris to think this one through, too
[23:24:53] -!- syyl has quit [Ping timeout: 248 seconds]
[23:25:15] -!- mattiasb has quit [Ping timeout: 256 seconds]
[23:25:28] <mhaberler> that would simplify farming out the toolinfo handling into a server big time
[23:26:42] <mhaberler> it would mean that the toolstore's view of offsets and other tool properties have no readahead aspect to it, aaah
[23:26:58] <andypugh> Interesting tool. Any idea _which_ motion controller that is?
[23:27:31] <andypugh> mhaberler: Yes, you spotted why I am attracted to the idea.
[23:27:38] <mhaberler> no, no time to read it yet
[23:28:10] <mhaberler> actually that's the issue which is the singlemost bugging on in the whole affair
[23:28:39] <mhaberler> maybe we should formulate this question to the devlist
[23:29:48] <mhaberler> and debugging too - you could rely on the toolstore reflecting what will be applied
[23:31:37] <mhaberler> (maybe we should just change the interp to sync at g10,g92.x and see if we get a bugtracker entry ;)
[23:31:47] <andypugh> Yes, if you specify that "there can be only one worldview" and that anything that breaks that (other than actual tool-point position) is a "queuebuster" then what is the penalty. I suspect that that in practice there is no penalty.
[23:31:50] -!- zzolo has quit [Quit: zzolo]
[23:31:56] <mhaberler> 'an empiricial study'
[23:32:21] <mhaberler> ah, thats an interesting angle
[23:32:36] <mhaberler> narrow down the concept of readahead state instead
[23:32:48] <mhaberler> we have tooltip, modal state, settings
[23:32:53] <mhaberler> anything else?
[23:33:24] -!- Laremere has quit [Ping timeout: 246 seconds]
[23:34:43] -!- mattiasb has quit [Ping timeout: 276 seconds]
[23:34:58] <andypugh> Not yet, I am thinking on my feet here.
[23:35:48] <mhaberler> that blob of state in _setup is frightening.. need to go through that line by line really
[23:36:33] Laremere_AFK is now known as Laremere
[23:38:48] <mhaberler> I think we might need a more formal definition what readahead state is
[23:39:32] <andypugh> It is frightening from a conventional software design POV. I have not yet convinced myself it is conceptually wrong for a machine controller.
[23:40:04] <mhaberler> attempt#1: all aspects of interpreter state which can affect machine state and may be out phase with the worldview by more than one command
[23:40:51] <andypugh> more than one NML message?
[23:41:15] <mhaberler> hm, canon command maybe
[23:42:37] -!- shurshur has quit [Ping timeout: 256 seconds]
[23:42:38] <mhaberler> attempt#2: all state in interp which may be changed without breaking position predicition
[23:43:21] <mhaberler> I think that is the more relevant view
[23:43:23] -!- apel has quit [Ping timeout: 240 seconds]
[23:43:51] <mhaberler> this suggests we look through all the state which gets set in a sync() operation - that is the ra state
[23:44:23] <mhaberler> by definition, any state that doesnt get changed in sync() cant break ra
[23:44:51] <mhaberler> otherwise it wouldnt be synced to start with..
[23:45:04] <mhaberler> so.. Interp::sync()...
[23:45:18] <andypugh> I think that is right, but need to check
[23:45:46] -!- mattiasb has quit [Ping timeout: 276 seconds]
[23:46:51] <mhaberler> Interp::init() just sets the starting condition
[23:47:28] <mhaberler> so: here
http://git.mah.priv.at/gitweb?p=emc2-dev.git;a=blob;f=src/emc/rs274ngc/rs274ngc_pre.cc;h=9137a96af1459e546af5ecd8babf1a777ae182ad;hb=d2f30b299c61986fa5ba398a478b78a778872cf3#l1883
[23:48:24] <andypugh> Hmm. Is that generic?
[23:48:50] <mhaberler> as opposed to what?
[23:49:45] <andypugh> (never sure in git.mah. Actually I am rarely sure in git.linuxcnc.org. How the heck do you work out which branch a commit exists in?)
[23:50:04] <mhaberler> I'm looking at master
[23:50:10] <mhaberler> not sure about the answer
[23:51:30] <mhaberler> interestingly offsets arent synced; this is because the interp really doesnt know lots about offsets
[23:52:21] <andypugh> To digress, the latter point mattered to me earlier today. A user on the forum wanted the pretty new foamcutter preview. I have no idea how to find out (from gitweb) which branches that exists on. For that matter I don't know how to do it on my own git clone either.
[23:52:31] <jepler> andypugh: if this is empty then commit d2f30b2 is on master branch: git rev-list origin/master..d2f30b299c61986fa5ba398a478b78a778872cf3
[23:52:58] <mhaberler> recording in cheatsheet...
[23:54:06] <andypugh> jepler: OK, so now, from a work PC, at lunchtime, on Windows, where buildbot is considered a malware server?
[23:54:19] <jepler> andypugh: using gitweb probably not possible
[23:54:33] <jepler> put git on your android smartphone instead
[23:54:49] <andypugh> That seems likely, and a _real_ oversight.
[23:55:26] <jepler> this will tell you *a* branch which contains the commit, but not necessarily a helpful one: $ git describe --all --contains d2f30b29
[23:55:30] <jepler> remotes/mah/master
[23:55:39] <andypugh> Surely knowing which branch a commit was pushed to is pretty dundamental?
[23:56:16] <jepler> I have to admit I'm somewhat surprised there's not a simpler incantation
[23:56:25] <andypugh> (I reserve the right to choose the definition of the new word "dundamental"
[23:56:29] <mhaberler> the tree of commits and the branch names seem to be disjoint concepts
[23:56:41] <mhaberler> branch name just points to a commit
[23:57:24] <mhaberler> so it doesnt tell anything about what else is in the forest except all the way back to the root
[23:58:09] <jepler> anyway, gitweb only exists to check the "has a web interface" item off somebody's imaginary list of requirements; it is typically the worst tool for serious investigation of the project's history.
[23:58:10] <mhaberler> returning to interp: I think we might have to look at canon a bit and how it handles offsets
[23:58:40] <andypugh> It's a real bother when trying to do support. "I know there is this new feature to solve your problem, I can find the commit, but I have _no_ idea which version you need to get it"
[23:59:37] <jepler> if you think it is in a released version, $ git describe --contains dcc5a94e64d03a754acc3cb2451e97ba58d85ee6
[23:59:41] <jepler> v2.5.1~2
[23:59:50] <jepler> this says "it's two commits before version 2.5.1, so it is in version 2.5.1."
