how about a stepgen parameter "headroom" that is multiplied by the max-* pins to get the real values, seems simple enough and wont bloat anything
you could do the multiplication in C so there wouldnt be a need for multiplying values in .ini/hal commands
we considered that before, and discarded the idea for some reason
it could default to 1.1 or something
wow dead tonight
possibly because it's unclear as to what the headroom is - is it percent (0.1 = 10% over), scale factor (1.1 = 10% over), additive (10000 = 10000 steps/sec more) ...
fenn: how did you like marriss reply
* fenn looks
swp that's what manpages are for
heh - if people would read the manuals, we wouldn't get as many questions
whatever - I can read manpages and still not figure out what is going on.
I wonder how the jeplers little mill did.
you could ask the jepler :)
I figured he is in bed :)
it is past 9
i think scale factor makes the most sense and is consistent with other hal conventions
scale is used to change the command input or results in just about every other place
(ie, DAC scale sets the range or multiplies the hal pin by some scale)
skunkworks: just finished the blog for tonight's work .. http://axis.unpy.net/index.cgi/01188441458
jepler: Hi :)
jeeze - I had just looked
now .. goodnight
nice - thanks for the update. BTW the emc2 splash screen isn't meant for milling ;)
i think mariss' "never more than 10% of the rated power gets delivered to the load" is a red herring
I noticed he forgot to mention that servos generally have a lot of dynamic torque available
and that the load is a lot more constant than he alluded to (by his own analysis in an email on the gecko list)
also that you still need torque to accel and decel, even at high speeds
the reason i think that is because you need excess voltage to run a stepper at max speed, and the rest of the time that power goes unused
or wasted as heat
well hopefully you arent using a linear driver :)
the iron-losses thing is interesting to me, i dont think he says anything about it
the more poles you add to an ac motor the more magnetic field change per second per cm^3
well, that's part of (or all of - I'm not sure) what causes the torque to fall off at high speeds
this makes me smile 72ipm rapids and no stalls. SCALE=8000, BASE_PERIOD=100000, doublestep
yes - 100000 input scale :)
not all of - most of what does it in steppers is winding inductance vs voltage
hmmm. I just had an idea for another stepping improvement
one problem double-step has is that the CPU busy-waits for the duration of the step (once other thread processing is done)
so you're not dissipating anything, the motor mostly just has higher impedance at higher frequency
any motor does - the "servos have a perfectly flat torque curve" is a myth and only true in relation to steppers
so if you have something with 2us or 5us steplens, you end up burning a lot of CPU cycles waiting
how does the overall cpu usage compare vs using twice as many threads?
guess that depends on busy wait time
and consequently you can't set BASE_PERIOD very low (which isn't necessary for step rate, but is for step frequency resolution)
so, I think it's a 6-line change or so to make parport.reset capable of waiting more than one thread period, and only busy-waiting during the last wait time, or if the remaining wait time is short enough
jmk was talking earlier about "request an interrupt in xx ns" - could that be used to get an arbitrary frequency?
yes, but it would totally destroy timing of slower threads (or get kind of complex making them work right)
so instead of BASE_PERIOD you'd have some parameter min_step_resolution
also, you have multiple axes - what if you need steps on two pins that are only 0.3 uS apart?
hm that's tough
yeah - the multi-rate thing is great for one axis, but it falls apart pretty quickly for >1
anyway - the double-step change is to add a parameter which is something like "max_wait_time", and add a variable to keep track of elapsed time across thread executions
(kind of how stepgen figures out when it's time fora step to occur)
if the wait time is > period, subtract period and finish the thread
you could have a non-busy wait period where you "catch' any interrupts in approximately the same time period and chop the busy-wait into hunks
if wait_time is < max_wait_time, then busy-wait
or do time slicing in the busy-wait and check for interrupts
i think that's called trapping
actually, you could use the period/4 trick it has now for reset-time
you could do that for multi-rate stepping, but remember it still takes 1 us or so to actually write to the port
which is between 500 and 3000 CPU cycles these days
then you arent gonna get a better resolution than 1us
that sounds fine to me :)
well, remember that there is also time to set up the timer for the next interval, all sorts of magic numbers regarding when to actually do individual writes vs. combined writes, and keeping track of when to run the slow threads
it isn't simple, even in a microcontroller. I thought about doing that with a uC, and gave up :)
woah what's this about combined writes? i dont think you'd have that with an arbitrary period
if two channels need a step within some time period of each other, you might as well output both in one port write due to output timing resolution
it throws approx 1us jitter into the signal whether you do two at once or delay one until the next port write
sure - you'd always have to delay, since you need to obey minimum timing (in general)
'epsilon' vs uh.. whatever the opposite of epsilon is
del cross B
silly mathematicians.. -1 should not mean inverse of a function
I guess the opposite of epsilon (error) would be accuracy, but I;m not sure there's a common symbol for that
here's what i meant by epsilon http://www.freesteel.co.uk/wpblog/2007/05/finding-points-in-triangles/
its basically whether you snap-to grid points or kick things off the edges by some amount
so if two write events are within N ns of each other, you have two options in how to deal with it
delay one or group them together
those are both "grouping them together"
you can either delay one, or advance the other
advancing is better in that you don't busy-wait for the next time interval
delaying is better because most timing settings are minimums
but having the two events separated in time seems less "grouped together" than having two separate pulses
said that wrong
having the two events at the same time seems less "grouped together" than having two separate pulses
shit i messed up again
* fenn abandons the conversation
ko, you're saying that when you calculate the next time events, just figure out whether you'll be able to group some together because they're too close
so there's no extra busy-waiting
yeah i guess that's better. there's no advantage to separating them
anyway - dropping it is good, because it is a real bitch to get to work, unless you actually have independent timing sources and non-sequential execution
(like an FPGA)
there will always be some stupid shit (like beat frequencies) that needs even more stupid and complex code to deal with when two or more asynchronous things are being done by one synchronous processor
beat frequencies? you mean on purpose, or its just something that happens and makes the code harder
makes the code harder
move from 0,0 to 1,1.0001 F10
you now need just slightly less time between pulses on Y
they get totally out of sync, slowly
then there would be a jump when you switch from combined writes to individual writes
you may need a separate timing event for each step on axis involved (for a while, then they'll kind of synchronize, then they'll get out of sync ...)
as I said, it'as a real PITA, and not likely to be worth the trouble
if you never did combined writes (separate the two writes in time) there wouldnt be a jump
I think I read a paper in the last couple of years that proves that, actually :)
but there will always be either combined writes or missed deadlines
only if your timing requirements are way strict
if you need two steps (on different axes) 17 ns apart, they'll either be at the same time or they'll be ~1 us apart
and then there are the problems when you add in multiple port writes (the parport is on 3 addresses, remember?)
for a milling machine type application, being 1us apart makes no difference
it does screw up timing though. the second write acts like a busy-wait loop
but having a sudden jump in the timing will effect finish
a busy wait for each axis isnt impossible
if you have 9 axes and you don't actively combine writes, you may spend 8 us waiting for writes to the same port, even if the events were all supposed to be within 1 us of each other
1us per axis per period right?
direction changes could screw that up, but they shouldn't happen at the same time as steps anyway
for your hypothetical 1us paraport write time, which i have yet to see any real data for
look anywhere for the data. everyone says it's somewhere between 500 us (I think Art said this once) and ~1.2 us (Jon Elson did lots of testing, and I think the 1.2 number was in there)
* fenn gallops in all directions
that seems trivially easy to measure (on a particular machine)
hmm I think jeff was tired when writing that - some doesn't quite make sense
yep - write a HAL module (or whatever) that toggles the prt a few hundred thousand times
heh "parport write time microseconds" brings up the recent doublestep blog entry
"deeper on the right than on the right"
[03:38:36] <SWPadnos> http://www.lvr.com/jansfaq.htm
first question in the speed section (search for microsecond)
wow isa is 1.3MHz - that explains it
ISA ran at 4.77 MHz, then 8 Mz, but there may have been address setup cycles thrown in
yeah you can't expect that to run at the full 4.77 MHz!
hmm i wonder if you could use EPP to send step bursts :D
I also spoke to an engineer from SMSC (I think), and complained about parallel port timing
or a 16550
sorry, I ought to go to bed and stop being destructive of the conversation
he was interested because strangely enough, he had a machine that he was trying to get some old BDI to work on :)
nah - it's a degenerative topic anyway
emc-devel: degenerate constructivism
I like to thikn of it as constructive degenerativism
comments on http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents
specifically, does the section "Legal" look OK? I want to head off the biggest problem with user submissions, that they do not clearly permit use and distribution.
or maybe I should say use, modification, and distribution
but I don't want to require a particular license..
* jepler adds "modification"
free according to the DFSGs?
then you can just link to their big list of acceptable licenses
(I agree this is the hardest part about hosting users' contributions)
Please clearly label each submission with its license, using MODULE_LICENSE("..."); for components compatible with EMC2.1 and later, or module "..."; for components compatible with EMC2.2 and later. Submissions must be released under a license that meets [Debian Free Software Guidelines]. Those without a license statement, or with a license that does not permit use, modification and redistribution, will be removed. GPL and LGPL are two examples of
you can also say something to the effect that uploading something to the wiki explicitly grants permission for us to license it under the GPL or LGPL
err - so we could incorporate modules into EMC under GPL or LGPL?
rather than "we're going to take them down", it's "if you don't specify, then we can stick GPL/LGPL on them"
I feel uncomfortable saying "by uploading a file, you place it under such-and-such a license". A person who can write a .comp file should be able to handle adding the line 'license "GPL";' to it.
how about: Please feel free to write components with any license you choose. However, to post them on linuxcnc.org, they must be as free or freer than EMC2 itself. This means approximately that they should have a license accepted under the [DFSG]. Please specify the license in your file using MODULE_LICENSE...
that avoids "will be removed", "grants us special powers", etc. It is a statement of what is allowed, nothing more.
maybe scratch "or freer than"
but for instance I don't see why we would decline to host a PD module
we can (obviously) distribute that under the GPL if we want
Clearly label each submission with its license. Submissions hosted on linuxcnc.org must be as free or freer than emc2. This means approximately that they should have a license accepted under the [http://en.wikipedia.org/wiki/Debian_Free_Software_Guidelines
Debian Free Software Guidelines]. GPL and LGPL are two examples of permitted licenses. "Free For Noncommercial Use" is an example of a non-permitted license.
For ".comp" components, use <tt>MODULE_LICENSE("...");</tt> for components compatible with EMC2.1 and later, or <tt>module "...";</tt> for components compatible with EMC2.2 and later. For all types of file, include the standard license block indicated by the license being used.
that looks good to me
strike "should" from "they should have a license"
now we just need some submissions to that page
has anyone tried reading/writing the parport with words or dwords (inw/outw, not sure if there's a 32-bit equivalent)?
well, that would make sense :)
cradek: the "check for epp communication right after loading firmware" behavior doesn't seem to be in emc2.1.
I was wondering that too
the more advanced EPP error clearing code is also not in 2.1.
maybe he should try trunk?
I'm sure he can handle
seems very capable of that
if he runs his own rtai
eek pluto doesn't reserve its ports!
* jepler hangs his head in shame
though it's only about a 10-line fix to counter to give it up/down counting capability
add a bit param, and check it ro decide whether to count++ or count--
maybe someone will want to put that in trunk
in TRUNK counter is deprecated and encoder has a counter mode..
maybe someone will want to put that in encoder in trunk
I can add that when I have an EMC2 dev machine running again (should be next week)
if I remember
skunkworks_, can you add that to your phone reminder list? :)
see you guys later
SWPadnos: there woudn't be a way to atleast delete that out of the logger - pretty please?
I can manually edit it out, but I may need to wait for the end of the day (so the file isn't open by the logger)
SWPadnos: just kill the logger? wouldn't want google to pick it up.
I can probably do that, but I think only Alex can restart it
nope - the logger isn't running under the emc board logi
what's the format for robots.txt? I can do that until the log can be edited
killing the logger and editing it right away sounds good to me
chmod 000 todays-log would also work
true (even if the logger keeps it open)
I can't see the logger processes under the emcboard login - I think Alex started them
yes, the logger has it open so it can continue to write to the file
so I can't kill them
and I'm not root, so I can't chmod
(at least, not someone else's files)
that's the downside to hosting ...
can you write to the directory?
I think so
I think you could just copy the log somewhere, then delete it
hard to say without knowing how the logger works
I really apreciate this.
ko, I think I made an appropriate robots.txt:
oops - typo... fixed
I'm not sure what would happen if I edit the log file while the logger is using it
stick another reminder in your phone, will you? :)
it'll probably work fine
Failed to alloc shared memory (434c522b 32772 47768) !
I can't run sim_cl after cmorley's changes
jepler: what's the trick to removing the shm stuff?
ipcrm -M <magic hex number>
hm that still doesn't fix it
jmkasunich_ is now known as jmkasunich
and debuting at #5 on a google search for 'zenbot cnc': my blog entry
(not much surprise that it's ranked pretty high once it appears, but it's a surprise that google only lags 1 or 2 days finding new entries on my boring blog..)
when is the circuit board mill going to comence?