jmkasunich: ed's latest report is very interesting...
I think I'm going to go cut a flowsnake
if by interesting you mean I'm gonna joing him in pounding my head on the table, then yes
I gotta wonder if he really knows all there is to know about his drive's timing requirements
IIRC, he told me that the drives on his sherline are not standard - he hacked on them
I think he has a pic reading the step/dir signals
I'd bet a fair amount that neither the old stepgen nor the new one actually violated any of the constraints as speced by the parameters
velocity, accel, setup and hold time, step length, and step spacing
that seems likely to me too
the thing is, you could cut a hundred flowsnakes, and not prove anything
he's (air)cut a few himself for that matter
true. but isn't there some value to trying the new stepgen on known-good hardware?
yes, by all means !
I'm just looking at the ed issue while disregarding everything else
right I understand
1) old stepgen works for many people on many hardwares
2) old stepgen doesn't work for ed on eds hardware
3) new stepgen seems to be nicer, not worse, at avoiding "bobbles" (even though said bobbles are within the allowed limits and therefore should not cause lost steps)
4) soon we hope to be able to say that the new stepgen works for at least one person
5) new stepgen doesn't work for ed, on eds hardware, in almost the same was as the old stepgen
I see what he means about the rhythm this program has...
are you doing the funky flowsnake dance?
it keeps the velocity up at about 10, impressive
the high accel on this little machine is nice
you are using your maxvel and accel values, right? and your step timings?
it can do 30, but I keep it at 20
unsuprisingly, it went up at the end...
I have no idea if his specs have anything to do with it - I did my runs using his numbers
is there anything we can do with the build system to make the "failed to remake makefile 'Makefile'" error easier to find?
it's usually some include that can't be found
petev: make -d will show it pretty quick
but you get no indication of what it is
make -d |tail -100 is even better
yeah, that prints a ton of stuff and you still can' figure out what make is looking for
it'll be right at the end
3 periods / 57uS steplen, 4 periods / 77uS space, 20 periods / ~400uS dir setup and hold
0.44 in/sec, 2.2 in/sec^2
heh, there is a wiki page for everything
wow, no kidding
jepler, I just wish I saw such a nice reason why it failed as in your example
I see nothing on my build, except the failure message
although that page doesn't tell how to solve the problem (assuming the header was removed on purpose, and you don't want to just replace it)
petev: you used --debug=m,b ?
used -d, haven't tried that your option yet
running after clean right now
thats on the wiki page
and I didn't delete any headers eiither
will probably result in output like on the wiki page
ok, will try next if it fails
petev: misspelling an include will do it too
yeah, that's what I suspect
I generally use: make -o removed-or-typoed-header-name
though you can also: rm -rf depends; make
petev: I added an item to http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?UpdatingConfigurationsForDevelopmentVersions
about the m5i20 change you checked in earlier. Did I correctly describe the change?
I guess I used the big hammer with make clean ;-)
"The m5i20 "encoder" pins now match the HAL canonical encoder interface. The -cnt-latch, -pos-latch, -idx-latch, and -latch-index pins have been removed. The standard encoder pin -index-enable has been added. The behavior of the -position and -count pins now match the HAL canonical interface."
yes, that's what's supposed to happen
petev: also I saw in the diff that you may have had a typo on a pin name in a comment: + * bit m5i20.<boardId>.enc-<channel>-enable-index
(shold be index-enable, I think)
ok, let me check
-reset-count also seems to be different than the canonical encoder interface -- it's bidirectional, so you'll have trouble hooking it up to most things, and the name is wrong
the index-enable typo is in a comment
reset-count is bi-dir
didn't realize this wasn't the standard name
what should it be?
petev: I usually refer to http://linuxcnc.org/docs/devel/html/hal/general_ref/
for answers to questions like that
(BIT) reset - When True, force counter to zero.
yeah, looks like some other drivers need fixing too
I just looked at some of the other code
it should also be input, not io
I think only the software encoder counter and the ppmc driver are canonical at the moment
jepler, why input if it's self clearing?
petev: canoncal encoder reset is also not self-clearing, it's persistent
the count output is held at 0 as long as reset is TRUE
oh, that answers that
jepler: should axis be idle when it's not updating anything on the screen?
cradek: yes, I thought that it was.
it sure isn't here, and emc is badly starved for segments when running this program
axis 50%, Xorg 50% while it's cutting
and when it stops, axis 40% Xorg 5%
cradek: while milling it will be updating all the time, since the coordinates are changing
this program has a LOT of segments...
swp and I were guessing at how many the other night
never did decide on the answer
3072 maybe? or 768?
they are about .003-5 long in the reduced version I'm using
and it goes through them fast...
eek I have a lot of debug information flying by
cradek: I know my computer is much faster than yours, but while milling flowsnake I get xorg 10-15%, milltask 5-10%, axis 3-5%
with debug turned off that is
got a warning on line 948 of saicanon.cc
is anyone editing that now?
if I hit p, xorg and axis drop to 0%
ok, I'll look at it as soon as I finish with this stuff
Ed's articles on his stepper mods are available online:
There's a third article, volume 191, June '06 - Stepper failure - death by disconnection
that one's not online.
Found them here: http://www.dtweed.com/circuitcellar/xnisleye.htm
* jmkasunich reads
did that compile farm error happen right in the middle of commits?
whenever possible its best to commit in one big lump
I had a bunch of different comments though
the farm checks for new commits every 5 mins, and starts a build if it sees one
what's the best way to handle that?
if they are unrelated and having the farm get one but not another won't break things, there is no problem
but if one commit changes foo, and other changes bar, and there is some interdependency, the farm might try a build with only foo
yes, they were related, but I wanted to describe the changes to each file
I haven't looked at the log yet, does it splain what happened?
it looked like the commit for the one file wasn't there yet
then it will fix itself soon
its already building again
I think I was wrong - I see the download files that went with the article, but not the article itself.
jtr: same here
I didn't get that far, distraced by something else
sorry for this distraction. I've got the first two around here somewhere, but not the third - let the subscription lapse.
When I find them, I'll get them to you. Bedtime now.
the farm is happy again ;-)
oh - half happy anyway - I didn't realize two slots had failed
BDI-4.51, and dapper
the BDI-4 one is taking longer to rebuild, not surprising since its a VM
I don't see an error in the dapper log
isn't it slot 7?
thats because dapper rebuilt already, and passed
and BDI-4 just passed now
(there is a message in #emc to that effect)
that saicanon error is a signed/unsigned in compare with a strlen
you want me to add a type cast?
jepler: even when I turn off everything in the View menu
it's in GET_EXTERNAL_PARAMETER_FILE_NAME so I don't want to change the param as it's an API call
petev: error? or just warning?
don't strictly need it, but I like code to compile clean, so real warnings are easier to see
I'd cast it
ok, will do
I think ed sent me copies of the two stories about his changes to the sherline driver
but I don't know what I did when them - may have deleted them
I don't even know what the original driver box is like
he said something about the copyrights being owned by the magazine, not him, and not to spread the files around, so I didn't...
should ahve saved backup copies tho
I do have my reply to him after he sent them...
seems his sherline drives are unipolar full step (or maybe half-step)
jepler: I don't think hungry mode is working. milltask isn't fighting for its share, it sits at 3% and it should be 33%
jmkasunich: surely not full step
* jepler has been working on upgrading 'comp': http://pastebin.ca/394166
jepler: this is the tc queue depth
cradek: huh -- yuck
I don't understand how it gets 5-10 at a time in one servo cycle
but it chews right through them and doesn't have any more for a while
I see that
1 sec per div
you sure thats happening in one cycle (did you zoom in?)
[02:46:07] <cradek> http://timeguy.com/cradek-files/emc/starving2.png
cradek: is that what's on debug-s32-1 by default, or do i have to change it?
I can check it in if you want
"yes" would have suficed ;-)
just show me the change and I'll make it locally
well -- whatever you want
I'll check it in - I like having this
if you like it a lot, why don't we make it a real param instead of a debug one?
oops, too late
oh hmm, I bet that's updated at traj cycle, not servo cycle
that explains how there are 5 at a time
well, I think I'm gonna do something novel, and go to bed before 11pm
I have traj/servo=10
I cut several flowsnakes successfully
air cut I assume?
or do you have pretty engravings now?
no, on PCB stock
several about 1" diameter
ooohhh... photos required ;-)
jepler can shoot them
(photos not required _today_)
maybe I need a faster computer.
or at least a newer matrox card
(like max has)
jmkasunich: see you jmkasunich
I think I'll commit this 'comp' stuff before I go to bed
arrays and dotted names are a nice improvement
I bet arrays and loops will be nice
cradek: did you look at the pastebin then?
I saw a for loop...
ok when I make traj=servo, the plot makes more sense
is there still interpolation when traj != servo ?
important for kinematics where the calcs are slow
how is the TP doing vel calcs now? Does it work back from 0 vel at the end of look ahead?
it runs each segment with trapezoidal profile, overlapping their acceleration phases to blend the motion
but how does it determine what max vel it can reach? kinda like driving and being able to stop by the distance you can see with your headlights
if a super sharp corner came up and you were going too fast, you would have a problem
seems like that's the reason for lot's of look ahead on complex 3D stuff with short segments
each segment does come to a stop within accel constraints. but the next one has already started, so the machine doesn't decel
yeah I know all about it...
so I think getting lots of segments into the motion queue is very important
ve7it is now known as LawrenceG
cradek_ is now known as cradek
in the canonical encoder interface, should "velocity" be held at 0 while reset is TRUE?
I don't think the reference implementation (encoder.c) does that
but I'm not sure if that's the question you're asking or not
the question was should
I see arguments for both ways
it turns out that pluto lets velocity be nonzero while reset is TRUE
I'm not sure I even understand when reset would be used
cradek: are the changes you made to the que in trunk?
yes, since last night
and backported to 2.1.x .. so it will be in 2.1.3
jepler, it seems that one could expect zero velocity when an encoder is reporting no position change
loadrt and count=3 personality=2,5,3
loads 3 'and' gates: and.0 has 2 inputs; and.1 has 5 inputs; and.2 has 3 inputs
up to 16, in this case
awesome. I've been thinking about that for some time, but (as you know) I'm too lazy to code it :)
[20:43:27] <jepler> http://pastebin.ca/395137
that return should probably be a break
can you make a FUNCTION(_#) ?
to get separate functions for each
I think they are separate
ok, then the personality loop isn't needed
that one is for the number of inputs imho
do you automatically get multiple functions unless you use singleton?
that example gives 3 functions: and.0, and.1, and.2
the ones you addf
hmmm. interesting. I don't immediately see how the correct personality variable gets found
I'm sure it'll be more apparent once I see comp / the generated C code :)
I'm working on the second, more complicated example :-P
jepler: what's that?
alex_joni: 'personality' can turn pins on and off altogether, not just set the size of an array pin
for instance, for a parport driver, personality=0 might select input mode, 1 and 2 would select output and "X" modes
jepler: yeah, I got that
was just wondering what your second example would be
parallel port ;)
another mindfart.. do you need the num_chan param at all?
not really :)
I'm not sure how the array parsing works for insmod
I had thought of just changing the num_chan to an array myself
been a while..
SWPadnos: not sure you get the nr. of elements in the array though
you have to have some sentinel value such as 0 or -1
jepler: right.. that's what I was afraid of :(
SWPadnos: wwjjd ?
that's no big deal, since in C you'd initialize the array to the sentinel value
yeah - saw it :)
SWPadnos: you can't initialize de array
err.. you can.. sorry, I'm beeing stupid
what you can't do, which is part of my excuse for not making these changes to C versions of the components, is have an arbitrary number of them - the array size limits you
I had considered just using a string as the initializer, but then realized that the max string length would still be an arbitrary limitation (though a larger one)
and you need to parse it.. which is a PITA
this doesn't escape having arbitrary limits ... e.g., 16 instances, up to 16 input pins each
not so bad with decimals, but ugly
because it has to lay everything out in a struct
right - as usual, I over-think and do nothing, while you rapidly do something useful :)
yet, you somehow manage to make a living
hmmm - do I?
I haven't died yet, which is good :)
indeed.. you don't seem like the regular AI IRC bot.. so I assume you're alive :P
error: Norman, coordinate
[21:04:00] <jepler> http://pastebin.ca/395164
[21:05:06] <jepler> http://pastebin.ca/395169 http://pastebin.ca/395171
jepler: 164 is for 2 pinned components?
guess not.. seen the next one
no - that's the one loaded in the other ones
interesting - that supports multiple outptus from a single set of inputs
the only thing needed now is selective inversion (inputs and outputs) :)
SWPadnos: that was exactly my question..
yeah -- it demonstrates both the use of personality to enable/disable pins (here, the outputs) and to set array sizes (here, the inputs)
why don't the components have all outputs (and, or, xor) by default
then you simply select the one you want
or maybe even more than one
feels easier to use imo
you could just load 16 x 16 pin modules, but that would be confusing
the example is somewhat contrived, I'll admit
you don't need more than one output, since you can connect it to multiple inputs
(output of the same type)
SWPadnos: I agree
I didn't say it should be of the same type
in-0 .. in-15, outputs: and, or, xor
ok, so a bit output and an int output that's 0 or 1?
(the posted example has individual selection of and, or, and not by oring together the 0x100, 0x200, and 0x400 bits for and, or, and xorr outputs respectively)
jepler, two questions which you may have already answered:
darn, I totally missed that .. :(
1) the code references and, or, and xor - does that mean that the line of code with "or" in it will be removed from the comp output if personality & 0x200 ==0?
SWPadnos: this condition is evaluated at runtime, every time: if(personality & 0x400) xor = x;
2) can you check constraints so that if for example personality&0xFF00 ==0, the module refuses to load
ok, but xor only exists if personality&0x400 ??
so the storage is always there, but the pin may not be created?
the pin 'xor' is only created when the 'pin ... if personality' condition is satisfied
the storage is always there (the instance structure layout is fixed)
ok - so there are no C problems with undefined variables or anything - good :)
I will probably add some easy way to check if a personality is valid .. right now you could use extra_init() to check and error
but I imagine something like: option valid_personality personality & 0xff <= 16;
(additional parens may be necessary there, I forget my order of operations:-P)
is "personality" a keyword or a variable name?
the only name you can use in that way in the declaration section is "personality"
in that sense it's a kind of keyword
ok, so it's a special variable name :)
how about split_personality?
howdy Ray - how goes it?
Keeping more than busy enough.
I worked with the SAI that Matt's been fixing.
It yields a very nice listing of the "cards" that are stacked by the interpreter.
I think you can see that with canterp too
yep. there are even some regression tests that use it (made for checking cutter comp changes)
I was thinking about SWPadnos's thoughts on canon and primitives.
didn't know he has any
I do have questions about canon's ability to handle parametric programming?
parametric in what way?
nurbs to start
arc segments defined by equasions.
I have my mother working on some of the math
we'll see if anything comes of that :)
We don't at present have any lower level code that can see anything but arcs and lines.
someone did some NURBS work - can't remember who
so if the interpreter expands a nurb into a set of lines and arcs we are okay as is.
xemet did I think
I was thinking that as well
and jepler did some work too in that area
jepler has spline code that makes lots of arcs. I'm not sure if Xemet's code does the same
I'd a whole lot rather see us edit canon to meet growing needs than bypassing it.
NURBS have the advantage of being of definable order, but I think that makes them harder to deal with at the lower levels
I asked my mother to look for a 3rd-order type of equation that meets our needs
specifically, one that you can solve an equation for length
instead of doing integration
If active line is handled by task, we may need to add a var to canon commands that reflect the line each canon command is produced fron.
"line" has no meaning for non-text input formats
turning nurbs or other splines into arcs is not an optimal solution
nurbs are inherently 3-d, arcs are 2d
additionally, I think xemet's code uses multiple lines to define control points, then one to execute
the example I gave my mother (a decidedly non-practical mathematician) was a sine wave
You can add a third to an arc but it is planar.
arcs are second order, I think he meant :)
I'm not sure if a cubic is as far as we would need to go or not
obviously some high-order NURBS path could be desired by the user, but that should be able to be split into several third order segments (I think)
the idea isn't necessarily to make all sorts of functions available, it's to increase the amount of information a single command transfers
SWPadnos: no, I meant 2D
2.5D if you want to call it that - helical is NOT the same as 3D
can't NURBS be used in 2-space? (not that it's all that useful)
ie, leave all Z = 0
yes, you can define a 2d spline
but being limited to 2d reduces their usefullness a lot
sure - you get a 3rd-order curve in a plane
are we suggesting that we add NURB_FEED to the canon and motion coord stuff to do that?
NURBS need variable amounts of data, I think (which NML can't do)
unless you set a maximum number of control points and always transfer that size buffer
why nurbs as opposed to other kinds of splines?
no reason yet
I guess I'm not up to understanding this.
some are defined by four points - fixed amount of data to pass
I'm sort of waiting to see what my mother comes up with on the 3rd-order equation front
then you just string them together
why not modal nurb_feed
and each point a block.
I think that's what xemet added
(but hasn't checked in)
how some points are path points, and some are control points
that makes three of us, I think
bye all, I should be back on sunday evening
alex_joni is now known as alex_joni_away
SWPadnos: yes, xemet is using the same approach I started with, but he's expanded it from cubic splines to general NURBS
while the implementation for milling turns them into arcs, that's done after the CANON calls which do pass the nurbs information
the current CANON calls confine NURBS to the XY plane, and the implementation in terms of arcs confines them to "some plane", even if the limitation at the canon layer is lifted
so while arcs are fine in terms of giving any desired accuracy for a planar NURBS curve, they are not fine in terms of allowing general XYZ movement
that's one reason my excitement about the approach waned, the other being the difficulties of doing an emc-appropriate adaptive subdivision
if it would help, I bet I/we could generalize arcs
cradek: the biarc method doesn't work for nonplanar curves
* jepler disappears again
Thanks for that nice summary, jepler.