jepler, u there?
petev: off and on ...
I have an idea
it seems like many of the hal comps are getting a lot of params that need setting
it would be nice to have some graphical way to do it
what would it take to make a gui tool that could parse an xml description of the comp and show widgets for param adjustment?
I could send you an example of the xml
does that sound possible?
the .comp file is already a representation of the comp, why would you want another one
just parse the .comp
for the gui to tell it what to adjust and how
for example, I just added the biquad IIR filter
it needs the coefs calculated
I am sure it could be done, but I'm not very interested in doing it...
it would be nice to be able to spec the filter type, sample rate, cutoff, etc. and have the coefs calced
petev: why not put those calcs in the component
the component should accept the parameters in a way that is useful to the user, not useful to itself.
any other suggestions then?
in other words, what jmkasunich said
that seems very ineffecient
it would bloat the RT code and limit the possibilities
and it's only config time stuff
so instead you want to put biquad config calcs in a supposedly generic GUI tool?
each comp would have an xml file
the gui would be driven by that
so it wouldremain generic
I think you
I think you are just adding an unneccessary layer of infrastructure
so what do you suggest?
* jepler goes back to "playing with his wii"
put the calcs in the component, and execute them only when one of the parameters changes
that is bad
there are too many coefs to check
if the calcs are simple enough to be described in xml, they're simple enough to be put in the component
and to do what you want, you could not set the coefs directly
that would then limit the filter possibilities to what was built in
and it doesn't satisfy other comp requirements either
pid would benefit from this soo
why have a specific GUI for each comp?
I think components should have everything they need contained in them
tuning PID with halcmd is a pain
that's why ray wrote the GUI
and I bet almost everyone uses it
and why limit the implementation options of the biquad?
and why bloat the RT code, and have to waste cycles checking for param updates?
I can't beleive you are saying this when you odered structure members for cache efficiency
we obviously don't see eye to eye about this
so you prefer to tune PID with halcmd or do you use the GUI?
halcmd of course
that just seems painful
so much extra typing
it has history and command completion
I guess to each his own, but it really doesn't work for filters or other comps that require the params to be calculated
jepler said it better than I: HAL component parameters should be designed for the benefit of the user, not the code
well I think flexibility is to the benefit of the user
what filter choices would be correct?
a few that the designer decides?
that is dumb
why not let any filter the biquad transfer function can implment be possible?
and why waste all the RT processing time and kernel mem?
a simple user space app can do the work when required
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
having a separate user space app for anything less than a monumentally difficult calculation is just a pain
that means for that one component, you need to use a different tool
so you would rather bloat the comp and limit it's usefullness and require a command line interface?
I would rather have a comp that is easy to use from the command (halcmd) line
a small amount of bloat is a perfectly acceptable price for that
and limited usefullness?
just because you prefer the command line doens't mean everyone else does
I would dispute that
you surely don't want to put every possible filter design in the comp?
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
so even more bloat to the comp
I don't understand your obsession about bloat... even the smallest GUI app is far more bloated than the worst HAL component
yes, but it's in user space
and not part of RT
I see a big difference
why did you bother with structure order for cache efficiency in PID then?
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
well a lot of guys want to use older PCs that are not so powerfull
and I for one would prefer to run higher servo rates
because pid was among the first few components I made, and my mindset has changed since then
in fact, that was one of the huge problems I had with 1KHz
I found that a properly tuned PID for a step input
resulted in outputs that caused too much change within a 1KHz update cycle
so up the servo cycle
I had to run 5KHz to even come close to keeping up with the drives
well that's hard to do with bloated code and a not so fast CPU
and I would also like to see traj run at servo rate
so I really don't want to waste cycles checking for param updates and the like
how long do you really think it takes say a 200MHz pentium to compare old and new versions of a half dozen parameters?
it all adds up
there may be multiple instances of all these comps
I would like to try a low pass on the PID output
I think way too much is being put in kernel space
so put the biquad between the PID output and the DAC and see how it works
but we obviously disagree
well that would be 4 biquads right there without even cascading, for one single application
for higher order cascading, that might be 8 or more
and they might be usefull elsewhere
and that's one comp
how many parameters does each one have?
then you have debounce, etc.
and it's all starting to add up
the number of params would depend on what they are
for raw coefs, its 5
and no checking is needed
so you would use raw mode, and be perfectly happy
yes, with a GUI to set them
this is open source - feel free to write the GUI
I could use matlab, but it's a bit of a pain and I don't think that helps most others
just don't try to talk people who disagree with the concept to do the work
it doesn't help anybody at all (except you) unless there is a GPL version of matlab
I think the only ones that disagree are some of the developers, not the end users
so who are we writing this code for?
hal parameters such as "filter-order" and "cutoff-freq" are for the users
change the param, and boom, you have a filter with a new corner frequency
and you feel that all users should just use halcmd too?
halcmd or a GUI that lets you easily access parameters
so why keep writing special GUIs for each comp instead of something general?
what are you talking about? you are the one who wants to put component specific calcs in a GUI
no, I said in xml
listen to what I say
I never said a specific gui
that's what I would like to avoid
as we are already building up a pile of those
list them please?
I have no problem letting the comp writer do a little work
but expecting every comp writer to write a GUI is not realistic
ther is one for PID, one for hal, etc.
If you think I'm even remotely suggesting that we have HUGE communications gap
some are old and don't work anymore
as far as I'm concerned, there are no GUIs for HAL
there are a bunch of experiments that various people have played with
and as you noted, most of them died
right, but it shows that people want guis
so why not build a proper method for making them?
there are only two HAL guis that I would endorse
personally, I don't care, I have matlab and can deal with halcmd
but I think emc is becoming rediculously hard to use for the average user
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
2) schematic to HAL tool - draw the blocks, connect them with wires, then produce a hal file from the "netlist"
both of those are totally generic
that would be fine if it could be extensible with meta params and calculations
sometimes it's just nice to present a different view to the user than the underlying implementation
ok, lets back up
I was suggesting we use xml for this extensibility
1) more power to you if you can do it
2) I don't think you can put arbitrary calculations in xml, but again, if you can do it, great
well you can, and I'll provide examples of the xml
3) I hate the idea of having a component AND some user space "thing" that must be used with it
I don't want to see examples, I hate XML
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
it was made to be read and written by machines not people
especially when I have no need for it
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
halcmd still has access to the uderlying implemetation and it's full power
supposedly people using halcmd have more expertise and thus more power
thats balony - just because you are using halcmd doesn't mean you know how to calc digital filter coefficients
ideally halcmd could read the xml and present the same view everywhere
but I know you don't wnat that
halcmd is a scripting language, that like bash can (but doesn't need to be) used interactively
GUIs lose that
GUIs lose what?
the scripting ability
I have GUIs from other products that you can scpirt
we're never going to agree here
I thinking having halcmd be sriptable would be great
halcmd IS scriptable
then the generic halshow tcl would almost meet all requirements
it doens't have meta vars or calcs
the program halcmd is an interpreter for the language hal
so it's not very scriptable
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
jepler has written hal hooks for python for example
well how can you keep the same power you want in halcmd if it's not extensible?
you force everything to be in the comps
I want all information related to a single component to be part of that single component
so you force everything into RT and you force the user view to match the implementation
that does not seem like a good design choice
I expect the implementation to provide a good user view
for example, corner frequency and filter order instead of raw coefficients
well I think we totally disagree on some of the fundamentals
I think there are some other things missing with your approach that cause problems. How do you keep the user from entering invalid params?
I have come across this many times already
the component validates them
and do what if they aren't valid?
it replaces them with valid values
the user says one thing, and the comp silently does another?
yes (semi-silently, the replaced value of the parameter is vislble)
what would you have it do?
so the user is expected to check that what he siad to do actually happened after every set commad?
so he hase to type twice as much now?
no, the user is expected to enter sane values, the validation saves him from typos, etc
I would have halcmd exptensible and error check the params and return an error
what is sane when you are entering filter params?
IOW, you would do the validation in user space
the user doesn't really know what is acceptable
is he expected to understand nyquist and other design issues?
yes, I would validate in the user space xml
I've already told you I think filters should accept params like corner frequency
screw XML, that is totally irrelevant, XML is implementation, not concept
so if the sample rate is 1KHz and the user says he wants a 600Hz corner, what happens?
the concept is that you are doing validation in userspace
that may seem reasonable to the user
and the params you want to specify don't even begin to fully define a filter design
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
general concepts is fine, but don't use the filter design as an example then
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
for general concepts, I think the more in user space the better, and different user views than implementation
the only difference is that in user space it doesn't matter how long it takes, and you can yell at the user
why do you keep treating RT and user space the same?
they ARE NOT the same
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
if I might weigh in here: having userspace tools to configure components is not exclusive of having components that validate their own inputs
err - chime in
jmkasunich, don't go there, because that's HAL implementation issues
SWPadnos, please do
I did :)
I don't think the two things conflict with each other
you must have more to say than that ;-)
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
you can't remove the checks in the RT components, because they're expected to generate output
but, you can make it easier to generate valid / useful sets of params with a userspace program (possibly with XML too :) )
anytime user space talks to realtime there will be atomicity issues, regardless of the implementation
atomicity in this case is an optimization, not a problem
I strongly disagree
there may be issues, but they are easily solved with proper implementation
any user space program can (and will) be interrupted by the RT code
actaully, it could be a problem, but as petev said, that's an implementation detail
jmkasunich, let's really not go there as it really is an implementation detail
it shouldn't be a problem because the RT component should be able to deal with any value on any of its inputs/params
no, I want to go there
I think I see where this is going
then to start with the whole idea of shared mem between kernel and user space is a bad idea
it's the same as the "larger types" problem we've deiscussed several times
you are going towards a system where there every single component has a user space part and a RT part
the user space part validates things, and sends validated data to the RT part
that's not a bad architecture, actually
and uses proper kernel/user space interfaces
and it allows callbacks (interrupts) instead of polling for parameter changes
I agree with SWPadnos that its not a bad architecture
it's not a 2.x thing though ...
but it isn't the architecture that we have now, and its not something that can be done incrementally IMO
but right now its a lot of work to get there from what we have
you gotta have all or nothing
so let's just talk about what we can do now
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
the HAL comms architecture should be doable in two chunks: one for hal_lib, the other for comp (if that's even needed)
it's pretty well encapsulated, AFAIK
jmkasunich, I can see ways to fix hal without a total re-write
why not a real kernel driver and keep the hal mem in kernel space?
then how do user space things export pin?
halcmd talks to the driver
no, not halcmd
the dirver knows what pins are alailable andthe user space interface is the same
things like halui, that are user space components and have pins
petev, is there a way to do that without changing the kernel (or are you not thinking of using ioctl?)
err - syscall, not ioctl
they talk to the driver as well, and make calls to create their pins
so there is a user space equiv to the hal api
and it makes calls to the driver and creates the pins in RT space
the hal API is user/kernel neutral, except for threads/functions
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
SWPadnos, driver details don't mater too much
user space comps don't need threads, they have their own processes
ioclt could be used
petev, I asked the question because syscalls need a kernel change, and I think that wouldn't be a great thing
though the changes would be minor
(kernel source change, that is)
SWPadnos, are you talking for creation, or for update?
I think for creation it's a non issue
just syscall in general - I think you need to add a hook to the kernel, unless you hijack some existing call
for update, it may or may not be, depending on the user thread rate
in any case, that's an implementation detail
oh, you mean adding a new syscall to the kernel?
I don't think we would need to do that
yes, for updates / reads of pins in userspace
we would use one of the standard driver interface mechanisms
sure - copy_to_user ...
not sure which would be best without some more research
there's a newer interface as well, that's meant for moving large amounts of data to userspace
but ioctl and copy_to_user would certainly work
how long does copy_to_user take, and how atomic is it?
it is atomic
not sure how long it takes
how can it be?
it takes almost no time, I think it just flips some bits in the page table (zero-copy)
it's atomic from the kernel driver perspective
I don't mean linux atomic, I mean RT atomic
I don't think it has to be RT atomic
the driver would take care of that in kernel space
right - it would be copies of pins, not the actual RT pin data
if you are transferring info from a RT component to a user space one, it needs to be RT atomic
each pin value gets copied atomically, every N'th of a second ...
yes, but I would not xfer straight from user to RT comp
and maybe a whole block at a time from user space to kernel
so you have essentially a slow thread updating the userspace HAL pin interface
then small RT atomic updates to the comp
this is rediculous... you are talking about rewriting everything
no, just adding a user/kernel interface
it should only be the hal_lib, plus some extra driver code
all RT code stays the same
and then adding a user lib for the user hal_ calls
there already is a user lib
right, so those are the areas I think would change
I don't think you would have to touch the comps
and most of the hal framwork would remain in tact
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):
1) atomic or at least "RT-safe" updates of things larger than 32 bits
you haven't come close to explaining how that would work
2) the ability to separate module load from component creation (possible once we have user -> kernel commands)
jmkasunich, explaining how the userspace interface to HAL pins would work?
no, atomic >32 bit
oh, that's a separate discussion, but it's desirable for this model :)
the user->rt interface you've described is 10x more complex than what we have
it's also much safer
and I don't think that much more complex
and HAL is 10x more complex than an integrated program
but we use it because it gives us other advantages
so you want to make it 100x more complex than an integrated program
only 10x more than the status quo, but with attendant advantages ...
I haven't heard any advantages
using linux interfaces instead of shmem isn't an advantage - it makes you vulnerable to changes in linux
so you think the user space access to RT mem is a fine implementation?
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?
petev: programs using hal interfaces to access the shared memory block won't get into trouble
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
in user space, sure, but thats totally irrelevant
kernel interfaces change every time you turn around
jmkasunich, I think you are treating the sytem like an embedded app, but it just isn't
well, I can't come up with examples, so I'll drop the stability line (for now :) )
there are a bunch of other user space things running and the system need to be robust to that
you mean other user space processes?
they have absolutely no access to the shared memory
and even EMC user space apps
the only thing with any access to shared memory are processes that have called "hal_init()"
and any bad pointer in any one of those apps can totally corrupt HAL
hold on, didn't we all agree that a userspace/kernel split is a good design?
even though we all know it isn't the current design
you mean each comp having a user space and a kernel space part?
I agreed that it has some advantages
err - every component has a user/RT part ...
but nowhere near enough to make me want to do it
what about allowing someone else to do it?
thats what branches are for
but I think you'll find its a lot more work than you think
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? :)
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
I've looked at comedi several times
layer on layer on layer of stuff
they have some good ideas
layering is *not* a bad thing. it just makes stuff harder to understand at first
there is really no reason all of HAL needs to be in kernel space
I'm not saying that COMEDI is good, but layers aren't intrinsically bad
only the drivers need to be there
it isn't all there, and there are very good reasons for other stuff to be RT
like PID and the motion controller, for example
I didn't say RT
I said kernel space
it has to be hard RT, which is supposedly doable in userspace, but I'm skeptical
user RT is getting very good numbers now
and I think in a few kernel release there will be native user space RT support
for anything other than step/PWM generation, it's probably good enough these days
user space RT would be nice, but if you put some hal RT things there, you gotta put all of them there
not if there is a user/kernel interface
is there no communication between kernel and user RT?
do you intend to abandon the entire concept of RT threads?
we could modify the drivers, which there aren't many of
no, we would keep threads, but they would be user space
then the drivers have to be in userspace too
we make a user space driver interface that talks to a kernel driver
so only the drivers need a user space and kernel space comp
crossing the user/kernel barrier imposes some latency, I believe
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
crossing rings is not a good thing timing wise
I don't think it's that big of a deal
and you can always use techniques like scheduled update times
whats not? abandoning the read-process-write thread concept?
remember that EMC generates step pulses as well ... (so microseconds are important in some configs)
no, crossing rings
I would not do it for each pin update
pete started this mess by claiming that microseconds counted, and I was bloating and slowing things down
but would do a block update of all outputs/inputs, etc.
this started by not wanting to bloat the RT portion of comps
I never said anything about user space
and not wanting to make the implementation the same as the user view
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
I said that (in not so many words) an hour ago
pete didn't buy it
and the param code can be stuck into a separate function, so it can be in a slower thread
SWPadnos, we were discussing a filter and having canned algos embedded in it and it checking to param updates
there are pretty easy methods of bulk updating internal data atomically
I objected due to the limted usefullness of the filter and all the uneeded checking
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
but canned algorithms can be implemented with a simple function pointer internally ...
and I suggested a generic user space app that would read an xml description for each comp
and that's where the whole thing started going downhill ;)
but mentioning xml wasthe first mistake ;-)
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
well you are flat out wrong, because I have it in other apps
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
s/tag/whatever the actual data is called in XML-speak/
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?
the XML would be written one time, by the developer of the module
the lines of code/xml is about the same, the diff is being compiled or just interpreted
but that doesn't make it irrelevent
and you could have a large program if you wanted, limited by filesystem/memory, not XML
the idea is to not have to duplicate the GUI work
we're not communicating again
(possibly limited to 2 or 4G by a 32-bit number in an XML library though)
it's not the work for each comp
that would be about the same either way
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
there is the XML that describes the computations, checks, and associated error messages, and then there is the generic code that interprets the XML
a program in what language?
language of implementers choice
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
the GUI that reads the XML and does what it says
then it displays the user view of the comp
and maps it to the underlying implemetation
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
remember - every programming problem can be solved with an additional level of indirection :)
so there may be some calcs that tie the user view to the implementation view
no, the C program would parse the xml
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
petev, he's talking about including custom C code in the XML data
(at my suggestion)
I wouldn't use a compiled language for the user space description
sure - python, perl, bc ...
I don't think I would go as far as putting C code in the xml
I think some simple calcs would suffince for most comps
so in order to write a component you need to know more than just C?
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
jmkasunich, the xml would have a description of the user view and the implementation view, and the mapping between them
we're only talking about things that can't be described with some pre-determined functions
since the configurator would need to do math, there should be support for equations and variables in the XML DTD
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
and some predetermined ones, like THREAD_RATE or the like
me or jmK>
what kind of math is involved with those coefficient calcs?
jmkasunich, I don't think we have to go crazy onthe first cut, start simple and expand the description capability as needed
SWPadnos, basic operators and some trig
you are using the complex case to justify doing this
I think bc can do a fair amount, and there are other command-line calculators that can do things like integration
so it better be able to handle the complex case
no, I don't think a filter is a complex case
the simple cases are handled just fine already
the filter can be handled without full flow control, etc.
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
you can start small and prove that it works, then add complexity later
I can write the parser with ANTLR if that's what's needed
then someone can add the GUI part
wtf is antlr?
it's a code generator
it's a parser generator, generates C++ code
similar in concept to yacc / lex / bison ...
this is making me insane, I need to stop talking to you guys
heh - oops :)
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
those are all concious decisions and goals that reflect my priorities
your priorities are obviously different, and we will never see eye to eye on this
I think you had / have some things you'd like in HAL, but we haven't been able to get there yet
such as separating load from instantiation
and having userspace able to call kernel code safely (like walking the various namespaces for pin lists)
and also having a user interface (like a schematic editor) at some point
(separate, but still configuration related)
any mechanism that can do that for the antlr/xml/c++ approach can do that for the simple C/shmem approach too
sure, so it seems there's agreement on some architectural things, but not on implementation
or if not architecture, then at least frature sets
I have a very selfish feature request - that a C programmer be able to write stuff
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
(I know because I'm more of C programmer than C++ ;) )
there are no other good reasons these days to stay away from C++ in favor of C
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
I disagree with that - personal preference is a perfectly legitimate reason
ok, that's valid
and lets NOT get into a C vs C++ discussion
[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!
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
I never said it was techinical - but the more differnet languages you require a developer to know, the smaller the developer pool gets
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
though nothing we've mentioned thus far is as bad as man-groff (or whatever that is)
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
thats by far easier for a novice to figure out than C++
antlr wouldn't be needed for the average developer, only people who need/want to work on the configurator program
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
just like only people who waht to work on axis or comp (or whatever) need to know python now
aw, you guys missed it... I posted the answer to all our problems during the netsplit
yep, I saw it
and I agree with everything
nevermind - that was a stupid question
he agrees with everything I posted during the netsplit
ah, I see
darnit, my company just hired 5 people and 3 of them are named chris
how many steve's do you have?
they'll just have to go by something else I guess
actually none - they're all named mike
how do I use the autotuning?
first, start before 10pm, I'm sure
use at_pid, then do some stuff petev knows about
beyond that, I don't know ;)
is there a man page for at_pid?
$ man at_pid
No manual entry for at_pid
petev: in biquad, do you really want s1 and s2 to be parameters?
aren't they just internal variables?
yes, they can be directly set when using direct mode for various startup conditions
maybe this will never get used, so we can make them internal if desired
did u see the farm error?
I don't get that here
I'll look into this breezy compile failure since it doesn't look like anyone else has yet...
well that was easy .. for someone who happened to have access to an actual breezy machine :-P
* skunkworks chears from the cheap seats.. :)
me is fighting the flu this weekend
well you understand. ;)
Was hoping to acutally cut some boards with the tool set microswitch.
yuck -- get well soon
SWPadnos_ is now known as SWPadnos
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.
To John K, you sure cleaned up my mass of spaghetti code - read_encoders is now less than a page.
But, I have a problem that encoder.xx.index is stuck true. I'm trying to debug it now.
elson: Would it be very hard to implement the "pcisetup" functionality into the USC driver?
or throw a copy of it with with emc?
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.
elson: lets take them one by one..
does emc2 run now?
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!
elson: or ass the option to do so..
It appears that is is ONLY needed by certain Dell boxes from the late 90's.
elson: so make it a insmod param (loadrt hal_ppmc ... pcisetup=1), which is not by default
some hp boxes too..
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 :)
Yeah, an insmod param might be OK. I was hoping the need for the horrible thing would just go away.
it probably won't, as long as old dell boxes are good for running EMC (and they're still available)
I can't get the latest compile of EMC2 to run.
you probably did the CVS checkout as root
elson: latest TRUNK?
No, I have not been root at all.
Really, that is just a local name, I did a cvs ... co emc
hmmm. that seemed to me like it could be the "unable to remake Makefile" thing, but I guess I'm wrong :)
elson: ok, lets take it step by step now.. did you run configure --enable-run-in-place
Yes, I got that "unable to remake makefile" message.
elson: that's a different issue..
Yes, I did ./configure --enable-run-in-place
you clean that out by running make clean
after I did the make clean (umm, I think I did, anyway)
elson: ok, did make clean, make, sudo make setuid work without warnings/errors?
Maybe I need to rerun the ./configure to be sure
I think there were no errors
what's the error when running emc2?
insmod reports ...rtlib/threads.ko "operation not permitted"
what does dmesg tell you?
I know.. I bet it
I know.. I bet it's the new restriction inserted by JMK
you can't insert faster threads after slower ones..
ah - thread period order
yep , fast first, slowest last
always existed, just didnt gnr8 error
Hmm, yes, "new thread period less than existing thread period"
elson: what config are you trying to run?
that really should be a min() function in threads
ahh, something cobbled up by Stuart Stevenson, and hacked just enough to run on my Bridgeport with PPMC.
But, it ran before the rebuild.
right - threads used to silently do the wrong thing sometimes
now it complains instead
OK, so I just have to change the order of RT threads in the load hal file?
make sure name1/period1 has the lowest period, then name2/period2 ...
OK, I'll try that. Hmm, "do the wrong thing", does that mean that the way threads were dispatched could get fouled up?
elson: this order fixed my prob last nite, fro xmpl... loadrt threads name1=fast period1=20000 name2=pdmthrd period2=500000 name3=slow period3=1000000
it means that in some cases, you could get segfaults (which is what tomp noticed, and the specific fix jmk made last night)
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
at least, that's my analysis of the problem (without benefit of having looked at the code ;) )
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?
probably soemthing didn't recompile the first time
only if it was from late last night or this mornong
that's why you got the error failed to remake makefile
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.
possibly because index-enable is expected to be reset by the encoder driver ???
but I'm just speculating here
But, it will nOT be reset if you abort the move early. ESTOP or abort should reset it.
OK, I'm going to try to fix the thread order.
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
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
it's kind of a handshake really
motion says "I want this sto happen" and the encoder driver resets the pin when "it happens"
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.
jepler, u there?
I see that somebody else has had out-of-order threads
I thought it might be a good idea for threads to create then in ascending period order
you mean sort them so no matter what the user specifies he gets the proper result
(instead of an error message)
ther ewould still be an error if the base period had already been set (from a previous load)
I was thinking about that last night
also thinking about getting rid of name1=foo name2=bar and having arrays like we do for step_type
yeah, I was thinking of that as well
so you could sort or keep a list of the order in which to create the threads
how many decimal places does emc need to not give errors about arc radius length?
not sure, thats an interpreter thing
I think its a #define actually
I'm using 6 in the post, but apparently that's not enough
I wish it would at least say which line it doesn't like
at least axis gives a line number in it's error dialog
petev: the documentation says this:
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:
* 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).
the recommendation later on in the documentation is to use 4 digits precision for inch output and 3 digits precision for millimeter output
now that I get the line # from axis, I can see it's the first arc move
I think maybe the vector is from center to start and not start to center?
I'll change the post and try it again
bbl, good luck with your arcs
yeah, the doc is wrong, the vector is from center to start, not start to center
I1 J1 means the center is +1,+1 from the start
hmm, I switched it in the cam to be center to start and all worked fine
maybe the cam defines it wrong... what does the generated G-code say
it's a bunch of small contour folowing moves so it's hard to say, but the path looks correct visually
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