Back
[00:35:56] <CIA-1> EMC: 03cmorley 07TRUNK * 10emc2/lib/python/pyvcp_widgets.py: Changed the pad size to scale itself and made knob circle small as per discussion with John T
[00:47:36] <BigJohnT> hi chester81
[00:47:57] <chester81> Hey john this is better!
[00:48:11] <BigJohnT> what happened to chester88?
[00:48:35] <chester81> Wow pyvcp has treasures to dig up!
[00:48:41] <chester81> what do you mean?
[00:48:59] <BigJohnT> the smaller knob covers up much less IMHO and looks cleaner
[00:49:18] <chester81> Yes I think I should change the job wheel too
[00:49:20] <BigJohnT> I thought last time you logged in as chester88
[00:49:45] <chester81> what does it say now ? (mine says chester88
[00:49:50] <BigJohnT> cool, what does gray52 do to the gray
[00:49:57] <BigJohnT> it says chester81
[00:50:08] <chester81> changes the shade
[00:50:27] <chester81> hmmm i'm down by 7 then!
[00:50:33] <BigJohnT> is it like 0 - 100 or 0 to 256 or something?
[00:51:36] <chester81> not sure did try it gray25 was pretty dark ...hold on i will try higher numbers...
[00:51:47] <jepler> I think that is in 0-100
[00:52:38] <BigJohnT> is it only for shades of gray?
[00:53:15] <jepler> that's an "X color name"; they come from the "rgb database" also known as rgb.txt. You can also specify hex colors that you might be familiar with from the web, like #828282
[00:53:24] <jepler> http://sedition.com/perl/rgb.html
[00:54:37] <BigJohnT> Sweet!
[00:56:06] <chester81> hmm yes seems only gray is working 0=100 . you can use terms such as lightyellow and darkblue etc
[00:58:37] <BigJohnT> blue1, 2, 3, 4 work
[00:59:17] <chester81> Wow John you got a lot of documentation to do...lol
[00:59:50] <chester81> everytime I commit you have to change all your pics :)
[01:00:13] <BigJohnT> heh that only takes a few seconds
[01:00:34] <chester81> well that's good then!
[01:00:46] <BigJohnT> and then Francis has to change his too :)
[01:01:59] <chester81> Hey Jeff do you have any info about loading images with pyvcp? you added some images and button images?? aprox 2 years ago....
[01:02:53] <chester81> Yes Francis is kept busy too!
[01:10:12] <BigJohnT> he must have wandered off chester81
[01:11:05] <chester81> I guess so - I should have used he stage name-jepler
[01:11:53] <BigJohnT> yea that will make his screen blink
[01:29:09] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (4 files): add images
[01:30:46] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: add a bit more info
[01:40:21] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (pyvcp_jogwheel.png pyvcp_dial.png): add image
[01:43:29] <jepler> chester81, BigJohnT: pyvcp image example:
http://pastebin.ca/1319135
[01:43:44] <jepler> assumes you made two images 'on.gif' and 'off.gif' of the same size
[01:44:14] <jepler> in the same directory as your inifile (or in current directory if you're testing with halrun/halcmd)
[01:44:22] <BigJohnT> thanks jepler
[01:44:35] <jepler> image_bit lets you choose from two images and the hal pin type is bit
[01:44:52] <jepler> there's also image_u32 which lets you have an essentially unlimited number of images
[01:45:05] <jepler> no useful formats besides gif are supported (jpg and png are not)
[01:45:13] <BigJohnT> ok
[01:47:48] <BigJohnT> thanks jepler
[01:49:48] <jepler> chester81: did the name 'init' cause a problem?
[01:49:48] <jepler> - [ <init>123</init> ] (initial value a whole number must end in '.')
[01:49:51] <jepler> + [ <initval>123</initval> ] (initial value a whole number must end in '.')
[02:17:50] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/ (pyvcp_number.png pyvcp_s32.png): add images
[02:20:01] <CIA-1> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/pyvcp.lyx: a few more tidbits
[02:38:48] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/tcl/bin/tkbackplot.tcl:
[02:38:48] <CIA-1> EMC: at least my own contributions to this file are made available under the GNU GPL
[02:38:48] <CIA-1> EMC: and are not released to the public domain.
[02:39:00] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/directory.map: Remove cvs keywords -- these only serve to muddle diffs
[02:39:02] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/scripts/ (emc.in hal_demo): Remove cvs keywords -- these only serve to muddle diffs
[02:39:04] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/src/emc/ini/ (inijoint.cc inijoint.hh): Remove cvs keywords -- these only serve to muddle diffs
[02:39:05] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/tcl/tkemc.tcl: Remove cvs keywords -- these only serve to muddle diffs
[02:39:07] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/tcl/bin/ (7 files): Remove cvs keywords -- these only serve to muddle diffs
[02:39:09] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/tcl/scripts/ (Set_Coordinates.tcl emchelp.tcl): Remove cvs keywords -- these only serve to muddle diffs
[02:44:03] <jepler> does anyone know whether iosh is still useful?
[02:48:09] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/src/po/Submakefile: remove pre-hal cruft
[02:48:09] <CIA-1> EMC: 03jepler 07TRUNK * 10emc2/tcl/scripts/Set_Coordinates.tcl: correct comment
[02:49:06] <jepler> if you try to use it, emc hangs at startup waiting for the component 'iocontrol' to become ready
[02:49:11] <jepler> if that's not been reported, nobody must use it
[02:49:26] <jepler> anybody want to stop me removing it?
[02:49:51] <jmkasunich> I don't have a reason to keep it
[02:49:56] <jmkasunich> but what is the reason to remove it?
[02:50:17] <jmkasunich> I think of that as a ray tool
[02:51:42] <jepler> unless it works to run both 'io' and 'iosh', it hasn't worked since June 2006
[02:52:03] <jepler> that's when I first made the emc script try to wait for pin creation in components instead of using 'sleep' to avoid those linkp failures during startup
[02:52:30] <jmkasunich> so nobody has used it since then?
[02:52:42] <jmkasunich> or if they have, they silently kluged some workaround
[02:52:56] <jepler> .. which they didn't tell us about in the following 2 1/2 years
[02:53:35] <SWPadnos> one potentially useful command: emc_mot)move <axis> <position> <velocity>
[02:53:45] <SWPadnos> s/)/_/
[02:53:57] <jepler> (that's before 2.0.0)
[02:59:11] <jepler> SWPadnos: that's an interesting find, but does it do something?
[02:59:32] <SWPadnos> dunno - it should use NML to move one axis (joint)
[02:59:58] <jmkasunich> jepler: no commits for the next couple mins, ok?
[03:00:44] <jmkasunich> I am only seeing one core loaded now
[03:00:49] <SWPadnos> you should see only 50%-ish utilization unless you use make -j
[03:00:53] <SWPadnos> yep
[03:01:05] <jmkasunich> I should try -j on the atom too - it is dual core
[03:01:15] <SWPadnos> not under RT
[03:01:23] <SWPadnos> unless you got the sim package
[03:01:30] <SWPadnos> ug
[03:01:33] <SWPadnos> smp package
[03:01:55] <jmkasunich> I haven't booted into RT yet
[03:02:03] <jepler> it looks like iosh and io can run concurrently
[03:02:09] <jmkasunich> I suspect network problems, and I was up too late last night
[03:02:17] <jmkasunich> if the reboot has problems, I go to sleep
[03:02:23] <jepler> emc_mot_move moves an axis (trivkins machine) instantly to <position> regardless of what's specified for velocity
[03:02:53] <jmkasunich> core 2 with no competing load
[03:02:53] <jmkasunich> real 2m1.105s
[03:02:53] <jmkasunich> user 1m29.482s
[03:02:53] <jmkasunich> sys 0m15.541s
[03:03:09] <SWPadnos> withoug -j
[03:03:11] <SWPadnos> t
[03:03:33] <SWPadnos> out of curiosity, try make -j4
[03:04:33] <jmkasunich> real 0m58.095s
[03:04:33] <jmkasunich> user 1m20.633s
[03:04:33] <jmkasunich> sys 0m15.005s
[03:04:38] <jmkasunich> that is with make -j
[03:05:14] <jmkasunich> the make -j on the atom is really thrashing the disk, it may be swapping a lot
[03:05:36] <SWPadnos> 512M memory on the atom?
[03:05:39] <jmkasunich> yeah
[03:05:48] <SWPadnos> hmmm that shouldn't thrash too much
[03:05:50] <jmkasunich> real 0m59.163s
[03:05:50] <jmkasunich> user 1m20.121s
[03:05:50] <jmkasunich> sys 0m14.585s
[03:05:57] <jmkasunich> -j4 didn't make much difference
[03:06:13] <SWPadnos> twice as fast in wall time
[03:06:58] <SWPadnos> I don't remember what -j does - it may be equivalent to -j NR_CPUS (or some multiple)
[03:07:09] <jmkasunich> ISTR reading something like that
[03:07:12] <jmkasunich> 2x maybe?
[03:07:22] <jmkasunich> which would make it j4 in this case
[03:07:44] <jmkasunich> the atom GUI is totally unusable, and it has slowed to a crawl
[03:07:46] <SWPadnos> right
[03:07:50] <SWPadnos> hmmm
[03:07:58] <jmkasunich> disk is going like mad tho
[03:08:08] <jmkasunich> wish I had run top before it got bad
[03:08:12] <SWPadnos> heh
[03:08:17] <jmkasunich> lemme try a text console
[03:09:55] <jmkasunich> wow, I can't get a text console, and I can't ssh into it
[03:10:14] <jepler> -j with no arg is "as many as possible", at least in old makes
[03:10:24] <jepler> "as many as CPUs" would be a sensible meaning to substitute :-P
[03:10:39] <SWPadnos> I wonder how "possible" gets defined in that case? :)
[03:15:08] <jmkasunich> docs (gnu make manual, and an online o'rielly book) don't say
[03:15:46] <jmkasunich> num_cores + 1 is mentioned as a good value to use in a few places, but no description of what make actually does when there is no number
[03:15:58] <jmkasunich> it does say "there is no limit" when there is no number
[03:16:13] <jmkasunich> but that way seems madness - there must be some way it decides enough is enough
[03:16:21] <SWPadnos> right - "make will not limit the number of jobs ..."
[03:16:32] <SWPadnos> actually, I think that may be like ping -f
[03:16:37] <SWPadnos> ie, you don't use it often
[03:17:00] <jmkasunich> maybe that's why my poor atom is having a meltdown
[03:17:17] <SWPadnos> soon it'll be quarks
[03:18:17] <jmkasunich> SWPadnos: this is your fault
[03:18:27] <SWPadnos> ctrl-c should stop it
[03:18:29] <jmkasunich> I may have to reboot that thing in mid-compile
[03:18:53] <jmkasunich> I'm working blind
[03:18:53] <SWPadnos> were you able to get to a text console?
[03:18:58] <jmkasunich> the screensaver kicked in
[03:19:02] <jepler> -j can easily start hundreds of child processes on my machine.
[03:19:03] <SWPadnos> eek
[03:19:11] <jmkasunich> I can't get a console, I can't ssh
[03:19:29] <SWPadnos> sorry - I always use a number with -j - I forgot that it's possible to use it without one
[03:20:50] <jmkasunich> wow, I just got a login prompt!
[03:20:58] <jmkasunich> typed my name, no characters have appeared yet
[03:21:02] <jepler> at one point, "make -j" in emc2 had spawned over 400 processes (top "tasks" highest value minus pre-run value)
[03:21:44] <jmkasunich> note to self: don't do that again
[03:22:03] <SWPadnos> heh
[03:22:42] <SWPadnos> interesting - Jaunty has gcc and make on the livecD
[03:22:48] <SWPadnos> CD even
[03:22:57] <jmkasunich> given that it is taking a minute or more to respond to anything (it finally echoed my name at the login prompt), what is the best way to stop it?
[03:23:08] <jmkasunich> I suspect that ps -A would take 15 minutes
[03:23:10] <SWPadnos> kill the make process
[03:23:25] <jmkasunich> so ps -A to find it
[03:23:27] <jepler> kill -9 -1 will kill all processes started by your user
[03:23:31] <SWPadnos> sudo killall -9 make
[03:23:48] <SWPadnos> user or login?
[03:23:52] <jepler> hold alt-sysrq and type u (remount readonly) s (sync) b (reboot) to reboot without filesystem damage
[03:23:58] <jepler> SWPadnos: user (by user id)
[03:24:10] <jepler> alt-sysrq is interpreted by the kernel, so it doesn't matter if userspace is all fubar
[03:25:19] <jmkasunich> it's doing the "Emergency Sync" now
[03:26:23] <jmkasunich> anyway, before I killed its little brain, it was 2 mins for core2, 5 mins for atom, single threaded on both
[03:26:55] <jmkasunich> I can live with that, for $100 and runs on a battery
[03:28:38] <jmkasunich> if I configured with no swap, would that mean it would be less insane about spawning processes, or does it just mean it would crash hard when it runs out of memory?
[03:29:10] <SWPadnos> I think option 2
[03:29:13] <SWPadnos> but I'm not sure
[03:31:59] <jepler> supposedly, linux kills processes according to a heuristic when it runs out of ram+swap, but in my experience it becomes pretty darned unusable before that point
[03:32:15] <jmkasunich> it's pretty darned unusable right now
[03:32:51] <jmkasunich> (still thrashing, either the sync is taking a long time, or the userspace activity is still going on and slowing it down)
[03:33:13] <jmkasunich> it did print messages on the console when I issued the commands
[03:33:30] <jmkasunich> 7 minutes....
[03:34:19] <jepler> after remount-readonly, userspace shouldn't be able to write disk anymore
[03:34:26] <jepler> but it could be furiously moving stuff in and out of swap..
[03:34:59] <jmkasunich> that should die down when it finishes compiling the file(s) it is working on
[03:35:18] <jmkasunich> or actually, crashes trying to write the output files to a RO device
[03:35:25] <jepler> [358865.809778] Emergency Sync complete
[03:35:35] <jepler> but it would write a message like this one ^^ when the sync completes
[03:35:53] <jmkasunich> haven't got that one yet
[03:36:04] <jmkasunich> probably swap is competing for disk cycles with the sync
[03:36:21] <jmkasunich> the poor drive is certainly getting a workout
[03:39:59] <jmkasunich> * jmkasunich looks at prices of bigger ram sticks....
[03:40:41] <SWPadnos> $4.95
[03:41:32] <jmkasunich> where?
[03:41:49] <jmkasunich> I paid 6.99 on sale at newegg for the 512
[03:42:00] <SWPadnos> oh. 1G should be $9.99 then
[03:43:31] <jmkasunich> they change their prices too often
[03:43:39] <jmkasunich> cheapest 1G is now 8.99
[03:43:55] <jmkasunich> when I bought the board, I think the cheapest 1G was 11.99, so I bought the 512
[03:44:08] <jmkasunich> to be honest, I really had no intentions of installing a full hardy desktop on here
[03:44:15] <SWPadnos> heh. it's midway between now
[03:44:20] <jmkasunich> but it was late last night and that was the easiest button to push
[03:44:24] <SWPadnos> DDR2 533?
[03:44:45] <jmkasunich> yes
[03:44:56] <SWPadnos> one DIMM or two?
[03:44:58] <jmkasunich> the 8.99 is actually 667
[03:45:01] <jmkasunich> one
[03:45:04] <SWPadnos> ah, ok
[03:45:05] <jmkasunich> there is only one slot
[03:45:31] <jmkasunich> what I really should do is go to sleep
[03:45:40] <jmkasunich> and tomorrow figure out how to do a lighter install
[03:45:41] <SWPadnos> indeed. that's a good plan
[03:45:52] <SWPadnos> server then RT kernel
[03:46:01] <jmkasunich> xubuntu
[03:46:03] <SWPadnos> since you'll compile as RIP anyway
[03:46:15] <jmkasunich> I want X, just not gnome
[03:47:12] <jmkasunich> but I hate the thought that the last X hours of install were wasted
[03:47:53] <jmkasunich> this is unbelievable - it is still going 20 minutes later
[03:48:23] <jmkasunich> it could have written that entire drive (10G) twice over
[03:48:30] <jmkasunich> if it wasn't bouncing all over the disk
[03:50:52] <SWPadnos> that's strange
[03:51:03] <SWPadnos> did you manage to kill make?
[03:51:08] <jmkasunich> no
[03:51:11] <SWPadnos> oh
[03:51:36] <jmkasunich> I did the shift-alt u, shift-alt s thing, remount read-only and emergency sync
[03:51:53] <jmkasunich> userspace (including issuing commands like kill) is totally hosed
[03:51:55] <jepler> it must be time to give up
[03:52:19] <jepler> I notice there's alt-sysrq-i to kIll, but I dunno what it kills
[03:52:31] <jmkasunich> let's find out
[03:53:05] <jmkasunich> kill all tasks
[03:53:12] <jmkasunich> took 10 seconds, got a text prompt, logged in
[03:53:48] <jepler> oh well that's dandy then
[03:54:31] <SWPadnos> heh - yep. kills all tasks other than init
[04:00:05] <jmkasunich> somewhere in the install process it got confused
[04:00:16] <jmkasunich> I don't think it ever wrote an MBR to the hard disk
[04:05:12] <cradek> I hate these posts to the list saying "OK I fixed it" or the variant "never mind I figured it out" with no information. that's very bad style.
[04:09:12] <jmkasunich> noobs
[04:12:42] <seb_kuzminsky> i hate posts asking questions, when the answer is in the quoted text of the email being replied to...
[04:14:09] <SWPadnos> I hate it when a newly compiled/installed module prevents your computer from booting
[04:18:12] <cradek> six days to feature freeze...
[04:18:15] <cradek> is everyone ready?
[04:20:26] <cradek> seb_kuzminsky: I think ERR and PRINT both do the same thing, so your commit has no effect
[04:20:45] <seb_kuzminsky> hmm, oops if so
[04:21:07] <cradek> actually I think PRINT is unconditional and ERR has a debug level
[04:21:24] <seb_kuzminsky> ERR is rtapi_print_msg(RTAPI_MSG_ERR, ...), PRINT is rtapi_print(...)
[04:21:43] <seb_kuzminsky> i thought the unconditional one didnt go into NML, is that wrong?
[04:21:50] <cradek> but both eventually call rtapi_msg_handler
[04:22:07] <cradek> they are the same except for level
[04:22:16] <seb_kuzminsky> yes, but the handler checks the level to see if it's RTAPI_MSG_ERR, and rtapi_print() uses RTAPI_MSG_ALL
[04:22:26] <cradek> I'm no expert, I'm only lookin' at the code :-)
[04:22:33] <seb_kuzminsky> the handler just sends ERR level messages i think
[04:22:57] <seb_kuzminsky> yes
[04:23:39] <cradek> ah ok
[04:23:43] <cradek> (I didn't even find it yet)
[04:23:56] <seb_kuzminsky> rtapi_print calls rtapi_msg_handler with RTAPI_MSG_ALL, so i think its ok
[04:24:12] <seb_kuzminsky> the handler is in src/emc/motion/motion.c
[04:24:26] <seb_kuzminsky> rtapi_print and friends are in src/rtapi/rtl_rtapi.c
[04:24:49] <seb_kuzminsky> but really i should just fix that stupid encoder vel bug
[04:25:35] <cradek> need any kind of help I can provide?
[04:25:53] <seb_kuzminsky> thanks but i dont think so...
[04:26:24] <seb_kuzminsky> well maybe i can run my thinking by you and you can point and laugh at the broken bits? ;-)
[04:26:47] <cradek> I'll try
[04:27:27] <seb_kuzminsky> the quadrature counter fpga module has a 16-bit clock that runs at 1 MHz (configurable freq, that's what i'm currently setting it to)
[04:28:05] <seb_kuzminsky> you can read the current clock count from a register, i do it in hm2_read each time through the servo loop
[04:28:54] <seb_kuzminsky> when the fpga detects an encoder edge, it puts the 16-bit encoder count and the 16-bit timestamp (at the time of the edge) into the encoders count/time register
[04:29:02] <seb_kuzminsky> there is one count/time register for each encoder channel
[04:29:18] <seb_kuzminsky> i read all of them in hm2_read, each time through the servo loop
[04:29:33] <seb_kuzminsky> ok, that's what the driver has to work with
[04:29:40] <cradek> what timestamp do you get if there are many edges between reads?
[04:29:51] <seb_kuzminsky> the most recent one before the read
[04:29:57] <cradek> ok
[04:30:14] <seb_kuzminsky> each edge it puts the current count & current timestamp into the reg, you read whatever's there when you feel like it
[04:30:32] <cradek> got it
[04:30:37] <SWPadnos> minor question: are the values latched at the same time?
[04:30:41] <SWPadnos> (for all channels)
[04:30:56] <seb_kuzminsky> SWPadnos: each encoder channel latches independently, when that channel sees an edge
[04:31:05] <SWPadnos> ok
[04:31:09] <seb_kuzminsky> (i think!)
[04:31:13] <seb_kuzminsky> ok
[04:31:33] <SWPadnos> it should work either way, go on
[04:32:20] <seb_kuzminsky> there are three asynchronous things going on:
[04:32:28] <seb_kuzminsky> 1. the encoder hardware is producing edges
[04:32:45] <seb_kuzminsky> 2. the fpga encoder clock is ticking, rolling over every 65 ms
[04:32:58] <seb_kuzminsky> 3. the driver is reading the fpga registers in the servo thread
[04:34:24] <dgarr> I was testing something using simulator and axis (i usually use tkemc) and found jogging of angular axis real slow.
[04:34:24] <dgarr> As i remember, ini values are typically expressed units/second and then converted to units/minute as required
[04:34:24] <dgarr> internally, often by the gui.
[04:34:24] <dgarr> In axis.py where some ini values are converted, it says:
[04:34:25] <dgarr> vars.max_speed.set(float(mlv))
[04:34:27] <dgarr> ...
[04:34:29] <dgarr> vars.max_aspeed.set(float(mav))
[04:34:31] <dgarr> shouldn't it be:
[04:34:33] <dgarr> vars.max_speed.set(float(mlv) *60)
[04:34:35] <dgarr> ...
[04:34:37] <dgarr> vars.max_aspeed.set(float(mav) *60)
[04:35:51] <cradek> let's back up - what is your angular axis's max velocity as configured in the ini?
[04:36:07] <SWPadnos> dgarr, I don't think so, since lienar axes seem to jog at fine speeds
[04:36:24] <SWPadnos> (if it were a *60 problem, neither would work as expected)
[04:36:44] <dgarr> i'm comparing behavior using same ini file with tkemc and axis
[04:36:51] <cradek> what is your angular axis's max velocity as configured in the ini?
[04:37:43] <SWPadnos> seb_kuzminsky, are d0 and d1 pointers to raw data or has the data been massaged by the time it gets to hm2_encoder_compute_relative_time_velocity?
[04:39:14] <seb_kuzminsky> SWPadnos: that function gets massaged data
[04:39:27] <seb_kuzminsky> previous datapoint and current datapoint
[04:39:36] <SWPadnos> ok, so theoretically tiner overflows have already been taken care of?
[04:39:38] <SWPadnos> timer
[04:39:46] <seb_kuzminsky> that's the intent ;-)
[04:42:13] <seb_kuzminsky> the tricky bit thats causing problems is when the encoder is moving so slow that the driver has to start tracking rollovers of the encoder timestamp clock in order to make sense of the timestamp
[04:42:24] <seb_kuzminsky> just like SWPadnos told me way back when ;-)
[04:42:31] <SWPadnos> heh
[04:43:15] <seb_kuzminsky> i wonder if i still have the timing diagrams i drew up to try to think about this stuff...
[04:43:20] <SWPadnos> what is the tsc_rollover_flag?
[04:43:20] <seb_kuzminsky> * seb_kuzminsky digs through the trash
[05:01:59] <SWPadnos> seb_kuzminsky, why is hm2->encoder.timestamp_count_reg a pointer?
[05:02:40] <seb_kuzminsky> it's in preparation for using the hm2 translation ram
[05:02:50] <seb_kuzminsky> the fpga has all these registers at different addresses
[05:03:10] <seb_kuzminsky> this is expensive if you have to pay for address cycles, like on epp (7i43)
[05:03:17] <seb_kuzminsky> so the hm2 has translation ram
[05:03:31] <seb_kuzminsky> you write a series of addresses into the translation ram to set things up
[05:03:41] <SWPadnos> ok, but the pointer is never initialized to point to anything, and nothing is allocated for it to point to
[05:03:55] <seb_kuzminsky> then you can read all of those addresses with one long sequential read, using just one address cycle
[05:04:03] <SWPadnos> its address is passed to register_tram_read, not its value
[05:04:36] <seb_kuzminsky> the memory for it is allocated in register_tram_read, and register_tram_read assigns the address of the buffer it allocates to the passed-in pointer-pointer
[05:04:37] <SWPadnos> so everywhere else should refer to it as (int)timestamp_count_reg
[05:04:44] <seb_kuzminsky> no
[05:04:46] <SWPadnos> ok
[05:05:23] <SWPadnos> no, it doesn't work that way
[05:05:58] <seb_kuzminsky> why not?
[05:05:59] <SWPadnos> hm2_register_read_tram_region only allocates space for the hm2_tram_entry
[05:06:11] <SWPadnos> it doesn't allocate space for the buffer
[05:06:16] <seb_kuzminsky> look down in hm2_allocate_tram_regions
[05:06:30] <seb_kuzminsky> it can't allocate the memory yet, because it doesnt know how much to allocate
[05:06:56] <seb_kuzminsky> all the subdrivers (encoder, gpio, stepgen etc) register what they want, then when they're all done the tram allocation happens and the pointers are updated
[05:07:16] <SWPadnos> ah, ok
[05:07:30] <seb_kuzminsky> this is not strictly needed for epp (since each read is standalone), but it'll help dma in the future
[05:07:43] <seb_kuzminsky> the 9054 PCI chipsets support that
[05:10:37] <SWPadnos> I don't know if it matters, but the way that *hm2->encoder.tiemstamp_count_reg is written is inconsistent
[05:10:44] <SWPadnos> sometimes it's (*hm2-> ...)
[05:10:49] <SWPadnos> sometimes no parens
[05:12:36] <seb_kuzminsky> when applying the -- or ++ operators, you need the parens because those ops have higher precedence than the "*" dereference operator
[14:13:41] <SWPadnos> thanks skunkworks_
[14:13:58] <micges> cradek: ferror I have about 2.0 mm :)
[14:16:37] <alex_joni> eww :)
[14:16:41] <alex_joni> that's big, even for plasma
[14:17:26] <micges> on a test machine I saw the jog issue
[14:17:35] <micges> rest have 1.0mm :P
[14:18:09] <skunkworks_> SWPadnos: no - thank you!
[14:18:15] <SWPadnos> heh
[14:18:21] <micges> ok I've changed what you ask and once for about 5 second I have "can't do that (UNKNOWN) in manual mode"
[14:19:50] <micges> alex_joni: but it doesn't hanging
[14:33:29] <skunkworks_> http://www.youtube.com/watch?v=AhsSgcsTMd4
[14:34:04] <SWPadnos> huh:
http://www.susestudio.com/
[14:38:51] <micges_emc> heh I've broke the coupling :(
[14:46:36] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/pyvcp_hbox.png: fix image
[15:17:06] <cradek> micges: can you reproduce the problem in an unmodified emc2 trunk or 2.2 version and tell us how to do it?
[15:17:36] <jepler> .. in a configuration file you can send to us in its entirety that does not require hardware we do not have
[15:17:45] <jepler> s/file//
[15:20:35] <micges> ok
[15:28:57] <cradek> hmm, I should vote
[15:30:41] <alex_joni> cradek: ha.. good luck
[15:30:49] <alex_joni> care for my randomize script?
[15:33:26] <cradek> I notice some people didn't bother to put a bio on the wiki...
[15:33:35] <cradek> although, the ballot didn't have a pointer there this time
[15:34:10] <jepler> I figured someone else would write one for me; it's a wiki, after all
[15:37:02] <alex_joni> jepler: lol
[15:39:33] <SWPadnos> something like "Jeff usually ends development conversations by posting a link to his implementation of what's being discussed"
[15:40:17] <skunkworks_> if discussion is lasting more than 5 minutes
[15:41:48] <skunkworks_> 1 minute to think about it, 2 minutes to write it, 2 minutes to debug it.
[15:41:59] <alex_joni> debug? what's that
[15:42:02] <alex_joni> * alex_joni runs home
[15:42:09] <alex_joni> cradek: let me know what you find, I'll read back
[15:42:26] <alex_joni> (btw.. new cvs stats are baking..)
[15:44:54] <cradek> unlike my strategy: commit first, defend/argue afterward
[15:45:35] <alex_joni> runtime: 494.478 seconds
[15:45:36] <alex_joni> memory usage: 63104.0 kb
[15:46:12] <alex_joni> Developer of the Month:
[15:46:25] <SWPadnos> bigjohnT
[15:46:25] <alex_joni> January 2009 bigjohnt 46600 (lines)
[15:46:29] <SWPadnos> :)
[15:46:35] <BigJohnT> hi SWPadnos
[15:46:43] <SWPadnos> hi. you were my guess
[15:46:43] <alex_joni> http://eneas.juve.ro/~juve/stats/
[15:47:30] <alex_joni> see you later .. bbl
[15:48:31] <alex_joni> (I should probably figure out how to specify not to count dxf's and the like)
[15:49:15] <cradek> strange - most activity on monday
[15:53:55] <cradek> alex_joni: pause/step/resume seems to work perfectly, thanks!
[15:55:34] <cradek> also I think I got the various line number stuff right, finally
[15:56:22] <cradek> something about RFL is still wrong though.
[17:11:12] <cradek> for anyone interested who does not have a mesa etc: here is a log of the thing happening.
http://timeguy.com/cradek-files/emc/rollover-bug
[17:12:13] <SWPadnos> do you have a little bit more than that?
[17:12:23] <cradek> no, that's the whole thing
[17:12:26] <SWPadnos> like the next message?
[17:12:27] <SWPadnos> darn
[17:12:34] <SWPadnos> cur was about to roll over as well
[17:12:38] <cradek> I don't think there is a next message
[17:12:40] <SWPadnos> the first value anyway
[17:12:48] <cradek> I assume when cur rolls over, it stops giving the error
[17:12:56] <SWPadnos> uh, I mean the second value
[17:13:14] <cradek> maybe I don't understand what you're asking
[17:13:23] <SWPadnos> me either - no worries :)
[17:13:41] <cradek> once in a while, there is a flood of messages - this is that flood
[17:13:48] <SWPadnos> I was curious to see what happens when the second value printed for cur overflows
[17:13:52] <cradek> the log is not cut off - this is the entire "event"
[17:13:52] <SWPadnos> ok
[17:13:55] <SWPadnos> ah, ok
[17:14:23] <SWPadnos> [2773112.993810] hm2_5i20: *** NOTE: This driver is obsolete, you should use hm2_pci instead, it works better ***
[17:14:23] <skunkworks_> this was the thing on seb_kuzminsky's todo list?
[17:14:27] <cradek> this is a little old, but I don't think the code has changed
[17:14:33] <cradek> skunkworks_: yes
[17:14:44] <cradek> SWPadnos: yeah I haven't changed that yet...
[17:14:47] <SWPadnos> heh
[17:14:53] <jepler> SWPadnos: indeed, but the errors are coming from common code I'm 95% sure
[17:14:57] <seb_kuzminsky> skunkworks_: i'm about to remove hm2_5i20 any day now
[17:15:27] <SWPadnos> ojk, gotta run now. looks like good info though, thanks
[17:15:28] <seb_kuzminsky> it doesnt do anything that hm2_pci doesnt do better
[17:15:31] <SWPadnos> -j
[17:15:35] <cradek> welcome
[17:15:56] <cradek> I should see if I can figure out how to make this happen
[17:15:57] <SWPadnos> so much better than trying to trace the driver and the FPGA in my head :)
[17:16:14] <cradek> maybe turning the spindle very slowly does it?
[17:17:29] <seb_kuzminsky> i've been connecting an hm2 stepgen in quadrature mode to an hm2 encoder, to feed it a repeatable quadrature signal
[17:17:33] <SWPadnos> set spindle speed to ~250 counts/second
[17:17:51] <cradek> seb_kuzminsky: neat idea
[17:18:00] <seb_kuzminsky> pcw's idea :-)
[17:18:28] <cradek> although I wonder if there's some timing thing you might avoid by having them run by a common clock
[17:18:55] <seb_kuzminsky> true, that could be a problem
[17:19:07] <cradek> but you can make the error happen with that setup?
[17:19:12] <seb_kuzminsky> yes
[17:19:18] <cradek> oh ok, good
[17:34:01] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp: fix dreaded "can't break line" warning
[17:36:47] <cradek> I do not understand near // might be the encoder event happened before the tsc rolled over
[17:40:15] <seb_kuzminsky> cradek: one of the cases i was trying to deal with is this timeline:
[17:40:23] <seb_kuzminsky> 1. read the count&time register
[17:40:33] <cradek> and why in the log does count stay the same but timestamp increases? is it dithering around two values?
[17:41:12] <seb_kuzminsky> the log is showing a simulated datapoint because no new datapoint arrived
[17:41:40] <seb_kuzminsky> the simulated datapoint is "one more edge in the same direction", at the time in the tsc register plus rollovers
[17:42:14] <cradek> ok, that's why cur raw_count is prev + 1, I see the made_up stuff
[17:43:04] <cradek> but the made_up should have a rolled over (+ 1<<16) timestamp?
[17:43:53] <seb_kuzminsky> the made_up timestamp is the tsc + zero or more rollovers
[17:44:04] <seb_kuzminsky> line 745 & 746
[17:45:09] <cradek> ok, which is zero in my error case
[17:45:39] <cradek> sorry, you were going to give a timeline, when I kept typing
[17:45:45] <seb_kuzminsky> i have a hunch that num_rollovers is not computed correctly
[17:45:57] <cradek> I have the same hunch
[17:48:03] <seb_kuzminsky> right
[17:48:03] <seb_kuzminsky> so
[17:48:40] <seb_kuzminsky> the driver reads the C&T register, then the encoder edge happens, then the rollover, then the tsc read
[17:48:52] <seb_kuzminsky> the driver will see no movement (since the C&T has the pre-edge value)
[17:49:07] <seb_kuzminsky> it will register a tsc roll-over because the tsc rolled over
[17:49:33] <seb_kuzminsky> next time through the loop it will see the pre-rollover edge.... and think there's one rollover to compensate for
[17:49:54] <seb_kuzminsky> that code on line 718 tries to unhork that situation
[17:50:39] <seb_kuzminsky> possibly that code snippet should be above the enclosing if...
[18:00:58] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/ (pyvcp.lyx pyvcp_fr.lyx): add and fix a few images
[18:03:41] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/hal/images/pyvcp_mypanel.png: add image
[18:04:50] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Submakefile docs.xml index.tmpl): add hardware examples to html
[18:38:20] <BigJohnT> * BigJohnT wanders off to ponder why one is scrambled and one is not... or take a nap which ever one wins
[18:43:14] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/src/hal/drivers/pluto_servo.comp:
[18:43:14] <CIA-2> EMC: find a compromise between scrambled html man page and can't break line...
[18:43:14] <CIA-2> EMC: now it is time for a nap...
[18:50:24] <alex_joni> cradek: cool.. glad to hear that
[18:50:33] <alex_joni> although I must say.. it was an odd change
[18:50:54] <alex_joni> one line in the diff.. I have little confidence why I had to do it that way :/
[18:59:40] <cradek> you're not supposed to say that out loud
[19:00:46] <alex_joni> well.. did I?
[19:00:55] <cradek> yeah, sorry
[19:01:04] <alex_joni> hmm.. damn :D
[19:01:07] <alex_joni> now it's out
[19:01:14] <alex_joni> although I guess the comment would have been a clue
[20:24:16] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/examples/ (pci_parallel_port.lyx mpg.lyx): add file
[20:25:12] <seb_kuzminsky> hi BigJohnT, thanks for the pluto docs cleanup, that's been bugging me ;-)
[20:25:26] <BigJohnT> not as much as it bugged me :)
[20:26:23] <BigJohnT> now there is only a couple of ignoring bogus filenames to clear up :)
[20:26:44] <BigJohnT> btw, I finally ordered my 5i20 and 7i31
[20:27:07] <seb_kuzminsky> then we can tackle the buildsystem linking issues:
http://emc2-buildbot.colorado.edu/buildbot/builders/hardy-x86-trunk-realtime-deb/builds/485/steps/compile/logs/warnings
[20:27:15] <seb_kuzminsky> cool! new toys :-)
[20:28:12] <BigJohnT> wow a zillion shouldn't be's
[20:28:30] <jepler> seb_kuzminsky: you worry too much about warnings
[20:28:35] <jepler> the relaxed programmer lets the warnings flow over him
[20:28:49] <jepler> he bends, but does not break
[20:28:55] <jepler> like a rock and like a blade of grass
[20:28:57] <seb_kuzminsky> it's my frantic nature
[20:29:05] <BigJohnT> like a hickory tree
[20:29:19] <jepler> dpkg-shlibdeps: warning: symbol _Z29GET_EXTERNAL_PROBE_POSITION_Zv used by debian/emc2/usr/lib/librs274.so found in none of the libraries.
[20:29:30] <BigJohnT> but it makes it hard to see the important ones
[20:29:31] <jepler> ^^^ like this one, for instance -- emc is doing something a trifle out of the ordinary with a shared library
[20:29:50] <jepler> and dpkg-shlibdeps can't shut its big fat mouth
[20:30:17] <seb_kuzminsky> it's like a loyal but stupid watchdog, barking at the wind outside...
[20:30:57] <jepler> dpkg-shlibdeps: warning: debian/emc2/usr/lib/libemchal.so.0 shouldn't be linked with libgcc_s.so.1 (it uses none of its symbols).
[20:31:07] <jepler> ^^^ unfortunately, gcc automatically links with libgcc_s, as far as I can tell
[20:31:29] <BigJohnT> seb_kuzminsky: when I plug the 5i20 in and add the hostmot2 is the rest automagical?
[20:31:49] <seb_kuzminsky> BigJohnT: you need to loadrt hostmot2, then loadrt hm2_pci
[20:32:10] <seb_kuzminsky> then curse and spit at hm2_pci's config="blah blah blah" argument
[20:32:20] <seb_kuzminsky> then it'll all work like magic ;-)
[20:32:28] <BigJohnT> LOL
[20:32:33] <jepler> (I have a bit of hate for dpkg-shlibdeps, in case you can't tell)
[20:32:51] <alex_joni> jepler: try lintian one of these days
[20:32:55] <cradek> you could fork your own dpkg-shlibdeps-stfu
[20:33:03] <alex_joni> dpkg-shlibdeps will feel like the best thing ever
[20:33:58] <seb_kuzminsky> BigJohnT: take a look at configs/hm2-servo or hm2-stepper, change the "hm2_7i43" to "hm2_5i20" in all the hal object names, and change the firmware name in the config string, and you might be up and running :-)
[20:34:15] <alex_joni> oh, and then cvs add the new config
[20:34:31] <CIA-2> EMC: 03tissf 07TRUNK * 10emc2/src/po/ (fr.po fr_axis.po fr_rs274_err.po): french translation update
[20:34:54] <seb_kuzminsky> alex_joni: that is still up for debate... there'd be a *lot* of new configs clogging up the configs dir
[20:35:14] <alex_joni> seb_kuzminsky: maybe we can finish the config tree thingie
[20:35:15] <seb_kuzminsky> hm2-{5i20,5i22,5i23,4i65,4i68,7i43}-{servo,stepper}
[20:35:23] <BigJohnT> ok seb_kuzminsky
[20:35:34] <alex_joni> mesa/hostmot/servo/hm2-*.ini
[20:36:48] <seb_kuzminsky> each .ini gets its own entry in the emc config-picker-thingy?
[20:36:51] <seb_kuzminsky> that's handy :-)
[20:38:39] <alex_joni> seb_kuzminsky: yup
[20:40:33] <alex_joni> the HAL files could be pretty generic
[20:40:54] <alex_joni> loadrt [HOSTMOT2]BOARD config="..."
[20:41:13] <alex_joni> and have [HOSTMOT2]BOARD = hm2_5i20 in the ini
[20:41:27] <seb_kuzminsky> alex_joni: does that substitution work for hal object names too?
[20:41:36] <alex_joni> only for complete names afaik
[20:41:47] <alex_joni> not sure you can do [FOO]BAR.baz
[20:42:27] <alex_joni> I think it first gets parsed (whitespace separation), then substituted
[20:44:05] <alex_joni> seb_kuzminsky: ask SWPadnos, he was involved in the design (implementation?) stage
[20:44:12] <alex_joni> probably jmkasunich too ;)
[20:44:23] <seb_kuzminsky> those seem like the likely suspects
[20:45:18] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/ (Master_Integrator.lyx Submakefile docs.xml index.tmpl): add pci parallel port to html
[20:45:42] <jepler> Inifile Variables
[20:45:42] <jepler> Inifile variables are available only when an inifile was specified with the halcmd -i flag. They have the following formats:
[20:45:45] <jepler> [SECTION]VAR followed by end-of-line or whitespace
[20:45:47] <jepler> [SECTION](VAR)
[20:45:58] <jepler> so with [HOSTMOT2](BOARD) it might work
[20:46:04] <seb_kuzminsky> jepler read the manual, that's cheating
[21:02:03] <CIA-2> EMC: 03flo-h 07TRUNK * 10emc2/src/po/ (de.po de_axis.po de_rs274_err.po): updated
[21:11:54] <SWPadnos> you only need the parens if you want to paste the ini value in and you want no whitespace after VAR
[21:16:56] <jepler> SWPadnos: right, as in the case of [HOSTMOT2](BOARD).gpio-0
[21:17:02] <SWPadnos> yes
[21:17:06] <seb_kuzminsky> groovy
[21:18:13] <SWPadnos> or setp [HOSTMOT](BOARD).[HOSTMOT](BOARDNUM).gpio-[EMCIO](SPINDLE_INDEX).is-output = 1
[21:18:15] <SWPadnos> :)
[21:19:26] <cradek> bleh
[21:19:37] <SWPadnos> yeah, but it's there!
[21:20:12] <jepler> I don't care for that style either
[21:20:29] <seb_kuzminsky> it's bulky but i like that it's possible
[21:21:41] <SWPadnos> if halcmd could do for loops and some math, it would be a truly awe-inspriing tool
[21:21:45] <SWPadnos> or useful anyway
[21:23:36] <seb_kuzminsky> can a .ini file include another .ini file?
[21:23:41] <SWPadnos> no
[21:23:42] <seb_kuzminsky> * seb_kuzminsky greps the docs
[21:23:42] <jepler> seb_kuzminsky: no
[21:23:52] <seb_kuzminsky> ok ok guys sheesh calm down
[21:23:55] <SWPadnos> no
[21:23:57] <cradek> NO NO NO
[21:24:01] <jepler> SWPadnos: you can use the awesome power of tcl to execute halcmd commands
[21:24:01] <SWPadnos> no
[21:24:11] <SWPadnos> isn't that an oxymoron?
[21:24:14] <SWPadnos> or two
[21:24:28] <jepler> SWPadnos: it's only 1/10 as shitty as the looping and math you'd make up for halcmd
[21:24:38] <jepler> s/you'd/one would/
[21:24:40] <SWPadnos> I resent that
[21:24:41] <cradek> haha
[21:24:45] <SWPadnos> I think it's 1/8 as shitty
[21:24:46] <cradek> I resemble that
[21:25:22] <jepler> SWPadnos: that's why I s///'d; it wasn't intended to be a callout of you personally
[21:25:37] <SWPadnos> heh
[21:25:50] <SWPadnos> actually, my proposed solution would be to reimplement halcmd in python
[21:25:59] <seb_kuzminsky> * seb_kuzminsky drools
[21:26:01] <SWPadnos> so you'd get eval and the interpreter for "free"-ish
[21:27:51] <cradek> http://www.cs.indiana.edu/scheme-repository/imp/siod.html
[21:28:13] <SWPadnos> * SWPadnos sees the word scheme and avoids clicking
[21:28:32] <cradek> dang, busted
[21:28:58] <seb_kuzminsky> i like that the first section is an appology
[21:38:00] <cradek> argh, my maxvel changes broke rotary velocities
[21:39:11] <alex_joni> seb_kuzminsky: no
[21:39:18] <alex_joni> * alex_joni is a bit slow, but still :)
[21:39:32] <seb_kuzminsky> wait, so can you or can't you????
[21:39:46] <alex_joni> ah RTFM
[21:39:57] <alex_joni> BigJohnT put a lot of effort in it lately
[21:39:58] <alex_joni> :)
[21:40:20] <seb_kuzminsky> http://www.zazzle.com/rtfm_maos_little_red_book_shirt-235940122340353167
[21:40:52] <BigJohnT> you rang?
[21:41:56] <alex_joni> no, your dialup is clogging the line
[21:42:15] <BigJohnT> let me go and shake the ice off the string
[21:43:34] <cradek> * cradek wonders what the maxvel slider (marked in ipm) should do for rotary motion
[21:43:53] <BigJohnT> * BigJohnT thinks nothing
[21:44:00] <SWPadnos> hmmm. there's a second slider for rotary jogging, isn't there?
[21:44:05] <cradek> (not limit it to "ipm" degrees per minute)
[21:44:11] <cradek> SWPadnos: yes
[21:44:20] <cradek> BigJohnT: I think I agree
[21:44:23] <SWPadnos> maybe a second slider for rotary limits then ...
[21:44:39] <cradek> sliders as far as the eye can see
[21:44:48] <BigJohnT> I second a second slider but should it be a dial...
[21:44:56] <cradek> to be complete and consistent you are right
[21:45:00] <cradek> BigJohnT: ??
[21:45:08] <cradek> there's no such thing as a dial, sorry
[21:45:18] <BigJohnT> if it is rotary it should be round
[21:45:23] <BigJohnT> :)
[21:46:00] <cradek> oh good, I thought you were serious
[21:46:32] <BigJohnT> no, I've been off all day and didn't go to work either as I'm iced in
[21:48:45] <cradek> now I wonder what it should do for uvw moves
[21:50:16] <cradek> ... limit them, I guess
[21:50:31] <BigJohnT> seems logical
[21:50:51] <BigJohnT> max_vel in the ini limits them?
[21:55:20] <cradek> if(!(tc->motion_type = TC_LINEAR && tc->coords.line.xyz.tmag_zero && tc->coords.line.uvw.tmag_zero)) {
[21:55:24] <cradek> wow, I'm a new C programmer
[21:55:26] <cradek> holy cow.
[21:55:50] <cradek> what interesting consequences that had
[21:56:50] <BigJohnT> is that different than an old C programmer
[21:57:18] <cradek> yep
[21:57:27] <cradek> only new programmers make obvious dumb mistakes
[21:57:51] <seb_kuzminsky> i'm surprised the compiler didnt complain
[21:57:52] <BigJohnT> old programmers make clever hard to find mistakes?
[21:57:59] <seb_kuzminsky> maybe that's a gcc 4.3 warning...
[21:58:11] <cradek> seb_kuzminsky: it didn't...
[21:59:10] <seb_kuzminsky> i really need to put a newer machine in the build farm
[21:59:13] <CIA-2> EMC: 03cradek 07TRUNK * 10emc2/src/emc/kinematics/tp.c: don't limit rotary axis moves to the gui's maxvel, as though they are in linear units
[21:59:46] <cradek> I'm glad I saw this before 2.3. how embarassing to break rotary axes.
[22:10:15] <BigJohnT> * BigJohnT wishes he had some clever words to put down about important concepts of pid tuning
[22:10:54] <BigJohnT> other than "it must be done"
[22:13:08] <SWPadnos> seb_kuzminsky, did you try to account for multiple rollovers in the hm2 encoder code?
[22:13:14] <SWPadnos> it sort of looks that way
[22:13:48] <jepler> SWPadnos: you mean something like this?
http://pastebin.ca/1319980
[22:14:07] <jepler> (45 minutes ago)
[22:14:11] <cradek> ha
[22:14:43] <SWPadnos> heh
[22:14:47] <SWPadnos> not exactly
[22:14:52] <jepler> oh
[22:14:53] <jepler> too bad
[22:15:00] <jepler> * jepler cvs up -C
[22:15:49] <SWPadnos> more like for i in range 0..71: setp hm2_5i20.0.gpio.%i.is-output 1
[22:15:57] <SWPadnos> (or however that would be spelled)
[22:16:19] <SWPadnos> but I'll take what I can get :)
[22:17:31] <SWPadnos> but from that pastebin, I can see that sim and2 uses 16 bytes of local storage :)
[22:17:50] <SWPadnos> or
[22:17:56] <SWPadnos> or "local" anyway
[22:19:58] <seb_kuzminsky> SWPadnos: well i *tried* to, yes
[22:20:50] <SWPLinux> in what circumstance would you expect to get more than one rollover?
[22:21:22] <seb_kuzminsky> it can happen if the encoder is producing less then one edge per servo period
[22:21:39] <SWPLinux> ah, ok
[22:21:52] <seb_kuzminsky> there's a parameter that says how long to wait for the next edge, that can be longer than one rollover period
[22:21:57] <SWPLinux> yep
[22:22:16] <seb_kuzminsky> oops "less than one edge per rollover-period" above ^^^
[22:22:23] <SWPLinux> that's awfully tricky
[22:22:25] <SWPLinux> yep
[22:22:35] <seb_kuzminsky> 't'aint easy
[22:22:54] <SWPLinux> you may need a per-channel extended counter (rollover count)
[22:23:17] <SWPLinux> or just keep track of rollovers all the time and use 64-bit numbers
[22:24:08] <SWPLinux> 64 bits would last ~5800 years at 100 MHz
[22:24:14] <seb_kuzminsky> the difficulty is that sometimes rollover info comes from the C&T register and sometimes it comes from the TSC register, and sometimes they provide superficially contradictory signals
[22:24:32] <SWPLinux> that's why I asked if all the data gets latched at one time
[22:24:43] <seb_kuzminsky> check out this timeline: read C&T, edge, rollover, read TSC
[22:24:57] <SWPLinux> each encoder channel is read atomically, but you actually need to latch the TSC at the same time, or you don't have a consistent data set
[22:25:09] <seb_kuzminsky> this time through the loop the C&T says no movement, so you rely on the TSC to detect rollover
[22:25:15] <SWPLinux> do it this way: read TSC, read C&T, read TSC again
[22:25:22] <seb_kuzminsky> next tiem through the loop you see the pre-rolled-over C&T register...
[22:25:49] <SWPLinux> you can then always determine if a rollover occurred during a read, and you can tell from one cycle to the last if one happened in the last cycle
[22:25:55] <seb_kuzminsky> i think i just need to spend some quality time with graph paper and write the algorithm right
[22:26:42] <seb_kuzminsky> i dont understand how that helps: the edge can still come between the C&T and the second TSC read, and that's the source of the difficulty
[22:26:48] <SWPLinux> you need to detect rollover during the encoder reads, and one way to do that is to read the TSC at the beginning and at the end of the encoder capture sequence
[22:27:30] <SWPLinux> no, because you can be "more careful" If you see a TSC rollover during the read
[22:28:18] <SWPLinux> actually, all you have to do is if (any_counter<early_TSC_value) that_counter += 65536
[22:28:21] <SWPLinux> I think
[22:29:22] <SWPLinux> the only way for a counter value to be below the TSC read before the encoders is if a rollover+edge happened between the TSC read and the encoder read
[22:30:20] <SWPLinux> (assuming there's a change in the count)
[22:32:11] <seb_kuzminsky> the TSC is only used to detect rollover while waiting for a slow edge
[22:33:10] <seb_kuzminsky> the rollover count (since the previous edge) is added to the new edge's C&T timestamp
[22:34:06] <seb_kuzminsky> the issue here is counting number of rollovers between the previous count and either "now" (from TSC) or the new edge's timestamp (from C&T)
[22:34:19] <seb_kuzminsky> i still dont understand how your algorithm helps with this
[22:34:25] <SWPLinux> me either :)
[22:34:34] <seb_kuzminsky> maybe you or i need more coffee :)
[22:34:39] <SWPLinux> maybe both
[22:34:49] <BigJohnT> I'm having a glass of wine :)
[22:34:57] <SWPLinux> or maybe that was an inclusive or
[22:35:17] <SWPLinux> hmmm. I could add Bailey's to the coffee, but it wouldn't help with algorithm development
[22:35:18] <seb_kuzminsky> you Or I need coffee Xor wine
[22:35:36] <SWPLinux> nokay!
[22:43:07] <alex_joni> hmm.. what's the ini param for spindle/stop on modeswitch again?
[22:50:06] <SWPLinux> all I see is TOOL_CHANGE_WITH_SPINDLE_ON
[22:50:53] <jepler> - if (NULL != (inistring = inifile.Find("SPINDLE_MODE", "EMCIO"))) {
[22:51:07] <jepler> cradek *removed* this recently
[22:51:11] <jepler> Date: Thu Oct 9 02:56:08 2008 +0000
[22:51:11] <jepler> to allow run-from-line to work better, let the user set the spindle
[22:51:11] <jepler> and coolant and TLO how it's needed, using either manual or MDI, and
[22:51:11] <jepler> then don't mess it up when changing modes and resuming the program.
[22:51:35] <jepler> it was added back in Date: Wed Jun 4 18:15:25 2008 +0000
[22:52:22] <alex_joni> ah ok, so it's on by default now
[22:52:31] <jepler> also, git is cool
[22:52:34] <alex_joni> no way to get the old behaviour back.. am I reading it right?
[22:52:41] <seb_kuzminsky> git *is* pretty cool :-)
[22:52:43] <jepler> * jepler was using 'git log -S' to find that
[22:52:49] <jepler> alex_joni: yes I think that's true
[22:52:55] <alex_joni> ok
[22:59:13] <alex_joni> good night all :)
[22:59:20] <seb_kuzminsky> seeya alex :)
[22:59:22] <BigJohnT> good night alex
[22:59:54] <alex_joni> seb_kuzminsky: seen
http://eneas.juve.ro/~juve/stats/ ?
[23:00:43] <seb_kuzminsky> cool :-)
[23:01:12] <seb_kuzminsky> what happened nov 2006?
[23:01:35] <alex_joni> jmkasunich commited some dxf's
[23:01:50] <alex_joni> the count is a bit off, I need to exclude dxf's and other documentation aids
[23:01:57] <seb_kuzminsky> lol, 150KLOC in dxfs :-)
[23:01:58] <alex_joni> eps & co
[23:02:22] <alex_joni> http://eneas.juve.ro/~juve/stats/file_sizes.html
[23:02:29] <alex_joni> 180k actually :D
[23:03:38] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/Integrator_Concepts.lyx: add a bit of info on servos
[23:03:41] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/common/images/pid-feedback.png: add a bit of info on servos
[23:04:59] <CIA-2> EMC: 03bigjohnt 07TRUNK * 10emc2/docs/src/Master_Integrator.lyx: remove ert honking up my side bar
[23:05:19] <BigJohnT> say goodnight Gracie
[23:05:29] <seb_kuzminsky> goodnight Gracie