Back
[07:10:43] <Dave911_> Dave911_ is now known as Dave911
[08:20:10] <alex_joni> micges_work: good morning
[08:20:16] <alex_joni> what axis pins do you mean?
[08:50:56] <micges_work> hi
[08:51:49] <micges_work> teleop position and axes velocities
[08:54:57] <micges_work> don't know if that data should go to hal directly or into status and the in halui to hal
[09:43:47] <alex_joni> I think both
[09:43:52] <alex_joni> always better ;)
[09:43:54] <alex_joni> brb
[09:45:11] <micges_work> brb too
[13:52:31] <alex_joni> jthornton, jt-plasma:
http://lmgtfy.com/?q=DMA&l=1
[13:54:41] <alex_joni> hmm.. my google search brings up something else than lmgtfy
[13:54:43] <alex_joni> http://en.wikipedia.org/wiki/Direct_memory_access
[14:26:36] <SWPadnos> huh:
http://www.engineeringexchange.com/video/northstar-shaftless-encoders
[14:27:17] <jepler> alex_joni: here www.the-dma.org is the top google hit for 'DMA'.
[14:27:37] <jepler> dietary managers association and dallas museum of art also beat direct memory access
[14:28:22] <SWPadnos> heh - "Helping over 275000 marketers succeed through relevance ..."
[15:02:15] <cradek_> cradek_ is now known as cradek
[16:29:23] <Dave911> DMA - Yes that must be the US version of DMA - is anyone else disgusted with the number of Adverts and sales shows on Dish Network? With all of the add shows on Dishnetwork they should be paying me to watch it! :-(
[16:29:53] <jepler> all mail advertising goes direct to recycling on principle
[16:30:10] <jepler> exception made for catalogs from companies that I first got after ordering from them
[16:31:28] <Dave911> I do the same thing... I have a trash can right next to where I sort the mail...I don't even look at it. I'm on the national "do not call list" but we still get sales calls every day! It is getting worse!
[16:38:28] <Dave911> OT - but Has anyone else noticed that Artsoft can't seem to make any progress on fixing anything related to the Mach3 software? It is really getting to be sort of sad. There are a lot of people who have hung their hat on Mach3 (I made the same mistake for a while) and the product is really having a rough time. They attempt to fix a problem and then they break 5 other things that was...
[16:38:30] <Dave911> ...working properly as part of the "fix". This has been going on for a while now.
[16:39:58] <jepler> It's terribly easy to do that; you're bound to do it, and something will slip by no matter how comprehensive you've tried to make your pre-release testing.
[16:41:05] <jepler> That's why we try to be as conservative as possible with emc point releases
[16:41:24] <jepler> even so we've had a number of egg-on-face releases
[16:43:00] <Dave911> I can see that it would be very easy to do ... but from what i can see EMC2 is still on the "rails". Sure once in a while a wheel jumps off the track, but the entire train never heads for the ditch.. (I guess I am into metaphors today .. ;-) )
[16:43:42] <cradek> when software gets mature, often the "low hanging fruits" are all picked and the remaining problems look like simple bugs to users but maybe they are really fundamental limitations of the whole design.
[16:43:55] <jepler> like "i wanna jog while paused", for instance
[16:44:00] <cradek> right
[16:44:21] <cradek> or, in mach lathe, "it cuts lousy threads"
[16:45:11] <cradek> having never used mach, I don't know what kinds of bugs you're talking about - I might be all wet
[16:47:11] <cradek> [insert rant here about how closed source software just leaves you screwed if the maintainer gets tired of fixing the stuff that bothers you]
[16:48:33] <Dave911> >>really fundamental limitations of the whole design.
[16:48:36] <Dave911> Yes, I think you are correct.
[16:48:37] <Dave911> I followed the Mach3 lathe threading issue for a very long time.... they have a message thread on the forum that stretches out over a year and Art was intimately involved in the discussion.. The issue was never really resolved. Brian or Art made a comment a while ago after beating their heads on the lathe threading issue that perhaps users would be better off using a different solution...
[16:48:38] <Dave911> ...than Mach3 for lathe threading apps... I think they were basically admitting to limitations of the design...
[16:49:05] <jepler> not that emc's threading hasn't had its share of problems, as seen by cradek's two brutal rewrites
[16:49:13] <cradek> it sure may be the best they can do given the constraints of their design.
[16:49:36] <cradek> yes I think our design allows for better threading performance. it took me many tries to write it, but it may be correct now.
[16:49:46] <Dave911> That is what I surmised after waiting for a long long time...
[16:49:57] <cradek> (ours was very certainly wrong until recently)
[16:50:56] <cradek> I expect that mach probably has a problem with feed override > 100% stalling steppers (exceeding configured constraints), which is another thing that our design can get right
[16:51:23] <Dave911> If EMC2 still had a threading problem I am pretty sure you would be hearing about it... So far it is working fine for me even via the LPT port.. :-)
[16:51:25] <cradek> on the other hand, our design is at the mercy of getting hardware with decent realtime performance - mach isn't so much.
[16:51:45] <cradek> Dave911: yeah and what a relief :-)
[16:52:34] <Dave911> The day I got my lathe threading properly with EMC2 was literally a holiday for me! :-)
[16:52:44] <jepler> the threading always worked pretty well with a high-accel machine and a mid-PPR to high-PPR encoder
[16:52:58] <jepler> low accel and low PPR now work much better, I understand
[16:54:19] <skunkworks_> Dave911: you just have to wait for mach4
[16:54:19] <Dave911> My machine is a pretty high accel lathe (big servos) with a low PPR count encoder and a very stable spindle drive.
[16:55:13] <Dave911> Skunkworks: I did that for a while... after two years .... ya gotta do something else ...
[16:55:56] <skunkworks_> ;)
[16:56:29] <Dave911> Have you seen the issues that have popped up recently trying to fix version 3 issues? It is getting sad to watch..
[16:56:54] <jepler> nah, I don't follow mach3 at all
[16:57:03] <cradek> yeah I only know what I hear here
[16:57:03] <skunkworks_> * skunkworks_ doesn't like to admit it...
[16:59:13] <Dave911> I should probably stop.. watching myself.... it is getting depressing. I know a lot of guys who have a lot of time and money invested in Mach related solutions and the core product seems to be broken/breaking and unrepairable..
[16:59:44] <cradek> ouch.
[17:01:13] <Dave911> So is the "I wanna jog while paused" an inherent limitation of EMC2?
[17:01:46] <cradek> no, but it's sure not low-hanging
[17:02:19] <Dave911> Ok.....
[17:02:41] <jepler> there are a lot of things that are perfectly possible, but they need a programmer to invest significant time into it
[17:03:15] <cradek> it's a bad combination of being in a hard part of the code to fix, and also being conceptually hard to decide how it should even work
[17:03:57] <cradek> also, there's an acceptable workaround that lets you accomplish the work you need (abort, do stuff, restart at a selected line)
[17:04:24] <cradek> so, it's hard for a developer to justify the effort
[17:04:42] <Dave911> The abort, do stuff solution seems to be undesireable - why is that?? Is something lost?
[17:05:50] <cradek> it's a sticking point for one vocal user, and I don't really understand why either...
[17:08:46] <skunkworks_> I think he is really upset that he has to use emc over mach.
[17:09:05] <skunkworks_> that is what I get anyways.
[17:11:24] <Dave911> Oh.... I know who you are talking about... Yes I think you are probably correct Skunkworks. He is one of many folks who have invested a ton of time trying to get Mach3 to work for them only to have it come up short in the end...
[17:11:59] <Dave911> He was involved in Mach way before I got into it.
[17:12:37] <cradek> well I hate to guess at anyone's motivations, but it does seem like he hates certain things disproportionate to their real impact on day-to-day use of the software.
[17:12:55] <cradek> but it takes all kinds :-)
[17:13:38] <Dave911> I agree
[17:15:24] <Dave911> In fact I saw that on the Mach3 list also.. a good guy non the less.. He spent an inordinate amount of time getting Mach3 on it's feet and in the end I think he feels like he got burned. Long story..
[17:18:03] <jepler> when emc finally burns me out I'm certain I'll be too bitter to ever work on a different piece of CNC software..
[17:19:24] <Dave911> He is not alone though.... (not me.. ) I had a comparable minor investment in time and $ compared to many others. Some of the other folks I really feel sorry for.. and the list is growing :-(
[17:19:35] <dgarr> a patch for toolparameters for consideration:
http://www.panix.com/~dgarrett//stuff/0001-allow-ro_toolparameters-on-right-hand-side-of-gcode.patch
[17:20:07] <Dave911> Oh well.. enough of that... somethings you can change/affect and somethings you cannot..
[17:23:27] <jepler> cradek: are you the one with the expertise to review dgarr's patch? I don't know the details of pocket numbers these days...
[17:25:05] <jepler> dgarr: if you want to simplify the way to refer to the information about the tool in pocket, you can write: CANON_TOOL_TABLE &tool = &_setup.tool_table[pocket]; and then write tool.x instead of _setup.tool_table[pocket].x
[17:25:28] <dgarr> cradek looked at it orignally, this one mainly fixes an oversight on my part that prevented readonly toolparameters from being used on right hand side of equations
[17:27:03] <jepler> so the "-" line in the first hunk is fixing current breakage?
[17:27:10] <jepler> (if you can't use them on the right hand side, where can you use them?)
[17:27:24] <cradek> I don't understand the patch
[17:27:47] <cradek> is it a bugfix plus an unrelated simplification?
[17:28:05] <dgarr> jepler: yes
[17:28:09] <dgarr> cradek: yes
[17:29:07] <dgarr> with the patch you can use them on the rh side(that was broken)
[17:29:27] <cradek> <swpadnos> Remember, 115200 baud is 1152 bytes.
[17:29:42] <jepler> cradek: eh?
[17:29:53] <cradek> from the list
[17:30:02] <jepler> oh
[17:30:16] <cradek> oh, he corrected it.
[17:30:22] <cradek> sorry for the derail.
[17:31:34] <cradek> dgarr: so the second half is removing unnecessary code, since the current tool is always in pocket 0?
[17:32:13] <dgarr> cradek: correct
[17:33:23] <jepler> #1=#5400 ; erroneous error: Parameter is readonly
[17:33:41] <jepler> but (DEBUG,#5400) worked .. curious, they don't go through the same routine? is the common routine a level deeper?
[17:34:33] <dgarr> dunno
[17:34:54] <cradek> yeah no idea
[17:36:28] <jepler> well, I see in the context that this routine directly indexes parameters right after the modified line
[17:37:40] <jepler> so anyway that first bit should pretty clearly go in, and in its own commit separate from the cleanup
[17:37:54] <cradek> yeah, working on that
[17:40:53] <cradek> dgarr: thanks
[17:41:10] <CIA-5> EMC: 03cradek 07master * r7f5894a5dded 10/src/emc/rs274ngc/interp_read.cc: allow ro_toolparameters on right-hand side of gcode equations
[17:41:20] <CIA-5> EMC: 03cradek 07master * ree1a30d280cb 10/src/emc/rs274ngc/rs274ngc_pre.cc: simplify by removing unnecesary code
[17:41:46] <dgarr> welcome, thanks for looking at it, i should learn to separate patches to emc's style i think
[17:42:21] <cradek> yeah just make unrelated changes separate commits - git format-patch will spit out several files. that's easier for us to review then.
[17:42:48] <dgarr> my git-foo is pretty limited
[17:43:14] <cradek> eh, you're doing fine
[17:43:21] <cradek> I've seen some bad patches in my time :-)
[17:43:31] <jepler> yeah you are doing better thatn some paid programmers I know
[17:43:46] <jepler> ("thatn"?)
[17:58:54] <dgarr> jepler: your mentioned the construct: CANON_TOOL_TABLE &tool = &_setup.tool_table[pocket]; -- is that a c++ism?
[18:01:23] <jepler> hm, I typed the wrong thing
[18:01:33] <jepler> but yes, the & in CANON_TOOL_TABLE &tool = ... is a C++ ism
[18:01:53] <jepler> the & after the = is wrong and will make it not compile
[18:02:27] <jepler> In the type declaration & means "tool is a reference to a CANON_TOOL_TABLE"
[18:02:46] <dgarr> ok -- thanks, new to me
[18:02:52] <jepler> it's like a "pointer lite" with no arithmetic and no need to use * or ->; simplistic guides to C++ will tell you they're safer than pointers because they "can't be NULL"
[18:17:03] <micges> git have some problems..
[18:17:43] <micges> I mean gitweb is working but git pull doesn't
[18:19:20] <seb_kuzminsky> the buildbot had the same problem
[18:19:52] <micges> hi seb
[18:19:58] <seb_kuzminsky> hey micges
[18:20:22] <seb_kuzminsky> did you get a chance to try that nan-finding patch i sent you?
[18:21:26] <micges> no sorry :|
[18:21:41] <CIA-5> EMC: 03micges 07joints_axes3 * ra4eb0b895110 10/src/emc/task/taskintf.cc: Convert NAN catching code to global macro
[18:21:42] <CIA-5> EMC: 03micges 07joints_axes3 * r99a975ccd9a4 10/src/emc/ (11 files in 2 dirs): Cleanup of motion code to prepare for deeper modifications
[18:21:43] <CIA-5> EMC: 03micges 07joints_axes3 * r797d1d3bfc86 10/src/emc/motion/ (command.c control.c motion_debug.h usrmotintf.cc): Remove old teleoperating code from motion
[18:21:44] <CIA-5> EMC: 03micges 07joints_axes3 * r955aa5400407 10/src/emc/ (8 files in 3 dirs): Move some global varables to emcmotConfig structure
[18:21:46] <CIA-5> EMC: 03micges 07joints_axes3 * r051afa0b2a52 10/src/emc/motion/command.c: Fix few comments in motion command handler
[18:21:49] <CIA-5> EMC: 03micges 07joints_axes3 * ra440d1679cf5 10/src/emc/ (8 files in 3 dirs): Add new teleop jogging code
[18:21:52] <CIA-5> EMC: 03micges 07joints_axes3 * rfb763a3b2511 10/src/emc/ (17 files in 2 dirs): Remove leavings of changelogs in motion source
[18:21:57] <CIA-5> EMC: 03micges 07joints_axes3 * r4de3d0514cca 10/configs/sim/ (gantry_mm.hal gantry_mm.ini gantry_mm.tbl): Add sim gantry config for testing
[18:23:41] <seb_kuzminsky> looks like you've been busy! :-)
[18:23:47] <skunkworks_> micges: wow - nice!
[18:24:32] <micges> sorry for cleanup in between but as that branch is working on my machine I can test if they're ok without messing so deep on master
[18:26:28] <micges> skunkworks_: clean gantry design is now a little closer ;)
[18:30:47] <skunkworks_> :)
[19:07:49] <cradek> yay!
[19:08:34] <cradek> huh, wonder why the occasional 'failed git'
[19:08:58] <cradek> also, BUILD FAILED: failed failed slave lost
[19:09:08] <cradek> hm, do you think it failed?
[19:10:13] <micges> cradek: here on ja3: Runtest: 34 tests run, 34 successful, 0 failed + 0 expected
[19:10:39] <cradek> slick
[19:10:57] <cradek> I think buildbot is just touchy lately
[19:13:50] <skunkworks_> heh looking at the irc logs..
[19:13:53] <skunkworks_> <skunkworks_> skunkworks_ has quit
[19:14:00] <skunkworks_> <cradek> yay!
[19:14:05] <skunkworks_> ;)
[19:14:39] <micges> hehe
[19:17:08] <jepler> cradek: I think the "slave lost" is my home system which is unreachable 50% of the time
[19:18:35] <skunkworks_> jepler: dsl issues?
[19:19:02] <jepler> skunkworks_: yes, for the past week or so
[19:19:29] <jepler> most recently I've been told I'm too far away from the whatsis for the 3.0Mb/s service I've had for the past 8 months
[19:19:41] <jepler> and that they can switch me to 1.5Mb/s in a few days time
[19:19:55] <jepler> until then I'm just f**ked and they don't care about that very much
[19:21:55] <seb_kuzminsky> jepler: is your hardy-amd64 machine virtual or real? if it's virtual send me a copy and i'll run it here right next to the buildmaster
[19:22:13] <jepler> seb_kuzminsky: it's real
[19:22:37] <seb_kuzminsky> well maybe i should make a virtual one here then
[19:23:44] <seb_kuzminsky> that should fix the "failed, failed, failed" emails too, since the slaves here at CU can all reach the git server reliably
[19:23:54] <jepler> feel free to disable that slave
[19:24:09] <seb_kuzminsky> i really like having a 64-bit slave
[19:24:58] <jepler> sure, but one that is unreliable is bad
[19:26:29] <seb_kuzminsky> the current emc2 live cd is 32-bit only, right?
[19:26:34] <alex_joni> right
[19:26:44] <alex_joni> but there are packages for 64bit too
[19:26:56] <alex_joni> just need to follow the stock install, then use the install.sh for emc2
[19:26:57] <seb_kuzminsky> right, and the hardy-install script works on 64-bit i think
[19:27:01] <seb_kuzminsky> cool
[19:27:06] <seb_kuzminsky> * seb_kuzminsky installs hardy in a kvm
[19:28:45] <jepler> yay, thank you
[19:29:18] <jepler> * jepler manages to log into his home machine long enough to shut down the unreliable buildbot
[19:36:38] <seb_kuzminsky> thanks for running it for a while :-)
[19:45:16] <alex_joni> micges: cool stuff
[19:45:22] <alex_joni> I'm reading the diff's now
[19:45:53] <alex_joni> -/* userdefined number of joints. default is EMCMOT_MAX_JOINTS(=8),
[19:45:53] <alex_joni> +/* userdefined number of joints. default is EMCMOT_MAX_JOINTS(=9),
[19:45:58] <alex_joni> especially that
[19:46:26] <micges> ?
[19:48:55] <alex_joni> I've been meaning to change that for a long time, but never got around to do it
[19:49:14] <alex_joni> it seems daft that g-code can have 9 axes, but motion only exports 8 joints
[19:54:56] <micges> alex_joni: motion exports 9 joints on master now, ^^ it was only comment
[19:55:30] <alex_joni> don't mind me :P
[19:57:40] <micges> ok :)
[20:01:16] <dgarr> for comment:
http://www.panix.com/~dgarrett//stuff/0001-allow-user-defined-mcodes-with-cutter-radius-compens.patch
[20:03:07] <jepler> sounds like a sane idea to me
[20:04:05] <alex_joni> dgarr: if it still works, it gets my vote ;)
[20:04:14] <alex_joni> especially if all runtests aren't affected
[20:04:34] <dgarr> tested on simulator with my app
[20:05:21] <cradek> yep that looks like pretty much it
[20:06:44] <cradek> I think this is a safe change
[20:06:55] <cradek> (I bet we don't have user M commands in any of the tests)
[20:07:17] <cradek> the other thing that's great about this change is HE TOUCHED IT LAST!!
[20:14:16] <cradek> dgarr: a few tiny things: the comment for immediate issuing (not queueing) should say "immediate ..." like the others. also, your comma placement doesn't match the rest of the file - put them at the end of lines, not the beginning
[20:29:25] <dgar1> amended patch:
http://www.panix.com/~dgarrett//stuff/0001-allow-user-defined-mcodes-with-cutter-radius-compens.patch
[20:31:33] <cradek> cool
[20:33:01] <CIA-5> EMC: 03cradek 07master * re9186c27f2de 10/src/emc/rs274ngc/ (interp_convert.cc interp_queue.cc interp_queue.hh): allow user-defined mcodes with cutter radius compensation on
[20:35:34] <cradek> thanks again
[20:36:15] <dgar1> thanks for looking at it!
[20:41:48] <jepler> hi PCW
[20:42:17] <PCW> Hi Jepler
[20:43:42] <seb_kuzminsky> dgar1: i'm going to bounce the buildmaster, i'll restart your build when it comes back
[20:45:11] <PCW> Did you guys give up on the high speed probing?
[20:45:12] <PCW> I was thinking both for hardware and software encoder counting
[20:45:14] <PCW> the 2 mS delay of the probe response could be fixed fairly easily
[20:46:32] <jepler> yeah, I haven't touched it in ages
[20:46:35] <cradek> yeah, I think we gave up
[20:46:45] <cradek> I think your part worked :-)
[20:46:51] <jepler> the initial changes I made in emc were simply unstable, and I didn't find the motivation to fix it
[20:47:27] <jepler> but yeah, for a known delay and under an assumption of constant speed, you could clearly do something fairly clever..
[20:49:37] <PCW> I was thinking of more brute force, for software, just having the base thread keep a 2 mS long FIFO of counts
[20:49:38] <PCW> and the hardware probe do the same with a hardware FIFO (so the latched count is always 2 mS old)
[21:06:04] <jepler> surely there's way too little RAM on the FPGAs to keep a 2ms position history for very long
[21:06:20] <jepler> on the other hand, I don't know that you use whatever block RAMs there are for another purpose yet
[21:08:10] <jepler> micges: I think you need to test this commit without ISNAN_TRAP defined: joints_axes3: Convert NAN catching code to global macro
[21:08:49] <jepler> probably the alternative needs to be #define CATCH_NAN(x) do {} while(0)
[21:09:43] <micges> jepler: thanks, missed that
[21:10:32] <alex_joni> and another one:
http://www.dailymotion.com/video/xbs1ja_premier-essai-portique-cnc-commande_tech
[21:12:20] <jt-plasma> alex_joni: LOL
[21:13:19] <PCW> In spartan 2 (5I20) I figure 10 usec resolution to 2.5 ms (256x16 block RAM) in spartan 3 I would have 2.5 usec resolution
[21:13:55] <PCW> (Even in 5I20 only 1 of 14 256x16 blockrams is used)
[21:14:11] <PCW> (oops 2/14)
[21:14:21] <jepler> sounds cool, but probably you shouldn't spend your time on it until after emc probing works with an external trigger
[21:18:42] <PCW> I wont worry about it until its supported
[21:18:44] <PCW> SPI, BISS, and resolver input are probably more valuable
[21:19:37] <jepler> yes
[21:19:39] <jepler> BISS?
[21:20:03] <cradek> I would have used SPI recently (switches on a front panel)
[21:20:16] <PCW> Its a fancier version of SSI for absolute encoders
[21:20:26] <cradek> I used a second m5i20 and opto22 board instead
[21:20:28] <jepler> ah
[21:20:45] <PCW> (Resolute (TM) encoders use BISS)
[21:25:19] <PCW> I'm trying to convince Sebastian (are you here?) that the SPI support should be done with some driver primitives
[21:25:21] <PCW> and leave the SPI device specific code to a COMP. That way adding a new device would be easier
[21:25:22] <PCW> Is this reasonable?
[21:27:04] <jepler> so for each SPI instance there would be a pin for input, a pin for output, a pin for "do transfer", and some parameters to set sizes, phases, speeds, and so forth?
[21:27:31] <jepler> you could do one transfer every period (if "do transfer" is always asserted)
[21:28:17] <jepler> are there situations where it would be desirable to do multiple transfers in one period? e.g., sequentially read several ADCs on a single bus, or where an address out followed by a data in/out are needed?
[21:28:18] <PCW> Yes something like that. The a comp could do the device specific data formatting, merging,etc
[21:29:03] <seb_kuzminsky> hey i'm here
[21:29:34] <PCW> Yes some devices like multi-channel ADCs and DACS need multiple transfers, some of this is handled by the buffered SPI interface
[21:30:01] <jepler> hal doesn't really handle buffers well
[21:30:41] <seb_kuzminsky> i had imagined the interface between an SPI port (provided by the hostmot2 driver) and the SPI device-specific device-driver (provided by a comp) would exist outside hal
[21:31:32] <seb_kuzminsky> i think we have a rough but working implementation of the spi-in-hal thing already
[21:32:06] <seb_kuzminsky> using the raw interface
[21:33:18] <PCW> I hacked one for motioncontrol but the one read/one write limit of the raw interface made supporting the six chanels slow (muxed, one per thread)
[21:33:20] <jepler> seb_kuzminsky: so you're imagining that hostmot2 would export some more C API functions so that a component could claim an SPI interface and do whatever is needed
[21:33:53] <jepler> loadrt hostmot2 / loadrt hm2_pci ...num_spi=1 / loadrt hm2_specificssidevice count=1
[21:34:26] <jepler> where the last one claims the next spi interface, creates pins and parameters as needed, and is magically called by the hm2_pci read/write functions
[21:34:52] <jepler> through a C API with function pointers
[21:35:22] <PCW> bbl emergency: out of TP here!
[21:35:53] <jepler> I'm guessing he doesn't mean trajectory planner
[21:40:01] <seb_kuzminsky> jepler: exactly
[21:41:11] <jepler> personally I think that'll be much better if there's any indication of a need for multiple transfers per period
[21:44:44] <seb_kuzminsky> it has the benefit that it'll be easier for users to set up - just load the driver, there's not a bunch of hal nets to configure
[21:45:20] <seb_kuzminsky> though it means we'll need some other way to assign specific-spi-drivers to particular spi ports (or just accept the "take the next free one" method)
[21:48:04] <jepler> it works OK for other things so far
[21:48:12] <jepler> encoders and so forth
[22:03:47] <seb_kuzminsky> jepler: you were not running the r-i-p test on your hardy-amd64 buildslave
[22:03:58] <seb_kuzminsky> i just tried it on mine and it locked up in the overrun test...
[22:04:25] <jepler> seb_kuzminsky: interesting
[22:04:28] <CIA-5> EMC: 03alex_joni 07v2_3_branch * ra6646644b89c 10/tcl/mini.tcl: fix incremental steps for mini based on mm/inch
[22:04:29] <CIA-5> EMC: 03alex_joni 07v2_3_branch * r743f42b97763 10/debian/changelog: note mini fix
[22:04:35] <jepler> seb_kuzminsky: that system doesn't run the RT kernel so it can't run the tests
[22:04:49] <seb_kuzminsky> i'm gonna reboot and try again
[22:04:59] <jepler> and the sim tests weren't being run either, because that would fail if I happened to be running emc on it at the same time
[22:06:23] <seb_kuzminsky> oh handy, alex_joni just committed so the buildbot is testing it all by itself :-)
[22:06:27] <CIA-5> EMC: 03alex_joni 07master * ra5133a5231f7 10/tcl/mini.tcl: fix incremental steps for mini based on mm/inch
[22:06:28] <alex_joni> jepler: hope you don't mind me pushing that to 2.3
[22:06:43] <jepler> alex_joni: only if it's wrong
[22:06:49] <seb_kuzminsky> been a while since 2.3 got built :-)
[22:07:16] <alex_joni> jepler: can't be more wrong that it was before :P
[22:09:13] <cradek> failed failed failed!
[22:10:42] <seb_kuzminsky> do two fails make a pass?
[22:10:54] <cradek> if so, it still fails
[22:11:13] <jepler> too bad
[22:20:25] <CIA-5> EMC: 03alex_joni 07v2_3_branch * r0a578cf8280b 10/configs/ (plasma-thc-sim/.gitignore plasma-thc/.gitignore): silence
[22:24:48] <seb_kuzminsky> hmm:
[22:24:49] <seb_kuzminsky> /home/farmer/buildbot/slave/emc2/hardy-amd64-2.3-realtime-rip/build/scripts/realtime: line 178: 31181 Segmentation fault $RMMOD $module
[22:25:17] <seb_kuzminsky> i'm going to disable the 64-bit realtime tests until i can debug this
[22:26:00] <seb_kuzminsky> brb
[22:35:26] <seb_kuzminsky> ok we'll see how that goes
[22:35:32] <seb_kuzminsky> later folks
[22:59:39] <CIA-5> EMC: 03micges 07joints_axes3 * rbeb46c6a9fe6 10/src/emc/task/taskintf.cc: Make CATCH_NAN macro more correct
[23:20:06] <alex_joni> hrmm.. seems the pumakins doesn't work anymore in ja3
[23:20:12] <alex_joni> err.. scarakins I mean
[23:22:04] <micges> aww
[23:22:43] <alex_joni> something happens when switching from joint to world
[23:22:54] <skunkworks_> it go boom?
[23:22:56] <alex_joni> (it does work if I go to MDI.. so the kins is ok)
[23:23:09] <alex_joni> skunkworks_: badabing badabang badaboom
[23:23:54] <micges> what happens?
[23:26:09] <alex_joni> micges: joint0 & 2 go out of range
[23:27:20] <alex_joni> only joint 2
[23:27:28] <alex_joni> but I see that X goes to -40
[23:27:40] <alex_joni> and the position of the arm changes
[23:28:25] <micges> some teleop<->free mode glitches
[23:28:35] <alex_joni> yup, sure seems like it
[23:28:49] <alex_joni> switching to MDI makes it go around the problem
[23:28:50] <micges> alex_joni: how did you run scara config?
[23:28:59] <alex_joni> just like that ;)
[23:29:21] <alex_joni> there's a small change to make it work
[23:29:36] <micges> on gui?
[23:29:43] <alex_joni> no.. hal file
[23:29:53] <alex_joni> BASE_PERIOD is gone, and SHMEM_KEY is gone
[23:29:56] <micges> I fixed hal
[23:30:06] <alex_joni> and I selected axis
[23:30:35] <alex_joni> [rejected] joints_axes3 -> joints_axes3 (non-fast forward)
[23:30:41] <alex_joni> meh
[23:32:18] <CIA-5> EMC: 03alex_joni 07joints_axes3 * rd1b3cba25d89 10/configs/scara/ (scara.ini scara_sim_4.hal): make scara config at least start up
[23:32:18] <CIA-5> EMC: 03alex_joni 07joints_axes3 * rb3d10cc2fafe 10/src/emc/task/taskintf.cc: Merge branch 'joints_axes3' of ssh://
[email protected]/git/emc2 into joints_axes3
[23:36:13] <alex_joni> emcAxisSetMinPositionLimit(6, -999999999999999967336168804116691273849533185806555472917961779471295845921727862608739868455469056.0000) returned 0
[23:36:26] <alex_joni> ^^ doesn't look too good ;)
[23:36:42] <micges> yep
[23:37:55] <micges> for now you can define [AXIS_X] MIN_LIMIT and such
[23:38:17] <alex_joni> there's one odd thing
[23:38:26] <alex_joni> Issuing EMC_JOG_CONT -- (+124,+24, +40, +1,6000.000000,)
[23:38:33] <alex_joni> but the vel it goes at is 60
[23:39:49] <alex_joni> it doesn't matter what I do, it's always 60
[23:39:55] <micges> teleop is limited by inifile [AXIS_X]MAX_VELOCITY (default = 1)
[23:40:00] <alex_joni> aha
[23:40:41] <micges> I'm trying to get tkemc working but got some errors
[23:40:52] <micges> (don't know tcl)
[23:41:09] <alex_joni> lots of things need to change in tkemc I think
[23:41:22] <alex_joni> does [AXIS_*] MAX_ACCEL work too?
[23:41:26] <micges> and others gui also
[23:41:31] <micges> also
[23:41:45] <micges> MAX_ACCELERATION
[23:43:12] <alex_joni> yeah, that one
[23:43:27] <alex_joni> ok, lots of loose ends here.. but it's jogging ;)
[23:43:50] <alex_joni> I see in world I get: X, Y, Z, A, C, U for scara
[23:44:06] <alex_joni> it should only be X, Y, Z, A
[23:44:14] <alex_joni> err.. C I think
[23:44:44] <alex_joni> hahaha.. this is fun
[23:44:55] <alex_joni> micges: it seems it remembers the joint position in joint mode
[23:45:00] <alex_joni> and the joint position in world mode
[23:45:23] <alex_joni> so when I switch from joint to world it jumps to the position it was last in world mode
[23:45:25] <micges> alex_joni: you must enter 4 axes in traj
[23:45:40] <alex_joni> when I switch back it jumps back to the position it was in joint mode
[23:46:41] <alex_joni> joint_position180.0000 -180.0000 490.0000 -0.0000
[23:46:58] <alex_joni> wonder where that comes from
[23:47:05] <alex_joni> maybe XYZA= 0,0,0,0
[23:47:59] <micges> scara need some work ;_
[23:48:01] <micges> ;)
[23:49:06] <alex_joni> yup, but not at 2am ;)
[23:49:09] <alex_joni> * alex_joni is off to bed
[23:49:21] <alex_joni> micges: I'm glad it started moving ...
[23:53:32] <micges> alex_joni: teleop mode or whole branch ;)?
[23:53:41] <micges> good night
[23:54:38] <alex_joni> micges: both ;)