Back
[00:49:13] <PCW> Basic question about emc threads: is the servo thread just a sub multiple of the base thread?
[00:49:15] <PCW> If so, is the count available for finer scheduling of servo thread synced operations?
[00:56:02] <SWPadnos> all slower thread periods are integer multiples of the fastest thread
[00:56:30] <SWPadnos> I don't know that the multiple is directly accessible, but the thread period is
[00:58:57] <jepler> we know that even if the nominal periods of two threads are K and 10*K that they do not actually run in that strict alternation. tests/threads.0 used to test for this but in 2008 Seb made the test check a weaker condition instead.
[01:00:08] <jepler> one reason for the non strict alternation would be if the servo thread runs for so long that the base thread interrupts it -- the base thread has a higher priority than the servo thread
[01:02:42] <jepler> on real machines the test was fairly reliable, it was in vmware or some other virtualization program that seb saw the test fail
[01:21:12] <PCW> For SPI /DMA/ RTNET or Ethercat basically any interface with some latency it would be nice to pull the trigger on read-request at a particular base thread count
[01:24:03] <PCW> (where instead of read compute write you have to read-request wait read compute write)
[01:57:52] <jepler> well, perhaps you could give rtapi a mode where it only has one rtai thread at the base period rate; if you have two threads at rate K and 10*K then it would call base every time and base followed by servo the 10th time. but if the servo lasts more than K then you might end up in trouble because you'll miss a deadline.
[01:58:37] <jepler> how long a turnaround is it? 10us, or 100s of us?
[01:58:58] <jepler> you could always just busy-wait, but if it's 100us then you busy wait 10% of the time away
[02:01:57] <PCW> Right, you can also just be one sample behind with your read data and run the servo loop faster to compensate
[02:02:36] <PCW> (doing read/write/read-request each time)
[02:03:37] <PCW> For DMA, its probably simplest to just wait (no longer than 10 uSec probably)
[02:07:17] <PCW> For our SPI stuff slowest turnaround would be maybe 20 usec. EThercat or RTNet may get into the 100 uSec region, not sure how efficient their drivers are either
[02:09:19] <jepler> it's too bad I don't know the rtai api very well; I am not sure what's possible -- only that the rtapi layer makes very little easy
[02:19:09] <jepler> ok, how about this. hal will keep track of how many times a thread has been run -- call that number R. With each function you put on the thread, you can specify two numbers A and B; the function actually runs if R%A==B. Default A=0, B=1 so that functions run every time (current behavior)
[02:19:47] <jepler> but you could run with a 100ms thread, specify A=10, B=1 for most things and A=10, B=0 for the 'request read' function
[02:20:26] <jepler> that'd be about the same as running a 1ms servo thread, but you can do your 'request read' activity in advance like you want
[02:27:41] <jmkasunich> so you are calling "request_read" 1 out of 10 runs of the base thread, and invoking the rest of the servo code in the servo thread? that doesn't work
[02:28:46] <jmkasunich> if you are talking about invoking request_read 1 out of 10 runs of base, and the rest of servo _also_ 1 out of 10, but not the same 1, then you are screwed if servo_time + base_time > base_period
[02:29:00] <jepler> (oh, I meant 'run with a 100us thread', of course)
[02:29:12] <jepler> jmkasunich: I am not sure my idea is entirely baked, but I think I didn't make it clear either
[02:29:18] <jmkasunich> yeah, I assumed 100mS was a typo
[02:29:24] <jepler> one thread, 100us (not two threads)
[02:29:30] <jmkasunich> that doesn't work
[02:29:42] <jepler> over 10 invocations, the thread does: read, everything else, then nothing 8 times
[02:30:15] <jepler> so everything happens once per ms but you got the chance to issue the read request 100us early
[02:30:22] <jmkasunich> unless you are absolutely sure that the worst case execution tome of the base code, and the worst case execution time of the servo code, add up to less than the base period - which is probably not true
[02:31:02] <jmkasunich> the reason we have two threads is so that the servo stuff can use several base periods to get stuff done, and the higher priority base stuff interrupts it
[02:31:11] <jepler> yes, if "everything else" takes over 100us then you miss a deadline
[02:31:19] <jepler> (or if "issue read request" does)
[02:31:35] <jmkasunich> everything else DOES take more than 100uS, or at least it certainly can
[02:32:40] <jmkasunich> think of complex kins math - possibly even stuff that has to do successive approximation to home in on a solution because a closed form solution doesn't exist
[02:34:48] <jepler> point taken
[02:35:35] <jmkasunich> the idea of scheduling threads at something other than simply "every 1mS" is interesting, but I think we have to retain distinct prioritized threads
[02:36:01] <jepler> in this kind of system I think both 'read' and 'everything else' are the same priority
[02:36:16] <jmkasunich> yes, but both are lower than the base thread
[02:36:39] <jmkasunich> also, "same" is tricky - what happens if read isn't finished when everything else is ready to run?
[02:36:49] <jmkasunich> gotta pick one or the other, hence prioroty
[02:36:59] <jmkasunich> priority
[02:37:39] <jepler> hm, rtai has rt_sleep and rt_sleep_until. "During this time the CPU is used by other tasks"
[02:38:14] <jepler> I wonder if that includes non-realtime tasks...
[02:38:47] <jepler> if so, maybe just try having 'read' request read, rt_sleep, finish read .. if that works out, we can add the call to rtapi which would just pass it through
[02:40:30] <jmkasunich> what does sleep take as an arg? time in nS or something?
[02:40:54] <jepler> it takes an RTIME which is the same as rt_make_task_periodic
[02:41:59] <jepler> rt_sleep(nano2clocks(20*1000)) // sleep (non-busy-wait) 20us
[02:43:26] <jmkasunich> looks like that would eliminate some busy-waiting
[02:43:52] <jmkasunich> scary though, if the user specifies a sleep time that is a significant portion of (or greater than) the task period
[02:45:12] <jmkasunich> in the application that seb has in mind, is the requirement to wait for some specific time interval, or are we waiting for the hardware to do something (which we can detect as finished by reading the hw)?
[02:46:35] <jepler> I assume that there's something you can poll to see if it's done, but I'm not sure
[02:46:52] <jmkasunich> I guess it was PCW, not seb
[02:47:14] <jmkasunich> anyway, he's talking about requesting the data before it's needed, to give it time to arrive
[02:47:38] <jepler> right, I think it's about kicking off some number of SPI reads in advance
[02:48:31] <jmkasunich> the sleep approach would work there, as would busy waiting, or "early start" - early is relative, we can either start the data early or do the computations a bit later, the net result is identical
[02:48:37] <jepler> right
[02:49:03] <jmkasunich> in any of those cases, the only difference is leaving more CPU cycles for the background non-rt code
[02:49:45] <cradek> is a pc keyboard a grid that's scanned or is it more complicated than that?
[02:49:52] <jmkasunich> I wonder what the overhead of rt_sleep() is
[02:50:02] <jepler> hm, now why in the world did I require that a component have at least one pin?
[02:50:18] <jmkasunich> cradek: since the interface is serial, I think the kb maker is free to do whatever they want
[02:50:29] <cradek> hmm.
[02:50:35] <jmkasunich> I bet most do some sort of scan/multiplex thing, but I don't think it is standardized
[02:50:59] <jmkasunich> back in the day there were standard scan codes, and I bet they mapped to the actual scan pattern of the IBM kbs, but today it can be anything
[02:51:03] <cradek> I need approximately a 5x10 grid of buttons...
[02:51:44] <jmkasunich> will you press more than one at a time?
[02:51:49] <cradek> no
[02:52:16] <jmkasunich> then I'm sure you could gut a keyboard and connect your 50 switches in place of 50 of the keyboard's switches
[02:52:26] <jmkasunich> you don't need to care about how the kb does it
[02:53:00] <jmkasunich> if you want to have less than 100 wires soldered to the pcb, then you start caring
[02:54:11] <cradek> it's not for a pc, I actually need a grid of contacts or something to simulate it
[02:55:02] <jmkasunich> are you talking about an input device (100 switches going to a PC or micro or whatever), or an output device (PC or micro or whatever making 50 contacts close)
[02:55:04] <cradek> I foolishly tried to fix the membrane keyboard on the bridgeport
[02:55:35] <cradek> sorry I didn't mean to be mysterious
[02:55:54] <jmkasunich> you tried to fix the membrane, and?
[02:56:05] <cradek> I bet you can guess how that went
[02:56:10] <cradek> it doesn't work at all now
[02:56:23] <cradek> it worked 10% before so this is not much worse, really
[02:56:30] <jmkasunich> and so somehow that leads to a question about how PC keyboards work?
[02:56:32] <jepler> aw geez
[02:57:38] <cradek> yeah if I had a grid, I'd just label them and it could work enough to home and run a program or two - that's the goal
[02:58:35] <jmkasunich> so the data that I'm missing is that the BP _does_ use a grid, and you are wondering if the switch assy (less the micro) of a PC can be used to replace it
[02:58:43] <cradek> yes
[02:58:56] <jmkasunich> why dincha say so in the first place?
[02:59:19] <cradek> poor communication skills, mostly
[02:59:27] <jmkasunich> do you know the nature of the BP scan? N rows by M columns, with or without diodes in each switch, etc?
[03:00:15] <cradek> I have schematics - I will dig
[03:00:41] <jmkasunich> you could open up a $5 PC keyboard and trace things probably
[03:01:08] <jmkasunich> I'd be astonished if it wasn't some sort of scanned matrix, but the dimensions might be strange
[03:04:59] <jmkasunich> if there aren't diodes at each switch, you can get strange effects if more than one switch is pressed
[03:06:26] <cradek> I know there are no diodes in the keyboard
[03:07:08] <jmkasunich> do you know how many wires connected to the kb (I'm assuming we're talking about the BP kb now)
[03:08:10] <cradek> yes I have the schematic for the keyboard. it is 5 rows, 10 cols
[03:08:22] <cradek> plain old switch closures, no smarts
[03:09:16] <jepler> rt_sleep seems to just return RT_TMROVRN
[03:10:38] <jmkasunich> overrun?
[03:10:42] <jepler> and the .time of the thread doesn't change when I change the requested sleep time -- but it should since the time is in tscs
[03:10:47] <jepler> yes I think that's what that means
[03:11:05] <jmkasunich> how long of a sleep are you requesting?
[03:11:14] <jepler> 20us from a 1ms thread
[03:11:23] <jmkasunich> try requesting 200uS
[03:12:18] <jmkasunich> the only implementation I can think of for rt_sleep would require it to set up a hardware timer to generate an interrupt at the desired wakeup time - that's the only way to get control back from the background task
[03:12:27] <jepler> hm that *does* change the time of the thread
[03:12:38] <jmkasunich> that setup might take non-trivial time, or might conflict with the normal periodic interrupt that is already being used'
[03:12:49] <jepler> er, no, it doesn't. adding more outb()s did.
[03:13:53] <jmkasunich> cradek: imagine 5 rows connected to 5 outputs from a micro, and 10 columns connected to 10 inputs
[03:14:07] <jmkasunich> the columns are pulled up by resistors, and the row outputs are normally high
[03:14:16] <jmkasunich> rows are A-E, cols are 0-9
[03:14:30] <jmkasunich> micro pulls A low, reads inputs, the puts A high and pulls B low, reads, etc
[03:14:46] <jmkasunich> if B3 is closed, then when B is low, 3 goes low - simple
[03:15:06] <jmkasunich> but suppose A5, B5, and A3 are closed
[03:15:34] <jmkasunich> B goes low, which pulls 5 low thru B5, that pulls A low thru A5 (fighting the A output which is trying to hold A high)
[03:15:52] <jmkasunich> assuming that A goes low, that in turn pulls 3 low thru A3
[03:16:10] <jmkasunich> the software sees 3 go low while B is low, and assumes (incorrectly) that B3 is closed
[03:17:36] <jmkasunich> the BP folks may simply have ignored that issue - especially since you don't touch type on such a kb, the odds of three switches being hit at the same time are low
[03:17:38] <cradek> yeah I'm sure the problem is it's got one or more things shorted row-to-column
[03:18:03] <jmkasunich> PC keyboards probably have to take a more sophisticated approach to dealing with that problem
[03:18:06] <cradek> yes I bet it does wrong things if you press more than one key at once (and that's what it's seeing)
[03:18:23] <jepler> RTE_TMROVRN if an immediate return was taken because the delay is too
[03:18:24] <jepler> short to be honoured.
[03:18:35] <jmkasunich> ah, that makes sense
[03:27:37] <jepler> [983985.716836] sysctl table check failed: /dev/parport/parport0/devices/sleeptest/timeslice Sysctl already exists
[03:27:41] <jepler> well that's a new one on me!
[03:31:35] <jmkasunich> this happened during testing rt_sleep()?
[03:32:28] <jepler> yes, but it was an unrelated problem (registered parport but didn't unregister it)
[03:32:41] <jepler> (sleeptest tweaks the parport, then calls rt_sleep, then tweaks the parport again)
[03:36:12] <jepler> well both from the scope and from other indications it's clear that rt_sleep isn't behaving as desired
[03:37:30] <jmkasunich> NEFS
[03:38:51] <jepler> [ 574.532058] PARPORT: ERROR: port parport0 claim failed
[03:38:51] <jepler> [ 574.532065] parport0: àdÚ߀gÚß tried to release parport when not owner
[03:39:11] <jepler> looks like my simple test code is still wrong :)
[03:46:27] <jepler> 'night all
[03:46:33] <jmkasunich> goodnight
[03:46:41] <jmkasunich> seems like a good time for that here too
[03:47:39] <jepler> ho boy, I would have made that announcement on -developers nly
[12:23:03] <CIA-2> EMC: 03jepler 07master * r329963bc9c39 10/src/po/it.po: Update Italian translation
[12:30:09] <jepler> whee, my menu patch works on 9.04 as well
[12:36:33] <CIA-2> EMC: 03jepler 07master * r2013d8013b9c 10/scripts/latency-test: make latency-test run without emc-environment
[12:36:42] <CIA-2> EMC: 03jepler 07master * rb300fd687e85 10/scripts/emc.in: set LD_LIBRARY_PATH like emc-environment
[12:38:00] <CIA-2> EMC: 03jepler 07master * r992e6bede71a 10/ (6 files in 4 dirs): 'make install-menus' puts RIP in the Applications menu
[13:43:24] <jthornton> jepler: rip menus work for me (after I reboot :) )
[13:48:05] <alex_joni> jthornton: it's enough to ctrl-alt-backspace
[13:48:21] <alex_joni> or there's another reload signal that can be sent to gnome
[13:48:30] <alex_joni> but I don't know which one
[13:51:54] <jthornton> alex_joni: that will rebuild the menus?
[13:53:50] <jthornton> alex_joni: did you see the inkscape plug in on the forum?
[13:56:05] <alex_joni> ctrl-alt-escape will kill your X server
[13:56:14] <alex_joni> when it will restart, it'll surely rebuild the menus ;)
[13:56:16] <alex_joni> yes, I did
[13:58:25] <jepler> huh, the items appeared for me without logging out (both on 6.06 and 9.10)
[14:03:34] <jthornton> I was on 8.04 and had to boot
[14:03:49] <jthornton> or have the secrect decoder ring from alex_joni
[14:08:12] <jepler> I noticed that if you just 'make install-menu' it didn't create all the necessary files; I had to 'make; make install-menu'
[14:08:21] <jepler> could it have been that?
[14:09:11] <jthornton> I put the make install-menu after the make in my script...
[14:09:23] <jepler> then ran the script?
[14:09:25] <jepler> ok, that should be fine..
[14:09:32] <jthornton> yes
[14:10:59] <jepler> I'll have to try this myself on an 8.04 machine, but for now a note on that thread that you might have to restart your login to see the items wouldn't hurt
[14:11:02] <jepler> bbl
[14:12:58] <jthornton> opps I've deleted that email all ready
[17:09:19] <CIA-2> EMC: 03jepler 07master * rcf28af957cdf 10/tcl/emc.tcl.in: provide tcl with info about config directories
[17:09:20] <CIA-2> EMC: 03jepler 07master * r078101f485df 10/tcl/bin/pickconfig.tcl: make sure to always describe directory
[17:09:21] <CIA-2> EMC: 03jepler 07master * r1f6cd76c5c5a 10/tcl/bin/pickconfig.tcl: get config dir list from emc.tcl
[17:09:23] <CIA-2> EMC: 03jepler 07master * ra570537b044c 10/tcl/bin/pickconfig.tcl: dir is guaranteed to be normalized
[17:09:26] <CIA-2> EMC: 03jepler 07master * r853d893e600c 10/tcl/bin/pickconfig.tcl: describe directories even for RIP
[17:09:29] <CIA-2> EMC: 03jepler 07master * rbec97ff71e22 10/tcl/bin/pickconfig.tcl: close right directory even for RIP
[17:09:32] <CIA-2> EMC: 03jepler 07master * rb83b1e254762 10/tcl/bin/pickconfig.tcl: correctly track whether there are nonsample configs
[17:09:35] <CIA-2> EMC: 03jepler 07master * r8206287dd8c5 10/tcl/bin/pickconfig.tcl: USER_CONFIG_DIR is a better way to name this location
[17:09:38] <CIA-2> EMC: 03jepler 07master * r4b911b69b53a 10/scripts/emc.in: don't send a pickconfig argument that goes unused
[17:09:43] <CIA-2> EMC: 03jepler 07master * r314f3aa2d90e 10/src/emc/task/emctaskmain.cc: improve behavior of MDI O-calls
[17:09:50] <CIA-2> EMC: 03jepler 07master * ree2d031d70f0 10/.gitignore: make overzealous ignore more specific
[17:09:52] <CIA-2> EMC: 03jepler 07master * rf40889afa748 10/src/Makefile: make the rule name match what I said in an earlier commit
[17:09:55] <CIA-2> EMC: 03jepler 07master * r81d7f2a54260 10/src/Makefile: make sure install-menu updates all menu-related files
[17:09:58] <CIA-2> EMC: 03jepler 07master * r9e03062a872a 10/src/emc/ (6 files in 3 dirs): factor tool table reading out of iotask
[17:10:01] <CIA-2> EMC: 03jepler 07master * r519fcb2ef1dd 10/src/emc/sai/ (Submakefile driver.cc): use new tool reading code in standalone interpreter
[17:10:04] <CIA-2> EMC: 03jepler 07master * r5d97897bc6cf 10/src/emc/rs274ngc/tool_parse.cc: fix a warning
[17:10:08] <CIA-2> EMC: 03jepler 07master * r637610ffbc59 10/src/emc/rs274ngc/tool_parse.cc: parse old-style tool files
[17:10:13] <CIA-2> EMC: 03jepler 07master * rfb8f8958a6c8 10/src/emc/rs274ngc/tool_parse.cc: warn (on terminal) about unrecognized lines
[17:12:16] <cradek> you fixed sai! yay!
[17:12:23] <cradek> and you fixed it the right way even
[17:13:55] <PCW_> PCW_ is now known as PCW
[17:14:22] <cradek> Runtest: 34 tests run, 34 successful, 0 failed + 0 expected
[17:14:24] <cradek> whee
[17:18:18] <micges> cool
[17:19:10] <jepler> Is the removal of G43.1 I- K- the only gcode incompatibility, or is there something about G10 L1 that is not forward-compatible?
[17:19:36] <micges> removal?
[17:19:52] <jepler> G43.1 I- K- is no longer accepted, but it was in 2.3.
[17:20:05] <micges> oh
[17:20:21] <jepler> is that the only one, or is there a G10 L1 that was accepted in 2.3 but not anymore?
[17:20:45] <micges> only paramters on G10 was added
[17:20:51] <jepler> OK, thanks
[17:22:34] <jepler> hi seb
[17:23:33] <seb_kuzminsky> hey there
[17:23:38] <seb_kuzminsky> thanks for the tooltable fix :-)
[17:23:44] <jepler> > G43.1 @1 ^1
[17:23:44] <jepler> Polar coordinates can only be used for motion
[17:23:48] <jepler> cradek: awww drat ^^^^^
[17:24:04] <cradek> don't be ridiculous
[17:25:51] <cradek> does this mean my old tool table will get automagically converted?
[17:25:57] <jepler> cradek: yes, I hope so
[17:26:01] <cradek> because if so, that's all kinds of awesome
[17:26:24] <jepler> hmm, I could make G43.1 I- K- work again, but it would be a different meaning in 2.3 for machines that were tlo_is_along_w
[17:26:30] <jepler> (because K would always be applied to Z, not W)
[17:26:47] <jepler> the code's written, but I dunno whether to push the change..
[17:26:48] <jepler> thoughts?
[17:26:54] <cradek> if the behavior changes, breaking the syntax is a feature
[17:27:08] <cradek> (I think I'm serious)
[17:27:56] <cradek> seb_kuzminsky: in this case I'm going to use the master packages on Jr. I don't have any need to compile on it.
[17:28:58] <seb_kuzminsky> cool :-)
[17:29:24] <seb_kuzminsky> the new debs from jeff's fix should be ready in a few minutes :-)
[17:29:48] <seb_kuzminsky> i'm excited to come see you guys tomorrow
[17:30:07] <cradek> me too
[17:30:23] <cradek> but I'm already wishing we had more time!
[17:30:39] <cradek> glad the weather is nice for your drive.
[17:30:53] <CIA-2> EMC: 03jepler 07master * r3378b866639b 10/nc_files/ (cone.ngc tool-length-probe.ngc): use new g43.1 syntax
[17:31:00] <seb_kuzminsky> yeah it's going to be super rushed...
[18:04:47] <seb_kuzminsky> grump, the buildbot built the wrong thing - it re-built the previous version, since i had forgotten to tell it to clean the build dir
[18:10:01] <skunkworks_> what are you guys having? A mini mesa rumble?
[18:13:35] <seb_kuzminsky> skunkworks: it's a mesa vs bridegeport smackdown
[18:14:27] <seb_kuzminsky> i'm trying to build up the nerve to buy chris' bridgeport & we're going to start by converting it to emc2 :-)
[18:14:37] <skunkworks_> Aww - very cool!
[18:15:40] <skunkworks_> did cradek ever find a transformer to convert the servo drives to single phase?
[18:16:31] <seb_kuzminsky> he's got the transformer, but we'll probably still need some more caps & a new rectifier
[18:17:04] <skunkworks_> neat
[18:17:12] <skunkworks_> we finally started our conversion...
http://www.electronicsam.com/images/KandT/conversion/xaxis/stripped.JPG
[18:17:43] <seb_kuzminsky> are those brass pipes the lube system?
[18:32:43] <skunkworks_> yes
[18:34:15] <jepler> skunkworks_: you can drive down if you want
[18:35:41] <cradek> yeah, by all means come join us
[19:17:05] <cradek> I think everyone agrees it's a blooper to have text on icons since it's not localizable. but what about our O words? was it bad to use english words instead of making a bunch of new M codes or something? I think many other controls use the latter system.
[19:24:50] <jepler> programming languages have a long history of having their tokens in english
[19:25:05] <cradek> that's true
[19:25:28] <jepler> I suspect more people are better served by "O call" than "M1337"
[19:25:39] <cradek> (I want to argue it's not relevant, since end users don't come into contact with programming langauges, but I can't bring myself to do it)
[19:26:43] <cradek> I suppose if it's an understandable word for half the users and an arbitrary token for the other half, that's better than it being an arbitrary token for everyone
[19:27:36] <cradek> but of course all the rest of gcode is arbitrary tokens...
[19:27:48] <cradek> meh
[19:27:53] <cradek> even I don't care about this, and I brought it up
[19:48:38] <skunkworks_> heh - I don't think I can make it. would be fun though!
[20:02:06] <CIA-2> EMC: 03jepler 07master * r51a2ee9fd46b 10/src/po/ru.po: Update Russian translation
[20:02:08] <jepler> aystarik: ^^^ thanks, applied.
[20:10:02] <seb_kuzminsky> skunkworks: where do you live?
[20:40:32] <jepler> jthornton: both lathe/lathe-user and gcode/tool_compensation have different diagrams showing the different tool orientation
[20:41:04] <jepler> jthornton: perhaps they should use the same image instead
[20:46:16] <skunkworks_> seb_kuzminsky: I live near lacrosse wi (trempealeau)
[20:46:40] <skunkworks_> long-ish drive ;)
[21:22:59] <micges> I have question
[21:23:21] <micges> I would like to home stepper machine on index
[21:24:29] <micges> I have steppers with encoders (internal loop)
[21:24:55] <micges> I have isolated index signal from encoders
[21:25:22] <micges> I would like to use software encoder to emulate it
[21:25:32] <micges> is it possible?
[21:25:47] <cradek> stepgen doesn't know how to reset position on index, but it seems like you could add that
[21:26:10] <cradek> I think there's no problem except it needs an interested person to work on it :-)
[21:26:45] <micges> but I don't know (get) why stepgens must reset position of index?
[21:27:28] <micges> (I never used indexes)
[21:27:41] <jepler> consider a servo homing to index instead
[21:27:52] <jepler> say it's turning at a rate of about 100 encoder counts per ms
[21:28:09] <jepler> the reset-on-index behavior means you know exactly where the index happened
[21:28:36] <jepler> if you don't reset then you know the position within 100 counts instead
[21:29:20] <jepler> that's (one reason) why home-to-index is better than home-to-switch -- you know the position of index to 1 count even if you're moving at more than 1 count per servo period
[21:30:49] <jepler> so to have stepgen "home to index" you have to have the same machinery -- if index-enable is TRUE and the rising edge of index is seen, reset count to 0 and clear index-enable. you have to do the check as often as you issue a step
[21:31:00] <jepler> (so if it's on mesa, you have to change the mesa firmware since that's what issues the steps)
[21:32:04] <micges> thanks
[21:33:18] <cradek> it's interesting that you would home to a particular encoder edge even though your stepper may never be able to settle there
[21:33:30] <cradek> not that that's a problem, but I think it's interesting
[21:33:31] <skunkworks_> mesa had a firmware that allowed stepper homing to index.. I wonder if that ever to integrated.
[21:33:42] <skunkworks_> *got
[21:34:49] <jepler> not that I know of; the hostmot2 regmap text file doesn't name a register for stepgen index
[22:01:43] <cradek> wonder when seb_kuzminsky will stop slapping emc2-buildmaster around
[22:02:21] <cradek> ha
[22:03:19] <alex_joni> that was on it's own ;)
[22:03:38] <alex_joni> just to spite you
[22:03:50] <micges> good night all
[22:04:30] <alex_joni> see ya micges
[22:05:14] <seb_kuzminsky> i'll stop slapping it when it stops misbehaving
[22:05:41] <cradek> but what about its morale?
[22:06:03] <cradek> did it make a package with the fixed runtests on master yet?
[22:06:16] <seb_kuzminsky> it did for realtime, but not for sim
[22:06:34] <seb_kuzminsky> i just fixed the problem that prevented the sim deb from building and restarted it
[22:07:34] <alex_joni> was it a divide by zero?
[22:07:37] <alex_joni> http://verydemotivational.com/wp-content/uploads/2010/01/129080056570437982.jpg
[22:08:51] <PCW> Probably for stepgen index you don _not_ want to reset on index, just latch the current count on index
[22:09:03] <PCW> (do not)
[22:09:19] <seb_kuzminsky> cradek: the most recent deb is from aystarik's localization commit
[22:09:33] <cradek> neato
[22:10:36] <cradek> funny, git describe doesn't work in my master checkout, but it is 51a2ee9
[22:12:36] <jepler> PCW: the hypothetical future hostmot2 could sure latch on index (just like encoder does), but to work with the current homing we'll want it to work "just like" encoder count at encoder index..
[22:12:54] <jepler> cradek: that's because there are no (annotated) tags in the history of master
[22:13:06] <cradek> the driver just uses subtraction to pretend, right?
[22:13:13] <jepler> cradek: git has two flavors of tags, "annotated" and "the one I think you're not supposed to use". guess which one is the default?
[22:13:23] <jepler> cradek: yes pretty much
[22:13:27] <cradek> jepler: well grr
[22:13:42] <jepler> cradek: and even worse, guess which one git-cvsimport created
[22:13:53] <cradek> THE DEFAULT KIND I BET
[22:14:04] <cradek> STUPID IT
[22:14:07] <alex_joni> nah.. the one you're not supposed to use
[22:14:26] <cradek> hey look, it's after 4pm
[22:14:30] <alex_joni> jepler: seen #emc ?
[22:14:38] <cradek> I was just going to go do anything else!
[22:14:59] <PCW> re step index, Sure Ive thought about it but have not implemented it
[22:14:59] <alex_joni> you need to finish the retrofit and surprise seb
[22:15:00] <PCW> (dont want to clea counter r, plays havoc with velocity on encoder counters and step sequence on step motors)
[22:15:54] <seb_kuzminsky> cradek: did you init your repo by "git init && git fetch"? If so you dont have tags, and git-describe will choke. If that's it, say "git clone" or "git fetch -t" instead
[22:26:34] <jepler> I just made new annotated tags for all the past v2.x.y releases (in that form) and turned cvs-import into a annotated tag as well
[22:26:53] <jepler> apparently you won't get the latter without 'git fetch -t', but I got the former with my next 'git fetch' in another repo
[22:44:38] <cradek> jepler: your parts are here
[22:44:48] <jepler> cradek: ooh
[22:44:56] <jepler> is it what we thought we were ordering?
[22:45:47] <cradek> yes, it all looks right
[22:48:04] <cradek> ok, after fetch -t, describe works
[22:50:41] <cradek> bbl
[23:00:27] <jepler> oh no, hostmot2 doesn't build on breezy anymore.
[23:00:27] <jepler> /home/jepler/emc2-dev/src/hal/drivers/mesa-hostmot2/hostmot2.h:32: error: parse error before "gfp"
[23:11:46] <jepler> apparently it never would have worked, anyway. When I load it: [11496305.074175] hostmot2: Unknown symbol release_firmware
[23:12:28] <jepler> but that must just be kernel misconfiguration, it's in the headers
[23:35:05] <alex_joni> would it be wise to change char to int for stepgen for 3.4 ?
[23:37:19] <alex_joni> jepler: sorry, just read your message on the list
[23:38:34] <alex_joni> * alex_joni writes "I shall read all channels before saying something" 100 times
[23:51:19] <alex_joni> hope it's ok to use a Oxxx loop
