SWPadnos : u still there?
here for a bit
rayh, you mentioned something about a demo today - how did it go?
swp: I was just thinking it may not make sense to export a lot of the interp status in the API
all of it, actually
most of it looks like what should be from canon
you need the API to support debugging and setup, so it's all got to be there
I don't see much need for a lot of it from interp
(that's one thing I often forget about)
hmm, not so sure about that
most of the status from interp is the same as canon, but the interp is just further ahead
maybe have a debugging API which is a superset of the "run" API, but there still should be hooks for debug in there
with G-code, yes. with a more high-level interpreter, that may not be so
I'll have to think about debug, but I don't think the API is the way to do it
I think many of the GUI problems today are because they get interp status instead of canon
there needs to be a debug API, even if it's an optional component to load
what kind of stuff do u want to see in the debug API?
I'm not sure at this point
(sorry - I'm thinking about other stuff right now - got a friend coming over in a minute)
I think usefull interp debug might be writing the blocks out to a file, the parse tree, etc.
or stuff like HALscope gives us - canon spitting out coefficients and the like (like logging)
ie, look at it when you're debugging a problem, but otherwise it's dormant
yes, and doesn't clutter the API so that the wrong status gets used
also, a sim API would be good
(not sure exactly what that would be like, but it just occurred to me ;) )
I'm going to make two canon classes
the debug one will be first
right - start with everything, then drop what you don't need / use
(like most technology products)
plus not sure what the SHMEM interface will look like yet
architecturally, the physical interface shouldn't matter
did I hear SHMEM?
yes, from canon to motion
SHHHHHHH - mem
that's why I can't do the SHMEM version, only the debug
the API will be the same, of course
heh, I don't know much about interps and such, thats why I've been quiet lately
but when you start talking about the motion interface, I delurk
yeh, but what about motion?
getting down to that layer quickly
you've seen Josh's emails?
you should look at the canon header too, it's lacking in the axis/motion area
yes, saw it
but I come back to cutter comp
how do we handle it with splines?
you mean if the language allows you to specify splines? then I dunno
if the language is still arcs and lines, then you offset before you convert to splines
gets very hard, or at least for my math challenged brain
right, arcs and lines are easy
use splines internally because of the good things they do for the planner
but I thought the whole idea was to reduce sample error too
may not be of much use though if you can't get splines from CAM
ok - friend's here - may be around, sort of ;)
jmk: are u up to speed on all of the offsets used in EMC?
the demo got postponed until tomorrow.
good thing gave me a chance to polish.
from the command struct in motion.h out to the motors I pretty much know, (except some internals of the TP)
Hi pete john
above that not so well at all
yeah, it's giving me a headache all the places I see offsets and origin stuff
ray's your man...
yeah, in the interp, canon, etc.
I don't have a good handle on it yet
been stumped for a day on how to handle as many pins, params, and such as a good sized installation will show.
as long as the motion controller never sees 'em I'll be happy
Yep still. Found a BWidget tree
jmk: u can probably help on these issues
which ones, rays or yours?
how are the feed/speed overrides and optional block delete handled?
not a clue about block delete
that will let me build trees from the answers to halcmd show
hmm, seems like it needs to be handled in motion because of the queue
feed override sends a command to motion that sets a variiable called "Vscale"
feedrate override is a scale variable that is applied inside the motion controller
but where does it come from, I didn't see an NML for it?
the same variable is used for feed hold, sets scale to zero
I'm not sure of the NML
ahh, cycle hold was another issue
lets find out... open motion.h first
in that command enum, EMCMOT_SCALE is the command to set the scale
phone, 1 sec
grepping shows emcmotCommand.command = EMCMOT_SCALE; in taskintf.cc
the call that sends that to motion is emcTrajSetScale in taskintf.cc
ganging up on you
Issuing EMC_TRAJ_SET_SCALE -- (+209,+20, +7,0.560000,)
the ray brigade
yes, I see the set scale
emctaskmain.cc calls it
ok, that explains feed
does speed use the same thing?
in response to a NML EMC_TRAJ_SET_SCALE_TYPE (one of those gawd-awful switch statements)
what is "speed override"? spindle speed override?
motion never sees that, spindle stuff goes off to the io controller
ok, don't u think all of this should go through canon?
well, canon is probalby what sent the NML in the first place
no, it's bypassed
EMC is like an onion
NML goes around it
I think canon should send it
lots of layers, and when you open it you cry
task must be sending the feed/speed values
so the GUI directly sends that NML?
there is nothing in the canon API for them
ok, GUI sends to task, task sends to motion
only to enable/disable them
yes, that's what I think
haven't confirmed it
keep in mind, canon was intended for the interp interface
feed override is never seen by the interp
why only the interp?
ask the original designers
they say it's the model of the machine
well what do you think about using it as the model for the machine?
that's the direction I'm going
I'm open to the idea, as I am to lots of other ideas
ok, I will proceed along those lines
but I can't give a really informed opinion
how far off are u from looking at the new motion interface?
I sent stuff to swp and cradek too
I do know that the more you change the architecture, the more likely you are to have strange problems, and resistance from others
swp is looking at it
yeah, I hear u, but I think they are good changes
swp had even more radical ideas
I thik the code will be much cleaner and easier to understand
pete: I really appreciate your enthusiasm, and envy your energy, but I just can't keep up
I have a good chunk done and it's much smaller than what it replaced in terms of source code
it's really not that much code if done right
let the tools do the work for you
I'm not talking about code...I can't keep up with your ideas
I don't know, seems like the code is out of control now and nobody can make changes without breaking things
there are large sections where that is true
but some folks manage
the lermen interp mods for instance
I'm still headed for the ideas in the doc and pic we did
swp wants to go even further with binary interps, etc.
he has some good ideas
I'm scared to look at the lerman stuff
the interp is so bad now, I can't imagine how he did it
I have high hopes for at least some of that, but my timescale and yours are about an order of magnitude apart (thats what I mean by I can't keep up)
but u totally have a good understanding of what motion has to do
why fight with the current code
it doesn't seem like it will take that long to just re-write it
question: how much time are you putting in on this lately?
I'm spending way more time figuring out how current stuff works than re-writing
probably a few hours a night
hell, I've been spending a few hours a night just talking about it ;-)
I coded the headers last night when u and swp were talking about the tcl stuff
I intended to work on VCP code last night, but didn't write a line because we were talking
I guess I have the advantage that I get my questions answered, u guys go to sleep, then I get a few hours
I did work on VCP sunday, but stayed up till 3:30, which I'll be paying for until Saturday when I can sleep in
exactly - when it was Paul and Alex I had these conversations with, I had the same advantage!
alex is asleep before I even get here
ray just reminded me of another thing I have to do.... test the UPC driver, now that I have a prom with the UPC fpga config
seems like the harder I work, the behinder I get
ok, well I'll keep going , then worese case I'll have to write an NML canon
sorry I can't take a more active role, I really enjoyed our late night discussions (until the time spend caught up with me, both lack of sleep, and lack of progress on other things)
no problem, I have a lot I can do now
the motion talks really helped
I did try to look at the canons at lunchtime at work, but the doze box made a mess of the unix line endings, and I wasn't sufficiently motivated to fix it
ahh, try wordpad
it handles them ok
I got a really stupid question, why would you ever use the D and H codes?
I thought that is what I used, but maybe it was notepad
wouldn't you just want the values from the tool table?
I don't even know what D and H are
yeah, notepad yacks
D and H are for cutter radius and TLO
I prefer it to wordpad most of the time tho
because wordpad nags me whenever I want to save as plain text
thinks it knows better than me what format I want
yeah, a lot of MS stuff is like that
fscking microshaft file formats
a few questions for jmkasunich regarding pwm board
05 float -W 1.00000e+00 ppmc.0.pwm.00.max-dc
05 float -W 0.00000e+00 ppmc.0.pwm.00.min-dc
these are the max and min output from ini?
they are the max and min duty cycle that the card will put out
IMO they don't map to any particular ini variables
they will probably be set based on hardware issues
for instance some MOSFET drivers (Jons maybe?) can't do 100% duty cycle
05 float R- 0.00000e+00 ppmc.0.pwm.00.duty-cycle
How does that fit in
thats a param, right?
all of these are
it is the duty cycle the board is putting out right now
(for scoping, troubleshooting, etc, unused in normal operation)
just like the frequency parameter on the stepgen
oh okay. duh
not duh, these things aren't written down anywhere yet
05 float -W 0.00000e+00 ppmc.0.pwm.00-03.freq
i should have seen the R-
the desired PWM carrier frequency
20KHz for quiet, lower for less switching noise in the MOSFETs
these are really params that should be specifed by the guy who builds the power stage
Okay. I presume that i can get some answers from jon's ini on these
I don't know if he ini's the frequency in emc1, or if its hard coded to match his power stage
the last one is the only one a normal integrator would probably mess with
personally I'd set it to the DC bus voltage
that way, the input command is in volts
you command 24.3, and the duty cycle will be whatever it needs to be to deliver 24.3 volts (average) to the motor
set it to 80 then
if you command 30V, the duty cycle will be 0.375, and you'll get 30V at the motor
I like it when the PID output and other internal signals have meaningfull scaling
you could also set scale to 10, if you are a traditionalist... then commanding 10 will give you full on, just like an analog input servo amp
what about these
05 bit R- FALSE ppmc.0.pwm.00.enable
05 float R- 0.00000e+00 ppmc.0.pwm.00.value
value is the command
maybe that name should change...
this is in from the pwm out?
enable is just what it says, when off, the PWM outputs are off
no, it is an input to the PWM
so that is the same as the stepgen enable
I need to do something about R and W, the directions are backwards for pins compared to params
a read param means it is read only for the user, IOW an output from the component
a read pin, is one that the component reads, IOW, an input to the component
fscked up, I know...
we do what we can.
its one of those things that I'm used to, but I will be answering questions from people confused by it for the rest of my life until I fix it
(heck, sometimes it even confuses me)
I don't have that problem cause I'm not used to anything.
I presume here that I need to connect linksp Xoutput => ppmc.0.pwm.00.value
is Xoutput from the PID?
if so, then yes
hey - what does the -R mean?
(pin / param directions - answering questions ... )
read back, I just explained it to Ray
heh - I know (hende the :) )
watch that haircut
(sound of it going right over my head)
no danger there, getting pretty thin on top
fsck, these interp axis and origin offesets are giving me a headache
there are way too many
there are probably good (or at least plausible) reasons for every single one of them
good luck finding them tho
what is the point of both G92 and G54..G59.3?
seems like G92 is not needed
ask ray or someon else who knows G-code
ray: u still here
G92 has been the center of many a discussion
yeah, and it has side effects on G54 data
I don't like it
especially with Tom Hubin, I think ;)
oh, don't remind me
heh - my ears still hurt
is Tom in dislike of G92?
yes - he was at the EMCFest in April and got into heated arguments with Ray and almost everyone else at one point or another about G92
you could say that
he wanted to do something with it, that everybody else said should be done another way
how "it's different from TurboCNC, which is GOD!!!"
but he stubbornly inisisted that it should work the way he wanted it to work
that kind of thing is probalby why there are so many offset and such in there
actually, G92 has a different purpose than the offsets (I think)
g-code in general wasn't designed, it evolved, defined by competing commercial companies who had absolutely no commercial gain from maintaining a uniform, logical standard
it seems to set some global notion of offset, but some of the G92 also overrite the G54 values for the system in effect
only worse, at least with HDTV, somebody eventually won and the market moved toward a standard
yeah, I wonder what fanuc does with this
G92 doesn't change the offset parameters, it just changes the offsets currently in use (I think)
ray wrote a long paper about G92
well -18 standards. 19 if you count normal TV
swp: some version of G92, but G92 itself changes things
I don't know where it is offhand, but it should be required reading if you're gonna tread that minefield
I just want to finish the interp
then finish it with a G92 that works exactly like the one we have now
anything else would be a disaster
yeah, if I had a good handle on all the subtle side effects
easier said than done
thats where ray's oaoer comes in
plus there is all this origin and offset stuff in the code
not really sure what the diff is
seems to be the same thing
G92 is offset, but it's changing origin
the G54 to G59.3 offsets are independent sets of offsets
they don't combine with each other
according to Kramer, they do
G92 is combined with any other offset
no -G54 and G55 will select different offsets
each of those will be added to the G92 offset, it G92 is in effect
I understand the G54..G59.3
so, for example, if you break a tool, and replace it with one that's .002 shorter than the last
but kramers verbage on G92 is not the greatest
yo ucan move down .002 inches, then issue a G92 Z (here + 0.002), to compensate all G5xx coordinate systems to the new tool length
kramer says "when G92 is executed, the origin of the currently active coordinate system moves"
as long as the program doesn't use G92, you'rea ll set
anyone got a link to Rays paper?
I asked him a few mins ago, no answer, may be away from his box
probably a link at linuxcnc.org
in the dropbox, he said in a user list post
ok, I'll check
looks like there is a notion of current G92 offsets and saved params
[03:12:17] <jmkasunich> http://www.linuxcnc.org/Dropbox/g92test1.pdf
the current offsets are in params 5211 to 5216
no, I don't those are the saved values
heh... the paper describes how it actually works.... "This paper does not attempt to say that this is the way it should work"
when you set G92, the offsets are saved
(according to kramer)
you can zero G92 offsets with G92.2 and not change the params
yeah, there is G92, G92.1, G92.2, and G92.3
G92.2 disables the mode, but doesn't zero the params, G92.1 disables the mode, and zeroes the params, G92.3 uses the saved params
yeah, well the way it seems to disbale the mode is by clearing the interp offest vars, but not touching the params
so you have it all - enable and set new params, enable and use old params, disable and save params, or disable and clear params
that's what I mean about the ones in use vs params
that would be an error ;)
what would be an error?
petevyeah, well the way it seems to disbale the mode is by clearing the interp offest vars, but not touching the params
that's for G92.2
OK - that's to spec
the interp is always using it's offsets (I think) and just sets them from params or clears them
that's fine, internally
ok, I think kramers verbage is misleading, because I don't see what he syas in the code
I'm goin with the code ;-)
well - that's how it's *supposed* to work ;)
I still can't get over the atan swill
rays paper goes into some depth on what exactly it does
ok, u know you're in trouble when u need a 22 pg doc on G92
You haven't met Tom
it's not a simple matter though - it does affect all coordinate systems, and has several options on how it's used
oh - can I get a copy of that "force HAL unlock" program? ;)
I never compiled it last night, too much fscking around to do it from the command line
I should just add it to the makefile and commit it
either way - I was glad that halcmd isn't what I fubared
you mean the segfault from scope?
you only get a lockup if you segfault while holding the mutex
both halcmd and scope do grab the mutex, but only to traverse the linked lists, then they release it
if I is gonna be a reel programmur, I'z got to be able ta unfubar my fsckups
you know, what I should really do, is put a timeout at the beginning of halcmd
if it tries to get the mutex for more than a couple seconds without succes, it assumes that something is busted and releases it
right - it only holdsthe locks while it's actually executing commands - should be short
or havean option to do it
an option would be better
I should do that
I seem to have brain freeze on my VCP stuff tonight anyway... keep going around in circles
circles are good - make nice meters ;)
not when its my brain that is going around and around
ah - you need a brainmeter
feel free to use me as a sounding board
sometimes I feel like mine is stuck on "duh"
tell you what... I'm gonna send you the source for the unlocker...
ok - I'll merge it int o halcmd with an option
if you want to add it to halcmd, I'd appreciate it
any choice for the option / command name? (forceunlock)
its main is 30 lines, and there aren't any functions - the main could be pretty easily turned into "do_release_mutex_cmd()" and called from the parser
(to reduce the shit :) )
I like that
but halcmd only uses short options.... -u I guess
could stand for unfubar, or unlock
yep, I like that one
it should be a command - it needs RT to be loaded
make it a case sensitive compare, and don't list it in the help screen
(the options are done before RT)
right, but you need to call it instead of hal_init, because if you call hal_init, you will hang waiting for the mutex
ah - OK
the way I see it, you give this option, halcmd does nothing except release the mutex and exit
ignore all other options, ignore any commands
ok - maybe a -F -u (Force unlock ;) )
with a prompt if -F isn't specified
too elaborate I should say
ah - I was waiting
(or wondering if you meant "do elaborate ...")
no problem. -u to unlock
just -u, imo
hmm - do we need a lock check as well? (or can that be done while the mutex is held?)
gotta stop talking and mail it already
for realtime stop
ok, code on the way
cool - thanks
you know there is another kind of locking (maybe what you are talking about now)
you had mentioned that realtime stop couldn't stop
since it used halcmd, which couldn't initialize
halcmd stop was broken
the other locking was intended to stop people from doing unlinkp or linkpp or setp on a running machine
and there are "lock" and "unlock" versions, so -u may be a poor choice for the mutex release
it would be useful for that to be available to (e.g.) tcl programs ;)
the lock command can be "lock none", "lock tune" or "lock all"
none unlocks everything
tune locks pins and params and loadrt, leaves setp open so you can tune things
all locks everything
there are matching unlock commands
but you can't check the state of those locks (there's not getlock command)
must be root (sudo) do use the lock and unlocks
or just plain status, shows all status
currently status choices are lock and mem
hm - maybe I'll add the -s option, to suppress headers on show output
-s for script friendly?
and the extra u8 and u16 print
sounds good to me
the help may exceed 25 lines though ;)
heh, its only 20 now
ok - I'll be OK then
damn thats a long file
over 2800 when you get done I'm sure
definitely - it's up 5 lines, and I haven't added anything yet ;)
just a var and a case
for the help: -s Script friendly
still trying to think of what to say about the mutex unlock
or -s Script friendly (no headers on output)
99.99% of folks will never need it and might be confused by it
-r Release mutex (for crash recovery only) ?
I wonder if the get/set sig/pin commands should be moved around in the help
get and set on their own lines?
ie - gets / getp gets the value of a signal or parameter
sets / setp sets the value ...
so that set and get are correctly alphabetized
heh, they're not alphabetized now
hmmm - the commands aren't alphabetized (options are)
layed out by function
ok - I'll leave them where they are, but changethe grouping
get that source yet?
hmmm - maybe -h prints the info about -r (-u), but plain "halcmd" doesn't
how about this: you have to give -g (for guru mode), only then will it print the help for the -r ;-)
and you need -g -r -r to actually unlock
and of course, -g is only documented if you specify it
which can be abbreviated as -grrrrrrr
so - do you want -r, or -u?
r I think
I guess r makes sense (maybe R - just to make it harder ;) )
we have an unlock command, don't want the word unlock to appear anywhere else
since it is a forced release
yeah, -R is fine
ideally, nobody will ever need that command
pwm link question when yo get a chance.
Is this the correct link for pwm out to ppmc in linksp Xoutput => ppmc.0.pwm.00.value
I think so... Xoutput is connected to the output of the PID block, right?
then that is correct
I wonder exactly how halcmd exited yesterday....
it happened when I tried a list command and instead of redirecting the output to /dev/null, I tried to pipe it there
should scriptmode be mutually exclusive with "-kf" mode?
no - nevermind - it shouldn't
linux must have terminated the process after it tried to write to the pipe
thats the only time it would have the mutex (iterating thru the linked list, printing each name)
when I enter the command above it gives no error but doesn't show the signal either
enter from the cmd line, or in the .hal file?
command line bin/halcmd linksp Xoutput => ppmc.0.pwm.00.value
value should be velocity, no?
on the command line you can use the arrow, bash thinks you are redirecting the output to file ppmc.0.blah
you probably have such a file now, with the error message in it ;-)
=> should be an error though
s/can/can't/ CAN NOT user the arrow
I can't type for shit
I cnat ithre
swp, bash has no problem with that syntax, it opens the ppmc.0.blah file, then invokes halcmd with the rest of the line
I'd have thought that the '=' would be an error
since the pin name is missing, halcmd errors, but he message goes into the file and you never see it
echo 1 foo => bar
puts "1 foo =" into bar
ok - the = ends up as a parameter to the func
working better now rayh?
I didn't understand anything you guys said... but tried without the ==> and now it shows.
thats what counts
rayh: you do know about redirecting to files don't you?
cat foo >bar copies foo to bar...
the > in the arrow is what causes the problem
okay got those now.
it is ppmc.0.pwm.00.velocity though, not value, right?
no it's value
and that's the R- pin?
well that's what halcmd says.
SWP: value is the input to the pwm module
ok - it's velocity to the stepgens
05 bit R- FALSE ppmc.0.pwm.00.enable
05 float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
after all, PWM duty cycle doesn't produce velocity, only voltage
ok - but then stepgen should be frequency ;)
and pwm should be dutycycle
velocity is scaled, so it isn't a frequency (frequency is in Hz)
ok - I can accept that
value is scaled, so it isn't a duty cycle (duty cycle is 0.0-1.0)
value maybe be a poor choice tho
(but you had to think about it ;) )
perhaps command or something would be better
05 bit R- TRUE ppmc.0.pwm.00.enable <== Xenable
05 float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
how's that look
looks good to me
rayh: a question for you
ppmc.0.pwm.00.command for both stepgen and pwm would be easier for a newbee to understand.
suppose that I decided that ppmc.0.pwm.00.command made more sense than value
I guess you'd be in agreement
I can change the component, and change the ini or hal files in the configs directory
but files like the ones you are developing would break
it isn't released yet ;)
even for a purely cosmetic change like a name
who else is developing for it now.
fix it now, or forever be screwed by all the people who get screwed when you finally get around to it
ok, just figured I'd ask
I understand why it wouldn't work for this but if stepgen and pwm could be combined to a single name
IMO, command instead of value is a no-brainer for pwm
then the same links would work for both.
no they wouldn;t
or even something kinda generic, like "input" (though that has other connotations)
ppmc.0.stepgen.00.command vs ppmc.0.pwm.00.command
they should, if the scaling is right
you still have to change stepgen to pwm
link pid.output to pwm.input - that makes some sense
and that's okay
ok, lets discuss this some more... good people to have for it
hm - "to" should be accepted in place of the arrows
I avoided "input" and "output" for drivers of any kind
because "input" to a driver probably eventually becomes "output" from the computer
and I was afraid that would be confusing
what do you guys think?
it can be explained that every "block" in HAL has inputs and outputs
PID has the input command, and an output value
* rayh looks at some of the IO stuff.
for purely internal blocks the potential for confusion is much lower
a driver has an input command, and a physical output
another driver has a physical input, and an internal output
think about the digital I/O
ppmc.0.dout.00.input seems screwy to me
yes - a bit is a different puppy though
as does ppmc.0.din.00.output
amp-enable-out i like this
how about ppmc.0.dout.00?
no input or output
well there is also ppmc.0.dout.00.invert
that's a param
and for the inputs
ppmc.0.din.00.in and ppmc.0.din.00.in-not
or just din00 and din00-not
(though I know there's good separation of functions now )
those make a lot of sense
one other thing, as long as we're on the subject
I guess in the back of my mind I have the component-pin model
I think we discussed this at fest, but I'll bring it up again
din.00 is a component
in, and in-not are pins of that component
if I had a schematic editor, the box would be labeled din.00, and the pins in and in-not
with that model, din.00 or din00 would mean a pin with no label at all
true - but only 0.0003% of the population is familiar with schematics ;)
its not just the schematic thing
anyway - the thing I wanted to discuss was - can't we just leave the "unit number" off of hardware drivers?
if we ever want heirarchical HAL (did I spell it right?) we want blockname/pinname
the first output on the first board
(nope ;) )
(i before e except after c)
fuck it, "layered HAL"
Now you're messing with my head. I thought that "05 RT hal_ppmc" showed that hal_ppmc was the component.
with the ppmc, there are three layers
ppmc.0 is all board(s) on the parport cable
I see that
no -hold on
pwm.00 is one pwm generator, kinda like a subcomponent
ppmc.0 is the first board found, right?
and enable is a pin of that subcomponent
nope, ppmc.0 is the bus
if there are two boards on the bus, you get ppmc.0.encoder.04, 05, 06, 07.blah
likewise with the dins
ok - that's why you have the next_stepgen vars in the bus struct
that concept is new for this driver, and maybe what you were getting at a few mins ago?
but it happens with parport as well, I think
parport is a special case
just like ppmc ;)
the pin numbers there are the physical pins
because otherwise you need a cheatsheet
and I think on the parport, they are called parport.0.pin-04-out or something
face it, we need a naming convention document for HAL modules
yep - I checked ;)
I've been writing hal modules for 2 years, and even my own ideas of what is right have changed in that time... add in other folks' opinion, and you have a mess
No you have evolution which is good.
look at the mess we're in with evolution now ;)
evolution is good, but the older drivers should be brought up to date so users can apply the same logic to drivers written 2 years ago and drivers written tomorrow
at least they should be before the release.
if we decide on a naming standard, I can get a lot of drivers and ini files changed in pretty short order
and hal files
list of outstanding HAL issues:
misleading or confusing use of Read and Write for params and pins
I don't think breaking a few test setups will hurt
and everything is a test setup at this point (for the most part)
lack of consistent naming conventions for pins and parameters
um how about the name of the pin, param following the name of the module
like iocontrol and classicladder
ok - print module name instead of owner ID in show
not a big issue
(I don;t think)
ray: in some cases they do (some again...)
I was wondering why motmod pins were named axis
instead of this:
because they are unique to an axis, and there are multiple axes in one motmod
05 float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
you should have this:
hal_ppmc float R- 0.00000e+00 ppmc.0.pwm.00.value <== Xoutput
fucks up the column alignment, unless you pad for the longest possible name length
you could do that on the script-friendly version if you want
true, but column alignment shouldn't be a priority over functionality
yep - was just thinking that
the human friendly ones needs readibility
or maybe -n - use names
a human can easily follow with show comps to get a magic decoder ring
btw I found a tree widget that can display the stuff swp and I were talking about.
99% of the time a human doesn't care about the owner field
I never got the chance to look at the BWidget page you linked
I just got a start at adding nodes and it looks good.
incidentally - there should be a list of packages that emc depends on, so that it's easier to aggregate everything into a custom distribution
so add BWidget to the list ;)
Well let me play and demo it first.
that package is about 250k
touch list ; echo BWidget >> list
pure tickle so no other dependencies
250k should fit on a CD ok ;)
I can imagine pressing a linkpp button and then selecting the two pins from the tree.
I can also imagine pressing a link bundle and selecting an axis node and a pid node.
ok - that gets back to naming conventions
(unless you want the tcl program to know all the significant names)
It's not like the entity we were speaking of for bundle. It just makes a set of links.
right - but which set?
it has some pre-existing knowledge of what an axis and a PID are?
do you want that in the tcl code (and change it if any pin names change), or have anaming convention that lets you figure it out?
um I was thinking of a hard coded set.
ok - that's easy, but has maintenance issues
as long aswe don't go changing pin names too often
Dont think I could get my head round the procedure required for automating it.
hopefully the things we would use that for will be pretty stable
or else the knowledge is imbodied in a file of some kind and imported
That would work also
name = PID to axis
you invoke it by name, and give it A and B
then you just add another bundle definition to the file and your tool gets smarter
actually, the don't even have to be bundles
what we are talking about is basically hal macros
with expression replacement
a macro to connect an axis to a pid
a macro to connect a pid to a ppmc
jmk - should I leave the unlocker name as "hal_unlocker", or still use halcmd?
I thought you were gonna extract the code from the unlocker and embed it in halcmd?
that avoids another executable
and a change to the makefile
and another source file
I did, but it contains a name for the rtapi_init
ok - left alone
halcmd appends a pid, so you can have more than one at a time open
this doesn't need that
true - it'll just be the exact code
not that I noticed
there are two of you now
the windows machine just disconnected and reconnected for no apparent reason
three of me
SWPadnos__ is now known as SWPadnos
Alan Parsons, actually
("The Three Of Me", from "Try Anything Once")
I was thinking of the cloned sheep
hmm - I'm thinking of making a lot of things change with script mode on
like status, show, list (use newlines vs. spaces), maybe others
you can lose the padding I applied around the numbers to make the fields line up in columns
for sure - data_value2
ok - I won't change the normal output, so it shouldn't matter
list in particular was intended for parograms in the first place
ok - maybe I'll just make that use newlines
I don't recall why it did all on one line instead of one per line
can you think of any reasons to keep it on one line?
I wish I could remember who wanted that
* jmkasunich checks commit log
I'll bet that python likes a single line better than a bunch of lines
I'll leave it
rayh: any requests for the "show" output?
I'm using list for the first part of it.
list was added back in june
ok - I'll leave that alone
SWPadnos__ is now known as SWPadnos
here I am again
guys, I hate to swith topc on you, but cradek brought up an interesting issue in his bug report
currently there is no code in the interp for changing origin and offest values when units are changed with G20/21 and it is documented that way
do we want to change this behavior?
it is documented which way, the way it works, or the way it doesn't work?
what about TLO and cutter comp too?
the way it works
the broken way
docs match code, but both don't do the "right thing"?
when it comes to the interp, I stay out of discussions about the "right thing"
rayh: did you read cradek's bug report?
it seems like it would be easy to duplicate the problem
I don't even think you have to exit, just set the offset with one units, then switch to another
if if you or someone else familiar with the behavior of that part said "this is a bug" then if pete can fix it he should
I wonder if tkemc behaves differntly than axis
well I think it's poor behavior, but not a bug since it works as documented
it seems so obvious that somebody should have noticed by now
how many people switch units in the middle of setup?
I sure don't, learned that the hard way on the BP
it doesn't handle it gracefully either
interesting - the feedrate gets set to F0 when you do G20 or G21 (with AXIS, at least)
Yes I did read the bug report.
no - the feedrate gets set to 0 if you command a move that results in no motion
do you agree that it is a bug? can you (or do you feel the need to) duplicate it?
(addressed to ray)
yep - I've gone back to halcmd ;)
NIST wanted to be able to directly read and write the tool and offset tables
so they intentionally avoided doing unit conversion on them?
So they assumed that whatever units the interpreter started up using that would be what the numbers in there are interpreted as
is it something we want to change?
should we put units in the tables?
You do have to be careful when you set offsets.
the parameter file numbers should probably be in "user units", but that may break some things
not "currently used" units
If we were to build gui interfaces to all of these things then I'd say write the whole thing in mm.
what are user units?
set in the ini file
lightyears parsecs you name it.
oh, why no just put units in the tables?
the base unit of the machine
if you change the ini u have the same problem
because the parameter file is just a long list of numbers
doesn't have to be
they are numbers
for all anyone knows, parameter 5214 is a loop counter for a canned cycle or something
you can't just go thru and multiply them all by 25.4 when you see a G21 (or G20, or whatever)
yeah, I'm thinking more of the tool tables, params are a bit ugly
sure, if we did it for params, each would have to have it's own units
emc supports any unit you want to use, within the range of a double
maybe units is a bad word for params, more like type
I don't think that should be limited by using mm, cm, inch, yard, foot, meter, cm, ....
yes, but think from the user standpoint, if he switches from inch to mm, he expects stuff to still work
yes - I agree
I'd just save all params in user units (as specified in the ini file)
For the most part, that is the way it works now.
I guess that's better than the way it is now
apparently, the offsets aren't converted before saving
The params themselves are unitless
they should be applied before any G20 or G21 as well
that's the trouble ;)
now you're really talking re-write
That is why the g20 0r g21 is specified in the ini file as the machine default
and yes it was a quick hack by Will at my request when we started getting mm users.
do you mean in the RS274NGC_STARTUP_CODE?
ok - I'm thinking that the [TRAJ]LINEAR_UNITS should define the unit in the parameter file
and any offsets should be applied before RS274NGC_STARTUP_CODES
(or after, as long as the unit is understood to be in machine units, not user units)
if you fiddle with the [TRAJ]LINEAR_UNITS, expect the vars to get screwed up
jmkasunich: do you have any objection to the ternary operator? (a ? b : c)
well the interp will always have to convert as G54 or somthing might change origins
not really, I just never got in the habit of using it
I doubt it generates code that is faster than an if
ok - it'll be handy for scriptmode
I find the if easier to read, but ifs can get bulky
bummer - I wanted some input from him on script mode
I think I have a love-hate relationship with pointers
kind of like guns
powerful, but watch where they're pointing ;)
inverse of each other in one way
the safest gun is one that is pointing nowhere (if such was possible)
but pointers going nowhere lead to segfaults
pointing at nothing
as I just tracked down...
part way thru allocation/initialization of an object, I find that I can't proceed (syntax error in input file) so I call my free routine on the partly allocated object
I thought it was robust against partly allocated objects, but there was a tiny hole
each object has pointers to a "definition", a parent, possibly a child and/or sibling, and to private data
any or all of which might be null
and only some of which should be deleted, if allocation fails
(freed, in C terms)
most of them, except for the definition
and the parent
and the siblings
freeing children and siblings is recursive
sibling implies younger sibling
I have buttons and boxes
of course, I had that two days ago
heh - but now they're more - um - betterer!
now I have a cleaner way of telling it what widgets can hold what children, and if they can hold more than one
ah - cool
getting the constraints right can be a bear
you know, I think GTK would let you nest multiple widgets, maybe even multiple buttons, inside another button
could well be
I'm not familiar with the gtk "way"
* jmkasunich tests
most controls can contain other controls (almost everything has a label, for instance)
yeah, button inherits from bin, which can hold one widget
imagine if you miss a button within a button though ;)
usaually a lable
bummer - if it could hold two, that would be good - an icon and a label
but I just put a box inside a button (boxes can hold lots of widgets)
maybe you can put a panel in the button, which contains a graphic and a label
have two labels in there now
box = label
box = panel
next I'm gonna try sticking a button in the box thats in the button
what happens if you click the box though - does the button "click"
invisible itself, but you can load it with widgets
right now (two labels in box) it appears to click
so you can't see it - where does the "click" event go?
(no handler installed yet)
check that soon ;)
you may find that things aren't going where you think
I don't intend to nest buttons, and may install something that rejects that if it is in the vcp file
but right now it appears to work
click the inner button, it appears to click, click outside the inner one and the outer clicks
"appears" - good word
the screen effect of clicking
that makes sense
guess I have to add handlers sooner or later
how about now...
the box thing would concern me, though a box isn't a control, it's a decoration (or a container)
decorations usually pass user events to their parent
well right now my .vcp file defines a button, holding a box, holding 2 labels and another button
I'll hang event handlers on each button and see what gets called
have you seen "buttonfly" - the SGI 3D menu demo from way back when?
it's pretty cool
it presents a menu as several buttons in space
click one, and it flips over (3drendered, it's an openGL demo), and has a sub-menu of buttons on it
click one of the buttons, same thing happens
click the "background" Of the button, and it flips back to the parent menu
lots of gtk error messages
I must not be connecting the signal right
better than segfaults
(which was my only experience with gtk ;) )
the GTK lib has lots of assert() calls
are you using gtk or gtk2?
gtk1.2 I think
least common denominator
duh, I see my problem
that's a good thing
I passed GTK a ptr to my widget struct, not the GTK widget associated with it
heh, it works
click on the inner button, it's handler gets called (only), click on the outer, its handler gets called
and now it is bedtime
I'm sorry I missed the discussion about that bug last night
don't you guys sleep?
Hi chris. I was trying to finish up a project
alex_joni: Hi. Sorry cleaning up my bsmt act
rayh: are you around?
gone for a while
me too (had to sleep sometime ;) )
err. I'm going away for a while
is what I meant :D
hey - that's the opposite of going
ah yes -hello
at least it wasn't ~hello ;)
heh.. yeah, just briefly read your changes to halcmd
cvs diff is not that easy to read, but it seems ok
I think diff -u is much easier to read than the default (-c)
I agree - I can never figure out what was added etc.
the second stuff is usually the changed one
sometimes it has a + in front if it weren't there
but it's harder for !
my next task is cleaning up the default ini, removing unused settings, and adding others
SWPadnos_: sounds like a good task
the ! lines in the first block are replaced by the ! lines in the second block
cradek: yes, but it's hard to read ;)
alex_joni: no argument from me
one thing I noticed about tkemc (and presumably mini) - the help.txt file isn't there in emc2
right.. seems like that
and if it were there, the path would be relative to configs
SWPadnos_: clean up the ini, I should commit the changes needed for subdirs in config
maybe there should be a separate "documentation" path exported by the run script?
and we should make some default configs, for steppers, servo, stg, motenc, classicladder, etc
yep - I'm working on that - setting PID and stepgen limits, etc
how about man?
getting rid of cruft from emc0.02-1.0
tkemc and mini reading a manpage would not be that hard
no - for front ends to point at their own documentation
installing a manpage is pretty standard stuff too
that would work, but not so good from within e.g. mini
why shouldn't tkemc and mini have their own man page?
likewise for axis..
they should - I'm talking about online help, accessed from within the GUI
yeah I know
not command-line help about the ini ...
nah.. online help
so they should execute man $0 > edit_window?
what about non-installed runs?
btw, this reminds me of something :D
man $EMC2_MAN_DIR/$0 > edit_window
SWPadnos_: guessed what it reminds me?
um - I don't know
recent changes, man page...
halcmd man page?
recent changes not to the man page..
hmm - I guess I could look at that
you could ;)
try mc, works great
view and edit
kate works - I just need to find the file ;)
ok - found it
any thoughts on what the default debug level should be? I'm thinking either 1 or 3
I don't know what the individual bits do, but I leave mine on 0 most of the time when I'm not debugging
that would work, but I think errors should be output
1 is EMC_DEBUG_INVALID
what that means, I'm not sure
but it sounds like it might matter, even when not debugging
I guess I'll leave the default display as tkemc, since AXIS isn't included (hint, hint)
sure (for the manpage?)
for doing it all the way ;)
heh - verbose is my middle name
werbose I guess
along with pedantic
and grammar-nazi :)
gotta run - brb