Back
[02:18:49] <SWPLinux> jepler: excellent!
[02:19:38] <SWPLinux> so I guess I had it half right - it was executing the thread again immediately (and an extra time), but not for the reason I thought
[02:20:24] <jepler> yep
[02:21:17] <jepler> I am a bit surprised that setting the base clock to X counts, then requesting a thread at X-1 counts, wasn't treated as an error by rtapi
[02:22:26] <SWPLinux> well, there was a change to that code recently, to fix the problem with thread ordering at insmod time
[02:23:03] <SWPLinux> did you write a test program to specifically ask for less time than the fastest thread?
[02:23:17] <jepler> no
[02:24:21] <SWPLinux> hmmm. so it automagically decided that 19000 should be 18953, which should then be rounded down to 237 periods instead of 238?
[02:24:22] <jepler> I just changed the latency test to do that, and it has the same behavior as emc did
[02:24:48] <SWPLinux> ok
[02:25:35] <jepler> I think that: nano2count(19000) = 238. count2nano(238) = 19853. nano2count(19853) = 237
[02:44:56] <cradek> does anyone remember how alex said to get the ubuntu kernel source with all the patches still separate?
[02:45:52] <cradek> I thought it was apt-get source linux-source-2.6.xx
[02:49:07] <jepler> good question
[02:49:54] <SWPLinux> it could be apt-get source linux-image.xxx
[02:50:09] <cradek> oh I guess I do get a .diff.gz
[02:50:11] <cradek> duh, sorry
[02:50:30] <SWPLinux> jepler: I got halmodule to compile, but I'm not sure I did the right thing
[02:51:23] <SWPLinux> in the halobject_map (around line 471), the first struct member should be a lenfunc, not an inquiry
[02:51:45] <SWPLinux> but I don't actually know the difference, other than the function return type
[02:52:24] <SWPLinux> also, several of the functions referenced in that struct and the shmbuffer_procs struct had to be changed
[02:54:08] <SWPLinux> I removed "get" from the type name of all those (getreadbufferproc -> readbufferproc), to use the Py_ssize_t version instead of the int version of the definition
[02:56:59] <jepler> the shared memory stuff is basically untested
[02:57:07] <jepler> but it happened to compile for me
[02:57:52] <SWPLinux> ok
[02:58:09] <jepler> I wrote it on one of those days I had resolved to rewrite halscope userspace portion in python
[02:58:16] <jepler> it hasn't gotten very far yet
[02:58:16] <SWPLinux> unfortunately, sim doesn't actually run on this machine yet, but it does compile :)
[02:58:22] <SWPLinux> heh
[02:58:25] <jepler> I'll be happy to hear all about it tomorrow
[02:58:26] <jepler> 'night
[02:58:29] <SWPLinux> night :)
[04:08:37] <cradek> what a surprise - the problem with my keyboard was software
[04:12:12] <cradek> you'd think by 2007 they wouldn't break the ps2 keyboard, but ...
[04:35:47] <jmkasunich> hi cradek
[04:36:41] <Unit41> I have something for you guys soon :)
[04:36:57] <Unit41> round up ur plasma /electronics guru's
[04:37:22] <Unit41> im just uploading the patent cd now
[04:37:28] <cradek> hi
[04:38:13] <cradek> jmkasunich: I gave up trying to fix the noise on the home switch, and just debounced it instead
[04:38:31] <jmkasunich> I thought you fixed it with a cap
[04:38:46] <cradek> I did, but after that I found that while homing (backing off the switch) it would sometimes trigger early
[04:38:55] <cradek> I assume it's a bit dirty
[04:38:59] <jmkasunich> ah
[04:39:17] <cradek> I hope this will make it not fiddly - so far so good
[04:39:42] <jmkasunich> I see jepler figured out what was going on
[04:39:52] <cradek> I guess he fixed it
[04:40:11] <jmkasunich> saw the CIA notice, haven't looked at the commit mail yet
[04:41:41] <cradek> oh more good news - when I clip the radio shack ferrite thing on the end of the spindle power cable, I have no more problems
[04:41:54] <cradek> (which is hard to believe)
[04:42:35] <jmkasunich> noise can be like that sometimes
[04:42:44] <cradek> and, all the usb stuff you helped me choose works
[04:42:50] <jmkasunich> great
[04:43:15] <jmkasunich> pictures-R-u
[04:43:33] <cradek> ?
[04:43:45] <jmkasunich> camera to PC transfers easier now?
[04:43:50] <cradek> oh, yep
[04:43:58] <cradek> don't have to break out the laptop anymore
[04:45:54] <jmkasunich> "Attention: Kasunich, I wish to notify you that late Prof Roger Michael Needham made you a beneficiary to his WILL"
[04:46:07] <jmkasunich> Oh wow, I'm rich!
[04:46:10] <cradek> yay!
[04:46:31] <jmkasunich> Note: You are advised to contact me through my secured email address- uk_legalassociates1@yahoo.co.uk
[04:46:40] <cradek> man I wish I had known Richard Michael John Thomas Roger Needham
[04:46:41] <jmkasunich> yahoo - thats a real secure addy there
[04:47:19] <cradek> you can tell it's from an important lawyer because he says "you are advised to"
[04:47:44] <cradek> only lawyers talk that way
[04:48:25] <jmkasunich> laywers and crooks
[04:48:27] <jmkasunich> except thats redundant
[04:50:01] <jmkasunich> just got home from a great baseball game
[04:50:02] <jmkasunich> http://cleveland.indians.mlb.com/news/gameday_recap.jsp?ymd=20070601&content_id=1998989&vkey=recap&fext=.jsp&c_id=cle
[04:52:06] <cradek> man look at all those words
[04:52:16] <jmkasunich> heh
[04:52:17] <cradek> do they mean one team was behind most of the game, but won in the end?
[04:52:21] <jmkasunich> yes
[04:52:30] <cradek> was that the local team or the visiting team?
[04:52:36] <jmkasunich> the home team
[04:52:47] <jmkasunich> I know you're not a sports fan
[04:52:49] <cradek> that does sound like a fun game then
[04:53:18] <jmkasunich> I'm not really much of one either, but being in a packed stadium when the home team just doesn't give up, and comes from behind at the last minute, is pretty cool
[04:53:43] <jmkasunich> and there were fireworks afterwards
[04:54:38] <cradek> I definitely understand
[04:54:55] <cradek> not my thing, but I can see it
[04:59:59] <cradek> goodnight!
[05:00:30] <jmkasunich> goodnight
[05:40:31] <Unit41> http://rapidshare.com/files/34750684/Plasma.tar.gz.html
[14:21:44] <jepler> rebuilt my rtai 64-bit kernel with SMP .. booted and runs latency test OK
[14:22:13] <cradek> wow
[14:22:37] <cradek> I rebuilt mine with a guess at which patch fixed the keyboard problem - so far so good too
[14:22:35] <jepler> nevermind, it just hung while compiling stuff, no RT loaded
[14:22:40] <cradek> oh
[14:25:17] <jmkasunich> morning
[14:25:38] <jepler> hi jmk
[14:25:51] <jmkasunich> hi
[14:26:03] <jmkasunich> seems you fixed the RT issue
[14:27:47] <jepler> weird -- it is not totally dead, just not responding right
[14:28:10] <jepler> it's printing IDE errors on the console
[14:28:12] <jepler> it responds to
[14:28:18] <jepler> "caps lock" or alt-f2 quickly
[14:28:46] <jepler> but most of the time it is unresponsive to other keypresses
[14:30:39] <jepler> jmkasunich: I would really appreciate if you review my changes to rtai_rtapi.c since they will affect all our real users...
[14:31:07] <jmkasunich> I'll take a look
[14:37:53] <jepler> jmkasunich: incidentally I got the same Dead Professor spam you mentioned last night
[14:38:20] <jmkasunich> we must have both been great friends of the prof
[14:42:06] <jepler> *sniff* I miss him now that he's gone
[14:42:47] <jmkasunich> you better be carefull at the workshop
[14:43:05] <jepler> why's that?
[14:43:10] <jmkasunich> this might be one of those stories where all the people in the will try to kill each other off to get a bigger share
[14:43:18] <jepler> hah
[14:44:30] <jmkasunich> I bet cradek got one too, and he's just being quiet about it
[14:48:45] <jepler> yeah could be
[14:54:07] <jepler> * jepler hooks up the 7i31 board to his mesa
[14:54:22] <jepler> are all the lights supposed to come on? I guess maybe those are pull-up resistor networks next to the connectors on the mesa..
[14:54:43] <jmkasunich> yeah, the lights come on when the outputs are disabled (no config loaded)
[15:09:59] <jepler> now I'm running m5i20
[15:10:09] <jmkasunich> cool
[15:10:11] <jepler> I notice that the DAC "direction" outputs change even when the corresponding dac "enable" is FALSE
[15:10:22] <jmkasunich> hmm
[15:11:06] <jmkasunich> not sure that bothers me
[15:11:12] <jepler> e.g., the LEDs corresponding to pins 17, 19, 39, 41 blink
[15:11:46] <jmkasunich> although if I was designing a DAC, I wouldn't be using a direction bit, I'd be using two PWM bits
[15:12:31] <jmkasunich> I haven't studied the 7i33 board to see how they convert PWM into +/-10V yet
[15:13:06] <jmkasunich> if they are using direction, it must be "filter PWM to DC, then run thru an amp that can invert it using analog switches driven by DIR"
[15:13:46] <jepler> I don't know either
[15:14:24] <jepler> for l298 the most natural thing was up/down
[15:15:02] <jepler> for another low-current h-bridge, you would use pwm+direction: set current with PWM duty cycle, set bridge configuration with direction
[15:20:20] <jmkasunich> once I get thru the infrastructure issues, I'm gonna write a 5i20 pwmgen based on the existing one, but that provides the same 3 output options that the software stepgen does
[15:20:34] <jmkasunich> (single unipolar PWM, PWM+DIR, and UP+DOWN)
[15:28:17] <jepler> I'm suppose this is obvious to you, but once you have up+down plus signal polarity selection, you can get PWM+DIR purely in the hal driver, no additional VHDL
[15:28:38] <jepler> as well as unipolar PWM of course
[15:29:25] <jepler> do you have enough gates on the mesa for all the stuff you want to do, or is it feeling cramped yet?
[15:38:05] <jmkasunich> no crampage
[15:38:16] <jmkasunich> regarding mode selection - can't do that in hal
[15:38:44] <jmkasunich> the whole point of HW pwmgen is that its too fast to handle in SW
[15:38:58] <jmkasunich> so the dir, etc logic also needs to be in hw
[15:40:10] <jmkasunich> it only takes a few gates though
[15:40:14] <Unit41> how do you use find to find all the jpg's in a dir ?
[15:40:20] <Unit41> find -name .JPG ?
[15:40:29] <jmkasunich> find . -name "*.jpg"
[15:40:32] <Unit41> thx
[15:41:03] <jmkasunich> not sure the first dot is strictly needed, it might default to the current dir
[15:41:16] <jmkasunich> the quotes are needed, otherwise bash expands the *.jpg
[15:41:29] <jepler> Unit41: in the manpage for find, read down to the section "NON-BUGS" if you tried something that seemed obvious to you but got the error 'find: paths must precede expression'
[15:42:01] <jmkasunich> jepler: I've read over the changes to rtapi, they seem sound to me
[15:44:41] <jmkasunich> man find is one of those manpages that result in people asking questions on IRC
[15:45:05] <jmkasunich> find can do a bazillion things, most users want to do one thing
[15:45:50] <jepler> jmkasunich: thanks for reviewing them
[15:46:01] <jmkasunich> np
[15:46:10] <jepler> * jepler notices that the last axis patchset before the move into emc2 was #666:
http://axis.unpy.net/index.cgi/downloads/nightly/changelog
[15:46:16] <jmkasunich> heh
[15:47:25] <jmkasunich> * jmkasunich finds it amusing that the best examples for building Py/Tkinter GUI stuff are on a java site:
http://www.java2s.com/Code/Python/GUI-Tk/CatalogGUI-Tk.htm
[15:47:34] <jmkasunich> (best ones I've found so far anyway)
[16:00:23] <Unit41> http://rapidshare.com/files/34838362/PlasmaHead.tar.gz.html
[16:14:57] <jmkasunich> gripe: one would not guess that "state=NORMAL" is the inverse of "state=DISABLED"
[16:28:30] <Unit41> burn it up, it would take you higher.. common now feal the heat or feal the fire..
[17:23:51] <jmkasunich> jepler: around?
[17:24:32] <jmkasunich> after scratching my head a bit, I figured out the difference between "import tkMessageBox", and "from tkMessageBox import *"
[17:24:59] <jmkasunich> one means that you invoke things like this "tkMessageBox.askyesno", the other means you use "askyesno"
[17:25:13] <jmkasunich> how do you decide which to use?
[17:25:26] <jmkasunich> seems the latter might lead to namespace clashes
[17:25:32] <jmkasunich> the former needs more typing
[18:02:28] <cradek> I think those are exactly the issues
[18:24:08] <jmkasunich> so you just pick one and stick with it?
[18:31:09] <SWPadnos> I suspect you'd use whichever seems more appropriate for each library/package
[18:31:32] <SWPadnos> one way to decide is to see how many of the functions you need from the library, and also how many times you use them
[18:32:00] <SWPadnos> if you only need 3 functions from a library containing 300, the blahblah.* method is probably not the best
[18:32:05] <jmkasunich> hard to say, I'm just getting started
[18:32:18] <jmkasunich> huh>
[18:32:35] <jmkasunich> seems that import foo would be good, if you don't want to pollute the namespace
[18:32:42] <SWPadnos> right
[18:32:50] <jmkasunich> then you invoke the ones you want with foo.bar
[18:33:12] <jmkasunich> from foo import * would be bad - 300 names in the namespace
[18:33:17] <jmkasunich> from foo inport bar would be Ok
[18:33:23] <SWPadnos> I'd say that import foo.bar is preferred for the namespace reasons, but in some cases you're justified in importing foo.*
[18:33:42] <jmkasunich> there is no import foo.bar (at least I don't think so)
[18:33:51] <jmkasunich> thats why you're confusign me
[18:33:53] <SWPadnos> well, from foo import bar
[18:33:56] <jmkasunich> ok
[18:34:15] <SWPadnos> that's best, until it gets unweildy enough to annoy you ;)
[18:34:19] <jmkasunich> I'm leaning toward import foo
[18:34:35] <jmkasunich> and typing foo.bar where I use bar
[18:34:50] <jmkasunich> thats clearer, for newbies like me who might forget where bar came from
[18:34:58] <SWPadnos> exactly
[18:35:14] <jmkasunich> that is NOT "from foo import bar"
[18:35:16] <SWPadnos> less polluted namespace, explicit description of where the function cones from
[18:35:20] <SWPadnos> ok
[18:35:41] <SWPadnos> that would only get access to the "foo.bar" function (called as bar), right?
[18:35:46] <jmkasunich> right
[18:36:06] <jmkasunich> from foo import * gets you access to all, called without the foo (pollution)
[18:36:07] <SWPadnos> ok. I don't know python, so this is my generalist view here
[18:36:17] <jmkasunich> import foo gets you access to all, called with the prefix
[18:38:25] <jmkasunich> if you haven't figured it out, I'm taking a stab at the GUI "fpga config tweaker" tool
[18:39:06] <SWPadnos> great!
[18:39:43] <jmkasunich> got the pre- and post-processors working
[18:39:55] <jmkasunich> although the pre-processor will need some work to support this new tool
[18:40:14] <jmkasunich> I'm trying to decide how to present things to the user
[18:40:20] <SWPadnos> ok. I never got the chance to look over those pastebins you - err - pasted
[18:40:33] <jmkasunich> they're in CVS now
[18:40:39] <SWPadnos> cool.
[18:40:44] <jmkasunich> spec2vhdl, and bit2fpga
[18:41:02] <SWPadnos> I'm trying to get a robot platform to work before leaving for Fest, in addition to possibly cleaning some of the 342 tons of junk in my office
[18:41:10] <SWPadnos> yep, I saw the commits
[18:41:17] <jmkasunich> busy busy
[18:41:23] <SWPadnos> yeah
[18:41:26] <jmkasunich> I'm trying to get fpga stuff to work before fest
[18:41:30] <SWPadnos> and not reallythe fun kind at the moment
[18:41:36] <SWPadnos> cool
[18:42:09] <jmkasunich> are you taking a break from 324 tons of junk right now, or am I distracting you from something you should be doing?
[18:42:21] <SWPadnos> well, I'm easily distracted ;)
[18:42:23] <jmkasunich> lol
[18:42:40] <jmkasunich> can I bounce some things off of you, or do you need to get back to work?
[18:42:53] <SWPadnos> I'm sure that the moment I start cleaning (or roboticizing), my wife will come in and want me to go on a bike ride or start gardening or something
[18:42:59] <SWPadnos> bounce away
[18:43:17] <jmkasunich> ok - the fpga editor app will have the usual file->open, save, save-as, etc
[18:43:37] <jmkasunich> when I open it, I don't want the traditional text in a window document view
[18:43:43] <jmkasunich> cause its not text
[18:44:06] <jmkasunich> its basically a bunch of modules, each of which has a bunch of varaible/value pairs
[18:44:11] <SWPadnos> "it" being an existing config?
[18:44:13] <jmkasunich> yes
[18:44:13] <SWPadnos> ah, ok
[18:44:21] <SWPadnos> are these going to be in ini format?
[18:44:29] <jmkasunich> not at this stage
[18:44:40] <SWPadnos> just "foo=bar"
[18:44:46] <SWPadnos> ?
[18:45:05] <jmkasunich> so far, I have two chunks with the data, one is the var/value pairs, the other is a template that lets me convert them to a stream of bytes for the ram
[18:45:28] <jmkasunich> both are stored in bitfile chunks, in an easily parsable format (basically, the python repr() format)
[18:45:52] <jmkasunich> I will be adding another chunk with info about each variable
[18:46:03] <jmkasunich> allowable values, a prompt string, etc
[18:46:23] <jmkasunich> I'll probably have several variations on that, enum, range, etc
[18:46:56] <jmkasunich> so when I open the file, I want to display the var/value pairs, sorted by module
[18:47:08] <SWPadnos> with the other options presentsd in a logical way ...
[18:47:20] <jmkasunich> other options?
[18:47:46] <SWPadnos> ie, one of an enum is selected, you want a drop-down with all the enum values in it, with the current one selected
[18:47:55] <jmkasunich> right
[18:48:16] <jmkasunich> that is the presentation format for an "enum" var - current value, + dropdown
[18:48:56] <jmkasunich> oh, and a label of some sort identifying what question the enum is answering. likewise a "binary" var would be a checkbox + a label
[18:49:02] <SWPadnos> right. or a spinedit for a range, checkbox for a boolean ...
[18:49:07] <SWPadnos> right
[18:49:33] <jmkasunich> the fun part is going to be the overall presentation
[18:49:54] <jmkasunich> the list is gonna be very long, so the main window needs to be scrollable
[18:50:07] <jmkasunich> I have to figure out how to put widgets in a very large window and then scroll it
[18:50:15] <SWPadnos> well, I can't help you there :)
[18:50:17] <jmkasunich> "canvas" maybe - gotta STFW
[18:50:34] <SWPadnos> tk and python (and gtk) are things I know nearly nothing about
[18:50:39] <jmkasunich> understood
[18:50:50] <jmkasunich> assuming I figure out the how, the real question is what
[18:51:14] <jmkasunich> a tree-ish view might be nice - collapse a module, or expand it to see all the choices inside it
[18:51:34] <SWPadnos> is there a reasonable structure to the data, or is it flat? (ie, do you have stepgens with some vars, then pwms with some vars ..., or is it one big list)
[18:51:39] <SWPadnos> yep - I was thinking a tree would be good
[18:51:53] <jmkasunich> its one big list, as stored, but the naming convention lets me split it by module
[18:51:57] <SWPadnos> ok
[18:52:19] <SWPadnos> think similar to halshow, where you have a tree for the modules, and a right hand pane for the list of values
[18:52:28] <jmkasunich> technically its a python dictionary, so I can do stuff[varname] = value
[18:52:50] <SWPadnos> but I'd only show values valid for the currently selected node, not all subnodes that also match
[18:52:50] <SWPadnos> ok
[18:52:58] <jmkasunich> hmm, I wasn't thinking of two panes, but maybe thats a good idea
[18:53:10] <jmkasunich> still might have to scroll the right pane, but much less often
[18:53:44] <SWPadnos> and the left, but that should be taken care of by the tree widget
[18:54:23] <jmkasunich> I was originally thinking of single pane, with the tree in it, and when you expand a node, the various listboxes, checkboxes, etc appear right there
[18:55:10] <SWPadnos> I suspect that's not too easy to do, based on the little experience I have with tree widgets
[18:55:11] <jmkasunich> you could leave any node expanded or not, and scroll the whole thing up and down
[18:55:28] <jmkasunich> yeah, I have next to no experience with tree widgets
[18:55:33] <SWPadnos> I think they like to be lists rather than active controls, unless you want to get into customization
[18:55:42] <jmkasunich> I want to keep it simple
[18:56:35] <jmkasunich> the tree is kind of flat
[18:56:45] <jmkasunich> I have module type and module number, thats it
[18:56:48] <jmkasunich> no arbitrary nesting
[18:56:56] <jmkasunich> I wonder if a tree is even the right choice
[18:57:06] <SWPadnos> it may not be. a list may be better
[18:57:47] <jmkasunich> I think pin drivers may want to be treated differently - thats really flat - 72 items at one level
[18:57:58] <jmkasunich> maybe pins are a tab, and modules are another tab
[18:58:34] <SWPadnos> does the kind of configuration you have keeps the pin function settings separate from other modules?
[18:59:00] <SWPadnos> ie, if you want to use a stepgen with geckos, and need the OC output, is that done in the stepgen or in the pin (or both) config?
[19:04:10] <jmkasunich> OC is a pin driver attribute
[19:04:15] <jmkasunich> as is invert
[19:04:43] <jmkasunich> one of the "types" (enum, binary, etc) will be "pin"
[19:05:26] <jmkasunich> so stepgen__1__step_up_phaseA will be a variable of type "pin", between 0 and 71
[19:06:02] <jmkasunich> that particular variable is set when the fpga is routed, so it will not be changable in the editor
[19:06:05] <jmkasunich> but it will be displayed
[19:06:31] <jmkasunich> hopefully as a "hyperlink" of sorts that can take you to the pin where you would set OC, invert, source, etc
[19:06:31] <SWPadnos> ah, so this is the user config tool :)
[19:06:33] <jmkasunich> yes
[19:06:53] <Unit41> I love you guys, I dont really listen to what you say but I know something usefull is being done infront of me
[19:07:38] <Unit41> most channels nowdays just spew out chit chat
[19:07:51] <Unit41> or part/join msgs
[19:08:03] <jmkasunich> we have #emc for that ;-)
[19:08:17] <SWPadnos> this is a developer channel, so we usually stay more or less on-topic :)
[19:10:55] <jmkasunich> right now my problem is going from the abstract to the concrete - I need to start somewhere
[19:11:10] <jmkasunich> I have a file menu, with open, save, etc entries
[19:11:20] <jmkasunich> the code behind them is skeletal at best
[19:11:51] <jmkasunich> the obstacle to fleshing it out is that "open" means "display in the main menu for editing"
[19:12:00] <SWPadnos> right
[19:12:02] <jmkasunich> and thats a big thing
[19:12:16] <SWPadnos> I'm not sure I know enough about the available libraries to be able to tell you much
[19:12:36] <jmkasunich> I'm trying to figure out "what" I want to do, as much as how to do it
[19:12:42] <jmkasunich> google is my friend for the how
[19:12:49] <SWPadnos> my approach would be to make something that can display at least the item names first, and organize it so that it uses a display function that's different for each data type
[19:13:33] <jmkasunich> there is also some status that is global to the entire FPGA, like "something has been changed, prompt for save before close"
[19:13:35] <SWPadnos> in fact, it may be good to make each data type a python class with read, write, display, and edit functions
[19:13:45] <jmkasunich> so I have a hunch the fpga should be a class
[19:14:02] <jmkasunich> yes, I agree
[19:14:12] <SWPadnos> then when an new class is added, you provide the same functions in the new name, and it should more or less automagically work
[19:14:21] <SWPadnos> think like pyvcp with the "update" function in each class
[19:14:25] <jmkasunich> each item type needs a class, and a representation in the file
[19:14:50] <jmkasunich> maybe thats part of the problem, I need to go bottom up for a bit
[19:15:31] <SWPadnos> right - make sure you can take some text (even if it's hard-coded in the program) and display it
[19:15:35] <SWPadnos> then add editing
[19:15:45] <SWPadnos> then add the "wrapper" that actually supplies the data
[19:15:51] <SWPadnos> (from the file)
[19:16:10] <jmkasunich> right now, I have a sample module spec stepgen.mspec
[19:16:17] <SWPadnos> this may make no sense for python programming, but it's how I'd approach it, as a novice python programmer ;)
[19:16:30] <jmkasunich> an enum var looks like: ctrl_type : 1 ! { "velocity":0, "position":1 } ! "position or velocity control mode?"
[19:17:05] <jmkasunich> the ! are dividers - when py initially parses it, everything after the 1st colon is a string that is associated with "ctrl_type"
[19:17:25] <SWPadnos> and python automatically parses that as "default "ctrl_type" to 1, with options 0 and 1 corecponding to "velocity" and "position" ...
[19:17:30] <jmkasunich> the 1 is the default, I already (in the pre-processor) pull that out and use it
[19:17:35] <SWPadnos> ah, ok
[19:18:09] <jmkasunich> the part in {} is a python dictionary, so it can be eval()'ed to set the enum up
[19:18:09] <SWPadnos> so ctrl_type[0] is the {}-bracketed thing, which can be passed off to something else as a list
[19:18:14] <SWPadnos> ok
[19:18:34] <SWPadnos> and ctrl_type[1] is the question string
[19:18:40] <jmkasunich> not yet
[19:18:54] <SWPadnos> and if you added another section with """, that could be a longer description
[19:19:42] <jmkasunich> the module spec is only read by the pre-processor
[19:19:42] <SWPadnos> I think I have the indices off by 1 - [0] would be the default, [1] is the dict, [2] is the question string
[19:19:57] <jmkasunich> not yet ;-)
[19:19:59] <SWPadnos> heh
[19:20:19] <jmkasunich> right now, "ctrl_type" is the key, and the entire remainder is the value
[19:20:21] <SWPadnos> with some more {}, you could make the wholse thing into a dictionary
[19:20:23] <SWPadnos> right
[19:20:52] <jmkasunich> the format of the "entire remainder" will be type dependent
[19:20:57] <jmkasunich> all will start with default
[19:21:15] <jmkasunich> followed by a type (enum, binary, pin, etc), not there yet
[19:21:18] <jmkasunich> then the type specific stuff
[19:21:28] <jmkasunich> like the dictionary of choices and the string for the question
[19:22:10] <SWPadnos> something like {"ctrl_type":{"default":1, "options":{"velocity":0, "position":1},"question":"position or velocity control mode?"}}
[19:22:26] <jmkasunich> oh...
[19:22:28] <jmkasunich> interesting
[19:22:44] <SWPadnos> then ctrl_type["options" is a dictionary
[19:22:48] <SWPadnos> then ctrl_type["options"] is a dictionary
[19:23:12] <SWPadnos> I think - I may have the synatax wrong, and the parsing may not be automatic
[19:23:23] <jmkasunich> I have to try that out, I'm not sure either
[19:23:43] <jmkasunich> I'm almost certain that the parsing will only be semi-automatic - they don't nest automatically
[19:23:59] <SWPadnos> ok
[19:24:24] <SWPadnos> but you can always parse(ctrl_type["options"])
[19:24:33] <SWPadnos> (or whatever the function name is)
[19:25:27] <SWPadnos> hey - it does work
[19:25:39] <SWPadnos> I just did a little test in the python gui
[19:25:50] <jmkasunich> you type faster than I do
[19:26:16] <SWPadnos> >>> fred={"ctrl_type":{"default":1, "options":{"velocity":0, "position":1},"question":"position or velocity control mode?"}}
[19:26:18] <SWPadnos> >>> print fred
[19:26:19] <SWPadnos> {'ctrl_type': {'default': 1, 'question': 'position or velocity control mode?', 'options': {'velocity': 0, 'position': 1}}}
[19:26:23] <SWPadnos> >>> print fred['ctrl_type']
[19:26:24] <SWPadnos> {'default': 1, 'question': 'position or velocity control mode?', 'options': {'velocity': 0, 'position': 1}}
[19:26:24] <SWPadnos> >>> print fred['ctrl_type']['default']
[19:26:27] <SWPadnos> 1
[19:26:28] <SWPadnos> >>>
[19:26:30] <SWPadnos> copy/paste ;)
[19:27:18] <SWPadnos> >>> print fred['ctrl_type']['options']['velocity']
[19:27:20] <SWPadnos> 0
[19:27:50] <jmkasunich> neato
[19:28:01] <SWPadnos> so you can even stick the addresses/formulas in there as well
[19:28:20] <SWPadnos> with different subscripts ["address"]
[19:28:58] <SWPadnos> so the file reader/writer would probably need to format/unformat things for human readability
[19:29:15] <SWPadnos> and you'll want to pick some standard (and preferably short) names for the various data items
[19:29:19] <jmkasunich> which file reader/writer?
[19:29:24] <SWPadnos> the config file
[19:29:38] <jmkasunich> you mean the pre-processor?
[19:29:46] <jmkasunich> (thats what reads the module specs)
[19:29:58] <SWPadnos> since python is indentation-sensitive, I'm not sure you can format things for human readability
[19:30:18] <jmkasunich> the module spec isn't quite that pythony
[19:30:27] <jmkasunich> its actually in inifile format
[19:30:44] <SWPadnos> yeah, I guess the pre-processor will write this file first, but if you want people to bne able to read it, there may need to be simple shim functions for read/write
[19:30:46] <SWPadnos> oh, ok
[19:32:23] <jmkasunich> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/src/hal/drivers/mesa_5i2x/firmware/stepgen.mspec?annotate=1.2
[19:32:46] <jmkasunich> line 11 is an example
[19:33:03] <jmkasunich> I think all I need to do is put { after the first :, and } at the very end
[19:33:11] <jmkasunich> oh, not quite
[19:33:23] <SWPadnos> right - the ! aren't meaningful to python
[19:33:27] <SWPadnos> AFAIK
[19:34:01] <SWPadnos> enable : { D:1, O:{ "no":0, "yes":1 }, Q: "enable step generator $INSTANCE?"}
[19:34:10] <jmkasunich> enable : { "default":1, "type":binary", "question": "enable step generator $INSTANCE?"}
[19:34:23] <SWPadnos> heh - I pre-optimized the names ;)
[19:34:37] <SWPadnos> right, its a binary, not an enum
[19:35:04] <jmkasunich> ctrl_type : { "default":1, "type":"enum", "options":{ "velocity":0, "position":1 }, "question": "position or velocity control mode?" }
[19:35:46] <jmkasunich> the parser will take the next step, making a dictionary with keys "enable", "ctrl_type", etc
[19:36:27] <jmkasunich> then I can use the expressions that you were using: master_dict["ctrl_type"]["options"][0]
[19:36:42] <jmkasunich> oops
[19:36:44] <SWPadnos> ctrl_type : { "default":1, "type":"enum", "options":{ "velocity":0, "position":1 }, "question": "position or velocity control mode?", "description":"Selects between velocity control mode and position control mode. In vel mode, this acts like freqgen ......", "addr":0x340, "bitshift":4}
[19:36:50] <jmkasunich> then I can use the expressions that you were using: master_dict["ctrl_type"]["options"]["position"]
[19:37:11] <SWPadnos> yep
[19:37:23] <jmkasunich> I don't want the address stuff in there
[19:37:44] <SWPadnos> it seems it should be there, even if it isn't presented to the user
[19:37:51] <jmkasunich> the actual address for a given instance depends on how its mapped into the FPGA, and what other instances there are
[19:37:56] <SWPadnos> it makes the parser more generic, I think
[19:38:13] <jmkasunich> ctrl type may not even be an FPGA register, it may only be info for the HAL driver
[19:38:23] <SWPadnos> ah, ok. if there needs to be some math, then the parser gets less generic
[19:38:27] <Unit41> HAL:73: ERROR: pin 'iocontrol.0.user-enable-out' not found
[19:38:27] <Unit41> HAL config file /home/gringos/emc2.1.5/configs/sim/core_sim.hal failed.
[19:38:27] <Unit41> Shutting down and cleaning up EMC2...
[19:38:46] <Unit41> its compiling alot better now though
[19:39:06] <jmkasunich> Unit41: that means line 73 (+/-1) of the specified HAL file is asking for a pin that doesn't exist
[19:39:19] <Unit41> its on simulation mode though
[19:39:32] <jmkasunich> go to that hal file, and one line before that line, add "show pin iocontrol"
[19:39:45] <jmkasunich> then when you try to run it, it will display all the iocontrol pins
[19:39:56] <SWPadnos> iocontrol.0.user-enable-out does exist in a sim run here
[19:40:21] <Unit41> <- 64 bit
[19:40:27] <jmkasunich> maybe iocontrol isn't loaded yet at the point where he's trying to connect to it?
[19:40:32] <Unit41> I get odd problems sometimes
[19:40:33] <SWPadnos> but if the connection is attempted before motion (?) is loaded, then the connection will fail
[19:40:34] <jmkasunich> put that show line in there
[19:40:34] <SWPadnos> 64-bit here as well
[19:40:38] <jmkasunich> or maybe a "show comp" line
[19:44:17] <jmkasunich> back to variables...
[19:44:22] <SWPadnos> ya
[19:44:26] <jmkasunich> the idea is, each of these entries just defines a variable
[19:44:33] <jmkasunich> its usage is defined elsewhere
[19:44:38] <SWPadnos> (the wife just got off the phone - I"m not sure how much longer I have :) )
[19:44:47] <jmkasunich> it can be substituted into a VHDL template, a config RAM template, etc
[19:45:40] <jmkasunich> for instance line 49 packs ctrl_type and other info into a config ram byte
[19:45:53] <SWPadnos> yep
[19:46:27] <jmkasunich> module instance chip selects and base address are determined based on the constant "num_regs" at the top of the module spec
[19:47:18] <jmkasunich> the preprocessor creates all instances, then packs them into the address space, generates the select logic, and sets variable "baseaddr"
[19:47:32] <Unit41> its not working
[19:47:39] <jmkasunich> whats not?
[19:47:42] <Unit41> "show comp"
[19:47:56] <Unit41> show comp
[19:47:56] <Unit41> linkpp iocontrol.0.user-enable-out iocontrol.0.emc-enable-in
[19:47:56] <jmkasunich> the suggestions I made won't fix the problem, they will give you information
[19:48:08] <jmkasunich> don't use linkpp
[19:48:15] <Unit41> ok
[19:48:30] <jmkasunich> did the show command produce any output?
[19:48:29] <Unit41> # estop loopback
[19:48:53] <Unit41> Can not find -sec HAL -var HALUI -num 1
[19:49:19] <jmkasunich> thats not from show
[19:49:45] <jmkasunich> you are running in a terminal, right?
[19:49:57] <Unit41> 32774 RT or2 ready
[19:49:57] <Unit41> 05956 User halcmd5956 5956 ready
[19:49:57] <Unit41> 32773 RT comp ready
[19:49:57] <Unit41> 32772 RT hypot ready
[19:49:57] <Unit41> 32771 RT ddt ready
[19:49:59] <Unit41> 32770 RT motmod ready
[19:49:59] <Unit41> 32769 RT trivkins ready
[19:50:06] <SWPadnos> that error points to an incorrectly set up environment
[19:50:22] <Unit41> im running suse
[19:50:28] <SWPadnos> or a version mismatch in the ini file (ie, an old ini wnd a new emc)
[19:50:33] <SWPadnos> s/wnd/and/
[19:50:41] <jmkasunich> SWPadnos: what are you talking about?
[19:51:10] <SWPadnos> I think this "Can not find -sec HAL -var HALUI -num 1" happens when the ini file isn't passed to halcmd
[19:51:21] <jmkasunich> Unit41: the reason you can't connect to iocontrol pins is because component iocontrol isn't loaded
[19:51:26] <SWPadnos> which I guess had nothing to do with version mismatches, so disregard that :)
[19:51:27] <jmkasunich> thats what show comp tells you
[19:51:50] <jmkasunich> SWPadnos: I think that line is routine actually
[19:52:11] <SWPadnos> I don't get it here
[19:52:15] <SWPadnos> using sim/mini
[19:52:30] <jmkasunich> I could also be wrong
[19:52:33] <SWPadnos> I can't run sim/axis for a different reason
[19:53:05] <jmkasunich> it its coming from hal, its because some HAL file is trying to do inivar substitution using the varable [HAL]HALUI
[19:53:12] <SWPadnos> I think that's from inifind, when it isn't given the right ini file
[19:53:14] <jmkasunich> which I seriously doubt is the case
[19:53:28] <SWPadnos> sorry - it's the runscript I guess
[19:53:29] <jmkasunich> its from inifind, when it can't find the requested item
[19:53:39] <jmkasunich> the runscript invokes inifind ;-)
[19:53:48] <Unit41> how do I --with-realtime=<path>
[19:54:01] <jmkasunich> but regardless, that line has absolutely nothing to do with Unit41's problems, as far as I can tell
[19:54:14] <jmkasunich> Unit41: just like that
[19:54:38] <jmkasunich> ./configure --with-realtime=<path-to-your-rtai-stuff>
[19:54:50] <Unit41> im not sure where that is
[19:55:01] <jmkasunich> well I sure don't know
[19:55:25] <jmkasunich> you build the RTAI patched kernel, you need to know where that stuff is
[19:57:03] <jmkasunich> SWPadnos: I'm changing my sample module specs over to the new notation, gotta change preprocessor to match
[19:57:11] <SWPadnos> ok
[19:57:16] <jmkasunich> thanks for the discussion, it helped a lot
[19:57:22] <SWPadnos> sure
[19:57:40] <SWPadnos> I guess I should get cleaning now - I Hear the vacuum getting closer ;)
[20:09:37] <jmkasunich> rip, tear, shred, revise, revise
[20:12:07] <jmkasunich> module specs will now have only two sections: [symbols] and [templates]
[20:12:25] <jmkasunich> the old constants, pins, pre_vhdl_vars, and post_vhdl_vars will all be symbols
[20:12:41] <jmkasunich> "constant" and "pin" are just two more types, like enum, etc
[20:12:58] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/scroll.py
[20:13:18] <jepler> jmkasunich: ^^^ python program showing how to get a scrolled area a little bit like what you were talking about earlier
[20:13:28] <jmkasunich> cool, thanks
[20:13:43] <jmkasunich> I can fill it with widgets?
[20:13:55] <jepler> yes
[20:14:05] <jepler> the example puts a grid of labels and entries in it
[20:14:07] <jmkasunich> I see now, the i in range 20 loop
[20:14:17] <jepler> when you close the window, it prints out the value stored in all the entries, which should be integers
[20:15:52] <jmkasunich> the three container and three frame lines create the basic scrolled window, and the stuff between vars=[] and app.mainloop() populates it, right?
[20:16:18] <jepler> yes
[20:16:29] <jmkasunich> can I populate it from within a call back function, or must it be done before entering the main loop?
[20:16:41] <jepler> you can create and destroy widgets any time you like
[20:16:44] <jmkasunich> file->open will want to populated it based on the file contents
[20:16:58] <jmkasunich> ok, that was the next question, how to destroy (on file->close)
[20:17:11] <jepler> widgets have a "destroy" method
[20:17:31] <jepler> when you destroy a parent widget, its children are destroyed as well
[20:17:31] <jmkasunich> ok, so I just need to keep the widgets in a list or something so I don't lose track of them
[20:19:12] <jmkasunich> or I could just invoke frame.destroy? then start again at frame=contents.getframe() ?
[20:20:12] <jmkasunich> I'll experiment when I get to that point
[20:20:34] <jepler> no, I think that if you destroy that frame, the 'contents' widget has become useless
[20:20:45] <jmkasunich> oh
[20:20:56] <jepler> getframe() is not "create a new frame and return it" -- it's "return the one frame that was created with the 'contents' widget"
[20:21:14] <jmkasunich> my main window is gonna have the usuall menu bar, and then a workspace below - typical single document interface
[20:21:37] <jmkasunich> I don't want the workspace to vanish and the main window to shrink when I close a file, I just want it to go blank
[20:22:21] <jmkasunich> duh
[20:22:56] <jmkasunich> does that mean "container" is my "work window", and I can destroy contents on file->close?
[20:23:04] <jmkasunich> I guess I can try that and see what happens
[20:24:23] <jepler> if you want to set your application's size, use something like: app.grid_propagate(0); app.configure(width=400, height=300)
[20:25:02] <jmkasunich> I was just realizing that the sample I copied does have a work window, but that it was defaulting to zero size since it had no contents
[20:25:32] <jepler> by default, Tk determines the size of a widget by computing the size of its contents (except for widgets that don't contain things like labels which do not contain other widgets -- their size is found by looking at e.g., the characters to be displayed)
[20:25:45] <jmkasunich> which is still contents ;-)
[20:25:50] <jepler> setting "propagate" to 0 means that the widget's own size is used, and then the children are made to fit within that area
[20:25:57] <jepler> the names I chose for those variables might not be very good
[20:26:12] <jepler> you will put everything you want inside the scrolling area in the thing I called 'frame'
[20:26:35] <jepler> you can create other children of 'app' and grid them; they'll appear outside the scrolled area
[20:26:41] <jmkasunich> this sample has mBar = Frame(app, .... and work_area = Frame(app, ....
[20:27:04] <jmkasunich> I had been ignoring work_area (in fact I didn't realize it was there)
[20:27:06] <jepler> ah
[20:27:26] <jmkasunich> I think I want to change work_area to be a bwidget.ScrolledWindow, right?
[20:27:35] <jepler> yes
[20:27:35] <jmkasunich> then go from there using your example
[20:28:16] <jepler> you may be working from old documentation -- there is now a "menu=" option for a Tk or Toplevel window to set the menu bar, and that's the preferred way to create a menu bar
[20:28:49] <jmkasunich> yeah, I ran across notes to that effect, and was planning to change
[20:28:55] <jepler> OK
[20:29:08] <jepler> I wanted to avoid having you create an elaborate menu that would have to be changed
[20:29:17] <jepler> but at least at first your menus won't be elaborate either
[20:29:42] <jmkasunich> this one uses the new form, right?
[20:29:43] <jmkasunich> http://www.java2s.com/Code/Python/GUI-Tk/Frameworkforasingledocumentinterface.htm
[20:30:03] <jmkasunich> this is what I started with:
[20:30:03] <jmkasunich> http://www.java2s.com/Code/Python/GUI-Tk/Abigmenubar.htm
[20:31:22] <jepler> yes, the first link has the preferred way of doing menus
[20:31:57] <jmkasunich> shame I didn't find it first ;-(
[20:32:20] <jmkasunich> its not that hard to switch over, and doing it piecemeal will be more educational than simply copying it and using it
[20:35:41] <jmkasunich> is there a canonical site for tkinter docs? when I see a line like "win.config(menu=top), I know that somewhere it is written what "menu=top" means
[20:36:01] <jmkasunich> I;ve found good sources for that kind of stuff for py, but tkinter seems well hidden
[20:57:44] <jepler> no all the documentation sucks
[20:58:17] <jepler> your best bet is to actually read the tk manpages (e.g., "man 3tk frame") and get an understanding of how to translate between tcl and python
[20:58:40] <jmkasunich> oh joy
[20:58:50] <jepler> you would look in "man toplevel" for -menu, to find out what menu=top means
[20:59:39] <jmkasunich> are the tk manpages in a -dev package or something, don't seem to have them here
[21:01:26] <jmkasunich> duh, tk8.4-doc
[23:00:18] <jmkasunich> duh, tk8.4-doc
[23:00:21] <jmkasunich> oops
[23:00:25] <SWPadnos> echo echo
[23:17:56] <petev> cradek, u there?