#emc-devel | Logs for 2007-05-13

[00:18:27] <petev> jepler, u there?
[01:00:46] <jepler> petev: off and on ...
[01:00:57] <petev> I have an idea
[01:01:12] <petev> it seems like many of the hal comps are getting a lot of params that need setting
[01:01:13] <jepler> what's that?
[01:01:23] <petev> it would be nice to have some graphical way to do it
[01:01:52] <petev> what would it take to make a gui tool that could parse an xml description of the comp and show widgets for param adjustment?
[01:02:00] <petev> I could send you an example of the xml
[01:02:06] <petev> does that sound possible?
[01:02:22] <jmkasunich> the .comp file is already a representation of the comp, why would you want another one
[01:02:31] <jmkasunich> just parse the .comp
[01:02:39] <petev> for the gui to tell it what to adjust and how
[01:02:52] <petev> for example, I just added the biquad IIR filter
[01:03:03] <petev> it needs the coefs calculated
[01:03:11] <jepler> I am sure it could be done, but I'm not very interested in doing it...
[01:03:31] <petev> it would be nice to be able to spec the filter type, sample rate, cutoff, etc. and have the coefs calced
[01:03:44] <jmkasunich> petev: why not put those calcs in the component
[01:03:46] <jepler> the component should accept the parameters in a way that is useful to the user, not useful to itself.
[01:03:48] <petev> any other suggestions then?
[01:03:49] <jepler> in other words, what jmkasunich said
[01:04:07] <petev> that seems very ineffecient
[01:04:20] <petev> it would bloat the RT code and limit the possibilities
[01:04:26] <petev> and it's only config time stuff
[01:04:53] <jmkasunich> so instead you want to put biquad config calcs in a supposedly generic GUI tool?
[01:05:01] <petev> yes
[01:05:12] <petev> each comp would have an xml file
[01:05:17] <petev> the gui would be driven by that
[01:05:23] <petev> so it wouldremain generic
[01:05:30] <jmkasunich> I think you
[01:05:32] <jmkasunich> oops
[01:05:47] <jmkasunich> I think you are just adding an unneccessary layer of infrastructure
[01:05:56] <petev> so what do you suggest?
[01:06:01] <jepler> * jepler goes back to "playing with his wii"
[01:06:06] <jmkasunich> put the calcs in the component, and execute them only when one of the parameters changes
[01:06:16] <petev> that is bad
[01:06:28] <petev> there are too many coefs to check
[01:06:37] <jmkasunich> if the calcs are simple enough to be described in xml, they're simple enough to be put in the component
[01:06:39] <petev> and to do what you want, you could not set the coefs directly
[01:06:52] <petev> that would then limit the filter possibilities to what was built in
[01:07:06] <petev> and it doesn't satisfy other comp requirements either
[01:07:21] <petev> pid would benefit from this soo
[01:07:23] <petev> too
[01:07:33] <petev> why have a specific GUI for each comp?
[01:07:39] <jmkasunich> I think components should have everything they need contained in them
[01:07:44] <jmkasunich> no GUI!
[01:07:56] <jmkasunich> man page!
[01:08:00] <petev> that sux
[01:08:08] <petev> tuning PID with halcmd is a pain
[01:08:14] <petev> that's why ray wrote the GUI
[01:08:22] <petev> and I bet almost everyone uses it
[01:08:38] <petev> and why limit the implementation options of the biquad?
[01:08:56] <petev> and why bloat the RT code, and have to waste cycles checking for param updates?
[01:09:22] <petev> I can't beleive you are saying this when you odered structure members for cache efficiency
[01:09:25] <jmkasunich> we obviously don't see eye to eye about this
[01:09:58] <petev> so you prefer to tune PID with halcmd or do you use the GUI?
[01:10:03] <jmkasunich> halcmd of course
[01:10:18] <petev> that just seems painful
[01:10:23] <petev> so much extra typing
[01:10:33] <jmkasunich> it has history and command completion
[01:11:15] <petev> I guess to each his own, but it really doesn't work for filters or other comps that require the params to be calculated
[01:11:20] <jmkasunich> jepler said it better than I: HAL component parameters should be designed for the benefit of the user, not the code
[01:11:42] <petev> well I think flexibility is to the benefit of the user
[01:11:53] <petev> what filter choices would be correct?
[01:11:58] <petev> a few that the designer decides?
[01:12:03] <petev> that is dumb
[01:12:21] <petev> why not let any filter the biquad transfer function can implment be possible?
[01:12:39] <petev> and why waste all the RT processing time and kernel mem?
[01:12:53] <petev> a simple user space app can do the work when required
[01:13:27] <jmkasunich> RT processing time is small, all you are doing is checking the params for changes, memory is even more ludicrous, given the massive bloat that is today's GUI world
[01:13:57] <jmkasunich> having a separate user space app for anything less than a monumentally difficult calculation is just a pain
[01:14:07] <jmkasunich> that means for that one component, you need to use a different tool
[01:14:28] <petev> so you would rather bloat the comp and limit it's usefullness and require a command line interface?
[01:14:56] <jmkasunich> I would rather have a comp that is easy to use from the command (halcmd) line
[01:15:06] <jmkasunich> a small amount of bloat is a perfectly acceptable price for that
[01:15:38] <petev> and limited usefullness?
[01:15:56] <petev> just because you prefer the command line doens't mean everyone else does
[01:15:56] <jmkasunich> I would dispute that
[01:16:02] <petev> how so?
[01:16:21] <petev> you surely don't want to put every possible filter design in the comp?
[01:17:00] <jmkasunich> it could have a load-time param that lets you choose between exporting params for "raw" coefficients, or exporting things like filter-type (eliptical, bessel, etc), corner-frequency, order, etc
[01:17:28] <petev> so even more bloat to the comp
[01:17:57] <jmkasunich> sure
[01:18:28] <jmkasunich> I don't understand your obsession about bloat... even the smallest GUI app is far more bloated than the worst HAL component
[01:18:42] <petev> yes, but it's in user space
[01:18:46] <jmkasunich> so?
[01:18:46] <petev> and not part of RT
[01:18:55] <petev> I see a big difference
[01:18:59] <jmkasunich> I don't
[01:19:15] <petev> why did you bother with structure order for cache efficiency in PID then?
[01:19:27] <jmkasunich> to me, the beauty of RTAI and HAL and EMC is that you have the full power of a GHz computer available to you for RT stuff
[01:19:48] <petev> well a lot of guys want to use older PCs that are not so powerfull
[01:20:00] <petev> and I for one would prefer to run higher servo rates
[01:20:02] <jmkasunich> because pid was among the first few components I made, and my mindset has changed since then
[01:20:17] <petev> in fact, that was one of the huge problems I had with 1KHz
[01:20:22] <jmkasunich> what?
[01:20:26] <petev> servo rate
[01:20:36] <petev> I found that a properly tuned PID for a step input
[01:20:58] <petev> resulted in outputs that caused too much change within a 1KHz update cycle
[01:21:11] <jmkasunich> so up the servo cycle
[01:21:11] <petev> I had to run 5KHz to even come close to keeping up with the drives
[01:21:30] <petev> well that's hard to do with bloated code and a not so fast CPU
[01:21:48] <petev> and I would also like to see traj run at servo rate
[01:22:04] <petev> so I really don't want to waste cycles checking for param updates and the like
[01:22:12] <jmkasunich> how long do you really think it takes say a 200MHz pentium to compare old and new versions of a half dozen parameters?
[01:22:26] <petev> it all adds up
[01:22:36] <petev> there may be multiple instances of all these comps
[01:22:57] <petev> I would like to try a low pass on the PID output
[01:23:45] <petev> I think way too much is being put in kernel space
[01:23:46] <jmkasunich> so put the biquad between the PID output and the DAC and see how it works
[01:23:58] <petev> but we obviously disagree
[01:24:33] <petev> well that would be 4 biquads right there without even cascading, for one single application
[01:24:51] <petev> for higher order cascading, that might be 8 or more
[01:24:59] <petev> and they might be usefull elsewhere
[01:25:04] <petev> and that's one comp
[01:25:05] <jmkasunich> how many parameters does each one have?
[01:25:12] <petev> then you have debounce, etc.
[01:25:20] <petev> and it's all starting to add up
[01:25:31] <petev> the number of params would depend on what they are
[01:25:37] <petev> for raw coefs, its 5
[01:25:42] <petev> and no checking is needed
[01:25:56] <jmkasunich> so you would use raw mode, and be perfectly happy
[01:26:07] <petev> yes, with a GUI to set them
[01:26:21] <jmkasunich> this is open source - feel free to write the GUI
[01:26:32] <petev> I could use matlab, but it's a bit of a pain and I don't think that helps most others
[01:26:45] <jmkasunich> just don't try to talk people who disagree with the concept to do the work
[01:27:08] <jmkasunich> it doesn't help anybody at all (except you) unless there is a GPL version of matlab
[01:27:08] <petev> I think the only ones that disagree are some of the developers, not the end users
[01:27:15] <petev> so who are we writing this code for?
[01:27:45] <jmkasunich> hal parameters such as "filter-order" and "cutoff-freq" are for the users
[01:28:21] <jmkasunich> change the param, and boom, you have a filter with a new corner frequency
[01:28:23] <petev> and you feel that all users should just use halcmd too?
[01:28:45] <jmkasunich> halcmd or a GUI that lets you easily access parameters
[01:29:06] <petev> so why keep writing special GUIs for each comp instead of something general?
[01:29:45] <jmkasunich> what are you talking about? you are the one who wants to put component specific calcs in a GUI
[01:29:58] <petev> no, I said in xml
[01:30:03] <petev> listen to what I say
[01:30:10] <petev> I never said a specific gui
[01:30:15] <petev> that's what I would like to avoid
[01:30:24] <petev> as we are already building up a pile of those
[01:30:32] <jmkasunich> a pile?
[01:30:36] <jmkasunich> list them please?
[01:30:42] <petev> I have no problem letting the comp writer do a little work
[01:30:57] <petev> but expecting every comp writer to write a GUI is not realistic
[01:31:11] <petev> ther is one for PID, one for hal, etc.
[01:31:20] <jmkasunich> If you think I'm even remotely suggesting that we have HUGE communications gap
[01:31:22] <petev> some are old and don't work anymore
[01:31:55] <jmkasunich> as far as I'm concerned, there are no GUIs for HAL
[01:32:09] <jmkasunich> there are a bunch of experiments that various people have played with
[01:32:16] <jmkasunich> and as you noted, most of them died
[01:32:29] <petev> right, but it shows that people want guis
[01:32:41] <petev> so why not build a proper method for making them?
[01:32:50] <jmkasunich> there are only two HAL guis that I would endorse
[01:32:59] <petev> personally, I don't care, I have matlab and can deal with halcmd
[01:33:19] <petev> but I think emc is becoming rediculously hard to use for the average user
[01:33:42] <jmkasunich> 1) halcmd equivalent - it would make all params accessible in a tree structure, so you could exapand "biquad.0" for example, or expand them all, or collapse them all, and modify those that are writable, etc
[01:34:05] <jmkasunich> 2) schematic to HAL tool - draw the blocks, connect them with wires, then produce a hal file from the "netlist"
[01:34:15] <jmkasunich> both of those are totally generic
[01:34:19] <petev> that would be fine if it could be extensible with meta params and calculations
[01:34:49] <petev> sometimes it's just nice to present a different view to the user than the underlying implementation
[01:35:13] <jmkasunich> ok, lets back up
[01:35:13] <petev> I was suggesting we use xml for this extensibility
[01:35:21] <jmkasunich> 1) more power to you if you can do it
[01:35:38] <jmkasunich> 2) I don't think you can put arbitrary calculations in xml, but again, if you can do it, great
[01:36:00] <petev> well you can, and I'll provide examples of the xml
[01:36:01] <jmkasunich> 3) I hate the idea of having a component AND some user space "thing" that must be used with it
[01:36:18] <jmkasunich> I don't want to see examples, I hate XML
[01:36:21] <petev> I'm the first to admit I'm not expert at writing GUIs and don't have the time to learn and do it myself
[01:36:28] <jmkasunich> it was made to be read and written by machines not people
[01:36:28] <petev> especially when I have no need for it
[01:39:50] <jmkasunich> 4) if you embedd the calcs in the GUI (or in an XML file that can only be used by the GUI) then you cripple people using halcmd
[01:40:21] <petev> halcmd still has access to the uderlying implemetation and it's full power
[01:40:38] <petev> supposedly people using halcmd have more expertise and thus more power
[01:41:02] <jmkasunich> thats balony - just because you are using halcmd doesn't mean you know how to calc digital filter coefficients
[01:41:16] <petev> ideally halcmd could read the xml and present the same view everywhere
[01:41:25] <petev> but I know you don't wnat that
[01:42:20] <jmkasunich> halcmd is a scripting language, that like bash can (but doesn't need to be) used interactively
[01:42:30] <jmkasunich> GUIs lose that
[01:42:43] <petev> GUIs lose what?
[01:42:50] <jmkasunich> the scripting ability
[01:42:58] <petev> why?
[01:43:12] <petev> I have GUIs from other products that you can scpirt
[01:43:35] <jmkasunich> we're never going to agree here
[01:43:35] <petev> I thinking having halcmd be sriptable would be great
[01:43:52] <jmkasunich> halcmd IS scriptable
[01:43:54] <petev> then the generic halshow tcl would almost meet all requirements
[01:44:10] <petev> it doens't have meta vars or calcs
[01:44:12] <jmkasunich> the program halcmd is an interpreter for the language hal
[01:44:17] <petev> so it's not very scriptable
[01:44:55] <jmkasunich> we've actually had that discussion, and we decided that it didn't make sense to turn halcmd into a full-fledged language, not when there are already a bazillion languages available
[01:45:16] <jmkasunich> jepler has written hal hooks for python for example
[01:45:20] <petev> well how can you keep the same power you want in halcmd if it's not extensible?
[01:45:28] <petev> you force everything to be in the comps
[01:45:56] <jmkasunich> I want all information related to a single component to be part of that single component
[01:46:21] <petev> so you force everything into RT and you force the user view to match the implementation
[01:46:29] <petev> that does not seem like a good design choice
[01:47:00] <jmkasunich> I expect the implementation to provide a good user view
[01:47:14] <jmkasunich> for example, corner frequency and filter order instead of raw coefficients
[01:47:25] <petev> well I think we totally disagree on some of the fundamentals
[01:47:30] <jmkasunich> yes
[01:51:16] <petev> I think there are some other things missing with your approach that cause problems. How do you keep the user from entering invalid params?
[01:51:24] <petev> I have come across this many times already
[01:51:27] <jmkasunich> the component validates them
[01:51:41] <petev> and do what if they aren't valid?
[01:51:51] <jmkasunich> it replaces them with valid values
[01:51:56] <petev> that's crap
[01:52:08] <petev> the user says one thing, and the comp silently does another?
[01:52:44] <jmkasunich> yes (semi-silently, the replaced value of the parameter is vislble)
[01:52:56] <jmkasunich> what would you have it do?
[01:53:12] <petev> so the user is expected to check that what he siad to do actually happened after every set commad?
[01:53:20] <petev> so he hase to type twice as much now?
[01:53:39] <jmkasunich> no, the user is expected to enter sane values, the validation saves him from typos, etc
[01:53:43] <petev> I would have halcmd exptensible and error check the params and return an error
[01:53:58] <petev> what is sane when you are entering filter params?
[01:54:05] <jmkasunich> IOW, you would do the validation in user space
[01:54:06] <petev> the user doesn't really know what is acceptable
[01:54:20] <petev> is he expected to understand nyquist and other design issues?
[01:54:42] <petev> yes, I would validate in the user space xml
[01:54:45] <jmkasunich> I've already told you I think filters should accept params like corner frequency
[01:55:07] <jmkasunich> screw XML, that is totally irrelevant, XML is implementation, not concept
[01:55:14] <petev> so if the sample rate is 1KHz and the user says he wants a 600Hz corner, what happens?
[01:55:19] <jmkasunich> the concept is that you are doing validation in userspace
[01:55:21] <petev> that may seem reasonable to the user
[01:55:44] <petev> and the params you want to specify don't even begin to fully define a filter design
[01:56:24] <jmkasunich> are we going to argue about the details of filters, or are we going to argue about the general concepts? please pick one and stick to it
[01:56:53] <petev> general concepts is fine, but don't use the filter design as an example then
[01:57:29] <jmkasunich> regarding filters: ANYTHING you can describe in XML, you can embedd in the component.... ANYTHING! and it will be less bloated, because it will be code, not some nightmarish generic representation of formulas and interacting limitations and such
[01:57:31] <petev> for general concepts, I think the more in user space the better, and different user views than implementation
[01:57:47] <jmkasunich> the only difference is that in user space it doesn't matter how long it takes, and you can yell at the user
[01:57:55] <petev> why do you keep treating RT and user space the same?
[01:58:01] <petev> they ARE NOT the same
[01:58:37] <jmkasunich> you're right, they're not... if you do things in user space and write the results to RT, you have atomicity issues to deal with
[01:58:37] <SWPadnos> if I might weigh in here: having userspace tools to configure components is not exclusive of having components that validate their own inputs
[01:58:48] <SWPadnos> err - chime in
[01:59:10] <petev> jmkasunich, don't go there, because that's HAL implementation issues
[01:59:20] <petev> SWPadnos, please do
[01:59:26] <SWPadnos> I did :)
[01:59:40] <SWPadnos> I don't think the two things conflict with each other
[01:59:40] <petev> you must have more to say than that ;-)
[01:59:43] <jmkasunich> unless there is only ONE possible way to change a parameter, and that way is thru the userspace tool that does the validtation, then comps MUST still validate their args
[01:59:59] <SWPadnos> you can't remove the checks in the RT components, because they're expected to generate output
[02:00:02] <jmkasunich> atomicity?
[02:00:12] <petev> yes
[02:00:33] <SWPadnos> but, you can make it easier to generate valid / useful sets of params with a userspace program (possibly with XML too :) )
[02:00:40] <jmkasunich> anytime user space talks to realtime there will be atomicity issues, regardless of the implementation
[02:00:52] <SWPadnos> atomicity in this case is an optimization, not a problem
[02:00:54] <petev> I strongly disagree
[02:01:12] <petev> there may be issues, but they are easily solved with proper implementation
[02:01:20] <jmkasunich> any user space program can (and will) be interrupted by the RT code
[02:01:21] <SWPadnos> actaully, it could be a problem, but as petev said, that's an implementation detail
[02:01:52] <petev> jmkasunich, let's really not go there as it really is an implementation detail
[02:01:57] <SWPadnos> it shouldn't be a problem because the RT component should be able to deal with any value on any of its inputs/params
[02:02:00] <jmkasunich> no, I want to go there
[02:02:04] <jmkasunich> I think I see where this is going
[02:02:20] <petev> then to start with the whole idea of shared mem between kernel and user space is a bad idea
[02:02:26] <SWPadnos> it's the same as the "larger types" problem we've deiscussed several times
[02:02:38] <jmkasunich> you are going towards a system where there every single component has a user space part and a RT part
[02:02:50] <petev> yes
[02:02:51] <jmkasunich> the user space part validates things, and sends validated data to the RT part
[02:02:54] <SWPadnos> that's not a bad architecture, actually
[02:03:00] <petev> and uses proper kernel/user space interfaces
[02:03:12] <SWPadnos> and it allows callbacks (interrupts) instead of polling for parameter changes
[02:03:21] <jmkasunich> I agree with SWPadnos that its not a bad architecture
[02:03:35] <SWPadnos> it's not a 2.x thing though ...
[02:03:39] <jmkasunich> but it isn't the architecture that we have now, and its not something that can be done incrementally IMO
[02:03:43] <petev> but right now its a lot of work to get there from what we have
[02:03:44] <jmkasunich> you gotta have all or nothing
[02:03:57] <petev> so let's just talk about what we can do now
[02:04:12] <jmkasunich> you are welcome to start your own version of such a thing, and in a couple years (thats how long HAL as been evolving) it will be ready to use
[02:04:13] <SWPadnos> the HAL comms architecture should be doable in two chunks: one for hal_lib, the other for comp (if that's even needed)
[02:04:33] <SWPadnos> it's pretty well encapsulated, AFAIK
[02:04:42] <petev> jmkasunich, I can see ways to fix hal without a total re-write
[02:04:57] <petev> why not a real kernel driver and keep the hal mem in kernel space?
[02:05:09] <jmkasunich> then how do user space things export pin?
[02:05:11] <jmkasunich> pins?
[02:05:18] <petev> halcmd talks to the driver
[02:05:26] <jmkasunich> no, not halcmd
[02:05:36] <petev> the dirver knows what pins are alailable andthe user space interface is the same
[02:05:36] <jmkasunich> things like halui, that are user space components and have pins
[02:05:37] <SWPadnos> petev, is there a way to do that without changing the kernel (or are you not thinking of using ioctl?)
[02:05:56] <SWPadnos> err - syscall, not ioctl
[02:05:57] <petev> they talk to the driver as well, and make calls to create their pins
[02:06:06] <petev> so there is a user space equiv to the hal api
[02:06:17] <petev> and it makes calls to the driver and creates the pins in RT space
[02:06:31] <jmkasunich> the hal API is user/kernel neutral, except for threads/functions
[02:06:32] <SWPadnos> as long as there's an interface in the kernel driver to set/get pin data, it doesn't matter - userspace pins aren't RT
[02:06:38] <petev> SWPadnos, driver details don't mater too much
[02:06:43] <jmkasunich> user space comps don't need threads, they have their own processes
[02:06:45] <petev> ioclt could be used
[02:07:13] <SWPadnos> petev, I asked the question because syscalls need a kernel change, and I think that wouldn't be a great thing
[02:07:21] <SWPadnos> though the changes would be minor
[02:07:28] <SWPadnos> (kernel source change, that is)
[02:07:48] <petev> SWPadnos, are you talking for creation, or for update?
[02:08:13] <petev> I think for creation it's a non issue
[02:08:21] <SWPadnos> just syscall in general - I think you need to add a hook to the kernel, unless you hijack some existing call
[02:08:28] <petev> for update, it may or may not be, depending on the user thread rate
[02:08:34] <SWPadnos> in any case, that's an implementation detail
[02:08:41] <SWPadnos> ojh, sorry
[02:08:46] <petev> oh, you mean adding a new syscall to the kernel?
[02:08:55] <petev> I don't think we would need to do that
[02:09:02] <SWPadnos> yes, for updates / reads of pins in userspace
[02:09:17] <petev> we would use one of the standard driver interface mechanisms
[02:09:24] <SWPadnos> sure - copy_to_user ...
[02:09:36] <petev> not sure which would be best without some more research
[02:09:46] <SWPadnos> there's a newer interface as well, that's meant for moving large amounts of data to userspace
[02:09:47] <SWPadnos> right
[02:09:48] <petev> but ioctl and copy_to_user would certainly work
[02:10:14] <jmkasunich> how long does copy_to_user take, and how atomic is it?
[02:10:25] <petev> it is atomic
[02:10:31] <petev> not sure how long it takes
[02:10:32] <jmkasunich> how can it be?
[02:10:33] <SWPadnos> it takes almost no time, I think it just flips some bits in the page table (zero-copy)
[02:10:43] <petev> it's atomic from the kernel driver perspective
[02:10:50] <jmkasunich> I don't mean linux atomic, I mean RT atomic
[02:11:09] <petev> I don't think it has to be RT atomic
[02:11:20] <petev> the driver would take care of that in kernel space
[02:11:33] <SWPadnos> right - it would be copies of pins, not the actual RT pin data
[02:11:33] <jmkasunich> if you are transferring info from a RT component to a user space one, it needs to be RT atomic
[02:11:49] <SWPadnos> each pin value gets copied atomically, every N'th of a second ...
[02:11:53] <petev> yes, but I would not xfer straight from user to RT comp
[02:11:59] <petev> right
[02:12:10] <petev> and maybe a whole block at a time from user space to kernel
[02:12:20] <SWPadnos> so you have essentially a slow thread updating the userspace HAL pin interface
[02:12:22] <petev> then small RT atomic updates to the comp
[02:12:38] <jmkasunich> this is rediculous... you are talking about rewriting everything
[02:12:54] <petev> no, just adding a user/kernel interface
[02:12:55] <SWPadnos> it should only be the hal_lib, plus some extra driver code
[02:12:55] <jmkasunich> ridiculous even
[02:12:59] <petev> all RT code stays the same
[02:13:09] <petev> and then adding a user lib for the user hal_ calls
[02:13:21] <jmkasunich> there already is a user lib
[02:13:35] <petev> right, so those are the areas I think would change
[02:13:43] <petev> I don't think you would have to touch the comps
[02:13:59] <petev> and most of the hal framwork would remain in tact
[02:14:17] <SWPadnos> there are a couple of things we've wanted to do for a long time, which I think could both be accomplished with this interface (or are needed/desired in implementing this):
[02:14:35] <SWPadnos> 1) atomic or at least "RT-safe" updates of things larger than 32 bits
[02:14:48] <petev> yes
[02:14:52] <jmkasunich> you haven't come close to explaining how that would work
[02:15:04] <SWPadnos> 2) the ability to separate module load from component creation (possible once we have user -> kernel commands)
[02:15:36] <SWPadnos> jmkasunich, explaining how the userspace interface to HAL pins would work?
[02:15:47] <jmkasunich> no, atomic >32 bit
[02:16:07] <SWPadnos> oh, that's a separate discussion, but it's desirable for this model :)
[02:16:17] <jmkasunich> the user->rt interface you've described is 10x more complex than what we have
[02:16:30] <petev> it's also much safer
[02:16:42] <petev> and I don't think that much more complex
[02:16:49] <SWPadnos> and HAL is 10x more complex than an integrated program
[02:16:59] <SWPadnos> but we use it because it gives us other advantages
[02:17:08] <jmkasunich> so you want to make it 100x more complex than an integrated program
[02:17:17] <SWPadnos> heh
[02:17:34] <SWPadnos> only 10x more than the status quo, but with attendant advantages ...
[02:18:00] <jmkasunich> I haven't heard any advantages
[02:18:26] <jmkasunich> using linux interfaces instead of shmem isn't an advantage - it makes you vulnerable to changes in linux
[02:18:36] <petev> so you think the user space access to RT mem is a fine implementation?
[02:18:46] <SWPadnos> well, we've (you and I, among others) discussed various things we want to be able to do, once we figure out "how to get commands across the user/kernel barrier", right?
[02:19:29] <jmkasunich> petev: programs using hal interfaces to access the shared memory block won't get into trouble
[02:19:31] <SWPadnos> the linux interfaces are very stable, though there are additions, I think for the most part you can still run programs that were compiled for kernel 0.9.x
[02:19:45] <jmkasunich> balony
[02:20:00] <jmkasunich> in user space, sure, but thats totally irrelevant
[02:20:18] <jmkasunich> kernel interfaces change every time you turn around
[02:20:34] <petev> jmkasunich, I think you are treating the sytem like an embedded app, but it just isn't
[02:20:52] <SWPadnos> well, I can't come up with examples, so I'll drop the stability line (for now :) )
[02:20:57] <petev> there are a bunch of other user space things running and the system need to be robust to that
[02:21:13] <jmkasunich> you mean other user space processes?
[02:21:20] <petev> sure
[02:21:32] <jmkasunich> they have absolutely no access to the shared memory
[02:21:33] <petev> and even EMC user space apps
[02:22:10] <jmkasunich> the only thing with any access to shared memory are processes that have called "hal_init()"
[02:22:55] <petev> and any bad pointer in any one of those apps can totally corrupt HAL
[02:22:58] <SWPadnos> hold on, didn't we all agree that a userspace/kernel split is a good design?
[02:23:06] <SWPadnos> even though we all know it isn't the current design
[02:23:10] <jmkasunich> SWPadnos: huh?
[02:23:40] <jmkasunich> you mean each comp having a user space and a kernel space part?
[02:23:47] <jmkasunich> I agreed that it has some advantages
[02:23:53] <SWPadnos> err - every component has a user/RT part ...
[02:23:57] <SWPadnos> right
[02:24:01] <jmkasunich> but nowhere near enough to make me want to do it
[02:24:10] <SWPadnos> what about allowing someone else to do it?
[02:24:23] <jmkasunich> good luck
[02:24:34] <jmkasunich> thats what branches are for
[02:24:42] <jmkasunich> but I think you'll find its a lot more work than you think
[02:24:50] <SWPadnos> ie, let's see if we can come up with a design that isn't so complex that you barf, but is safe enough that petev doesn't abrf, and has enough features that I don't barf? :)
[02:25:00] <petev> personally I would more most of HAL to user RT using Xenomia and eventually native linux user RT when it has been integrated to the kernel. I think we could also learn a lot from the COMEDI project
[02:25:07] <petev> more^move
[02:25:14] <jmkasunich> oh gawd
[02:25:21] <jmkasunich> I've looked at comedi several times
[02:25:29] <jmkasunich> layer on layer on layer of stuff
[02:25:34] <petev> they have some good ideas
[02:25:49] <SWPadnos> layering is *not* a bad thing. it just makes stuff harder to understand at first
[02:26:10] <petev> there is really no reason all of HAL needs to be in kernel space
[02:26:11] <SWPadnos> I'm not saying that COMEDI is good, but layers aren't intrinsically bad
[02:26:16] <petev> only the drivers need to be there
[02:26:29] <SWPadnos> it isn't all there, and there are very good reasons for other stuff to be RT
[02:26:38] <SWPadnos> like PID and the motion controller, for example
[02:26:38] <petev> I didn't say RT
[02:26:41] <petev> I said kernel space
[02:26:57] <SWPadnos> it has to be hard RT, which is supposedly doable in userspace, but I'm skeptical
[02:26:57] <petev> user RT is getting very good numbers now
[02:27:23] <petev> and I think in a few kernel release there will be native user space RT support
[02:27:27] <SWPadnos> for anything other than step/PWM generation, it's probably good enough these days
[02:27:28] <jmkasunich> user space RT would be nice, but if you put some hal RT things there, you gotta put all of them there
[02:27:31] <jmkasunich> (including drivers)
[02:27:49] <petev> not if there is a user/kernel interface
[02:27:50] <SWPadnos> is there no communication between kernel and user RT?
[02:27:57] <jmkasunich> do you intend to abandon the entire concept of RT threads?
[02:28:02] <petev> we could modify the drivers, which there aren't many of
[02:28:23] <petev> no, we would keep threads, but they would be user space
[02:28:34] <jmkasunich> then the drivers have to be in userspace too
[02:28:44] <petev> why?
[02:28:57] <petev> we make a user space driver interface that talks to a kernel driver
[02:29:11] <petev> so only the drivers need a user space and kernel space comp
[02:29:14] <SWPadnos> crossing the user/kernel barrier imposes some latency, I believe
[02:29:19] <jmkasunich> because a typical thread invokes drivers to read inputs, then components that compute new outputs based on the inputs, then drivers to write the outputs
[02:29:30] <SWPadnos> crossing rings is not a good thing timing wise
[02:29:55] <petev> I don't think it's that big of a deal
[02:30:12] <petev> and you can always use techniques like scheduled update times
[02:30:16] <jmkasunich> whats not? abandoning the read-process-write thread concept?
[02:30:23] <SWPadnos> remember that EMC generates step pulses as well ... (so microseconds are important in some configs)
[02:30:27] <petev> no, crossing rings
[02:30:36] <petev> I would not do it for each pin update
[02:30:45] <jmkasunich> pete started this mess by claiming that microseconds counted, and I was bloating and slowing things down
[02:30:48] <petev> but would do a block update of all outputs/inputs, etc.
[02:30:51] <SWPadnos> heh
[02:31:14] <petev> this started by not wanting to bloat the RT portion of comps
[02:31:23] <petev> I never said anything about user space
[02:31:34] <petev> and not wanting to make the implementation the same as the user view
[02:32:05] <SWPadnos> the part of the components that deals with parameter updates only imposes a memory penalty. the computation time is minimal since it's all circumvented by if/then blocks
[02:32:23] <jmkasunich> I said that (in not so many words) an hour ago
[02:32:29] <jmkasunich> pete didn't buy it
[02:32:42] <SWPadnos> and the param code can be stuck into a separate function, so it can be in a slower thread
[02:32:42] <petev> SWPadnos, we were discussing a filter and having canned algos embedded in it and it checking to param updates
[02:33:01] <SWPadnos> there are pretty easy methods of bulk updating internal data atomically
[02:33:12] <petev> I objected due to the limted usefullness of the filter and all the uneeded checking
[02:33:52] <SWPadnos> sure - I think we could all agree that it would be ideal (conceptually) to have only the actual calculation code in the RT section of a component
[02:34:10] <SWPadnos> but canned algorithms can be implemented with a simple function pointer internally ...
[02:34:28] <petev> and I suggested a generic user space app that would read an xml description for each comp
[02:34:41] <SWPadnos> and that's where the whole thing started going downhill ;)
[02:34:42] <petev> but mentioning xml wasthe first mistake ;-)
[02:34:48] <SWPadnos> heh
[02:35:44] <jmkasunich> I refuse to believe that any arbitrary set of checks and computations can be encoded in XML (or any other form) in a generic way, without once again adding 10x complexity, compared to simply writing the code
[02:36:05] <petev> well you are flat out wrong, because I have it in other apps
[02:36:23] <SWPadnos> well, it's a little more complex, but since you can include code in an XML tag, I'd have to say it's possible
[02:36:43] <SWPadnos> s/tag/whatever the actual data is called in XML-speak/
[02:36:51] <jmkasunich> how many lines of code? and how easy is it to write the XML, compared to simply writing the code to do the calcs and checks directly?
[02:37:10] <SWPadnos> the XML would be written one time, by the developer of the module
[02:37:21] <jmkasunich> I know
[02:37:25] <petev> the lines of code/xml is about the same, the diff is being compiled or just interpreted
[02:37:28] <jmkasunich> but that doesn't make it irrelevent
[02:37:30] <SWPadnos> and you could have a large program if you wanted, limited by filesystem/memory, not XML
[02:37:47] <petev> the idea is to not have to duplicate the GUI work
[02:37:51] <jmkasunich> we're not communicating again
[02:37:55] <SWPadnos> (possibly limited to 2 or 4G by a 32-bit number in an XML library though)
[02:37:55] <petev> it's not the work for each comp
[02:38:05] <petev> that would be about the same either way
[02:38:43] <SWPadnos> my point was that if something special is needed in the description of how to set a components parameters, a program can be embedded in the XML data that would do the needed custom stuff
[02:38:49] <jmkasunich> there is the XML that describes the computations, checks, and associated error messages, and then there is the generic code that interprets the XML
[02:39:04] <jmkasunich> a program in what language?
[02:39:11] <petev> the interpreter?
[02:39:22] <petev> language of implementers choice
[02:39:26] <SWPadnos> right - the generic code can look at a <CODE> tag, and then literally compile the data from that tag and run the resulting program, if it needs to be that complex
[02:39:27] <jmkasunich> the GUI that reads the XML and does what it says
[02:39:53] <petev> then it displays the user view of the comp
[02:40:00] <petev> and maps it to the underlying implemetation
[02:40:03] <jmkasunich> implementers choice? I choose C. Can you embed C in an XML file, and run it later? seems hard to do that without having a compiler at riuntime
[02:40:08] <SWPadnos> remember - every programming problem can be solved with an additional level of indirection :)
[02:40:16] <petev> so there may be some calcs that tie the user view to the implementation view
[02:40:35] <petev> no, the C program would parse the xml
[02:40:40] <SWPadnos> you would need all the necessary tools, so if you include C code, then your component would have a "configure-time dependency" on a C compiler
[02:40:56] <SWPadnos> petev, he's talking about including custom C code in the XML data
[02:41:02] <SWPadnos> (at my suggestion)
[02:41:11] <petev> I wouldn't use a compiled language for the user space description
[02:41:26] <SWPadnos> sure - python, perl, bc ...
[02:41:35] <petev> I don't think I would go as far as putting C code in the xml
[02:41:58] <petev> I think some simple calcs would suffince for most comps
[02:42:02] <petev> suffice
[02:42:08] <jmkasunich> so in order to write a component you need to know more than just C?
[02:42:13] <SWPadnos> we were having a couple of simultaneous code discussions there - you were talking about the language for the parser/configurator, and I had just mentioned putting code in the XML data
[02:42:47] <petev> jmkasunich, the xml would have a description of the user view and the implementation view, and the mapping between them
[02:43:06] <SWPadnos> we're only talking about things that can't be described with some pre-determined functions
[02:43:39] <SWPadnos> since the configurator would need to do math, there should be support for equations and variables in the XML DTD
[02:43:51] <petev> correct
[02:43:53] <jmkasunich> petev: that mapping can be arbitrarly complex - thats where this whole mess started - you want to put active filter coefficient calculations and validation in there
[02:43:57] <SWPadnos> and some predetermined ones, like THREAD_RATE or the like
[02:44:06] <petev> correct
[02:44:14] <SWPadnos> me or jmK>
[02:44:16] <SWPadnos> k?
[02:44:18] <petev> you
[02:44:54] <SWPadnos> what kind of math is involved with those coefficient calcs?
[02:45:08] <petev> jmkasunich, I don't think we have to go crazy onthe first cut, start simple and expand the description capability as needed
[02:45:16] <jmkasunich> copout
[02:45:22] <petev> SWPadnos, basic operators and some trig
[02:45:28] <jmkasunich> you are using the complex case to justify doing this
[02:45:34] <SWPadnos> I think bc can do a fair amount, and there are other command-line calculators that can do things like integration
[02:45:40] <jmkasunich> so it better be able to handle the complex case
[02:45:48] <petev> no, I don't think a filter is a complex case
[02:45:48] <jmkasunich> the simple cases are handled just fine already
[02:46:07] <petev> the filter can be handled without full flow control, etc.
[02:46:20] <SWPadnos> jmkasunich, that makes perfect sense: there are complex cases for which the current system isn't workable (for whatever reason), but you don't have to implement everything in the new system first
[02:46:29] <SWPadnos> you can start small and prove that it works, then add complexity later
[02:47:08] <petev> I can write the parser with ANTLR if that's what's needed
[02:47:14] <petev> then someone can add the GUI part
[02:47:29] <jmkasunich> wtf is antlr?
[02:47:35] <SWPadnos> it's a code generator
[02:47:41] <petev> it's a parser generator, generates C++ code
[02:47:47] <SWPadnos> similar in concept to yacc / lex / bison ...
[02:48:38] <jmkasunich> this is making me insane, I need to stop talking to you guys
[02:48:57] <SWPadnos> heh - oops :)
[02:49:05] <jmkasunich> HAL is simple, it uses plain old C, its fast, it RT safe, it has minimal dependencies on things like the kernel than can be changed by others
[02:49:32] <jmkasunich> those are all concious decisions and goals that reflect my priorities
[02:49:52] <jmkasunich> your priorities are obviously different, and we will never see eye to eye on this
[02:50:20] <SWPadnos> I think you had / have some things you'd like in HAL, but we haven't been able to get there yet
[02:50:29] <SWPadnos> such as separating load from instantiation
[02:50:56] <SWPadnos> and having userspace able to call kernel code safely (like walking the various namespaces for pin lists)
[02:51:23] <SWPadnos> and also having a user interface (like a schematic editor) at some point
[02:51:31] <SWPadnos> (separate, but still configuration related)
[02:51:41] <jmkasunich> any mechanism that can do that for the antlr/xml/c++ approach can do that for the simple C/shmem approach too
[02:52:07] <SWPadnos> sure, so it seems there's agreement on some architectural things, but not on implementation
[02:52:26] <SWPadnos> or if not architecture, then at least frature sets
[02:52:29] <SWPadnos> feature
[02:53:34] <jmkasunich> I have a very selfish feature request - that a C programmer be able to write stuff
[02:54:24] <SWPadnos> I can agree with that, but with two caveats: one, that it's a pain to use C++ in kernel, and two that C programmers are generally afraid of C++ for the wrong reasons
[02:54:41] <SWPadnos> (I know because I'm more of C programmer than C++ ;) )
[02:55:01] <SWPadnos> there are no other good reasons these days to stay away from C++ in favor of C
[02:55:37] <SWPadnos> I can show you code examples in C++ that are completely type-safe (for example), and generate zero extra bytes of runtime code or data
[02:55:39] <jmkasunich> I disagree with that - personal preference is a perfectly legitimate reason
[02:55:45] <SWPadnos> ok, that's valid
[02:55:49] <jmkasunich> and lets NOT get into a C vs C++ discussion
[02:56:51] <christel> [Global Notice] This is your captain speaking; in a little while our main US hub will be going down for some maintenance. As you may feel some turbulence as we jump I would ask you to keep your seat in a upright position, stow the tray table and keep your seatbelt fastened while the fasten seatbelt sign is illuminated. Thank you for flying freenode and have a great day!
[02:57:01] <SWPadnos> sure, but you mentioned C++ as a problem (along with high level tools like antlr and high level data encapsulation like XML), which I think is more personal preference than technical
[02:57:33] <jmkasunich> I never said it was techinical - but the more differnet languages you require a developer to know, the smaller the developer pool gets
[02:58:05] <SWPadnos> sure
[02:58:39] <jmkasunich> I want joe coder to be able to write components... if writing a component means also writing some xml/antlr/who-knows-what description of the "user/implementation mapping" then you've made that a lot harder
[03:00:18] <SWPadnos> that's true
[03:00:34] <SWPadnos> though nothing we've mentioned thus far is as bad as man-groff (or whatever that is)
[03:01:16] <jmkasunich> man sucks, but at least you can read the source of other man pages and figure it out - its also easy to view and correct the output
[03:01:32] <jmkasunich> thats by far easier for a novice to figure out than C++
[03:01:48] <cradek> 3hi guys
[03:01:48] <SWPadnos> antlr wouldn't be needed for the average developer, only people who need/want to work on the configurator program
[03:01:58] <SWPadnos> 200hi Chris
[03:02:11] <jmkasunich> I admit that C++ can be used in efficient ways.... but it also can be abused horribly, and you gotta know it well before you know the difference
[03:02:22] <SWPadnos> just like only people who waht to work on axis or comp (or whatever) need to know python now
[03:02:27] <SWPadnos> yes
[03:08:28] <jmkasunich> aw, you guys missed it... I posted the answer to all our problems during the netsplit
[03:08:35] <cradek> yep, I saw it
[03:09:03] <SWPadnos> bastid
[03:09:04] <cradek> and I agree with everything
[03:09:13] <SWPadnos> even Bush?
[03:09:34] <SWPadnos> nevermind - that was a stupid question
[03:09:39] <jmkasunich> he agrees with everything I posted during the netsplit
[03:09:49] <SWPadnos> ah, I see
[03:09:49] <cradek> darnit, my company just hired 5 people and 3 of them are named chris
[03:09:55] <SWPadnos> heh
[03:10:03] <SWPadnos> how many steve's do you have?
[03:10:11] <cradek> they'll just have to go by something else I guess
[03:10:24] <cradek> actually none - they're all named mike
[03:10:57] <cradek> how do I use the autotuning?
[03:11:16] <cradek> first, start before 10pm, I'm sure
[03:11:34] <SWPadnos> use at_pid, then do some stuff petev knows about
[03:11:45] <SWPadnos> beyond that, I don't know ;)
[03:11:51] <jmkasunich> is there a man page for at_pid?
[03:12:04] <cradek> $ man at_pid
[03:12:04] <cradek> No manual entry for at_pid
[07:10:37] <jmkasunich> petev: in biquad, do you really want s1 and s2 to be parameters?
[07:10:44] <jmkasunich> aren't they just internal variables?
[07:54:18] <petev> yes, they can be directly set when using direct mode for various startup conditions
[07:54:51] <petev> maybe this will never get used, so we can make them internal if desired
[07:54:58] <petev> did u see the farm error?
[07:55:10] <petev> I don't get that here
[13:32:37] <jepler> I'll look into this breezy compile failure since it doesn't look like anyone else has yet...
[13:36:32] <jepler> well that was easy .. for someone who happened to have access to an actual breezy machine :-P
[13:38:09] <skunkworks> * skunkworks chears from the cheap seats.. :)
[13:38:20] <skunkworks> cheers
[13:40:10] <jepler> hi skunkworks
[13:40:40] <skunkworks> good morning.
[13:40:52] <skunkworks> me is fighting the flu this weekend
[13:41:15] <skunkworks> well you understand. ;)
[13:41:42] <skunkworks> Was hoping to acutally cut some boards with the tool set microswitch.
[15:19:54] <jepler> yuck -- get well soon
[17:53:02] <SWPadnos_> SWPadnos_ is now known as SWPadnos
[19:23:38] <elson> Hello, all!
[19:25:13] <alex_joni> hi Jon
[19:25:58] <elson> I just made a small change and tried to recompile emc-trunk, and got an error from insmod that installing ...rtlib/threads.ko was "not permitted". I had just checked out the source and compiled an hour earlier OK. When I tried to recompile, I got a complaint that make couldn;t remake Makefile, so I did make clean then make, etc.
[19:26:04] <elson> Hello, Alex
[19:27:04] <elson> To John K, you sure cleaned up my mass of spaghetti code - read_encoders is now less than a page.
[19:27:38] <elson> But, I have a problem that encoder.xx.index is stuck true. I'm trying to debug it now.
[19:28:17] <anonimasu> elson: Would it be very hard to implement the "pcisetup" functionality into the USC driver?
[19:28:46] <anonimasu> or throw a copy of it with with emc?
[19:28:47] <elson> Another thing I ran into is that index_enable can get stuck true if you abort a homing move, and the only way to reset it is to restart EMC. Aborting a homing move or an estop should reset index_enable on all encoders.
[19:29:44] <alex_joni> elson: lets take them one by one..
[19:29:50] <alex_joni> does emc2 run now?
[19:29:51] <elson> pcisetup writes 0x80 to an io port 0x402 above the parallel port data reg address. If you don't know for sure what is at that io port, it could be a REALLY bad idea!
[19:30:23] <anonimasu> elson: or ass the option to do so..
[19:30:30] <elson> It appears that is is ONLY needed by certain Dell boxes from the late 90's.
[19:30:34] <alex_joni> elson: so make it a insmod param (loadrt hal_ppmc ... pcisetup=1), which is not by default
[19:30:36] <anonimasu> some hp boxes too..
[19:31:00] <anonimasu> elson: just thought of it when I installed my box as I had to grab it, and your site were down for a few days at that time :)
[19:31:07] <elson> Yeah, an insmod param might be OK. I was hoping the need for the horrible thing would just go away.
[19:31:29] <SWPadnos> it probably won't, as long as old dell boxes are good for running EMC (and they're still available)
[19:31:34] <elson> I can't get the latest compile of EMC2 to run.
[19:31:48] <SWPadnos> you probably did the CVS checkout as root
[19:31:50] <alex_joni> elson: latest TRUNK?
[19:32:02] <elson> No, I have not been root at all.
[19:32:29] <elson> Really, that is just a local name, I did a cvs ... co emc
[19:32:29] <SWPadnos> hmmm. that seemed to me like it could be the "unable to remake Makefile" thing, but I guess I'm wrong :)
[19:32:33] <alex_joni> elson: ok, lets take it step by step now.. did you run configure --enable-run-in-place
[19:32:52] <elson> Yes, I got that "unable to remake makefile" message.
[19:33:06] <alex_joni> elson: that's a different issue..
[19:33:13] <elson> Yes, I did ./configure --enable-run-in-place
[19:33:15] <alex_joni> you clean that out by running make clean
[19:33:29] <elson> after I did the make clean (umm, I think I did, anyway)
[19:33:31] <alex_joni> elson: ok, did make clean, make, sudo make setuid work without warnings/errors?
[19:33:48] <elson> Maybe I need to rerun the ./configure to be sure
[19:34:18] <elson> I think there were no errors
[19:34:36] <alex_joni> ok..
[19:34:43] <alex_joni> what's the error when running emc2?
[19:35:12] <elson> insmod reports ...rtlib/threads.ko "operation not permitted"
[19:35:20] <SWPadnos> what does dmesg tell you?
[19:35:34] <alex_joni> I know.. I bet it
[19:35:41] <alex_joni> I know.. I bet it's the new restriction inserted by JMK
[19:35:52] <alex_joni> you can't insert faster threads after slower ones..
[19:35:55] <SWPadnos> ah - thread period order
[19:36:19] <tomp> yep , fast first, slowest last
[19:36:48] <tomp> always existed, just didnt gnr8 error
[19:36:54] <elson> Hmm, yes, "new thread period less than existing thread period"
[19:37:09] <alex_joni> elson: what config are you trying to run?
[19:37:33] <SWPadnos> that really should be a min() function in threads
[19:37:43] <elson> ahh, something cobbled up by Stuart Stevenson, and hacked just enough to run on my Bridgeport with PPMC.
[19:38:41] <elson> But, it ran before the rebuild.
[19:39:06] <SWPadnos> right - threads used to silently do the wrong thing sometimes
[19:39:12] <SWPadnos> now it complains instead
[19:39:16] <elson> OK, so I just have to change the order of RT threads in the load hal file?
[19:39:20] <alex_joni> yes
[19:39:22] <SWPadnos> hopefully :)
[19:39:37] <SWPadnos> make sure name1/period1 has the lowest period, then name2/period2 ...
[19:40:01] <elson> OK, I'll try that. Hmm, "do the wrong thing", does that mean that the way threads were dispatched could get fouled up?
[19:40:35] <tomp> elson: this order fixed my prob last nite, fro xmpl... loadrt threads name1=fast period1=20000 name2=pdmthrd period2=500000 name3=slow period3=1000000
[19:40:36] <SWPadnos> it means that in some cases, you could get segfaults (which is what tomp noticed, and the specific fix jmk made last night)
[19:41:41] <SWPadnos> you'd end up with thread periods = 0 in the internal HAL data, so if you added a function to one of those that used the period (more specifically the reciprocal of period), then you'd get a divide by 0
[19:41:57] <SWPadnos> at least, that's my analysis of the problem (without benefit of having looked at the code ;) )
[19:42:03] <elson> I never got any seg faults. But, I've been getting a LOT of strange stuff happening. But, why did it wait to complain until after I recompiled? Shouldn't the first compiled version straight from head have complained, too?
[19:43:16] <alex_joni> probably soemthing didn't recompile the first time
[19:43:19] <SWPadnos> only if it was from late last night or this mornong
[19:43:28] <alex_joni> that's why you got the error failed to remake makefile
[19:43:39] <elson> If anyone wants to look at code, I'm wondering why aborting a homing operation doesn't reset the index-enable signal on that axis.
[19:44:12] <SWPadnos> possibly because index-enable is expected to be reset by the encoder driver ???
[19:44:22] <SWPadnos> but I'm just speculating here
[19:44:43] <elson> But, it will nOT be reset if you abort the move early. ESTOP or abort should reset it.
[19:45:09] <elson> OK, I'm going to try to fix the thread order.
[19:45:50] <SWPadnos> I understand the problem - I'm not sure the canonical encoder interface specifies what the encoder driver should do if an external thing (motion) resets the index-enable
[19:46:29] <tomp> elson: SWPadnos; as i recall that particular action requires a special form of readwrite.. that is your function can set it ( like a flag saying hit me ), but emc/hal must reset it. i remember writing a specific pyvcp switch type that allowed that... it turned on an led, but the led was turned off ONLY but outside influences
[19:46:53] <tomp> s/but/by
[19:46:53] <SWPadnos> it's kind of a handshake really
[19:47:01] <tomp> yep
[19:47:09] <SWPadnos> motion says "I want this sto happen" and the encoder driver resets the pin when "it happens"
[19:47:26] <tomp> hitme/smack!
[19:48:34] <SWPadnos> ouch!
[19:59:47] <elson> Yes, a one-pin handshake. OK, I removed the jog controller file that had a fast thread in it, and EMC2 runs again. I'm having a problem with the sensing of the index pin. My diagnostic says it works at the hardware, but the signal never makes it through the driver.
[20:04:41] <anonimasu> ยด/w 12
[20:59:53] <petev> jepler, u there?
[21:51:52] <jmkasunich> hi guys
[22:06:08] <SWPadnos> hi John
[22:06:33] <jmkasunich> hi
[22:06:49] <jmkasunich> I see that somebody else has had out-of-order threads
[22:08:01] <SWPadnos> yep
[22:08:20] <SWPadnos> I thought it might be a good idea for threads to create then in ascending period order
[22:08:44] <jmkasunich> you mean sort them so no matter what the user specifies he gets the proper result
[22:08:50] <jmkasunich> (instead of an error message)
[22:08:52] <SWPadnos> yep
[22:09:12] <SWPadnos> ther ewould still be an error if the base period had already been set (from a previous load)
[22:12:00] <jmkasunich> I was thinking about that last night
[22:12:28] <jmkasunich> also thinking about getting rid of name1=foo name2=bar and having arrays like we do for step_type
[22:12:38] <jmkasunich> names=foo,bar periods=20000,100000
[22:13:42] <SWPadnos> yeah, I was thinking of that as well
[22:13:52] <SWPadnos> so you could sort or keep a list of the order in which to create the threads
[22:15:37] <petev> how many decimal places does emc need to not give errors about arc radius length?
[22:18:25] <jmkasunich> not sure, thats an interpreter thing
[22:18:33] <jmkasunich> I think its a #define actually
[22:18:53] <petev> I'm using 6 in the post, but apparently that's not enough
[22:19:25] <petev> I wish it would at least say which line it doesn't like
[22:24:53] <petev> at least axis gives a line number in it's error dialog
[22:30:04] <jepler> petev: the documentation says this:
[22:30:04] <jepler> In the center format, the coordinates of the end point of the arc in the selected plane are specified along with the offsets of the center of the arc from the current location. In this format, it is OK if the end point of the arc is the same as the current point. It is an error if:
[22:30:09] <jepler> * When the arc is projected on the selected plane, the distance from the current point to the center differs from the distance from the end point to the center by more than 0.0002 inch (if inches are being used) or 0.002 millimeter (if millimeters are being used).
[22:30:58] <jepler> the recommendation later on in the documentation is to use 4 digits precision for inch output and 3 digits precision for millimeter output
[22:30:58] <petev> now that I get the line # from axis, I can see it's the first arc move
[22:31:14] <petev> I think maybe the vector is from center to start and not start to center?
[22:31:45] <petev> I'll change the post and try it again
[22:33:45] <jepler> bbl, good luck with your arcs
[22:34:23] <petev> yeah, the doc is wrong, the vector is from center to start, not start to center
[23:31:27] <cradek> you're mistaken
[23:31:58] <cradek> I1 J1 means the center is +1,+1 from the start
[23:43:21] <petev> hmm, I switched it in the cam to be center to start and all worked fine
[23:48:03] <jmkasunich> maybe the cam defines it wrong... what does the generated G-code say
[23:48:35] <petev> it's a bunch of small contour folowing moves so it's hard to say, but the path looks correct visually
[23:49:31] <jmkasunich> do a straightforward case (nice big arc, maybe 1" radius, and at least 90 degrees), run the cam both ways, and examine the generated output's I and J terms