Back
[00:45:10] <jmkasunich> jmkasunich is now known as mach-is-junk
[00:45:24] <mach-is-junk> mach-is-junk is now known as jmkasunich
[00:46:23] <jmkasunich> * jmkasunich grumbles
[00:46:59] <SWPadnos> hmmm. I think Ilike mach-is-junk better :)
[00:47:19] <jmkasunich> he grumbles too
[00:47:41] <jmkasunich> less than thrilled about emc specific error messages in stepgen is all
[00:48:21] <SWPadnos> yeah. I tend to agree, but I also see that the amount of confusion for EMC users (the only known current users of HAL) may be more important at this point
[00:48:30] <jmkasunich> yeah
[00:48:49] <jmkasunich> that why all I'm doing is grumbling, and not trying to convince people to change it back
[00:49:25] <SWPadnos> then again, the last thing suggested would (might) fit both bills if a replacement could be found for the term "following error"
[00:49:24] <jmkasunich> I'm not very friendly to people who don't know how to work a calculator
[00:49:35] <SWPadnos> heh
[00:49:44] <SWPadnos> that's whut computerz is fer
[00:50:24] <jmkasunich> "otherwise, the motor won't be able to keep up with the program"
[00:51:07] <SWPadnos> something like that
[00:51:37] <SWPadnos> actually, there's no reason for HAL to report errors at all, unless they're load-time "I can't find my hardware" kinds of stuff
[00:51:51] <SWPadnos> that should all be done by the higher level system
[00:54:19] <jmkasunich> I agree
[00:54:42] <jmkasunich> this stepgen message is setting a precedent that I'm not very comfortable with
[00:55:07] <jmkasunich> and its for the benefit of the most annoying class of users - the ones who don't read the manual and do the math
[00:55:22] <SWPLinux> I don't see an error reporting scheme though, which is a problem
[00:56:19] <jmkasunich> one of the principles of hal is that you don't report errors - in realtime code, you can't afford to stop and fiddle around, so instead you make a reasonable assumption (or reject the bad data outright) and carry on
[00:56:42] <jmkasunich> I wonder how much time stepgen takes when you trigger that message
[00:56:47] <SWPLinux> that's fine, but it makes sense for the next level up to know that something was wrong
[00:56:48] <jmkasunich> bet its a lot longer then normal
[00:56:58] <SWPLinux> it only happens once, at machine on
[00:57:06] <SWPLinux> (so at enable time)
[00:57:26] <cradek> I wish it could just fail to load
[00:57:50] <cradek> I think a misconfigured system that doesn't tell me it's misconfigured, and then works bogusly, is bad
[00:57:55] <jmkasunich> can't do that unless you are going to give up the ability to change params at runtime
[00:58:03] <jmkasunich> which I sure as hell don't want to do
[00:58:05] <cradek> yeah I know
[00:58:07] <SWPLinux> no - it can tell you if the initial parameters are bad
[00:58:42] <SWPLinux> stepgen only reports once, right? ie, if you fix it later, then put it backj to the unusable config, you won't get another error
[00:58:44] <cradek> there aren't necessarily any parameters set at startup time
[00:58:46] <jmkasunich> SWPLinux: "initial parameters" are an EMC thing - HAL understands no such concept
[00:58:51] <SWPLinux> I understand
[00:58:58] <SWPLinux> or is it done at every enable?
[00:59:12] <jmkasunich> * jmkasunich checks
[00:59:58] <SWPLinux> once
[01:00:31] <jmkasunich> why on enable?
[01:00:40] <jmkasunich> (haven't seen the code yet, doing the cvs up)
[01:00:41] <SWPLinux> so you have time to configure without getting bogus messages
[01:00:59] <SWPLinux> you load, set parameters, and until it's enabled, it doesn't matter if they can work or not
[01:01:30] <jmkasunich> argh
[01:01:46] <jmkasunich> this once again is emc centric
[01:01:48] <SWPLinux> that makes sense. the problem is that there's no way for a HAL component to signal "upward" that there's a problem, other than using rtapi_print_msg ...
[01:02:10] <jmkasunich> if you were running things manually, the logical time to complain is when they set a bad value, not later when they enable
[01:02:25] <SWPLinux> that's dependent on the order in which you set parameters
[01:02:56] <jepler> and no code in your component gets run just because a parameter is set
[01:03:06] <jepler> you have to wait until your thread is run before you have a chance to "do something"
[01:03:14] <jmkasunich> thread running yes
[01:03:31] <SWPLinux> I bet if you set scale to 40000, and leave everything else at default, you have a problem
[01:03:47] <jmkasunich> we're probably never going to agree about this, so we're probably wasting our time discussing it
[01:04:13] <jmkasunich> I strongly feel that realtime HAL components should be simple, fast, quiet, and generic
[01:04:41] <SWPLinux> well, I wouldn't mind figuring out a solution that satisfies both viewpoints, and I think that solution is to make a better error reporting interface in HAL (I know this depends on a lot of other things as well)
[01:05:09] <SWPLinux> right now, there is no way to tell if something "can't work"
[01:05:39] <jmkasunich> you could read back maxvel and see if it matches what you set
[01:05:55] <SWPLinux> and it doesn't matter when the component makes the determination. it has no way of reporting anything to upper level software, other than the print interface
[01:06:06] <jmkasunich> you could read back maxvel and see if it matches what you set ;-)
[01:06:12] <SWPLinux> ok. and when that's a pin?
[01:06:25] <SWPLinux> are all pins going to be RW?
[01:06:40] <SWPLinux> (and what happens if the same signal is run into multiple stepgens with different parameters?)
[01:06:56] <SWPLinux> which pin gets changed? (scale, max_*, requested_position) ...
[01:07:08] <jmkasunich> not suggesting that you would readback a signal
[01:07:08] <SWPLinux> (not to rant here, but it's not a simple problem, IMO)
[01:07:49] <jmkasunich> currently, if maxvel represents an unattainable step rate, maxvel is lowered automatically
[01:08:30] <jmkasunich> I find it rather convenient that I can try to set maxvel to bignum and it will automatically calculate the actual max for me
[01:08:35] <jepler> once the enable pin goes true
[01:08:52] <cradek> emc could validate those numbers if it knew the stepping type, but that's duplicated code and another violation of layering
[01:08:53] <SWPLinux> unless the requested value is saved, that's still dependent on the order in which you set parameters
[01:09:20] <jepler> SWPLinux: yes, that's one thing that the 'don't calculate before enable' logic buys you
[01:09:24] <jmkasunich> like I said, we're not gonna agree about this
[01:09:24] <SWPLinux> yep
[01:09:49] <cradek> commit war!
[01:09:57] <SWPLinux> I don't think we're disagreeing much. just discussin issues with the various approaches
[01:10:29] <jmkasunich> the fundamental disagreement is that I think RT modules should never print anything once their RT code starts
[01:10:34] <SWPLinux> does anyone disagree with the statement that it would be preferable to have a well-defined programmatic error reporting method for HAL?
[01:10:38] <SWPLinux> I agree completely
[01:10:41] <jmkasunich> because printing can take a LOT longer than normal execution
[01:10:48] <SWPLinux> as a workaround, they do right now :)
[01:11:04] <SWPLinux> but not too often
[01:11:07] <jmkasunich> they do what? pring?
[01:11:08] <jmkasunich> print?
[01:11:22] <SWPLinux> they print right now, because there's no other well-defined way of reporting problems
[01:11:23] <jepler> if it's any consolation, the message is written only once per stepgen -- it's like any other "initialization that basically happens once in a running system"
[01:11:28] <jmkasunich> the only one I'm aware of (not counting motmod) is this new stepgen change
[01:11:45] <jmkasunich> still happens in the RT thread
[01:12:20] <SWPLinux> however, it's done rarely, and only when there can be no activity (ie, it can only delay the generation of steps, since it's done at the transition from inactive to active step generation)
[01:12:50] <jmkasunich> nitpicking
[01:12:57] <jmkasunich> when I say "never print" I mean "never print"
[01:14:33] <SWPLinux> well, there are two alternatives if printing from RT is disallowed: 1) ignore any problems with no indication to the user or the next higher layer of code or 2) make an error channel between the layers ...
[01:14:37] <jmkasunich> there are lots of places where poorly chosen values for parameters can cause problems
[01:14:57] <jmkasunich> the only reason the focus is on this one is because this one is the one that the most clueless users are going to screw up
[01:15:38] <jepler> bingo
[01:15:42] <jmkasunich> I humbly submit that setting maxvel too high is not an "error", its a value outside of the acceptable range
[01:15:59] <cradek> I'll be very happy if we fix/eliminate the most common questions new users ask.
[01:16:20] <jmkasunich> cradek: I understand that desire - believe me I don't want to answer the same stupid questions all the time either
[01:16:28] <jmkasunich> but dumbing down stepgen isn't the answer
[01:17:02] <cradek> no, but reporting common misconfigurations in a helpful way is the only possible answer I see
[01:17:15] <cradek> like jepler's "copy the sample config for you" change
[01:17:53] <cradek> is there another possible answer I'm missing?
[01:18:11] <SWPLinux> not in the near term (except for the code duplication thing)
[01:18:15] <cradek> given that "we don't want to answer the same questions all the time" (we all seem to agree on that!) what do we do?
[01:18:30] <jepler> we can add something better and more comprehensive during 2.2 -- we're not committing to report the error to the user IN EXACTLY THIS FASHION forever
[01:18:31] <cradek> SWPLinux: I don't think that can work, because emc doesn't know the stepping type.
[01:18:58] <jmkasunich> jepler: I've hardened my stance since my email to the dev list
[01:19:02] <SWPLinux> actually, that may be viable. there has been a desire for a configurator app, a program like that can refuse to write bad configs (and if it can load configs, it can point out that kind of problem)
[01:19:08] <jmkasunich> before, I thought printing a message with emc specific terms was wrong
[01:19:10] <cradek> how about take the change out of TRUNK?
[01:19:15] <jmkasunich> now I think printing any message is wrong
[01:19:36] <cradek> just stick it in the release versions?
[01:20:05] <cradek> because that hal code is RELEASED with emc. let's just say "it needs a few tweaks to best work for emc"
[01:20:27] <SWPLinux> so the next patch will remove rtapi_print* from rtapi.h ??
[01:20:38] <SWPLinux> since printing from RT is a no-no ...
[01:20:39] <jepler> SWPLinux: troll?
[01:20:40] <jmkasunich> no (smartass)
[01:20:49] <cradek> I'm serious
[01:20:57] <SWPLinux> sorry - that's the real hardline approach I'm seeing here
[01:21:05] <cradek> I'm trying to find middle ground
[01:21:11] <jmkasunich> I was talking to SWPLinux - printing from init code is finee
[01:21:27] <jmkasunich> printing from RT when something really nasty happens might be okj
[01:21:37] <SWPLinux> printing once when it can't have a noticeable effect is a reasonable compromise
[01:21:38] <jmkasunich> being able to put prints into rt code for debugging is important
[01:22:00] <jmkasunich> I see that as the camel's nose under the tent
[01:22:03] <SWPLinux> well, this is a debugging print, it's just for the user
[01:22:17] <jmkasunich> pretty soon there will be all kinds of tests in hal components, printing all kinds of things
[01:22:41] <jmkasunich> are we gonna print when somebody tries to get 11V out of a 10V dac?
[01:22:44] <SWPLinux> or we can come up with a method of reporting problems to higher level code, and have the higher level decide what to do ...
[01:22:49] <jmkasunich> or are we just gonna output 10V and carry on with life?
[01:23:12] <cradek> jmkasunich: do you have another solution to propose that would solve this particular problem that new users have all the time?
[01:23:15] <jmkasunich> I see the maxvel thing as _exactly_ the same as the 11V thing
[01:23:36] <jmkasunich> hit the users with a clue-by-four
[01:23:38] <SWPLinux> it's the same problem, but a lot more obvious for users ...
[01:23:40] <SWPLinux> heh
[01:24:22] <jmkasunich> if somebody is building a CNC machine, and they are too fscking lazy/stupid to calculate their max step rate before they even start wiring, they deserve what they get
[01:24:46] <jmkasunich> the _only_ reason I'm not being even more stubborn is because _we_ don't deserve to have them asking stupid questions
[01:24:49] <cradek> the amount of clue required to never run into this requires knowledge of hal internals.
[01:25:04] <cradek> heh that's my main goal too :-)
[01:25:13] <jmkasunich> no internal knowledge needed
[01:25:26] <cradek> I think that's incorrect
[01:25:31] <jmkasunich> beyond the meaning of BASE_PERIOD and two interrupts per step
[01:25:33] <SWPLinux> this could be solved by having EMC use different parameters, like "max step rate" in theini
[01:25:46] <SWPLinux> and coinvert those to HAL parameters as needed
[01:25:49] <SWPLinux> err - convert
[01:25:54] <jmkasunich> SWPLinux: what
[01:25:56] <jmkasunich> ?
[01:25:58] <cradek> yes I can imagine step/dir that can step once per period, or once every other period.
[01:26:16] <SWPLinux> well, HAL has base_period and stuff, but the user wants "35000 steps/second" ...
[01:26:50] <SWPLinux> it's an implementation detail that HAL uses a BASE_PERIOD which is the (integer) number of nanoseconds per half-step
[01:27:36] <jmkasunich> I don't consider that internals (as in "gotta read the source to figure it out")
[01:27:43] <SWPLinux> so make a [HAL]MAX_STEPS_PER_SECOND ini var, and use that to calculate the proper PERIOD
[01:27:49] <jmkasunich> its not in the man page because there isn't one yet, but that si a far better place
[01:27:57] <jmkasunich> SWP, thats backwards
[01:28:06] <SWPLinux> no it's not, for EMC users
[01:28:18] <jmkasunich> the way I see it, you do this:
[01:28:23] <SWPLinux> this wouldn't be a HAL conversion. EMC would translate from EMC-specific units to what HAL understands
[01:28:30] <jmkasunich> 1) figure out the shortest period you can use
[01:28:38] <jmkasunich> 2) figure out the max step rate based on that
[01:29:04] <jmkasunich> 3) look at your scaling (probably fixed, if you were dumb enough to build the machine before doing the math)
[01:29:10] <jmkasunich> 4) set max vel accordingly
[01:29:43] <jmkasunich> a smart person would do 1 and 2, then decide whether to micro step or not, or to buy some hardware, then he'd build the machine
[01:30:07] <cradek> if he knew ahead of time that this is an issue
[01:30:22] <SWPLinux> I disagree with that last statement. the person may not have the actual computer they want to use, or may buy the computer based on what they calculate
[01:30:31] <jmkasunich> if he doesn't realize that software step generation has limits, he has a problem
[01:31:02] <SWPLinux> it's nearly impossible to know what the performance of a particular computer will be (for stepgen)
[01:31:08] <SWPLinux> until you test it
[01:31:14] <jmkasunich> IOW, what the lowest base period will be....
[01:31:41] <jmkasunich> s/will/can
[01:32:26] <jmkasunich> I agree with SWP about one thing - the best solution is some better way to deal with this situation
[01:32:55] <jmkasunich> I really really hate the idea of fscking up HAL components to compensate for people who don't know how to do design
[01:33:18] <cradek> I'm back to suggesting that they be "fscked up" in the release branches
[01:33:26] <SWPLinux> without a pretty major redesign of HAL (the mythical refactor), I think we have two options:
[01:33:36] <SWPLinux> 1) leave messages in as a stopgap
[01:33:47] <SWPLinux> 2) make a better "front end" for creating configs
[01:34:00] <SWPLinux> 2a) make EMC do parts of what a better front end would do
[01:34:19] <cradek> 3) suffer with this problem like with the 2.0 release family
[01:34:22] <jmkasunich> 3) add a wiki page that tells people how do to basic system design, and link it to the troubleshooting page
[01:35:09] <SWPLinux> 4) assume that everyone who wants to use EMC has a network connection available *while they're configuring their machine*
[01:35:19] <SWPLinux> this is a bad assumption, IMO
[01:35:22] <cradek> true
[01:35:37] <cradek> then we're stuck putting it in the pdfs that people print
[01:35:43] <jmkasunich> ok, a readme or howto
[01:36:08] <jmkasunich> I simply can't imagine building a system _without_ doing those calculations up front
[01:36:15] <SWPLinux> documentation could be a partial solution
[01:36:21] <SWPLinux> you're an engineer ...
[01:36:30] <jmkasunich> we should be educating people about how to be better than "cut and paste machine designers"
[01:37:46] <SWPLinux> I think the idea of a couple of "quick start guides" was floated sometime in the last few months
[01:38:03] <jmkasunich> it seems like the prints in stepgen only help a small subset of people
[01:38:21] <SWPLinux> (yeah - the EMC support team)
[01:38:22] <jmkasunich> some have low resolution and/or speed, and can use software stepgen no problem
[01:38:41] <SWPLinux> quick start guides should be a few pages long at most, and should be linked from the EMC menu
[01:38:50] <jmkasunich> others have high resolution and/or speed, and need hardware stepgen (stepgen printing won't help them at all)
[01:38:52] <cradek> one page
[01:39:05] <SWPLinux> actually, both the gnome/kde menu and available from within the GUIs
[01:39:17] <SWPLinux> yeah - one page is best, but some stuff may need a little more
[01:39:27] <jmkasunich> at least some of the people who see that message are going to find out that they are fscked
[01:39:30] <cradek> if it's more, it's a user manual, not a quickstart
[01:39:39] <jmkasunich> because the performance they wanted _can't_ be gotten with stepgen
[01:39:46] <jmkasunich> and a little math a week earlier would have told them that
[01:40:43] <cradek> without the error, they don't even know it's their fault, they think emc is bogus.
[01:41:08] <SWPLinux> yeah - "how can I get following errors, this is a stepper system?"
[01:41:14] <cradek> right
[01:41:19] <SWPLinux> I don't have encoders
[01:41:53] <cradek> doesn't make sense, obviously the software is buggy or silently failing, and either rightfully makes a user sad
[01:42:29] <jmkasunich> you guys obviously have valid points, and I'm also obviously outnumbered
[01:43:50] <SWPLinux> well, how about this. let's leave it in for this next release, and see if there's a reduction in people asking stupid questions, or if it causes them to ask a different question: "I get this message when I try to start the machine ..."
[01:43:52] <jmkasunich> but I can't help feeling that this message (and the others that I'm sure will follow) is an ugly hack
[01:44:01] <SWPLinux> no doubt about it
[01:44:30] <jmkasunich> it breaks the HAL model
[01:44:33] <SWPLinux> there should be a well defined scheme for moving command and status data between levels of code
[01:44:44] <SWPLinux> it breaks the OSI model, it breaks the NIST model ...
[01:44:51] <cradek> I'm going to stick my neck out and say that reporting errors instead of failing silently is good design. I wish there were a better way to report the error though.
[01:44:53] <jmkasunich> real circults don't pop up little flags and say "oh by the way, you're asking me to do something I can't do"
[01:45:13] <SWPLinux> they let out smoke - sideband signaling ;)
[01:45:27] <jmkasunich> real circuits have transfer functions that define their behavior for any possible set of inputs (even out of range ones)
[01:45:28] <cradek> heh
[01:45:39] <jmkasunich> and then they just do the defined behavior
[01:45:49] <SWPLinux> smoke is one of the defined behaviors
[01:46:07] <SWPLinux> (if you exceed the absolute maximum ratings)
[01:46:31] <jmkasunich> the nice thing about software components is that they don't have to have absolute maximum ratings
[01:47:00] <SWPLinux> taking the hardware analogy further, chips aren't guaranteed to give valid output when the inputs are out of spec
[01:47:04] <jmkasunich> the fundamental difference of opinion here is that I'm trying to design components for engineers who will read the datasheets
[01:47:16] <SWPLinux> so a small RT bump fits well with the analogy
[01:47:18] <jmkasunich> and you are trying to let people who refuse to read the datasheets use the parts
[01:47:43] <SWPLinux> right - EMC is a circuit board with pots the user has to set before it will work
[01:47:57] <SWPLinux> they shouldn't have to read the datasheets for each component before turning those pots
[01:48:14] <jmkasunich> beg to differ
[01:48:26] <SWPLinux> and the error message is like a little "out of tune" LED on the board
[01:48:43] <jmkasunich> if one of those pots is "max step rate" they better know that they can't set it to a megahertz
[01:49:00] <SWPLinux> sure
[01:49:36] <SWPLinux> I'd say that a reasonable approach here is to make a very short quick start guide (like the tuning stuff in the gecko manuals)
[01:49:49] <SWPLinux> one for stepper (or step-to-servo) systems
[01:49:59] <SWPLinux> another for servo systems
[01:50:02] <jmkasunich> "before you even download EMC, do this: "
[01:50:10] <jmkasunich> "basic machine design 101"
[01:50:29] <SWPLinux> possibly a separate sheet that tells basics of how to calculate OUTPUT_SCALE ...
[01:50:45] <jmkasunich> screw pitch, gearing/belt ratios, steps/rev, microstep ratio
[01:51:08] <SWPLinux> yes
[01:51:13] <jmkasunich> there are two kinds of users in the world - those that understand that stuff, and those that don't
[01:51:27] <jmkasunich> I want to convert the second group into the first
[01:51:48] <jmkasunich> those who willfully insist on staying the second group I don't give a flying fsck about
[01:51:52] <SWPLinux> the problem with doing this for EMC is that you either have (a) a long quick start because there are so many hardware possibilities or (b) a thousand quick start guides
[01:52:37] <jmkasunich> I don't believe in "quick start guides" either
[01:52:43] <SWPLinux> I agree. you can't protect users from themselves, but you may be able to protect the EMC developers from the users ;)
[01:52:49] <jmkasunich> for example - stepper motor overdrive
[01:53:05] <jmkasunich> "what power supply voltage should I use"
[01:53:19] <jmkasunich> that to me is yet another part of "design the machine before you build it"
[01:53:49] <SWPLinux> I'm not talking about a "machine quick start", I'm talking about "these are the things you need to change in the INI file" ...
[01:54:04] <SWPLinux> it's a guide for configuring EMC
[01:54:33] <jmkasunich> but both of those tasks are the exact same thing
[01:54:37] <jmkasunich> its part of designing your machine
[01:54:39] <SWPLinux> no they aren't
[01:54:51] <SWPLinux> they're part of the overall picture, but not the same thing
[01:55:12] <SWPLinux> the emc guide says "multiply screw pitch by drive ratio by ... to get INPUT_SCALE"
[01:55:25] <SWPLinux> nothing about how to select the right components goes in there
[01:55:48] <SWPLinux> (that can be a separate document if we like, or a couple of suggested google search terms)
[01:56:06] <jmkasunich> and it should also explain how to figure the required step rate for steppers, and/or the encoder count frequency for servos
[01:56:21] <SWPLinux> yep
[01:56:22] <jmkasunich> and point out that software counting or stepping has limitations (and where those limitiations are)
[01:56:44] <jmkasunich> if you buy a gecko and don't read the white paper, you might well be dissipointed
[01:57:00] <jmkasunich> if you install emc and don't read the white paper you might well be dissapointed
[01:57:25] <SWPLinux> people treat power electronics and software differently
[01:57:29] <SWPLinux> sad but true
[01:57:46] <jmkasunich> well, HAL is supposed to be like electronics, not software
[01:58:10] <SWPLinux> but EMC is like software, and users don't give a flying fsck what's under the hood - they just want it to work
[01:58:24] <jmkasunich> and this is a perfect example of why I don't write GUIs
[01:58:29] <SWPLinux> heh
[01:59:07] <jmkasunich> I can just see the creeping crapification of HAL
[01:59:18] <jmkasunich> first we detect hal maxvel too high
[01:59:33] <jmkasunich> then we try to detect people who didn't provide headroom for stepgen
[01:59:44] <jmkasunich> then we try to detect people who set base-period to short (or long)
[02:01:08] <SWPLinux> well, any of those are reasonable, but not in HAL components themselves
[02:01:28] <SWPLinux> the best thing to do would be to make a well defined system for reporting errors upstream
[02:01:56] <SWPLinux> there's another problem here - EMC doesn't configure the HAL, halcmd does. so EMC doesn't really know what happens during configuration
[02:02:24] <SWPLinux> errors go to the wrong place at config time, and go nowhere afterwards (currently)
[02:02:32] <jmkasunich> wrong place being dmesg?
[02:03:12] <SWPLinux> yes, that's wrong for most software users
[02:03:18] <SWPLinux> great for developers though
[02:03:20] <jmkasunich> true
[02:03:29] <jmkasunich> not even that great for devs
[02:03:39] <SWPLinux> and it doesn't help the higher level of software at all
[02:04:00] <jmkasunich> it would be wonderfull if a setp command could run some code in the component, and that could validate the value before setting it, and have the setp command return an error if the value was no good
[02:04:07] <SWPLinux> EMC (or some other thing built on top of HAL) may want to respond to some errors and ignore others
[02:04:16] <SWPLinux> need I mention C++ again? :)
[02:04:31] <jmkasunich> but that would bloat every hal component with lots of value checking code (besides which we currently don't have a way to run kernel code from user space)
[02:04:56] <SWPLinux> all the value checking code is already there, it just gets run all the time instead of once per parameter write
[02:05:13] <SWPLinux> the code would shrink using a C++-like setter/getter method
[02:05:19] <jmkasunich> thats for two reasons:
[02:05:34] <jmkasunich> 1) params can be changed at any time
[02:05:45] <jmkasunich> 2) I forget what I was gonna say for 2
[02:06:00] <SWPLinux> any time a param gets changed, the code would be run, so the "always active" argument doesn't work
[02:06:11] <SWPLinux> 2) you hate C++ and it doesn't work in the kernel? :)
[02:06:25] <jmkasunich> except that there is NO mechanism for doing getter/setter
[02:06:39] <jmkasunich> C++ has nothing to do with it
[02:06:54] <SWPLinux> C++ has setter / getter functions as a core feature of the language
[02:07:10] <SWPLinux> (assuming you want to use them - other wise it's just pointers)
[02:07:10] <jmkasunich> they can't get across the user/kernel boundary
[02:07:37] <SWPLinux> well - no point in arguing because I know I won't win the C++ battle here. however, RTAI has a kernel C++ interface
[02:07:53] <jmkasunich> the only way to run any code (regardless of language) in kernel space from a user program is to make a system call
[02:08:07] <jmkasunich> language is not the issue
[02:08:11] <SWPLinux> structures like those used in C++ can be useful as examples of ways of doing what we want though
[02:08:26] <jmkasunich> C++ is a red herring
[02:08:33] <SWPLinux> oh - the user / kernel problem is still there - I know that
[02:08:37] <jmkasunich> if it can be done in C++, it can be done in C
[02:08:47] <SWPLinux> or assembly
[02:08:55] <jmkasunich> I was gonna say that ;-)
[02:08:58] <SWPLinux> heh
[02:09:31] <jmkasunich> the problem is 1) making a system call for every setp, and 2) having call handlers in every component to run when the call happens
[02:10:02] <SWPLinux> how many setps do you think there are after initial config?
[02:10:12] <SWPLinux> I'd imagine it's pretty low
[02:10:16] <jmkasunich> doesn't matter
[02:10:25] <jmkasunich> I'm not talking about the speed of a call
[02:10:30] <jmkasunich> I'm talking about the cruft
[02:11:11] <jmkasunich> making a completely new system call means getting far more intimate with the kernel that I want to
[02:11:21] <jmkasunich> we could use existing calls, most likely ioctl
[02:11:38] <SWPLinux> um, why is syscall(blah blah) more crufty than SHMEM[SHMOFFSET(**paramyaddayadda)] ...
[02:11:45] <SWPLinux> (or whatever ... :) )
[02:11:52] <jmkasunich> you'd have to have a /dev/hal (or maybe /proc/hal) and implement most of the hal API as ioctl's to that device
[02:12:19] <SWPLinux> true - a new syscall requires a change to the kernel, I think
[02:12:35] <jmkasunich> because SHMEM(blah) is local to HAL and doesn't change at the whim of somebody else
[02:12:45] <jmkasunich> (embedded programmer's attitude)
[02:12:55] <jmkasunich> syscall interfaces change
[02:13:07] <SWPLinux> not too often, I think
[02:13:19] <SWPLinux> if they did, old programs wouldn't work on newer versions of Linux ...
[02:13:28] <jmkasunich> /dev changes (udev and stuff like that)
[02:13:30] <SWPLinux> sure
[02:13:47] <SWPLinux> ah yes - syscall and ioctl are different beasties
[02:14:15] <jmkasunich> believe me, I've wanted the ability to have halcmd invoke kernel code for a long time
[02:14:26] <SWPLinux> none of the dev stuff matters to the driver though (I think) - that's a matter of how the userspace apps acn fund the driver
[02:14:26] <jmkasunich> I want the metadata out of shmem and into kernel space
[02:14:38] <SWPLinux> s/acn/can/
[02:14:39] <jmkasunich> I want the ability to create threads without loading "threads.ko"
[02:14:51] <SWPLinux> yep
[02:15:05] <SWPLinux> and to instantiate independent of init time
[02:15:15] <SWPLinux> (or multi-load modules)
[02:15:20] <jmkasunich> and yes, I want the ability for a setp command to say "sorry, value out of range"
[02:15:50] <jmkasunich> _all_ setp commands, not just the one or two that we thing are gonna screw up emc users who don't do their homework
[02:16:00] <jmkasunich> s/thing/think
[02:16:18] <SWPLinux> ok. I think everyone can agree with that
[02:16:41] <jmkasunich> but since those things are hard/impossible (depending on your timeframe) the HAL philosophy is "take what they give you and make the best of it"
[02:17:09] <jmkasunich> that means if you ask for more than the upper limit of some var, HAL sets it to the upper limit
[02:17:22] <jmkasunich> all transfer functions saturate
[02:18:04] <jmkasunich> if there was a sqrt hal block, it would output either zero or or sqrt(abs(in)) for negative inputs, it would NOT declare an error
[02:18:28] <SWPLinux> or 0 for <0 input ....
[02:18:56] <jmkasunich> I said either zero or sqrt(abs())
[02:19:03] <jmkasunich> dunno which, I'd pick one and document it
[02:19:04] <SWPLinux> that's also a "function" thing, not a "configuration thing"
[02:19:07] <SWPLinux> sorry - misse that
[02:19:12] <SWPLinux> missed
[02:19:23] <jmkasunich> I don't make the distinctuon
[02:19:24] <SWPLinux> or have a parameter that chooses ...
[02:19:29] <jmkasunich> any parameter can be changed at any time
[02:19:34] <SWPLinux> not now, because there's no way to do so
[02:19:46] <jmkasunich> open a shell and go to town
[02:19:54] <jmkasunich> I can tune on the fly
[02:20:09] <jmkasunich> EMC may not, but that is emc's limitation, not HALs
[02:20:23] <SWPLinux> no - I meant that there's no error path for a signal, but trying to set a parameter to some illegal state should have an error return path
[02:20:51] <jmkasunich> if there are things that MUST be set at insmod time (mostly things that would change the pins/params that will be exported) they are insmod params - that is the only true config data
[02:20:56] <SWPLinux> the transfer function of the component should be GIGO at worst
[02:21:06] <jmkasunich> I don't distinguish between params and signals
[02:21:12] <jmkasunich> either one can change at either time
[02:21:21] <SWPLinux> heh - you did at some point ;)
[02:21:34] <jmkasunich> in fact I still intend to eliminate params as a separete namespace and turn them all into poins
[02:21:37] <jmkasunich> pins
[02:21:57] <jmkasunich> separate param were a mistake in hindsight
[02:22:03] <jmkasunich> (IMO)
[02:22:17] <SWPLinux> I don't think so
[02:22:32] <SWPLinux> they can change at any time, which makes them act like pins
[02:22:37] <jmkasunich> saying "this is a param" is enforcing polich
[02:22:40] <jmkasunich> policy even
[02:23:00] <SWPLinux> but if you add a "lock" input to every component, you could lock down a configuration
[02:23:02] <SWPLinux> which could be useful
[02:23:11] <jmkasunich> siggen had a frequency param, but anders wanted to hook a pyvcp control to it to make a "bench instrument"
[02:23:33] <SWPLinux> hmmm
[02:23:51] <jmkasunich> so that one (and that one only so far) now has pins for everything
[02:23:53] <SWPLinux> yeah - I saw that. I agree that changing them on the fly is useful in some circumstances
[02:24:39] <SWPLinux> is there a terrible downside to adding a pair of pins to every component called something like "check" and "error"
[02:24:49] <jmkasunich> yes
[02:24:51] <SWPLinux> "check" might be just a boolean
[02:24:52] <SWPLinux> heh
[02:25:07] <SWPLinux> other than the effort ...
[02:25:13] <jmkasunich> those pins are very much NOT part of the basic definition of the component
[02:25:27] <jmkasunich> they are like the "funcname-max-time" params, only worse
[02:25:51] <jmkasunich> the max-time params have metadata about the component, just like check and error
[02:26:05] <jmkasunich> but with max-time, I have the excuse that its usefull to be able to scope that data
[02:26:15] <SWPLinux> error isn't metadata - it can only be determined by the component itself
[02:26:37] <jmkasunich> the concept of an error is where we're not communicating
[02:26:42] <SWPLinux> whereas the execution time isn't imoprtant to the config of the component
[02:26:47] <jmkasunich> IMO, a hal component should never "throw an error"
[02:27:06] <SWPLinux> why not?
[02:27:15] <SWPLinux> I'm not saying that it should stop working
[02:27:15] <jmkasunich> it should always have an answer, no matter how rediculous the input
[02:27:24] <jmkasunich> I can't spell that word
[02:27:28] <SWPLinux> sure - there's an answer, and a flag that says it's not within spec ...
[02:27:45] <SWPLinux> or that says it was limited by the configurtation of the component
[02:27:52] <jmkasunich> what configuration
[02:27:54] <SWPLinux> configuration, that is
[02:28:12] <jmkasunich> max_vel isn't "configuration", its just another input into the component
[02:28:15] <SWPLinux> one sec
[02:28:27] <SWPLinux> let me look up some of the actual pin/param names
[02:31:57] <SWPLinux> ah - ok. (assuming step_type=1) given a set of base_period / stepspace / steplen, dirsetup / dirhold / maxvel, it is an error if the specified maxvel is higher than the attainable step rate
[02:32:12] <SWPLinux> calculated from the other parameters
[02:32:46] <SWPLinux> I know that the component looks at this and just sets it to the real max if the user tries to set it too high
[02:32:50] <jmkasunich> right
[02:33:12] <jmkasunich> and if they later lengthen stepspace (which will lower the limit) it once again sets max-vel to the new limit
[02:33:27] <jmkasunich> no difference between maxvel and stepspace
[02:33:38] <jmkasunich> both affect the output (in this case the maximum frequency)
[02:33:47] <SWPLinux> however, that is also an error, and the only way for the user to know that an error has occurred is to wait some amount of time (unknown) and check to see that it's still the same value they set before
[02:34:01] <jmkasunich> and one of them (the one that seemed most "flexible" to me) gets adjusted to prevent the error
[02:34:10] <SWPLinux> what if the stepgen is running once per second ...
[02:34:22] <jmkasunich> then maxvel is gonna be pretty darned low
[02:34:46] <SWPLinux> but there is an error. so I'm saying that the component *should* limit its operation, but also signal that something was limited
[02:34:47] <jmkasunich> remember, these are components with datasheets - their only responsibility to the user is to do what the data sheet says they will do
[02:35:03] <SWPLinux> sure, but the more useful the component, the better ...
[02:35:36] <jmkasunich> error detection doesn't increase the usefullness of the component even a tiny tiny amount
[02:35:55] <jmkasunich> it increases its ease of use perhaps, but not its usefullness
[02:36:07] <SWPLinux> it helps for inexperienced people configuring their components
[02:36:15] <SWPLinux> "oops - I did something wrong"
[02:36:42] <jmkasunich> this is where I get obnoxious and say "I didn't design it for inexperienced people"
[02:36:51] <jmkasunich> ;-)
[02:37:02] <SWPLinux> heh - that's what everyone else is here for, I guess :)
[02:38:17] <jmkasunich> no
[02:38:42] <jmkasunich> thats what the man pages are here for
[02:39:05] <SWPLinux> separate question: do you know if it works if you set soem linear axes to one UNIT and others to another (and possibly TRAJ differently)?
[02:39:11] <SWPLinux> heh
[02:39:20] <jmkasunich> and the comps that don't have pages should - I'd much rather be spending time writing a manpage for stepgen than arguing about this, or clapping printfs into the realtime code
[02:39:33] <jmkasunich> no clue
[02:39:41] <SWPLinux> I'm writing a stepper wuickstart at tthe moment, hence my question ...
[02:39:47] <SWPLinux> quickstart, that is
[02:39:54] <jmkasunich> by the time commands get into motmod, the units are all the same
[02:40:14] <jmkasunich> I have no idea how the non-realtime code deals with mixed axes
[02:40:16] <SWPLinux> where does motmod get them from?
[02:40:56] <cradek> I suspect it doesn't work right
[02:40:58] <jmkasunich> task calls usrmotintf, which puts commands into a shared mem block (not hal, this is motmod specific)
[02:41:11] <jmkasunich> motmod fetches the commands from there
[02:41:12] <SWPLinux> ok
[02:41:13] <cradek> also, joints 012 are assumed to be linear, 345 are rotary
[02:41:53] <SWPLinux> ok
[02:42:25] <cradek> it seems like emc was written as ngc (orthogonal, 3 linear and 3 rotary), then later people wanted flexibility, so they added ini file stuff but didn't finish
[02:42:39] <SWPLinux> ok
[02:42:41] <cradek> (kinematics is a prime example)
[02:42:44] <jmkasunich> or something like that
[02:42:51] <SWPLinux> oh - also OT, but does anyone have any idea what size servo would be needed to drive the back (spinning) head to do polygon turning?
[02:43:02] <SWPLinux> roughly the same as the spindle, I'd imagine
[02:43:03] <jmkasunich> some parts of it were written in a more general way, but other parts make assumptions
[02:43:20] <cradek> yeah
[02:43:29] <jmkasunich> SWPLinux: I'd guess about the same as the spindle motor
[02:43:34] <SWPLinux> ok
[02:43:45] <jmkasunich> maybe even more
[02:43:46] <SWPLinux> I may play with that on the lathe (someday)
[02:44:06] <jmkasunich> in that video, they were cutting flats on a 1" dia part, using a cutter on a 6" or so disk
[02:44:16] <cradek> it's cool but I wonder if it's the easiest way to make those parts
[02:44:31] <jmkasunich> assuming the same cutting force acts on cutter and workpiece, that is more torque on the cutter because of the larger radius
[02:44:31] <SWPLinux> it may actually be, when you consider that it's only one process step
[02:44:41] <SWPLinux> true
[02:45:28] <jmkasunich> otoh, the inertia of that disk is non-trivial, and the motor only has to supply the average torque
[02:45:48] <jmkasunich> like a wood chipper ;-)
[02:45:51] <SWPLinux> yep
[02:47:20] <SWPLinux> I suspect that a nice facemill might be able to do that (with the right cutter orientation)
[02:50:22] <jmkasunich> get a carbide one, and remove all but one or two inserts
[02:50:27] <jmkasunich> (two if balance is an issue)
[02:51:10] <SWPLinux> yep
[02:51:49] <SWPLinux> I was thinking of using a higher speed servo than the spindle - run it at a multiple of the spindle speed to get multiple faces
[02:52:23] <jmkasunich> gonna have to model the relative motion of the cutter and work
[02:52:40] <jmkasunich> if the speed ratio and radius ratio aren't right, the flats won't be flat
[02:53:01] <cradek> I don't think the flats are ever flat
[02:53:09] <SWPLinux> well, that's what I think is wrong - remember the pyramid they cut?
[02:53:28] <SWPLinux> that had the same spindle speed (I think), and multiple cut radii
[02:53:44] <SWPLinux> same speed ratio, anyway
[02:53:50] <jmkasunich> yeah
[02:54:04] <jmkasunich> like I said, I'd have to model it somehow, I can't visualize it
[02:54:14] <SWPLinux> apparently, when you run through the math, you end up with an excellent flat surface
[02:54:27] <SWPLinux> (I haven't done it, but someone on CCED did)
[02:54:51] <jmkasunich> are the spindle and the cutter head rotating the same direction?
[02:55:04] <SWPLinux> looked at from one end, yes
[02:55:04] <jmkasunich> (so that the cutter and work are rotating against one another when they meet)
[02:55:10] <SWPLinux> but that gives opposite motion
[02:55:13] <SWPLinux> yes
[02:55:51] <jmkasunich> I bet the ratio has to be 1:1 then
[02:56:01] <SWPLinux> that could be
[02:56:05] <jmkasunich> if you want more facets, add more cutters to the wheel
[02:56:09] <SWPLinux> right
[02:56:21] <jmkasunich> or do multiple passes, adjusting the phase of the wheel between passes
[02:56:24] <SWPLinux> yep. that makes sense
[02:56:56] <SWPLinux> one case gives you a convex curve (like normal turning), the other gives you a concave curve stopped spindle)
[02:57:05] <SWPLinux> in the middle, you get a straight line
[02:57:33] <SWPLinux> there was supposed to be a "(' before "stopped spindle"
[02:58:50] <jmkasunich> ok, back to the argument, but trying to keep it positive
[02:59:09] <jmkasunich> if we must have "error" indication, can we do it in a less ugly way?
[02:59:24] <jmkasunich> ugly = copying a string during RT execution
[02:59:41] <jmkasunich> and worse, doing printf style formatting on it
[03:00:06] <SWPLinux> I'm fine with that
[03:00:09] <SWPLinux> do you have a suggestion for something less ugly?
[03:00:18] <jmkasunich> not really
[03:00:50] <jmkasunich> if its going to be fast, it has to be no worse than setting a pointer or an int, and letting user space code translate that into something for the user to read
[03:01:10] <SWPLinux> can we leave in the ugly stuff for this release, with a to-do item (high on the list) to think of something else?
[03:01:30] <SWPLinux> hmmm - there is a way, but it's somewhat ugly
[03:01:52] <SWPLinux> though a little better in terms of encapsulation, and lots better for RT performance
[03:01:59] <jmkasunich> I really really don't want to release what we have now
[03:02:05] <jmkasunich> its just "wrong"
[03:02:24] <jmkasunich> what is the ugly way?
[03:02:29] <SWPLinux> well, there's a "ready" flag in the HAL data for each component. that can be set to "not ready"
[03:02:55] <SWPLinux> or add an error field
[03:03:00] <jmkasunich> I'd add another flag instead of overloading that one
[03:03:28] <jmkasunich> but a proper HAL component when given bad data, fixes it and carries on
[03:03:42] <jmkasunich> (even if we agree that we'd like to send a message, it should still carry on)
[03:03:52] <jmkasunich> so how do you know when to clear the error flag?
[03:03:57] <SWPLinux> then it's incumbent on emc to look at some list of components and refuse to "machine on" if those have errors
[03:04:41] <SWPLinux> actually - there's a two part answer to that
[03:05:03] <SWPLinux> the component should clear the error flag when all the requested inputs are acceptable
[03:05:23] <SWPLinux> however, it needs to save a copy of the request versus the actually used parameter to do that
[03:05:30] <SWPLinux> it should do so anyway for other reasons:
[03:06:22] <SWPLinux> in the stepgen case, if the stepspace is increased, the maxvel will possibly be decreased. without saving the requested maxvel, it can't be increased if the stepspace is set lower
[03:06:56] <jmkasunich> yeah, today thats how it works (once lowered, it stays low)
[03:07:18] <jmkasunich> I can say setp maxvel 1e20 to find the max allowable value, and then carry on with life
[03:07:23] <SWPLinux> so saving settings aside from used settings is a good idea anyway (in some cases)
[03:07:42] <SWPLinux> sure, but you may want one channel to go slower than its calculated max
[03:08:01] <jmkasunich> then I would setp it to whatever I want
[03:08:25] <jmkasunich> I don't like the idea of remembering 1e20
[03:08:28] <SWPLinux> right, but then it may get automagically (semi-permanently) set to something else by accident
[03:08:38] <jmkasunich> hun?
[03:08:44] <jmkasunich> huh?
[03:09:08] <SWPLinux> saving "external" settings is only a memory burden - it adds no processing time to the components
[03:09:46] <SWPLinux> hmmm - that may not be true
[03:09:48] <jmkasunich> the displayed value of "maxvel" is exactly what it is, no hidden information, no strange behavior... the only time it will EVER change is if you make the current value impossible
[03:09:54] <jmkasunich> its not
[03:10:18] <jmkasunich> you would have to check every time to see if it has become possible to use the requested value even tho you couldn't use it before
[03:10:57] <SWPLinux> but you're doing that anyway - there's alread ya saved value and a check to see if it's different from the new param/pin value
[03:10:59] <jmkasunich> also, the requested value becomes hidden...
[03:11:15] <jmkasunich> thats a check that becomes true only when the user does a setp
[03:11:22] <SWPLinux> correct
[03:11:27] <jmkasunich> IOW, once, not every pass
[03:11:40] <SWPLinux> every pass, there's a check to see if a parameter has changed
[03:11:57] <jmkasunich> yes, a simple equality check
[03:12:01] <SWPLinux> yes
[03:12:13] <jmkasunich> not a complex formula to see if the max allowable value has changed
[03:12:18] <SWPLinux> then all the calculations that are dependent on the parameters are done
[03:12:33] <SWPLinux> but the max allowable value can only change if a parameter changes ...
[03:12:37] <jmkasunich> suppose I entered 1e20 as maxvel
[03:12:56] <jmkasunich> the displayed value becomes 10000 because thats the max
[03:13:08] <jmkasunich> then I change something (stepspace maybe) and the new max is 15000
[03:13:26] <jmkasunich> never mind, you're right at least in this particular case
[03:13:33] <jmkasunich> the max gets calculated every time
[03:13:53] <jmkasunich> and compared to the param every time
[03:14:07] <jmkasunich> in case the user raised the param, or lowered something else
[03:14:22] <SWPLinux> there's an extra variable my way - you need "saved", "set", and "param"
[03:14:23] <SWPLinux> right
[03:14:49] <jmkasunich> yeah, extra storage, and probably one extra compare, but no extra computation
[03:14:54] <SWPLinux> right
[03:15:02] <jmkasunich> this isn't gonna work
[03:15:11] <jmkasunich> the more I think about this stuff the more I hate it
[03:15:15] <SWPLinux> the only burden is that you need to revisit all the params when one changes (which is probably true anyway)
[03:15:24] <jmkasunich> I love the fact that a hal component is often only a few lines of code
[03:15:41] <SWPLinux> the parameter stuff is usually not like that though
[03:15:56] <SWPLinux> if (foo) {calculate bar and baz; update foo }
[03:15:58] <jmkasunich> we're taking something that is clean and simple,and adding loads of stuff to it for a reason that I still can't convince myself is good
[03:16:26] <SWPLinux> this adds to discoverability, both for users and higher level software
[03:16:34] <SWPLinux> that is good, IMO
[03:16:42] <jmkasunich> what discoverability?
[03:16:55] <SWPLinux> you can discover that there's an error in configuration :)
[03:17:00] <jmkasunich> you wanna know the max value, try setting something really high, then look at it
[03:17:26] <SWPLinux> how long after setting it?
[03:17:47] <jmkasunich> so far, you are talking about stuff that suffers the same delay
[03:18:07] <jmkasunich> unless setp can invoke code in the component that re-evaluates all params, that will always be true
[03:18:51] <SWPLinux> that's true, but it's a lot more difficult to keep track of all the parameters that could have been silently changed on me than it is to look at one well-known location in the component data (which I also have to keep track of, of course)
[03:19:33] <jmkasunich> hmm
[03:19:54] <jmkasunich> what if hal components could optionally have a validator "method"
[03:20:02] <SWPLinux> any "method" would be great :)
[03:20:21] <jmkasunich> I say method to distinguish it from a hal function
[03:20:32] <jmkasunich> this would be a separate API
[03:20:35] <SWPLinux> that's getting close to the check/error pin idea though, I think
[03:20:38] <SWPLinux> ok - that would be fine
[03:21:26] <jmkasunich> something lile "hal_set_validator(ptr-to-function)"
[03:21:47] <jmkasunich> the component could call it to register a validator just before calling hal_ready()
[03:22:00] <SWPLinux> hal_ready(validatorfunct)
[03:22:10] <jmkasunich> then "halcmd validate" would (somehow) invoke all the registered validator functions
[03:22:18] <jmkasunich> that could happen before starting the RT code
[03:22:28] <jmkasunich> which is better than the existing approach
[03:22:34] <SWPLinux> it needs to be doable while running, I think
[03:22:44] <jmkasunich> well, you can run the validator any time
[03:22:47] <SWPLinux> since configuration is dynamic ...
[03:22:47] <SWPLinux> right
[03:22:48] <jmkasunich> its not in the hal thread
[03:22:58] <jmkasunich> fsck, it won't work
[03:23:12] <SWPLinux> no - it needs to know how to check for validity
[03:23:19] <SWPLinux> err - nevermind
[03:23:20] <jmkasunich> the RT code still needs to "deal with it and move on" if a param is set to a bad value
[03:23:43] <jmkasunich> so unless you call the validator before the RT code runs, it will always see things as correct
[03:23:53] <SWPLinux> what can set a parameter?
[03:24:05] <SWPLinux> right now there's halcmd, and internal setting of "local" params, right?
[03:24:15] <jmkasunich> yeah
[03:24:23] <SWPLinux> can one module change another module's parameters?
[03:24:30] <SWPLinux> (possible, but unused at this point, right?)
[03:24:38] <jmkasunich> not today (but I already told you I want to convert params to pins)
[03:24:42] <SWPLinux> sure
[03:25:54] <jmkasunich> to be honest, it makes the most sense to run the validator before you start the RT code
[03:26:03] <jmkasunich> so that may not be a major problem
[03:26:13] <SWPLinux> not for a dynamically configurable system
[03:26:34] <jmkasunich> I think the RT code should "fix" bad values, and the validator should report them (and not fix them)
[03:26:40] <jmkasunich> two different approaches
[03:26:39] <SWPLinux> if you can change it on the fly, you should be able to check it on the fly
[03:26:45] <SWPLinux> correct
[03:27:02] <jmkasunich> the problem with checking on the fly is the time between the change and the check
[03:27:08] <SWPLinux> each component has to fend for itself as far as correcting things
[03:27:15] <jmkasunich> if the RT code runs and there is a bad value, what can it do?
[03:27:20] <jmkasunich> the only choice it has is to fix it
[03:27:44] <jmkasunich> so I think the RT code should fix it just like it does now
[03:28:11] <jmkasunich> the validiator is a parallel and indpendent capability that can be used to get more informative info about bad values
[03:28:23] <SWPLinux> well, it may be possible to do sometihng about that. the thread execution code can have an execution count for each thread. halcmd does a setp, then saves all the counts. once all counts have gone up by 1, check the error flag
[03:28:44] <SWPLinux> it may wait for more than one count, but it'll never wait for less than one
[03:28:52] <jmkasunich> that isn't as nice as a separate validator
[03:29:10] <jmkasunich> the RT code has to fix, not just check, and it can't print pretty messages
[03:29:24] <SWPLinux> hmmm
[03:29:28] <jmkasunich> so the error flag will just say "something ain't right", but not tell you what
[03:29:48] <jmkasunich> and besides, in the stepgen case, the RT "fixer" code doesn't even examine the values until you enable the axis
[03:29:59] <jmkasunich> the validator code could examine them anytime
[03:30:06] <jmkasunich> and it can print messages
[03:30:16] <SWPLinux> are you thinking that the validator would be basically the code that looks at params and fiddles with them, only without the fiddling?
[03:30:23] <jmkasunich> yeah
[03:30:27] <jmkasunich> and with messages
[03:30:46] <jmkasunich> some duplication there unfortunately
[03:30:52] <SWPLinux> seems like a lot of duplication, unless you can make them the same code
[03:31:26] <jmkasunich> crap, its worse than that
[03:31:40] <jmkasunich> you don't even know the max frequency until you know the period
[03:31:46] <SWPLinux> which is wrong, maxvel or stepspace? ...
[03:31:50] <SWPLinux> yep
[03:32:22] <jmkasunich> well thats why a separate validator can be good - because it can point out at length exactly what is screwy, and let the user decide
[03:32:30] <jmkasunich> the RT fixer code has hard coded assumptions
[03:32:50] <jmkasunich> assumption: maxvel is more "flexible" than the timing of the signals going to the stepper drive"
[03:33:08] <SWPLinux> for a couple of reasons, I think it's better for any HAL validation code to return a code (bitmap, int, whatever), and have a higher level decide what to print
[03:33:13] <SWPLinux> i18n is one of those reasons
[03:33:27] <jmkasunich> eww
[03:33:42] <SWPLinux> error messages are useless in the wrong language ...
[03:33:52] <jmkasunich> you are gonna have a user space "chunk" that accompanies every RT component with the component sepecific messages?
[03:34:08] <SWPLinux> also, depending on the "consumer" of HAL, the messages may be different
[03:34:28] <SWPLinux> no - I think the messages are application-specific, not component-specific
[03:35:20] <jmkasunich> if the application is smart enough to understand what a stepgen specific code is, then its probably smart enough to validate the values in the first place
[03:35:47] <jmkasunich> what if I use a small stepper to turn the knob of my sherline spindle drive for speed control?
[03:35:48] <SWPLinux> no - the documented interface to stepgen would be extended to include error codes for certain specific problems
[03:35:54] <jmkasunich> that stepgen has nothing at all to do with emc proper
[03:35:58] <SWPLinux> what to do with those numeric codes is up to the user
[03:36:30] <SWPLinux> so emc may print "you may get a following error, bnonehead"
[03:36:52] <SWPLinux> and a conveyor program may print "the industrial processes will need to be slowed down"
[03:37:02] <jmkasunich> HAL just managed to get stepper specific stuff out of emc, and we're putting it back in
[03:37:07] <jmkasunich> all in the name of dumb users
[03:37:23] <SWPLinux> well, it's a strings file, not stepperspecific stuff
[03:38:00] <SWPLinux> a PID would have some error codes as well (maybe), and the combination of some module ID and the error numberwould let us look up an error string
[03:38:21] <SWPLinux> or just pring "component 43: error 12"
[03:38:22] <SWPLinux> print
[03:38:52] <jmkasunich> well, that solves the "printing takes too long" problem
[03:38:57] <SWPLinux> heh
[03:39:39] <jmkasunich> if the code was a 32 bit number, consisting of component ID, instance number, and error number concatenated into 32 bits, it could be atomic
[03:39:49] <SWPLinux> yep
[03:39:49] <jmkasunich> which means that there could be a single shmem location for it
[03:40:00] <SWPLinux> though you need one location per instance, not per component
[03:40:03] <jmkasunich> the rt code would write to it when it detects something
[03:40:24] <jmkasunich> halcmd or whatever is displaying the error would clear it
[03:40:45] <jmkasunich> I mean one location per all of HAL
[03:40:51] <SWPLinux> hmmm
[03:40:58] <jmkasunich> if multiple components had errors, you'd get the most recent one
[03:41:07] <SWPLinux> that will only tell you the last error that was detected
[03:41:08] <SWPLinux> ok
[03:41:25] <SWPLinux> ok - so one for all of HAL is step 1
[03:41:32] <SWPLinux> 1 per component is step 2, perhaps
[03:41:45] <SWPLinux> still updating parameters as it's done now
[03:41:44] <jmkasunich> or jump all the way to one per instance
[03:42:31] <SWPLinux> yep, though that requires specific data per sub-component, and that's a per-component job (not a HAL_lib job)
[03:43:04] <jmkasunich> just rambling here, haven't thought this thru yet
[03:43:09] <SWPLinux> sure
[03:43:13] <jmkasunich> you could make it a convention, not a lib thing
[03:43:28] <jmkasunich> the convention is "compname.N.errorcode" as a param
[03:43:41] <jmkasunich> some comps wouldn't bother exporting it
[03:43:54] <jmkasunich> (for instance, mux2 has no possible error states, all inputs are legal)
[03:44:07] <SWPLinux> sure
[03:44:12] <jmkasunich> the list of error conditions would be in the components man page
[03:44:24] <SWPLinux> right
[03:44:39] <SWPLinux> just one more section in the manual
[03:44:46] <jmkasunich> the problem is that higher level stuff would have to understand the convention, and somehow identify all the relevant params, and poll them
[03:45:09] <SWPLinux> that's where the single flag for all of HAL is a good thing :)
[03:45:15] <SWPLinux> at least to start with
[03:45:19] <jmkasunich> a single global error code (part of the lib) would eliminate polling
[03:45:22] <jmkasunich> (what you said)
[03:45:42] <SWPLinux> well, one per comp is also relatively easy, isn't it?
[03:45:58] <jmkasunich> thinking
[03:46:04] <jmkasunich> actually, its not
[03:46:09] <SWPLinux> and the code to check all the flags can be in hal_lib, like the find_x_by_name
[03:46:19] <jmkasunich> it would be part of the comp structure
[03:46:20] <SWPLinux> ah - the same problem as the tmax thing
[03:46:32] <jmkasunich> but the realtime code doesn't get a pointer to the comp struct, only to instance data
[03:47:13] <SWPLinux> hmm. there is a convoluted way around that
[03:47:19] <jmkasunich> I'm sure
[03:47:20] <jmkasunich> ;-)
[03:47:21] <SWPLinux> heh
[03:47:33] <jmkasunich> one way:
[03:47:40] <SWPLinux> actually, there's a better way
[03:47:46] <SWPLinux> than the one I was thinking of
[03:47:54] <jmkasunich> hal_errorcode_new(comp_id, inst_num, &code)
[03:47:58] <SWPLinux> how about adding another hal allocator
[03:48:02] <SWPLinux> heh - beat me to it :)
[03:48:07] <jmkasunich> code is part of the instance struct just like a param or pin
[03:48:29] <jmkasunich> optional part of course
[03:48:38] <SWPLinux> sure. then the checker just walks that list
[03:49:15] <jmkasunich> you could have "halcmd checkerror" that would walk the list and print any non-zero values
[03:49:45] <jmkasunich> damn, still have to walk the list at runtime
[03:49:56] <SWPLinux> there needs to be a library method for that - non-halcmd code should be able to do it
[03:50:01] <SWPLinux> (easily)
[03:50:06] <jmkasunich> yeah, there would be
[03:50:16] <jmkasunich> and the halcmd would just be a wrapper for the api
[03:50:51] <jmkasunich> (believe it or not, halcmd was originally supposed to be a lightweight wrapper for the HAL api - parse commands, call the api, print results
[03:51:00] <SWPLinux> hmmm - do we need to add NML support for "configuration check" - to maintain the ability to use remote UIs?
[03:51:09] <SWPLinux> (I hope not)
[03:51:16] <jmkasunich> now halcmd is almost 4000 lines
[03:51:23] <SWPLinux> yeah - I rememberthat about halcmd
[03:51:48] <jmkasunich> the problem is that its easier to add something to halcmd than to the api
[03:52:24] <SWPLinux> there doesn't seem to be much looping in the API (other than find*) -which is a good thing
[03:53:02] <jmkasunich> yeah, the API needs to be reentrant and non-blocking
[03:53:16] <jmkasunich> because multiple processes might be trying to access the shmem at the same time
[03:53:49] <jmkasunich> whats missing from the API is a way to traverse lists
[03:54:12] <jmkasunich> because a single call has a hard time passing back a list of arbitrary length
[03:54:39] <jmkasunich> and multiple calls need to protect the list from alteration between calls
[03:55:26] <jmkasunich> part of the refactor was going to be adding find_first() and find_next(char *prev_name) calls
[03:55:38] <jmkasunich> find-next is safe if you use names
[03:56:11] <jmkasunich> even if the prev object was deleted between when you found it and when you call find_next, it will just return the next one in sort order
[03:56:37] <jmkasunich> but with a linear linked list, it goes as O(n^2)
[03:56:53] <SWPLinux> but if next is deleted before you use it ...
[03:57:08] <jmkasunich> not a problem - do everything by names
[03:57:27] <jmkasunich> I'm thinking about things like the halmeter selection list
[03:57:32] <SWPLinux> yep
[03:57:40] <jmkasunich> items can be deleted after they are added to the list but before you select them
[03:57:49] <jmkasunich> if so, it just says "item not found"
[03:57:51] <jmkasunich> or it should
[03:57:59] <jmkasunich> bet that hasn't been tested lately ;-)
[03:58:04] <SWPLinux> heh
[04:02:53] <SWPLinux> are cradek or jepler still with us?
[04:02:58] <SWPLinux> hello?
[04:03:00] <jmkasunich> probably hiding
[04:03:04] <SWPLinux> yeah ;)
[04:03:21] <SWPLinux> "mommy and daddy are fighting again" :)
[04:04:18] <jmkasunich> just tested halmeter
[04:04:22] <jmkasunich> it works
[04:04:43] <jmkasunich> if you remove the pin after the list is built, then select it, halmeter goes to its "displaying nothing" state
[04:04:46] <SWPLinux> ah - the "item not found" thing
[04:04:48] <jmkasunich> (same as when you start it)
[04:04:54] <SWPLinux> good deal
[04:05:34] <jmkasunich> also, if you delete the pin it is observing, it goes to that state
[04:06:14] <SWPLinux> does it look for the pin every update?
[04:06:38] <jmkasunich> I guess (I was actually expecting it to do something bad in the second test)
[04:07:08] <SWPLinux> yeah - it wasn't obvious to me how it avoided something bad
[04:07:30] <jmkasunich> I really don't feel like checking the code right now
[04:07:43] <SWPLinux> heh - no problem. just curious
[04:07:53] <jmkasunich> I never intended to get into a discussion tonight, I was going to do some lathe work
[04:08:08] <SWPLinux> sorry about that
[04:08:17] <jmkasunich> I'm gonna make a dummy fuse for the neutral pole of my input disconnect
[04:08:53] <SWPLinux> hmmm. other than the thrill of constructing something, wouldn't an insanely high current fuse do the same job?
[04:09:13] <jmkasunich> probably
[04:09:23] <jmkasunich> but the biggest available in that formfactor is 30A
[04:09:38] <jmkasunich> the main fuses are 10A time delay
[04:09:50] <jmkasunich> I found a 15A fast acting, but nothing bigger
[04:09:57] <SWPLinux> hmmm. halmeter survices from either dumb luck or very skilled and subtle programming
[04:10:01] <SWPLinux> survives
[04:10:09] <jmkasunich> the latter I'm sure
[04:10:14] <SWPLinux> heh :)
[04:10:20] <jmkasunich> now I'm curious
[04:10:32] <SWPLinux> the check is this:
[04:10:35] <SWPLinux> if (probe->pin != NULL) {
[04:10:36] <SWPLinux> if (probe->pin->name[0] == '\0') {
[04:10:38] <SWPLinux> /* pin has been deleted, can't display it any more */
[04:10:38] <SWPLinux> probe->pin = NULL;
[04:10:41] <SWPLinux> return 1;
[04:10:41] <SWPLinux> }
[04:10:55] <SWPLinux> so it relies on the memory not being used for soemthing else
[04:11:24] <SWPLinux> which is OK at this point, since deleted pin memory isnpins aren't reallocated
[04:11:32] <SWPLinux> ... isn't ...
[04:11:37] <SWPLinux> argh
[04:11:48] <SWPLinux> which is OK at this point, since deleted pin memory isn't reallocated
[04:12:34] <SWPLinux> even if it were, the new name would justpop up, since it does relad the name every refresh
[04:12:42] <jmkasunich> free_pin_struct() in hal_lib sets name[0] to "\0"
[04:12:54] <jmkasunich> and saves the pin struct on a free pin struct list for reuse
[04:13:08] <jmkasunich> so it may get reused, but always as a pin
[04:13:14] <SWPLinux> right - so it'll always be a pin
[04:13:42] <jmkasunich> I suppose you could delete it and then reuse it withing one update of the meter
[04:13:52] <jmkasunich> the value and name would change to the new pin, whatever that is
[04:14:05] <SWPLinux> yes. though it is smart enough to just display the new name
[04:14:07] <jmkasunich> strange for sure, but not a crash or segfault or anything nasty
[04:14:37] <SWPLinux> no, since it's looking at statically allocated memory that's being internally dished out
[04:15:02] <jmkasunich> I think halscope isn't quite so clever
[04:15:19] <jmkasunich> if you delete a signal, it will keep sampling from it
[04:15:29] <SWPLinux> actually, there's still a race condition where the name may be null after the check (pin gets deleted after check for \0, but before name is displayed)
[04:15:56] <jmkasunich> if you scope an unconnected pin, it samples from the "dummy" signal, if you later link the pin to a real signal, scope keeps sampling the dummy
[04:16:10] <SWPLinux> ah - that's a bummer
[04:16:42] <jmkasunich> you're right about the race
[04:16:54] <SWPLinux> there are several there, actually
[04:17:00] <jmkasunich> maybe the assignments to name_str and value_str should be before the test?
[04:17:15] <SWPLinux> well, that would be kinda backwards
[04:17:22] <jmkasunich> yeah
[04:17:29] <SWPLinux> the problem is that the check and the read are non-atomic (as a pair)
[04:17:40] <SWPLinux> and they aren't protected by locks
[04:17:44] <jmkasunich> and that will never change
[04:17:47] <SWPLinux> rigth
[04:17:50] <SWPLinux> right
[04:17:54] <jmkasunich> actually, it could change
[04:18:01] <jmkasunich> I could request the mutex
[04:18:05] <SWPLinux> hmmm
[04:18:29] <SWPLinux> actually, there are a couple of places where pointers from the pin struct are used
[04:18:56] <SWPLinux> err - nope. nevermind
[04:19:01] <jmkasunich> request it before the big if, and release it before calling GTK to display the strings
[04:19:48] <SWPLinux> you'd have to copy the strings out of the HAL data first
[04:20:24] <SWPLinux> the actual pointer into the HAL data is passed to the GTK code right now
[04:20:56] <jmkasunich> strncpy (name_buf, probe->pin->name, BUFLEN); instead of name_str = probe->pin->name;
[04:21:03] <SWPLinux> right
[04:21:35] <jmkasunich> it would also hold the mutex thru a call to snprintf, part of "data_value()"
[04:21:51] <SWPLinux> no - just copy the type and 32 bits of value out
[04:21:53] <SWPLinux> format it later
[04:21:56] <jmkasunich> I don't like calling library functions while holding the mutex
[04:22:15] <jmkasunich> copying isn't pretty if you don't know the type
[04:22:54] <SWPLinux> this isn't all that critical since the memory will always be valid (no segfaults)
[04:23:22] <jmkasunich> not entirely true,although the window is _very_ narrow
[04:23:24] <SWPLinux> just copy it to a 32-bit int, and then data_value can have it
[04:23:36] <SWPLinux> unless HAL is shut down, it will be true
[04:23:52] <SWPLinux> the pointer will point to accessible memory, which may hold bogus data
[04:23:56] <jmkasunich> it tests probe->pin->signal for zero, if zero then it reads the dummy (safe)
[04:24:08] <jmkasunich> if non-zero, reads the real signal, also safe
[04:24:42] <jmkasunich> but if it does the test, and then the pin is unlinked, probe->pin->signal will be zero
[04:24:49] <jmkasunich> null pointer dereference
[04:25:05] <SWPLinux> does the pointer get set to 0 on pin deletion?
[04:25:08] <jmkasunich> yes
[04:25:11] <SWPLinux> oh
[04:25:18] <jmkasunich> same as name gets set to '\0'
[04:25:22] <SWPLinux> got it
[04:25:34] <jmkasunich> free_pin_struct() in hal_lib.c does that
[04:25:36] <SWPLinux> ok
[04:25:43] <jmkasunich> mutex is the answer
[04:26:10] <jmkasunich> debatable wether the changes needed to avoid holding the mutex for the data_value() call are worthwhile
[04:26:17] <SWPLinux> eek. even worse, all the pointers get zeroes before the name
[04:26:25] <jmkasunich> oops
[04:26:28] <jmkasunich> I can fix that
[04:27:32] <jmkasunich> oh, wait - thats not a problem
[04:27:40] <jmkasunich> free_pin_struct is called under mutex protection
[04:28:04] <SWPLinux> ok - not a problem once there's a mutex call in halmeter ...
[04:28:20] <jmkasunich> the order is not a problem at all
[04:28:34] <jmkasunich> everything in free_pin_struct() can be considered atomic
[04:28:53] <SWPLinux> isn't that only true when things that looka t / modify stuff all use the mutex?
[04:29:00] <jmkasunich> duh, right
[04:29:09] <SWPLinux> phew :)
[04:29:23] <jmkasunich> I was thinking halmeter couldn't interrupt hal_lib while it had the mutex
[04:29:35] <jmkasunich> it just can't get the mutex while hal_lib has it
[04:29:42] <SWPLinux> I think I'd prefer strncpy to snprintf while holding the mutex
[04:30:17] <SWPLinux> and a simple copy of the data (since it's known to fit into a 32-bit int)
[04:30:59] <SWPLinux> does it make sense to add a union to one of the hal headers, containing the various types? ...
[04:31:00] <jmkasunich> well. I'm lazy
[04:31:06] <SWPLinux> I can do this stuff
[04:31:18] <jmkasunich> don't look up then
[04:31:35] <jmkasunich> popup_probe_window() holds the mutex while calling GTK code
[04:31:45] <SWPLinux> ah :)
[04:32:11] <SWPLinux> that stuff, I'll ignore :)
[04:32:12] <jmkasunich> it holds the mutex while building the list
[04:32:29] <SWPLinux> list population is a pain I'm not willing to undertake yet
[04:32:30] <jmkasunich> doesn't paint it onto the screen until it releases the mutex
[04:32:44] <SWPLinux> besides, the problem will go away once the hal refactor takes place :)
[04:32:46] <jmkasunich> well, I already added the mutex calls to refresh_value
[04:32:51] <SWPLinux> ok
[04:32:59] <SWPLinux> then you do it :)
[04:33:16] <SWPLinux> snprintf is likely much more lightweight than gtk list building
[04:33:22] <jmkasunich> yep
[04:33:26] <jmkasunich> I'm not gonna sweat it
[04:33:47] <SWPLinux> it's pretty infrequent anyway (in CPU time)
[04:34:09] <jmkasunich> 5 times a sec
[04:34:28] <jmkasunich> I'm more worried about code that can either a) block waiting for user input, or b) crash
[04:34:37] <SWPLinux> heh
[04:34:48] <jmkasunich> snprintf isn't real likely to do either
[04:35:37] <SWPLinux> nope
[04:38:13] <jmkasunich> on that note, time to turn a 1/2" bronze bolt into a fuse ;-)
[04:38:19] <SWPLinux> heh - have fun
[04:38:36] <SWPLinux> (not a very good fuse though)
[04:38:49] <jmkasunich> very high rating
[04:38:59] <SWPLinux> heh - large AC fuse ;)
[04:55:27] <A-L-P-H-A> jmkasunich, what's actually involved with making the step/dir for the mesa? I don't even know what's going on... I bought it for the bandwagon (and lack of speed that I have)...
[04:57:33] <tomp> i heard some of the coversation on halmeter, does it affect this symptom? ...
[04:57:36] <SWPLinux> it's not too hard to get going once all the "extra stuff" is in place
[04:57:55] <tomp> i init a widget with a value, open halmeter, halmeter says it's 0,
[04:58:07] <SWPLinux> extra stuff being the ability to make anything work on the mesa card (like regenerating identical files to what's in the stock config)
[04:58:07] <tomp> but 1 chnage on the widget and all isok
[04:58:48] <SWPLinux> tomp: could be - these are python userspace widgets?
[04:59:09] <tomp> pyvcp, so ... yes i think
[04:59:58] <SWPLinux> and the problem is that you load a widget (which creates a pin), then run halmeter and connect it to that widget, and halmeter displays 0 until you do something to the widget?
[05:00:07] <SWPLinux> err - connect it to that pin ...
[05:00:15] <tomp> exactly
[05:00:42] <SWPLinux> I'd say it's an initialization thing in the sidget code then
[05:00:45] <SWPLinux> widget
[05:01:39] <tomp> if it's initialization... let me check the pin, not the connected signal...
[05:01:49] <SWPLinux> if the pin exists before halmeter is run (which it must or you can't select it in the list), and it updates after there's a change, then halmeter is working correctly
[05:02:28] <SWPLinux> is this in all the widgets or just some of them?
[05:06:51] <jmkasunich> tomp: the halmeter issue that we just fixed was something that would be extremely rare
[05:07:10] <jmkasunich> and could only happen if you were deleting a widget while halmeter was looking at it
[05:07:44] <jmkasunich> if halmeter says your widget is doing something weird, then your widget is doing something weird
[05:11:48] <tomp> ok, this is something else
[05:12:26] <tomp> i had 5 widget, 3 in a vert frame and 2 in horz frame, only the 1st of the vert fram did this
[05:12:28] <tomp> then
[05:12:55] <tomp> i added another widgte to the vert frame, the prev bad one was ok, the new 1st is wrong
[05:13:13] <SWPLinux> sounds like an off-by-one error somewhere :)
[05:13:33] <tomp> i only copied the xml, so its not my xml description thats wrong
[05:13:35] <SWPLinux> can you pastebin the configs that do this?
[05:14:01] <tomp> will do
[05:17:35] <tomp> xml
http://pastebin.ca/321204 and my pyvcp_widgets.py is coming next
[05:17:42] <SWPLinux> ok
[05:19:29] <tomp> http://pastebin.ca/321207
[05:21:07] <tomp> fiddle the 1st widget in the vert frame by changing the <text> </text> to see this
[05:21:48] <SWPLinux> and how are you loading this file?
[05:22:01] <tomp> i can copy the cmd...
[05:22:23] <SWPLinux> did you replace pyvcp_test.xml with this file?
[05:22:32] <tomp> bin/pyvcp -c mydial jnk4.xml
[05:22:38] <SWPLinux> ok
[05:23:14] <tomp> no, the xml is in emc2-head's root
[05:23:36] <SWPLinux> ok - this is the same test file as before?
[05:24:15] <tomp> ? not, following before what
[05:24:58] <tomp> this file can show the error, a hack of this file can show the error also
[05:25:09] <SWPLinux> sorry - you did an imagebin of the knobs before, and there's a pyvcp_test file in the configs/sim dir (I think)
[05:25:29] <SWPLinux> so I naturally (erroneously) linked the two :)
[05:25:56] <SWPLinux> it comes up with a window with only a title for me - no widgets
[05:26:21] <tomp> oh, no this xml is slightly different, there's 1 more widget, and the .py has a couple fixes ( color, and an 'x' before the scael )
[05:26:32] <tomp> scale
[05:28:19] <tomp> maybe i show it to awallin tomorrow, you guys have been at it all day , he may be able to see it or explain it better
[05:28:45] <SWPLinux> I don't get any widgets at all, so I'm afraid I can't help for a bit :)
[05:29:30] <tomp> urf! i can run it, tho my checkout is maybe 2 days old
[05:29:54] <SWPLinux> lemme try with the original pyvcp_widgets.py
[05:30:30] <tomp> can you run the original? ( cvs xml & cvs pyvcp_widgets.py )
[05:30:37] <tomp> k
[05:31:15] <SWPLinux> no joy with the CVS version of pyvcp_widgets
[05:31:28] <tomp> k
[05:32:18] <tomp> hmm, i'm afeared of updating mine :)
[05:32:36] <SWPLinux> the pyvcp_demo file in configs/sim works ok
[05:33:09] <tomp> so the new dial is the bugger?
[05:33:09] <SWPLinux> oh - duh me. one sec
[05:33:15] <tomp> k
[05:34:01] <SWPLinux> no - me missing the '_' in pyvcp_widgets.py is the problem ;)
[05:36:22] <SWPLinux> um - the default for the first knob is 0. I'm not sure if there's a problem
[05:38:18] <tomp> the 1st is 'farfelnoogies' and is in the vert frame of 3, the problem is in the 4th in the xml, which is the 1st in the horizontal frame 'Kpk/min'
[05:38:32] <SWPLinux> ok
[05:39:38] <tomp> you'll need something like newsig jnk4dial float linkps mydial.anaout666 jnk4dial
[05:39:50] <SWPLinux> it reads 123.456 for me, without touching any widgets
[05:40:04] <tomp> right >it< read, but not halmeter
[05:40:17] <SWPLinux> hmmm - this is a question for jmkasunich
[05:40:25] <tomp> the widget looks right, but other processes would have wrong data
[05:40:27] <SWPLinux> no - halmeter connected to that pin reads the correct value
[05:40:42] <SWPLinux> this is an issue in HAL, not the widget itself
[05:41:09] <tomp> before you move it? my halmeter doesnt read right, reads 0 not 123.456 before i move widget
[05:41:41] <jmkasunich> ?
[05:41:51] <tomp> wether i connect to pin or to signal, reads 0 at first
[05:41:52] <SWPLinux> the pin reads correctly, but a signal connected to the pin won't until you move the knob
[05:42:01] <SWPLinux> ok - I see the pin reading correctly for me
[05:42:18] <SWPLinux> jmk - one sec. I may be wrong about the issue
[05:42:20] <jmkasunich> when does the widget write to the pin?
[05:42:31] <SWPLinux> that's the thing I was getting to
[05:42:40] <SWPLinux> I think it only writes when the knob is moved
[05:42:45] <jmkasunich> if ti only writes when you move the widget, you are gonna have issues
[05:42:55] <tomp> tomp thinks it writes to the pin at __init__
[05:43:10] <jmkasunich> at init, it writes to the pin, which is linked to the dummy signal
[05:43:14] <SWPLinux> but a signal connected to a writer should be pointing at the actual pin data, so it should get the value without the pin value being updated
[05:43:22] <jmkasunich> no
[05:43:25] <jmkasunich> there is no pin data
[05:43:29] <SWPLinux> ah - ok.
[05:43:32] <jmkasunich> pins are ptrs, signals have data
[05:43:36] <SWPLinux> right
[05:43:39] <jmkasunich> at init, pin points to a dummy sign
[05:43:41] <jmkasunich> sig
[05:43:45] <tomp> so I added updates to the tail of __init__
[05:44:03] <tomp> same thing happened
[05:44:10] <jmkasunich> I think the original vcp updated everything several times a second whether the user touched the widgets or not
[05:44:13] <SWPLinux> right - that's expected
[05:44:33] <A-L-P-H-A> jmkasunich, above. :)
[05:44:54] <jmkasunich> because if you inlink the pin from signal A and connect it to signal B, you want to update signal B right away, not wait for the user to move the widget
[05:44:54] <SWPLinux> ok, so does it make sense to copy the pin dummy value to the signal value when a writer is connected to a signal?
[05:45:23] <jmkasunich> no, widgets should write to their outputs on a regular basis
[05:45:38] <SWPLinux> UI widgets should possibly be spared that requirement
[05:46:04] <SWPLinux> actually, all should be spared that - it could save a fair amount of CPU time
[05:46:23] <SWPLinux> if (nothing has changed) return;
[05:46:25] <jmkasunich> RT widgets by their very nature are periodic, they read their inputs and write their outputs
[05:47:45] <SWPLinux> although the BASE_PERIOD has to account for the longest runtime, the overall usability of the computer will be better if the high frequency tasks take less time
[05:47:47] <jmkasunich> how much CPU time is needed to do *pin = value; ?
[05:47:53] <SWPLinux> depends on cache
[05:48:06] <SWPLinux> and for I/O ports, if nothing has changed, that's very significant
[05:49:17] <jmkasunich> for _some_ limited class of drivers, there might be _some_ argument for keeping old values and comparing them to new, and not writing the hardware every time
[05:49:25] <jmkasunich> but we're not even gonna talk about that
[05:49:37] <SWPLinux> heh
[05:50:01] <SWPLinux> stepgen/parport would be the best candidate, I think
[05:50:02] <jmkasunich> on the gui side, if you have any toolkit at all, the time spend slinging pixels and doing other such stuff makes the assignment negligable
[05:50:10] <SWPLinux> true
[05:50:12] <jmkasunich> parport you mean
[05:50:15] <jmkasunich> stepgen always has things to do
[05:50:46] <SWPLinux> parport with stepgen driving it would be the combination that would have the most benefit
[05:51:04] <jmkasunich> parport still has to read all the bit signals and either individually look for changes, or go ahead and assemble the bytes, the look for changes and decide whether to output
[05:51:33] <SWPLinux> until the step rate gets very high, the machine wouldn't feel as sluggish
[05:51:50] <SWPLinux> that's true, but it's the back-to-back I/Os that cause the bus stalls
[05:51:51] <jmkasunich> if its an ISA (or maybe mobo/southbridge) parport, you might save a uS or so by avoiding the outb
[05:52:11] <tomp> can i (should i ) force an update? ( 1 step fwd & 1 step back would get the right data on the pin )
[05:52:25] <SWPLinux> tomp: the idea is to periodically refresh anyway
[05:52:32] <jmkasunich> tomp: you should write data to the pin on a regular basis
[05:52:42] <SWPLinux> I'm not sure there's a timer in the code at this point though
[05:53:36] <tomp> i didnt see anything in pyvcp_widgets.py
[05:53:43] <jmkasunich> no poll loop or anything?
[05:53:49] <SWPLinux> it's event based
[05:53:54] <SWPLinux> (I bet)
[05:54:08] <jmkasunich> I think in gtk, you can register a timer event and a callback function for it
[05:54:18] <jmkasunich> I have it set for 10 times a second or somethgin like that
[05:54:43] <SWPLinux> python must have a similar capability, since AXIS uses it for backplot
[05:54:43] <tomp> yes, there could be a timer callback in tkinter
[05:55:19] <jmkasunich> when a widget gets a "user moved me" callback, the handler should write to the HAL pin and a local variable
[05:55:27] <jmkasunich> the timer callback should copy the locals to the pins
[05:55:40] <tomp> tkinter can watch for a change in a data ( not just events) and cause a callback trigger
[05:55:59] <tomp> right, its a periodic update function
[05:56:05] <SWPLinux> that would be useful for updating widgets when the data changes
[05:57:00] <jmkasunich> here's the VCP version:
[05:57:00] <tomp> right ( 2 ideas crossed there ) need periodic updating of pins
[05:57:00] <jmkasunich> /* arrange for periodic call of heartbeat() (every 100mS) */
[05:57:00] <jmkasunich> gtk_timeout_add(100, heartbeat, NULL);
[05:57:38] <jmkasunich> how does pyvcp update leds when the bit pin changes?
[05:57:49] <jmkasunich> VCP polled the bits in the heartbeat routine
[05:58:39] <tomp> led changes on event
[05:59:25] <jmkasunich> event is what?
[05:59:44] <jmkasunich> a change in the value of a pin? how can that trigger an event?
[06:00:15] <SWPLinux> tkinter provides that
[06:00:36] <jmkasunich> how can it tell?
[06:00:45] <jmkasunich> the pin is just a memory location in shmem
[06:01:01] <jmkasunich> nothing short of a debugger can trigger on a write to a memory location by another process
[06:01:07] <jmkasunich> it must be polling that location somehow
[06:01:20] <SWPLinux> I guess you give it a pointer to the data, and it automagically creates a polling loop for you :)
[06:01:30] <jmkasunich> could be
[06:01:31] <SWPLinux> it's all polling, regardless of what they tell you
[06:01:43] <SWPLinux> there's no hardware to interrupt the CPU when a bit of data changes
[06:01:48] <jmkasunich> exactly
[06:02:02] <jmkasunich> handling of keyboard or mouse input might not be polled
[06:02:23] <jmkasunich> the task might block on keyboard input, and get awakened when the keyboard interrupt makes data available
[06:02:34] <jmkasunich> but no such niceness for hal pins
[06:02:47] <SWPLinux> yep
[06:02:48] <jmkasunich> dammit, 1am again
[06:02:49] <SWPLinux> heh
[06:02:53] <jmkasunich> goodnight
[06:02:55] <SWPLinux> see you
[06:03:51] <tomp> your right, it watches for change on the pin, and compares that to a prev state to detect change, the led has an input pin , not what i expected
[06:04:03] <tomp> goodnight jmk
[06:04:13] <SWPLinux> hmmm - what calls the code that looks for the change?
[06:04:53] <tomp> the led class sets up that relation ( chnage of state = funct call )
[06:06:03] <tomp> no, again not what i expect... the class has an (expected/manditory) update method which does the checking
[06:06:51] <tomp> the class only has __init__ and update()
[06:07:11] <SWPLinux> hmmm
[06:10:04] <tomp> tomp looks up tkinter and timerstuffe
[06:12:15] <tomp> no thie solution isnt in pyvcp_widgets.py, it's lower than this... all widgets should have the neccesary update function run periodicly
[06:13:15] <tomp> now what body of code makes the widget from the xml desxcription & pyvcp_widget.py characteristics....?
[06:13:34] <SWPLinux> import HAL ...
[06:13:39] <SWPLinux> I wonder if that's it
[06:15:58] <tomp> pyvcp_parse.py has an updater func that runs every 100ms on each widget...
[06:16:17] <SWPLinux> ok, so the update function just has to write the value to the hal data then
[06:16:41] <SWPLinux> ah yes - import time ...
[06:20:11] <SWPLinux> ok. just replacing the 'pass' statement with this fixed it:
[06:20:30] <SWPLinux> self.pycomp[self.halpin] = self.faccumul8r
[06:22:14] <tomp> i'm too literal, i kept seeing that notice at the ends read like ( no code needed here, i'm event driven ) doh!
[06:22:23] <SWPLinux> heh
[06:22:31] <SWPLinux> update is an event, I gues s:)
[06:22:35] <SWPLinux> guess :)
[06:22:38] <SWPLinux> there!
[06:23:39] <tomp> wait, this only happens on the 1st widget in a horizontal frame & the fix is to change the update() ??? well i gonna try it ...
[06:24:04] <SWPLinux> I bet it happens everywhere, but just wasn't noticed
[06:24:24] <SWPLinux> either that or there's a problem with the first widget getting updated :)
[06:26:33] <tomp> acts the same way for me, what did you see change?
[06:26:45] <SWPLinux> well, I;m not sure it represents a change, actually
[06:27:11] <SWPLinux> I now have a signal that's persistent across runs of pyvcp
[06:27:23] <SWPLinux> lemme just check to be sure - one sec
[06:28:09] <SWPLinux> remember - in the file you sent me, the first widget has a default of 0.
[06:28:20] <SWPLinux> I changed it to something else
[06:28:44] <SWPLinux> when I load the file and connect the signal, the value changes in halmeter immediately
[06:29:53] <SWPLinux> ok - I changed that line back to "pass", and now the signal doesn't update
[06:29:53] <tomp> yes, for the 1st widget, not for the widget that is the problem, the one 'Kpk/min' is the problem
[06:30:10] <SWPLinux> heh - silly me :)
[06:30:14] <tomp> strike that while i read you r comment...
[06:33:53] <SWPLinux> ok - it looks like none of them were working with update = "pass"
[06:34:07] <SWPLinux> and all of them are when update actually does something
[06:34:39] <SWPLinux> I can check this by linking the signal to each pin in turn, and watching the halmeter display change
[06:35:02] <SWPLinux> this is what I do to check it:
[06:35:24] <SWPLinux> 1) start up a halcmd window, for ease of use
[06:35:52] <SWPLinux> 2) create a float signal
[06:36:06] <SWPLinux> 3) load up a halmeter, and connect it to the signal
[06:36:22] <SWPLinux> 4) load the xml file with pyvcp (from a separate shell, but that probably doesn't matter)
[06:37:09] <SWPLinux> 5) from the halcmd window, show (just to make sure the pins are all there and at the values I expect)
[06:37:45] <SWPLinux> 6) link the signal to the first pin (anaout2), and verify that the meter reading changes
[06:38:09] <SWPLinux> 7) unlink the signal, and go back to 6) for the next pin
[06:38:26] <tomp> right, i did same, and it does work now
[06:38:36] <SWPLinux> this sequence works correctly with the change to update, but not if I change that back to "pass"
[06:38:42] <SWPLinux> yay!
[06:38:44] <SWPLinux> :)
[06:38:54] <tomp> right, youda man
[06:39:05] <SWPLinux> yoda, man :)
[06:40:05] <tomp> did you know yoda programmed in forth? listen to him talk luke the the fence painted must be
[06:40:20] <SWPLinux> on wax off wax
[06:40:21] <SWPLinux> oh wait :)
[06:40:58] <tomp> ?
[06:41:23] <SWPLinux> sorry -that was Mr. Miyagi
[06:41:35] <SWPLinux> "Wax on, wax off"
[06:41:45] <tomp> :)
[06:41:46] <SWPLinux> Miyagi-yoda
[06:42:19] <tomp> woof! i'm off to update the updates
[06:42:26] <SWPLinux> have fun
[06:42:32] <SWPLinux> I'll leave that to you to commit :)
[06:43:13] <tomp> thanks, it was beyond me! and yes, i learn to commit ( damn this emc turning into a woman )
[06:43:24] <SWPLinux> heh
[06:43:40] <SWPLinux> commiting with a woman is significantly harder than with EMC :)
[06:44:49] <tomp> a thought: soem of the confusio was becasue the widget had text on it with the ;correct value' but, for the wrong reason,
[06:45:20] <SWPLinux> well, that's an artifact of how the component is written (and bad, IMO)
[06:45:33] <tomp> so the widget should set thier internal data, and be updated from thier internal state
[06:45:37] <SWPLinux> the displayed text should be derived from the output value, not the other way around
[06:45:43] <tomp> not just printed
[06:45:42] <SWPLinux> yep
[06:45:49] <tomp> k
[06:46:06] <tomp> again, thanks
[06:46:10] <SWPLinux> well, the graphical update only needs to be done when the control is cahnged, so that's not needed in the update function
[06:46:32] <tomp> right, i mean the value display
[06:46:42] <SWPLinux> but the widget should have a "value", and the text on the display should be updated from that
[06:46:58] <tomp> right
[06:47:16] <SWPLinux> that may be more difficult though, since you'd have to add data members that the parser can set
[06:48:47] <tomp> as long as the data members are internal, and what the user (and hal ) sees is a result of the update, then ok
[06:49:06] <tomp> then it will be ok
[06:49:08] <SWPLinux> ok. my understanding of the parser is - erm - minimal :)
[06:49:46] <SWPLinux> by the way - what are the square brackets for in the test xml file?
[06:49:55] <tomp> well, we have a way to tell when it's right, that's half the battle :)
[06:50:02] <SWPLinux> heh
[06:50:22] <tomp> i duuno what they're for, i figure thats in the parser too
[06:50:38] <SWPLinux> well, it works with pyvcp_demo.xml, which doesn't have them
[06:51:58] <tomp> moof! more i dont know :(
[06:52:13] <SWPLinux> heh. I thought you put them there for a reason :)
[06:52:42] <tomp> i'm pretty sure my xml didnt fly without them
[06:53:49] <SWPLinux> it seems to work with or without
[06:54:02] <SWPLinux> I took them off one component and it still shows up and appears to work
[06:54:29] <tomp> i also, they are re-dumb-dant
[06:54:51] <SWPLinux> heh
[06:57:42] <tomp> all sqr brkts removed & all widgets ok
[06:57:58] <SWPLinux> cool
[06:59:10] <tomp> thanks again, see you tommorow
[14:51:20] <jepler> SWPLinux: wax dup on off
[14:51:35] <SWPadnos> heh
[15:05:02] <cradek> I need to and together six hal bits - is match8 the easiest way?
[15:07:46] <SWPadnos> that or make an and6 :)
[15:08:09] <SWPadnos> ideally, the various logic blocks would have definable width
[15:08:18] <cradek> yeah I noticed that too :-)
[15:09:15] <SWPadnos> with all of them split out as comps, that should be easier (I think)
[15:17:08] <jepler> SWPLinux: "comp" doesn't allow that kind of flexibility, unfortunately.
[15:17:19] <SWPadnos> bummer
[15:19:21] <jepler> I know
[15:20:59] <SWPadnos> I don't recall exactly why that is. is it that there's no support for cmodule parameters or that there's no way to programmatically decide what to export?
[15:21:13] <jepler> SWPLinux: the latter
[15:21:16] <SWPadnos> ok
[15:21:24] <jepler> all the pins in the top section are always created
[15:21:47] <SWPadnos> right - there have to be parameters or you can't specify how many comps to create
[15:22:27] <cradek> match8.0.in (cascade in) defaults to false if it's unconnected - is that bogus or is it my fault for not reading all the manpage right away?
[15:23:53] <cradek> (or both)
[15:25:13] <SWPLinux> it seems to be bogus
[15:26:19] <jepler> 32769 bit IN FALSE match8.0.in
[15:26:29] <jepler> it's not different from the 'blocks' version, fwiw
[15:28:49] <cradek> seems like if you're not cascading, you shouldn't have to mess with that pin
[15:29:32] <SWPLinux> that's why I haughtily declared it bogus :)
[15:33:05] <cradek> oh, I didn't compile, that's why last night's bugfixes aren't working
[15:34:33] <cradek> ah much better!
[15:39:04] <jepler> I'll commit a fix to match8 if the current behavior sounds funny to everyone
[15:39:15] <cradek> thanks
[16:15:10] <cradek> morning ray
[16:15:53] <rayh> Hi Chris.
[16:20:03] <cradek> since I was silly enough to promise a release date, I've dived into testing now. we're fixing a few things but it's looking really good.
[16:25:53] <rayh> That's good news.
[17:55:49] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[20:50:43] <alex_joni> awallin: how far is pyvcp?
[20:52:09] <awallin> alex_joni: the basic widgets are there, they layout isn't as pretty as it could be
[20:52:28] <alex_joni> ok, so is it ready for 2.1.x ?
[20:52:35] <awallin> there's one ugly place, I think for radiobutton, where instead of being event driven it does polling at 100ms intervals
[20:52:43] <cradek> can you get the basic widgets into the 2.1 branch?
[20:52:50] <awallin> yes I think so
[20:52:57] <awallin> it would be nice to fix radiobutton first
[20:53:21] <alex_joni> awallin: the schedule says 2 more days till 2.1.0
[20:53:41] <cradek> we have a schedule?
[20:53:43] <alex_joni> well.. + a few more days for packaging and actual release
[20:53:51] <alex_joni> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Emc2.1.0
[20:53:55] <alex_joni> cradek: I was looking at that
[20:54:10] <alex_joni> I think jmk said we want < 1 Feb 2007
[20:54:13] <cradek> I was hoping for packages by end of month, that's 2 weekends
[20:54:18] <cradek> yes that's what I "promised" on the list
[20:54:42] <alex_joni> but that means we should stop adding things to emc2.1 this weekend
[20:54:49] <cradek> that's probably a good idea
[20:55:03] <cradek> because we'll probably need that last weekend for packaging etc
[20:55:03] <alex_joni> that's why I wrote there 21.1.2007
[20:55:07] <cradek> ok
[20:55:30] <alex_joni> might have been bad wording a few lines up
[20:55:46] <alex_joni> cradek: I saw you started testing too..
[20:56:02] <cradek> yes quite a bit
[20:56:11] <alex_joni> how does it feel?
[20:56:17] <cradek> better now :-)
[20:56:23] <alex_joni> nice :)
[20:56:28] <cradek> fixed a few things. I have not tried the realtime packages yet.
[20:58:04] <cradek> we decided 'no' on halcmd net right?
[20:58:52] <SWPadnos> that would be a bummer
[20:59:13] <alex_joni> I didn't know we decided..
[20:59:22] <alex_joni> maybe jmk did?
[20:59:41] <SWPadnos> it makes sense to have net, since it doesn't change any other behaviors
[20:59:53] <SWPadnos> I thought jmk wanted to include net, and deprecate linkpp
[21:00:05] <cradek> I think he started to backport it, but rewrote half of halcmd instead
[21:00:23] <SWPadnos> heh - that was an implementation problem, not a philosophical one :)
[21:00:51] <cradek> I like net, but not if it destabilizes hal
[21:01:28] <cradek> I guess we better get busy and decide this weekend
[21:01:35] <cradek> we're running out of time fast
[21:01:54] <SWPadnos> net has nothing to do with the other stuff - it just triggered a more general code review
[21:02:16] <cradek> is that rewritten stuff going in 2.1?
[21:02:46] <SWPadnos> most of the recent changes were bugfixes, I think
[21:02:53] <alex_joni> guess then yes
[21:03:10] <SWPadnos> the discussion last night hasn't rtesulted in any code yet, I think (other than the little bugfix for halmeter)
[21:08:57] <awallin> lines 285 to 304 describe the thing I wanted to fix before pyvcp can go into 2.1:
http://cvs.linuxcnc.org/cvs/emc2/lib/python/pyvcp_widgets.py?annotate=1.20
[21:12:18] <alex_joni> I think that counts as a bugfix for lateron
[21:13:06] <SWPadnos> you still need to update the pin periodically anyway
[21:13:24] <awallin> and tomp did some work on a 'dial' widget, but that could wait also
[21:14:00] <awallin> SWP: why? a widget that sets the value of a pin needs to update the pin only when the user does something to change the value - not every 100ms neccessarily
[21:14:18] <alex_joni> isn't it IO ?
[21:14:28] <SWPadnos> except that a signal doesn't "automatically" get the new value when it's connected to the pin
[21:14:38] <awallin> pycomp.newpin(c_halpin, HAL_BIT, HAL_OUT)
[21:14:58] <SWPadnos> the signal is what allocates storage for the value, so the writer component needs to write to the signal data even if the user hasn't changed the widget
[21:15:43] <awallin> I don't follow. this is an OUT pin from my component
[21:15:48] <SWPadnos> I understand that
[21:16:01] <SWPadnos> a HAL pin contains a pointer to data
[21:16:21] <SWPadnos> when the pin isn't connected to a signal, that pointer points to a dummy location in the pin struct
[21:16:37] <SWPadnos> so you're writing to nothing important until a signal is connected
[21:16:53] <SWPadnos> a HAL signal struct contains memory to store the signal value
[21:16:53] <alex_joni> yeah, but the dummy location value is copied over when you link the signal
[21:16:59] <SWPadnos> no it isn't
[21:17:02] <alex_joni> are you sure?
[21:17:05] <SWPadnos> yes
[21:17:15] <alex_joni> hmm.. that seems odd to me
[21:17:42] <SWPadnos> it seemed that way to me as well, but if you look at the log of my discussion with jmk last night, you'll see :)
[21:17:42] <awallin> I've tested the widgets mostly with halmeter
[21:18:10] <awallin> I haven't probably tried linking a signal to each widget yet
[21:18:12] <SWPadnos> right. do this: run halcmd and make a set of bit signals
[21:18:27] <awallin> so is there a difference between linking signals and watching with halmeter?
[21:18:27] <SWPadnos> load up a few halmeters, and connect them to the signals
[21:18:33] <SWPadnos> yes
[21:18:44] <SWPadnos> halmeter loks at the dummy value in the pin struct
[21:18:51] <SWPadnos> (if you meter the pin)
[21:19:04] <awallin> from a user perspective, that doesn't sound right
[21:19:06] <SWPadnos> if you connect to a signal, it looks at the "real" data in the signal struct
[21:19:09] <SWPadnos> I agree
[21:19:57] <SWPadnos> jmk pointed out that pins write their values periodically, so you shouldn't have to do that at connect time
[21:20:07] <alex_joni> data_ptr_addr = SHMPTR(pin->data_ptr_addr);
[21:20:07] <alex_joni> comp = SHMPTR(pin->owner_ptr);
[21:20:08] <alex_joni> data_addr = comp->shmem_base + sig->data_ptr;
[21:20:07] <alex_joni> *data_ptr_addr = data_addr;
[21:20:08] <SWPadnos> I don't remember what the downside is though
[21:20:19] <alex_joni> that's from hal_link()
[21:20:36] <SWPadnos> uh - huh. that copies an address to a pointer
[21:20:51] <awallin> i'm firing up the vm now to try this
[21:21:58] <alex_joni> SWPadnos: if I'm understanding that snip of code right.. it gets the address of the pin dummy place, and replaces that pointer to the signal data place
[21:22:22] <alex_joni> but the new value will be the default value for the signal
[21:22:33] <SWPadnos> correct. that points the pin data pointer at the signal data, but doesn't replace the signal data with the pin dummy data value
[21:22:48] <alex_joni> that strikes me as a bug ..
[21:22:52] <alex_joni> imagine I do this:
[21:23:09] <alex_joni> setp iocontrol.0.spindle-on 1
[21:23:19] <SWPadnos> add the one-liner *data_addr = pin->dummy_value ...
[21:23:24] <alex_joni> newsig spindleon bit
[21:23:24] <SWPadnos> (or similar)
[21:23:37] <alex_joni> linksp spindleon iocontrol.0.spindle-on
[21:23:50] <alex_joni> linksp spindleon parport.0.pin-15-out
[21:24:05] <alex_joni> I would have never expected to have a 0 on the signal
[21:24:05] <SWPadnos> that will work, because iocontrol rewrites that bit periodically (I think)
[21:24:19] <SWPadnos> it'll be zero until the next time the motion thread executes
[21:24:37] <alex_joni> I see..
[21:24:56] <alex_joni> well. it won't work because the setp will be overwritten with the internal value of iocontrol..
[21:24:56] <SWPadnos> here's the sequence of steps I used last night to check the knob widget (modify as appropriate for the radiobuttons):
[21:25:05] <alex_joni> probably a bad example :)
[21:25:14] <SWPadnos> 06:35:24 <SWPLinux> 1) start up a halcmd window, for ease of use
[21:25:17] <SWPadnos> 06:35:52 <SWPLinux> 2) create a float signal
[21:25:17] <SWPadnos> 06:36:06 <SWPLinux> 3) load up a halmeter, and connect it to the signal
[21:25:20] <SWPadnos> 06:36:22 <SWPLinux> 4) load the xml file with pyvcp (from a separate shell, but that probably doesn't matter)
[21:25:20] <SWPadnos> 06:37:09 <SWPLinux> 5) from the halcmd window, show (just to make sure the pins are all there and at the values I expect)
[21:25:23] <SWPadnos> 06:37:45 <SWPLinux> 6) link the signal to the first pin (anaout2), and verify that the meter reading changes
[21:25:23] <SWPadnos> 06:38:09 <SWPLinux> 7) unlink the signal, and go back to 6) for the next pin
[21:25:27] <SWPadnos> any of the RT comps will be a bad example :)
[21:26:37] <SWPadnos> if you click the radiobuttons, the signal will change
[21:26:56] <SWPadnos> actually, to see the effect, run 2 halmeters, one on the signal and one on the pin :)
[21:27:17] <awallin> works just fine with jogwheel, and jogwheel doesn't have any periodic updating
[21:27:42] <awallin> now I have a.jogwheel.0.count(a pyvcp pin) -> b (float signal)
[21:28:02] <awallin> and I'm looking at both with halmeter. both show the same value and change correctly when I jog the wheel
[21:28:43] <SWPadnos> of course. the issue is that if you disconnect the wheel and change the value, then reconnect and *don't* change the value, the signal will not "snap" to the new value when you reconnect it
[21:29:39] <awallin> so HAL is not 'hot-plugable'
[21:30:15] <awallin> alex_joni: how do I do a 2.1.0 checkout ?
[21:30:23] <SWPadnos> it is, but it's up to the component writers to make sure that output pins are refreshed periodically
[21:30:43] <SWPadnos> that's part of the reason that there's a 100ms update with the python lib ...
[21:30:55] <alex_joni> awallin: cvs ... co -rv2_1_branch -d emc2.1 emc2
[21:32:37] <SWPadnos> I think it would be better to have signals get the pin value at connect time (for writers only), but we'll have to gang up on jmkasunich for that to happen :)
[21:33:52] <awallin> alex_joni: and then I just copy over my files to the 2.1 tree, do cvs add and the cvs commit ?
[21:34:06] <alex_joni> awallin: something like that
[21:34:19] <alex_joni> I usually do lots of cvs diff's in the process :)
[21:34:35] <jepler> awallin: "cvs up" as a mode for incorporating changes from another version of a file
[21:34:57] <jepler> "cvs up -jREV filename" or "cvs up -jREV1 -jREV2 filename"
[21:35:21] <jepler> the first adds all the differences from the common ancestor up to REV and puts them in filename
[21:35:33] <jepler> the second finds all the differences after REV1 up to REV2 and puts them in filename
[21:35:49] <jepler> so to add a file from the trunk to a branch, use "cvs up -jHEAD filename"
[21:36:04] <jepler> and to take the differences from revision 1.13 to the branch, use "cvs up -j1.12 -j1.13 filename"
[21:36:19] <jepler> review (with 'cvs diff') and test, then check in like normal
[21:36:49] <alex_joni> does that work if the file doesn't exist on the branch?
[21:38:06] <awallin> ? someone already put pyvcp into the 2.1 branch
[21:38:55] <alex_joni> remind me.. where is it located?
[21:39:09] <jepler> awallin: the "co" line that alex_joni showed you created the checkout in the directory "emc2.1", not "emc2". Did you change to the right directory?
[21:39:30] <jepler> alex_joni: yes, "cvs up -jREV filename" will add the file on the branch if it was created on TRUNK after the branch
[21:39:39] <awallin> alex_joni: lib/python has vcpparse.py and pyvcp_widgets.py and src/hal/user_comps has pyvcp.py
[21:39:54] <alex_joni> awallin: make sure you are in the folder emc2.1
[21:40:04] <alex_joni> the command I gave you created a different dir
[21:40:08] <awallin> I think I was..
[21:40:13] <alex_joni> so as not to overwrite your TRUNK
[21:40:31] <alex_joni> http://cvs.linuxcnc.org/cgi-bin/cvsweb.cgi/emc2/lib/python/?only_with_tag=v2_1_branch
[21:40:42] <alex_joni> there is no pyvcp there.. yet TRUNK has some files
[21:40:58] <SWPadnos> should I check in the version with periodically updating knobs?
[21:41:29] <awallin> SWPadnos: did you go through all event driven widgets?
[21:41:37] <SWPadnos> no - only the knobs needed the change
[21:41:57] <awallin> and which one is 'knobs' ? radiobutton?
[21:42:01] <SWPadnos> well - I looked, and any widget that had an update function with "pass" got changed (which ended up being only the knobs)
[21:42:14] <SWPadnos> hmmm - one sec
[21:42:50] <alex_joni> well.. I'm heading for bed
[21:42:51] <SWPLinux> pyvcp_dial
[21:42:55] <awallin> alex_joni: that's strange, is the command yo wrote earlier correct: font size="3">cvs ... co -rv2_1_branch -d emc2.1 emc2
[21:43:06] <awallin> or should I delete the last 'emc2'
[21:43:10] <alex_joni> np
[21:43:12] <alex_joni> no
[21:43:17] <alex_joni> the -r is the revision
[21:43:19] <SWPLinux> this was from tomp, so it's probably different from what you've got
[21:43:22] <alex_joni> the -d is the destination dir
[21:43:39] <alex_joni> and the last emc2 is the name of the module you want to check out
[21:43:57] <SWPLinux> and make sure you put the "-d emc2.1" between co and emc2
[21:44:05] <alex_joni> awallin: wherever you were when you ran that command you must have a folder called emc2.1
[21:45:04] <awallin> I might have got HEAD accidentaly...
[21:45:07] <awallin> trying again
[21:45:29] <alex_joni> you can check by looking at emc2/CVS/Tag
[21:46:44] <jepler> or "cvs status filename"
[21:46:49] <jepler> $ cvs status README
[21:46:51] <jepler> Sticky Tag:v2_1_branch (branch: 1.9.8)
[21:51:39] <awallin> ok, now there's a basic version of pyvcp in 2.1, more fancy development can go into HEAD
[21:57:30] <alex_joni> cool
[21:58:24] <awallin> maybe there could be a 'sim-pyvcp-halui' demo config included?
[21:58:41] <awallin> I haven't made one yet though...
[21:58:55] <cradek> I think it would be nice to have a demo
[21:59:02] <SWPadnos> in general, are there objections to adding components to pyvcp (even in the stable branch)?
[21:59:45] <SWPadnos> the reason I ask is that they would generally not have an impact on other widgets, and have no effect unless someone adds them to an .xml file ...
[22:00:51] <cradek> I'd like for us to not add anything new after this weekend. we need to work on packaging, and new files disrupt that work
[22:01:01] <awallin> SWPadnos: I don't have any objections, as long as the widgets are sensible (i.e. not much overlap with an existing widget, or if there is overlap it might be better to improve the existing one)
[22:01:12] <SWPadnos> sure
[22:01:30] <cradek> (I'm just talking about the branch of course)
[22:01:37] <SWPadnos> though I'd not make changes to esxisting widgets in the stable branch - that represents a change in "API"
[22:01:46] <SWPadnos> ok
[22:01:57] <SWPadnos> (sorry - missed your comment there cradek)
[22:02:38] <awallin> people(2.1.0 users) who want the latest pyvcp can easily replace one or two files from HEAD if they want
[22:03:03] <SWPadnos> people (2.1.0 users) mostly don't know what CVS is :)
[22:03:33] <awallin> well, theres web acces now, so you can maybe just point them to the right page
[22:03:42] <SWPadnos> heh
[22:03:59] <jepler> one problem with that is that a new version they download will get blown away if we make a bugfix release
[22:04:04] <jepler> (replaced with copies from the new package)
[22:04:17] <SWPadnos> it's OK with me either way - I just wanted to see what the general opinion of that would be
[22:06:00] <jepler> I have a feeling cradek will be a hardline "bugfix only" type about this one
[22:06:10] <cradek> that's me
[22:06:59] <SWPadnos> heh
[22:07:01] <cradek> that's what made 2.0 so good. not once did we introduce a new bug.
[22:07:28] <SWPadnos> ok. so the message here is to put in partially functional skeletons for anything I may want in 2.1 before the end of the weekend :)
[22:07:40] <jepler> SWPadnos: that's right -- then you can tell cradek it's a bugfix
[22:07:46] <SWPadnos> right
[22:07:50] <cradek> only if you don't let me know about that plan ... oops
[22:07:55] <jepler> cradek: what about when I get the '8255 driver finished?
[22:07:57] <SWPadnos> ok. I won't
[22:08:00] <SWPadnos> I
[22:08:16] <cradek> jepler: this weekend?
[22:08:20] <SWPadnos> I'll explain all the bugs away with my complete lack of python knowledge
[22:08:22] <awallin> and all the m5i20 activity planned?
[22:08:25] <jepler> awallin: that's a 2.2 thing
[22:08:37] <jepler> unfortunately
[22:08:45] <jepler> but if we waited for all the features to be ready we'd never get another version out
[22:09:00] <cradek> maybe the thing we should concentrate on is not waiting so damn long for the 2.2 branch
[22:09:15] <cradek> if we get a couple neat things done, branch and release
[22:09:32] <jepler> we could set a goal of "a little after fest"
[22:09:57] <cradek> mesa stepgen and rigid tapping? release!!
[22:09:58] <jepler> fest will bring new features to the TRUNK -- or at least I hope it will
[22:10:04] <cradek> right
[22:10:23] <SWPadnos> polygon turning :)
[22:13:30] <alex_joni> cradek: I still have to backport jon's changes to the uxc driver
[22:18:43] <alex_joni> but that's for tomorrow night..
[22:18:49] <alex_joni> fading fast now
[22:18:51] <alex_joni> good night all
[22:37:56] <lerneaen_hydra> 'night all
[22:38:08] <lerneaen_hydra> oops
[22:38:12] <lerneaen_hydra> wrong chan