MichelG: I'd happily review your probing patch
MichelG: there was lots of talk about probing a while back but I don't think anyone involved was actually using it.
cradek: ok, I will make it available next tuesday.
MichelG: was it a recent or old emc2 that you patched?
cradek: everything was still there, except connecting a hal pin in the parport.hal and adding 10 lines to manage the trip of the probe
cradek: as my hard drive broke, I have to redo it again. I can take either emc 2.03 or the CVS as you like.
I have a TP-100 probe on my sherline mill and I have many uses for it.
ok, let's patch cvs head first, and then afterward decide whether it can go in 2.0 branch.
cradek: OK; I'll do that on Monday.
03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/image-to-gcode.py:
support choice of direction (positive, negative, or alternating)
support milling in rows, columns, or both
03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/image-to-gcode.py: combobox looks better than optionmenu
anyone around this evening?
is dsplabs.cs.upt.ro down?... I am trying to set up a new box and that ip isnt resolving anymore
LawrenceG: a DNS server is down and apparently won't be fixed this weekend. There's an alternate URL you can use and I'm looking for it in my scrollback.
LawrenceG: the alternate location is http://dsplabs.utt.ro/emc2/
thankyou... I will give that a try
do you know waht debs are needed for the latest install.... I have bwidget, emc2-axis and and emc2 debs in cache from an older install
they are version 2.0.3
and axis 1.4a0-0
all the requirements should be pulled in automatically when you install emc2 and emc2-axis
or was that not the question?
will try the apt install first with the backup repository.... was looking to see if I had all the needed debs on another box as an alternate way to get things installed
ah. ok. if you look in Synaptic, you should be able to see the list of dependencies
I'm not sure what they are now
I reformatted an old bdi 4.2 install and updating to ubuntu and emc2
oooh - gotta run - fireworks are starting :)
have fun... cheers
hmm - hard to see them through the trees
jepler: backup repository working like a charm... nice fast downloads as well about 300K/sec
it's the same server, just a different DNS path
LawrenceG: glad you were able to get going
hello, just a minor question
theoretically could i just use the rtai modules to develop a rt app other then emc2?
probably a stupid question....
zbyte_, you can. no one is stopping you.
cool :), thx
rtai is not made by emc.
its' GNU... you can do what you want... as long as it's within the liscense of the GNU.
time to sleep
does anyone know of data recovery methods for EXT3 or EXT2?
especially deleted files..
alex_joni: No firsthand experience, but a google on ext2 deleted file recovery
alex_joni:gave a promising hit on using midnight commander - third from the bottom on the first page.
jtr: thanks, looking
03alex_joni 07HEAD * 10emc2/configs/stepper/stepper_mm.ini: typo
I forget .. what #<number> ranges are available to users in emc for random variables within programmes?
check the manual? I have no clue :D
[11:28:23] <robin_sz> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?TubeCutter
sigh ... not where I thought it would be .. on the gcode page.
so, explain this to me .. in the manual in "gcode best practice" it says:
18.6 DONT USE LINE NUMBERS
and then every example in the book has 'N' words for line numbers ...
no idea why it says that
mainly it syas that because EMC reports errors by line number
but not the line number set inthe N word
the line number in the file
fixing emc to report the N word (if one is set for the line) might solve that
bah, can't seem to find it inthe manual ... I'll assume the ones from #5000 on are system related, and the rest are free for me to use.
I'll probably end up hi-jacking G54,55,56,57 that are used for workspace selection for face selection
seems the most logical choice
robin_sz: also, the phrase "n-word" is offensive
seriously, I wrote that part of the manual and it's probably up for debate. However, I see no benefit to N-numbers but they can be the cause of confusion for the reason you mentioned.
jepler: how is n-word offensive O.o
it's like the F-word :D
but for coloured people :D
in borkland you don't tend to censor swear words nearly as much
not even in the news IIRC
there's even a baked candy-esque good called n-word ball
[13:21:03] <Lerneaen_Hydra> http://en.wikipedia.org/wiki/Chokladboll
though the politically correct term is chocolate ball nowadays
sanity check, TTL output is 0.35V low, 2.0V high?
something like that
any idea of minimum assertion time?
I see some funny letters :D
* alex_joni curses UTF for beeing so late
that would be parport specific
Lerneaen_Hydra2: a definate answer is in the datasheet
depends on the family you're using (L, LS, HC, HCT)
oh, you mean on the parport?
thought you want to place another TTL chip there
10usec sounds slow then
nonio, this is just what the parport needs for input
it's for my encoder, so I get the needed voltage & timing window
Lerneaen_Hydra: if you're reading the quadrature signal with hal_parport, then there can't be more than one transition per BASE_PERIOD
nothing to do with the inherent speed of TTL
the encoder doesn't output perfect square wave at my max spindle speed, it's a form of sawtooth form
this page gives TTL voltages, though I don't know if it's correct: http://www.allaboutcircuits.com/vol_4/chpt_3/11.html
so I wanted to know the minimum voltage and time for a high to be registered
as it is now the top of the sawtooth reaches 3V
if you're not getting a square-ish wave, you probably have a grounding problem
but the time that is asserts fully 2.7V is less
SWPadnos: I've got optocouplers :/
a sawtooth sounds like capacitive decay
the optocouplers have that behavior
maybe they need a pull-up
it's just more prominent when running at high speed
so it's about the Tr and Tf of the optocoupler?
yeah they do, but the pullup current is limited becuase I'm using a parport output as power for the pullup
by changing the pullup current I can get either better voltage or faster times
I have a 220µF cap to smooth it out too
heh - well, I shouldn't be talking like I know anything - I haven't gotten my parallel port to work at all :)
220 uF - that sounds huge for smoothing
I had it lying around in a box ;)
so I think, why not
maybe you should put it back in the box :)
there's plenty left
what value pull-up resistor do you have?
it's not like they're expensive or anything
$ units "220 micro F * 1 kilo ohm"
Definition: 0.22 s
currently around 16kohm
5kohm was too little, so the voltage started sagging
gah - that's a 3 second time constant
22kohm was too much, so it wouldn't reach vmax (the slope was too blunt)
16kohm seems to be right, assuming that the time is enough
get rid of the cap, or put another 10 in parallel with it :)
err - series
currently I've got 25-30µs at >2.7V
it tops at 3.2V
better to get a real +5V on the computer side of the optos (maybe steal it from a USB port?) and put some schmitt-trigger buffers and appropriate pull-ups
yeah, USB port works great
jepler: yeah, I know, but then I have to pull *more* cables (eugh) and it leaves for more stuff to do
at least it'll work
anyway, when I run at sane threading speeds (around 100-500rpm) the asserted time is far greater
25-30µs is what I get at 3200rpm, which is lathe max
Lerneaen_Hydra2: if the time at >2.7V is longer than BASE_PERIOD then it ought to work.
have you halscoped it?
nope, not yet
when running at 600rpm I get times of >400µs, which is far more than enough
while it's no sure test, you'll have some level of confidence if you get a nice square wave with no visible glitches in halscope
as my base period is 25µs
Lerneaen_Hydra2: did you see that I added 90 degree lace to image-to-gcode?
I haven't done an update yet
I'll do that in just a moment
sounds nice :D
you may have to remove ~/.image2gcoderc if it seems confused -- I changed the way the options are saved
the main other thing that may be worth looking into would be the "derivative of the image" thing, but that would be mainly if there happened to be a lib that does that already
[15:08:53] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/lace.png
whoa.. nice :)
he's slow today too :(
10:11:09 <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/lace.png
* jepler discovers that row-milling is broken when the image is not square
I'm glad I didn't update yet ;)
you can see why it's good to have a 90degree rotate, right?
can you config the number and angle of rotation?
and the angle of the lace?
you mean, someone might want to mill at 30 and 120 degrees, for instance? or in multiples of 60 degrees?
that may be good, if the part has a certain disposition, though it's not very important
maybe the part is hexagonal
still, it's a rare case
so not very important IMO
most of the time a 90 degree rotate is perfect
and if you want to do stuff that nitty-gritty then you'll probably need real CAM for some other reason
jepler: if you're coding after Lerneaen_Hydra2's suggestions, you'll never finish
hm, and here's another bug: http://emergent.unpy.net/index.cgi-files/sandbox/wronglace.png
someone moved the workpiece ;)
what are you using to make the images?
so a 3d model to begin with?
[15:27:51] <jepler> http://runevision.com/graphics/stereo/depthmap/
hmm.. axis should load those.. kinda like a stereogram cheat prog
yet another thing to add to "LH's list of features that never stops growing", differing feed between X/Y travel and Z plunge
for people who can't see them ... ROFL
you haven't asked for waterlining yet either
get to work on those feature requests!
how about waterlining? ;)
ooh ooh, a roughing sequence ;)
milling around X+Y, at various Z levels
yeah - roughing is actually important, depending on the depth of cut
so first remove first N*X mm of depth, then 2N*X mm depth
are 3D goggles supported under linux?
and an offset
I think so
in the NVidia drivers at least (I think)
red/green or the LCD shutter?
LCD shutter type
do you have those?
I just remembered I have a pair in a bottom drawer
I've always wanted to test them, though I've heard they give headaches becuase of the short focal distance and illusion of distance far away
the ones you connect on the VGA out, and uses sync to switch alternatively on/off
Lerneaen_Hydra2: not that I noticed
and with an LCD monitor, the image goes away if you titl your head
they won't work with LCD at all though, will they?
same with polarized sunglasses
if the orientation is right, they will
don't LCD have far too much latency?
though you may get a negative color image in the wrong orientation
most modern LCDs can do ~80 FPS updates (more, if you listen to the claims of the manufacturers)
Lerneaen_Hydra2: not at 3-4msec
hmm, how accurate are those numbers, IIRC it was 3-4ms for a certain grey to a certain white
ok - it looks like I was wrong about that. people think that there are no drivers for stereo glasses for Linux
full-scale changes are maybe 8-10 ms for most medium to high quality LCDs these days. It takes a bit longer to do lesser changes (from 30% to 60% off, for instance)
8-10 ms is the maximum - most are lower
you mena higher?
no - most medium-high quality panels tout lower transition times. 16 ms is the highest I've seen lately, but I wouldn't call it a quality panel ;)
so how long does a change take in the worst case scenario?
say it's a 8-10ms screen
SWPadnos: there might be this: http://futurelab.aec.at/vrizer/
well, if you can afford a CAVE, I'm sure you can get stereo glasses working ;)
[15:48:13] <alex_joni> http://www.stereo3d.com/discus/messages/24/2648.html?1121890613
seems other managed to make it work
but those are probably some other type
it sounded like they were talking about a software feature, noit a hardware driver
heh.. mine are similat to these: http://www.stereo3d.com/revelator_cable.jpg
similar.. argh I hate my typing today :(
Lerneaen_Hydra2: why do you say "argh" when you find out my .pngs come from 3d models?
there, I think I've fixed the bugs. http://emergent.unpy.net/index.cgi-files/sandbox/lace3.png
and boy is it wrong
try this instead: http://emergent.unpy.net/index.cgi-files/sandbox/lace2.png
03jepler 07HEAD * 10emc2/src/emc/usr_intf/axis/scripts/image-to-gcode.py: fixes for non-square images and output orientation
Can someone answer a general linux question about using signals between peer threads?
I can try but I don't use threads much
Is there a way for peer threads to notify eachother, or does the parent need to keep a table of pids of children, then when notified by one child, in thurn send a signal to each of the other children?
you can send a list with pids to the children
a list? With what function?
but usually (if I remember this right) one opens a pipe from the main process to the spawned one
this is over my head, I'm not sure of the answer.
EHJ-1: same here.. no expert by far
EHJ-1: are you using pthreads?
k, I thought there was a way to set a general signal that any thread could respond to.
Just using "fork".
there is something called pthread_cond_broadcast, which is apparently similar to pthread_cond_signal but for the case that more than one thread is "in a blocking wait state" .. er, nevermind.
if he's using fork() then no pthread
I just want to communicate a single "state" between each peer thread.
how about a global var?
and some mutexes?
jepler: not argh at that the models are 3d, but alex_joni's awful pun ;)
I thried both fork and vfork, which doesn't push the context. I see how to signal between parent and child, I just thought there would be an easier way than having to maintain a list of pids for each thread spawned by fork.
EHJ-1: probably you need to do it yourself
get the list from all the children
Yea, I was looking at global vars too. That seemed as hard as maintaining a table of pids.
jepler: nice image/toolpath :D
Just in setting up the shared data space.
hmm.. do you really need that?
I thought fork()ed children inherit all the rest
I thought I did, based on how things operated. It sure seemed like there should be an easier way.
maybe you should consider use of pthreads instead of fork(). It will help you do stuff like share state among threads.
If you use fork, the entire context (variable space) gets duplicated, so one peer thread can't see the data space of another.
k, I will look that up. I didn't see that in my linux book (linux for Windows programmers <g>).
[16:27:30] <jepler> http://www.llnl.gov/computing/tutorials/pthreads/
jepler: should a cvs update be safe now?
as safe as head can be that is ;)
last time I tried it worked
jepler: maybe instead of "ROWS" and "COLUMNS" it should be something with X and Y?
then again, with ROWS and COLUMNS people running special kins won't be affected
X and Y are the same for special kins too
I'm sure all the user-interface texts need improvement
maybe some way to save the gcode to a file would be good
to do that, run from the shell: image-to-gcode blah.png > foo.ngc
oh, in which dir?
it assume it uses the previous settings?
still, a GUI method to do that would be good
well for run-in-place just give the path to image-to-gcode
(here I am adding stuff to the feature list again :/ )
something I just noticed, when attempting to zoom in really close (to see blending effects in sim) there seems to be some type of clipping
Lerneaen_Hydra2: yes, there is
IMO it occurs too far away, though I don't really know what I'm talking about
so it may be good to be able to zoom closer by adusting that variable
* alex_joni will be back later
see you alex_joni
hi all. chech this machine out http://www.mecof.it/ING/emcolineaperforma.htm
nice, but out of my budget
a good friend of mine just commissioned it and has no work for it... but i do... l ; )
a bit over my bbudget too ;)
jepler: what are you using EMC for?
Lerneaen_Hydra2: nothing, really. I don't have a CNC machine aside from my etch-a-sketch.
occasionally I mill PCBs on cradek's maxnc
its good to know I'm not the only EMC developer who doesn't have a CNC machine
Lerneaen_Hydra2: you were telling me that up/down milling is related to the second derivative of the surface, but from that image it looks like it's about the slope (first derivative)...
to find the point where you have to stop, raise the tool, and then move it for a re-placing the second derivative is quite usefull
though you'll need the first derivative to find out which direction to go in the first place
* Lerneaen_Hydra2 hopes that was understandable
* Lerneaen_Hydra is back now
is someone from here trying to acsess ftp?
looks like it ;)
just downloading those two screen grabs from yesterday
yeah, no problem
just a bit surprising that's all
are you thinking about implementing stuff that advanced?
oh trying to get an idea how hard it would be
do you know of any image-derivative library?
I was just going to take the 2D derivative of the tool path
that's not too hard
hmm yeah that's quite easy actually
how hard do you think it would be to implement those two functions?
something like f'(x) ~= (f(x + eps/2) - f(x - eps/2)) / eps, and eps is 1 pixel
I'll know when I'm done or when I give up...
waterlining should be easy too, right? shouldn't it just be an if then with a bit other stuff?
probably gets interesting when you have to deal with "islands"
hmm, maybe not
maybe not interesting?
if you just set a certain Z depth to be maximum
well, maybe not difficult
one thing that makes this semi-CAM thing easy is that it's very easy to know where G0 is safe and where it's not
so islands don't have to be hard as such
how about islands with lagoons in the middle ;-)
that's the same thing
oh, you meant like that
not exactly the same - you can mill all around an island without moving Z at all, but you have to move Z up and back down to get into the "lagoon"
oh, like that
I'd have done the simple thing: always move Z up
yeah, move Z to predetermined "safe", then plunge in lagoon
maybe the config screen could ask for a safe clearance plane
but what is the algorithm for finding the existance of the lagoon in the first place?
that would have to be if you have waterlining
maybe waterlining isn't the name for what I mean
yeah, I'm talking about waterlining (maybe I should have explicitly said that)
I'm not entirely sure what waterlining is either ;-)
what I mean is this; (does a CAM file and screenshot)
I mean simply not descending further than Z=-k in the first pass, Z=-2k in the second pass, and so forth until you reach the bottom depth
that's what I mean too
but the scan is still lines in X or Y
for lagoons to have any meaning you would have to have that effect
I thought you were talking about doing something like contour lines on a map
jmkasunich: did you see the screenshot? http://emergent.unpy.net/index.cgi-files/sandbox/lace2.png
waterlining as you've just described is is just multiple runs of that algorithm, with differnet base planes each time, and rapids once Z gets above the previous base plane
also it would be nice if you don't remachine the bits you've already done
once Z > previous_base_plane, you want to pull up to avoid touching the part, and rapid to the next time Z < prev_base_plane
maybe with a lead-out
the rapid either has to follow the part contour with some Z offset, or just go up to a safety plane
if you follow the contour, blending will be different at high speed, so you need the offset so you don't hit the part during blends
a contour line based approach would probably be faster for many parts (but harder to implement)
jepler: the "depth" in the program is the overall depth, from the whitest pixel to the blackest one?
jmkasunich: it's the depth for the "0" pixel, or the darkest one if "Normalize image" is checked.
though that profile is not quite the same as the one we are discussing, as it doesn't smooth out the missing bits
(No such file `waterlining_example.ngc'.
and it has some other logics
well there are a whole lot of things there my program doesn't do .. and won't anytime soon
oh, I don't mean to say that everything I'm talking about should be added
even as it is now it's extremely usefull
if the part is too deep to cut in one pass, the existing program could still be used, with some preprocessing
take the original image, and use some image processing program to make every pixel less than some value = that value
use that image for the first pass
yeah that would work
and the second image would exclude the bits you've alread done
is that link valid?
I'll fix it
if you don't want to cut the final surface except in the last pass, why not make sure each waterlining pass goes no closer than TOL to the surface .. so it's not min(model_z, waterline_z) in those passes, but min(model_z + TOL, waterline_z)
TOL, is that tolerance?
it's some value
AFAIK when running with a roughing and then a final pass you want around 0.2-0.5 mm
yeah that's good
I was thinking something completely different (and worse)
hmm, one thing that's harder to add (and less important) is offsetting in X
so a straight wall would have some material left for the final pass
I thought that pass 1 would do the finish cut for everything above its base plane, and pass 2 would do the finish cut for everything below pass 1
but the transition would probably be visible and ugly
sometimes that's good, but the transition is ugly
^^^^ what you said
so if you leave a bit unmachined that can be removed in the last pass
if the total part depth is such that it would take three passes, the total job would require four do get nice results
three roughing, then a finishing
usually you'd even have higher feed on the roughing
as written, all the roughing passes would run at F1 feed all the time
G1 feed, not F1
so ideally you would have four feeds, roughing plane movement, roughing plunge, finish plane, finish plunge
plunging is gonna be ugly
if you set waterlineing to sane values it's not that bad
if the part has a vertical wall and you are moving from the high side to the low side, it will be straight down, and many end mills won't cut that way
CAM apps have ramping stuff though
you'd need a center cut mill
poor jepler, we just keep adding stuff to the list of features...
heh, we're not doing that
we're talking about a generic problem
he's free to choose any subset of the problem he wants to solve
yeah, of course
I think for best roughing performance (speed) you'd want a contour line approach
that way the depth of cut remains constant
oops, thats not so efficient after all
assuming large Z steps, you'd have a lot of uncleared material if the slope was shallow
like the first example program
lots of material left behin
[18:38:42] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/by_sign.ngc
you could use a "bigger" tool on the other passes to make sure you don't get too close to a wall
is this correct "up milling"?
you are starting at the arrow?
so you plunge straght down and ramp up?
duh, stupid question, riunning the program shows what you are doing
that assumes a tool that can plunce straight down
usually ramping is preferred
jepler: I don't have an emc machine here now, could you screengrab?
you can paste in ftp://basic:email@example.com/upload
although that particular profile is so steep its almost plunging anyway
ramp or helix
I think I get it though
the part is basically a sine wave, with about 60-70 degree slopes
up milling is better for shallow objects
down milling for deep parts
for something like that you'd definetly want down milling
well my point wasn't whether up or down milling is right in this case
but whether this file is an example of up milling
if you squashed the Zscale so the trough was the same as the ball radius then up would be better
yes it is
Lerneaen_Hydra: what do you mean by down milling?
how does it return to the bottom to do the other half?
I'd think that down on a steep ramp is bad
up down mill.png
each vertical line is traveled twice
yeah that makes sense
ok, down milling only works when the material to be removed is less than the tool radius, so you're not trying to cut at the center of the tool
well, that was their example. in that cam app you usually do a roughing first and have the paralell lace as finishing
[18:52:19] <jepler> http://emergent.unpy.net/index.cgi-files/sandbox/upmill.png
that looks good actually
like you might actually be able to mill it?
except for the excess left near the g0 bit (becuase of blending)
it looks millable
would I actually want to dwell or exact-stop at the end of the plunge or before the g0 out?
the best solution is a lead out
the updownmill_example file has that
45° of 5mm radius
did I miss anything?
how could tyou?
you were connected the whole time
well.. was just reading back now ;)
mostly it was discussion about possible features in jepler's image-to-gcode
oh, right ;)
was hoping for a summarize :)
not sure if there was a conclusion as such, but mainly a discussion of possible features
ok, that's probably more than enough ;)
how was F1 ?
wasn't it in italy this weekend?
was wondering... a possible use of my cnc code before
I don't know :)
oh.. I see it was turkey ;)
what cnc code where you wondering about?
I wrote a CNC code (that I still use under dos)
that cut 2D pieces from dxf cad drawings
now that I want to use just plain linux (and EMC of course)
I need a translator of my old drawings into G-code
and, as I already ported this code to linux c code
pier: there are a few noted here: http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?Cam
going to have a look at it
ok... so my code is completely useless.. thank you :)
pier: not useless.. I wouldn't say that
does it properly convert to G-code ?
not yet... I was thinking that writing some more lines
can you release under GPL? or any other Open Source license?
if so.. it might be interesting ;)
I really don't care about putting the source code on a site
but I think I saw some dxf-lib out there, so it shouldn't be hard to write :D
but I am afraid that it is not professionally written
pier: too bad it's not python.. bet jepler would have wanted it to use as a filter for AXIS
that's not that bad ;)
I think I'll put it on a page once it is ready
the source I mean
you decide that ;)
take a look at other available stuff, and then decide if it's worth to invest more time/energy or noe
you know... it is just putting the output to svga (in the graphic preview)
alex_joni: there's no need for AXIS filters to be written in Python
they are any Unix program that takes a filename as a parameter and writes g-code to standard output
then this may be interesting for emc2/AXIS
in terms of writing the proper G1 movement
* jepler disappears again
es:line(100, 200, 0, 20) -> writeln to a file "G1 X100 Y200 Z20 F20"
but it would be probably discovering hot water again
there's also no reason that the other GUIs couldn't use the same ini-file entries to allow filters to work
jepler: I know of one reason
nobody motivated enough to code it..
I am having a look at http://www.mgl.ca/~ecp/gobweb/cnc.c
very short code.... it took me more than 1000 lines... perhaps I am not so good at coding
but reordering the entities took me a lot
to optimize the lenght of the tool treck
and then cutting the internal holes first
pier: what language is that (e:line ...)?
peorting from borland
: confused me
after porting the whole lot under linux
I discovered it wasn't all that easy to write to parport
as it was in dos
no, it's not
for timing I just wrote few asm lines for timing the 8253
so now my code is useless unless I could use it as a dxf to G-code translator
it sounds possible
I woudd just have to remove all the writing instructions to the parport address and substitute the function that moves the tool dx, dy, dz, f with the corresponding G string (no pun here)
Well, darn it, I thought I had everything working great. input_scale = 40000, 2000 uSteps, very smooth travel etc.
Just now as I was homing the y axis, it stopped midway and sounded like a car horn.
Just kept that up, motionless, till I hit the e-stop.
Anybody ever had this happen?
yes, they do that all the time
I have plenty left.
Besides lump it?
is this your low geared dividing head?
No, this is the mill Y axis. 20 TPI lead screws.
and these are standard ACME type screws?
It really sounds real good 99% of the time.
no theyre triangular thread
whatever, not ball screws
are you running the motors close to their design current?
I truned off the driver and tried turning the shaft. It was free.
as expected ...
are you running the motors close to their design current?
Thgey are at 2 amp. I think the rating is 3.0 have to check. They are cool.
in that case, yes, do turn it up
I was assuming you were at rated current
anything up to 70~80c is considered normal for case temperature for steppers
This was so strange. just really smooth & sounds perfect, then this very rare out of the blue
how many Nm are the motors?
282 oz in,
plenyty for this mill.
ummm ... whats that? 2.5nm?
and what dia are the screws?
But with uStepping you're not at full power between detents though.
have to look it up...
1/2 inch shafts
and I assume they are direct drive to the screws?
no, you have mroe power ...
think about it ... on coil on = full step
What I meant is ...
mid step you have two coils at about 71% ...
actually, most good drives trasition to full step mode over about 600 rpm
when the rotor is 1/2 way between two poles, the rotor is being held between them, and not directly as close to either one as with a full step
oh, didn't know that.
* alex_joni heads to bed..
parker have patent on it, so I assume the use it ...
How bout that.
they transition to a trapezoidal and then a square wave from a sine wave at low revs ...
the other option is to either limit the speed, or gear the motors
it CAN also be the controller .. if it has a delay and fails to send pulses and then catches up in a hurry .. it stalls the motr and it never recovers
robin_sz: this was during homing..
so I doubt speed was involved
* alex_joni really heads to bed now
speed was 20 in/min.
mmm 400 rpm
282 oz in = 1.99 NM
X can do 120 in/min in this config.
400 rpm on screws like that is a bit hard for such a small motor I suspect .. try limiting the speed
looks like it.
thats pretty impressive
and it does that reliably?
I've actually had it up to 136 in/min before it complained.
wow ... thats impressive
I run 30 all the time.
forget the motors not being up to turning that screw then
must be very free running
The factory motors are smaller than mine and the specs for the mill with those are 30 in/min.
so, probably a pulse glitch of some flavour
are you opto isolated on the inputs?
That's what I'm thinking too, since it has only happened once after about an hour running time all together in this config
might just have been a latency thing in the RT side for a moment ...
glitched, stalled em and sat there.
Oh, I'm using an old Heathkit prototyping hobby box for the power supply to the interface.
oh not for the motors?
I have hex inverters after the par port & then on to the Parkers.
thats prolly OK
I really don't need the inverters though.
Maybe the power supply wigged out or something...
stick a bigger C on it
* robin_sz gets annoyed with some idiot on Groklaw
not for the motors. The Parkers use 120 V chopped direct from the line.
robin_sz, what is RT side?
the real time side of the system ... if the rt scheduler doesnt have the resources to perform the task in the time it needs, well it gets messy
normally its rock solid
Can any process interrupt it?
but near the limits "bad things" can hppen
mmm ... user side processes no
Well I am near the limit...
its upstream of the linux kernel in effect
but, during an rt timeslot, as I understand it, it has to be able to complete all the things it needs to do ... if it hangs on too long "bad things" can happen
I kept lowering BASE_PERIOD till bad things happened, then put it up some.
maybe a bit close?
I think I had problems below 10000 ns.
Actually I think 10000 was ok, 8000 was not. I put it at 12000, => input_scale = 40000,
1/(2* 12000) = 41600.
I need at least 40000 for 2000USteps. I could run at 1000 USteps & half the RT speed. Maybe I'll try that. What do you think?
I would do 1000uSteps and base_period = 20000
or maybe 16000 or 18000
OK. The box is pretty slow for other things at 40000 anyway.
As I understand it, (or misunderstand it)...
My choices on the drive are 1000, 2000, 5000, etc...
you just said you were running 2000
which requires an input scale of 40000
So I have to use either 20000 scale or 40000 scale to make the numbers work.
so cant do 16000 or 18000...
drive uSteps/rec = 1000, input_scale = 20000
anyway, the 16000, 18000 I was talking about was for base_period
smaller values of base period allow higher step frequencies, _but_ they put a heavier load on the computer
But SWPadnos told me input_scale = 1/(2* BASE_PERIOD)
you did trial and error, found out the computer got very unhappy at 8000, kinda OK at 10000
seemed ok at 10K
the highest possible value of input scale is a little less than 1/(2*base_period)
oh I see...
that'd not the same as =
actually even that is a huge oversimplification
SWPadnos should have said <= not =
why am I not surprised...
it's more complicated than that...
its not really that complicated
not even esoteric
you just have to be willing to do some math, and understand a few simple facts
How do I find out the whole story?
I'm gonna try to 'splain it
willing & able :)
ok, first - base period
I'll try to 'stand it
the code that makes steps runs periodically
base_period is the time between each run
so if you set base_period to 50000, then the step code will run 20,000 times per second
because 1 second divided by 50000nanoseconds = 20000
run being a group of output pulses?
it has nothing to do with output at this point
that is just how often the code runs
the code runs at the same speed all the time, and every time it runs it decides "should I make a pulse now?"
so if the base period is 50000, the code is running 20,000 times per second, whether you are making one pulse per second, or 100, or 10000
in order to make a single pulse, the code has to decide "its time to make a pulse", and turn the output on
the next time it runs, it turns the output off
Ah, so there is overhead for the code, and so input_scale needs to be enough below the base frequency to allow for that.
the soonest it can make another pulse is the time after that
you're getting ahead... be patient
anyway, if the code is running 20,000 times per second, the fastest it can make pulses is 10,000 times/second
because it needs one run to turn the pulse on and one to turn it off
if you want faster pulses, you have to run the code more often
thats why you use shorter base_period
with a base period of 10000 nanoseconds, the code is running 100,000 times every second
and you can in theory make 50,000 step pulses per second
but when that code is running 100,000 times per second, it doesn't leave the CPU much time for anything else - thats why your computer starts to get slow when you have very small base_period
got it so far?
what SWP told you was the absolute theoritical maximum step pulse frequency you can get for any given base_period
but you _don't_ really want to ask for that high of a frequency
let's use your numbers - base_period is 10000, the code is running 100,000 times a second
and the maximum frequency is 50,000 steps/sec
at BP = 12000, max = 41600, I'm at 40000 ... That ok you think?
I'm running at 12000...
you keep trying to connect BP to input scale, but thats not all there is
machine velocity also matters
50k steps .... 2000 steps per rev ... 25 revs/second ... thats 1.25 in/ second on 20 tpi screws
80 ipm ...
umm I thought you said it did 120 ipm?
But I'm running 40000, not 50000
* robin_sz estops
not now, I've reconfigured for max vel = 60 ipm.
40000 is your input scale, right?
indeed. I did notice he was changing stuff halfway through the explanation
that has absolutely nothing at all to do with the 50000 steps/sec in robins math
* robin_sz suspects hes fiddling instead of reading.
you keep confusing scale and step-rate
* robin_sz nods
ok sorry. I am trying & don't mean to be a pain...
just listen for a while
don't fiddle with anything
scale is a physical thing .. how many pulses per inch. not a speed thing. its fixed by physucal properies like gearing and tpi
* robin_sz nods
I'm trying to do this step-by-step, so you actually _understand_ what you are doing (and can do it yourself), instead of blindly taking advice from us
robin has a good idea, lets start with scale (I was starting with base period, maybe this is better)
like he said, scale is nothing more than pulses per inch
so it is determined by your screw, motor, and drive, and nothing else
it has nothing to do with base_period at all
(but once you understand how everything interacts, you can tweak things for the best combination)
lets forget for the moment that you can change the steps/rev on your drives
so, the screw pitch is fixed, the gear ratio is fixed (you don
so, the screw pitch is fixed, the gear ratio is fixed (you don't have any gears, right), and the steps per rev are fixed
therefore, there can be only one value of scale
steps per rev are selectable in his case ... which is kinda relevant
20 revs per inch times 2000 steps per rev = 40000 steps/inch
yeah, I know, and I'll get back to that
yep, just reminding for the later calculation
once we see the limits of 2000 steps per rev, he'll be able to see the reason for changing to something else
* robin_sz nods sagely
anyway, as long as the drive is set for 2000 steps/rev, scale _must_ be 40000 steps/inch
yes I do understand that aleady jmkasunich
now going back to base period, if its 12000, then the code runs 1e9/12000 times per second
that gives you a max step rate of 83,333 / 2 = 41667 steps per second
That's what I meant to say above.
_if_ you are gonna run right up to the theoritical limit, your max speed is 41667 steps/sec divided by 40000 steps/inch, or 1.0417 inches/second
Im with you...
in practice, I don't think its wise to ask for more than about 2/3 of the theoritical maximum, 1/2 is even better
do you want me to explain why? or skip that and move on?
Please do explain.
If you don't mind...
at the max step rate, the code is flipplng the step bit every time it runs
on, off, on, off, on, off, etc
suppose you ask for a slightly lower frequency
I need numbers for this
lets assume BP = 10000, the numbers are simpler
if you are doing on, off, on, off, on, off, etc, with each on and off lasting 10000nS, that is 20000uS between rising edges, or 50,000 steps/second
suppose you want 45000 steps/second
45000 steps/sec = 22,222nS between steps
but our code is running every 10,000nS
so it can't do exactly 45000 steps/sec
it can do on,off,on,off,on,off,on,off, for 20,000nS per step, or it can do on,off,off,on,off,off,on,off,off,on,off, etc, for 30,000nS between steps
does get more complicated, I see.
if you want something in between, the best it can do is flip back and forth between on/off/on and on/off/off/on so that the average speed is what you want
and thats exactly what it does
but that flipping makes pulse jitter
the closer you go to the theoritical maximum speed, the worse the jitter gets
The light is dawning... :)
in the case I just mentioned, you have to jitter between 20000nS (50000 steps/sec) and 30000nS (33333 steps/sec)
suppose instead of 45000 steps/sec you were asking for 4500
that means a period of 222,222nS
it still can't do that exactly
it will have to flip between 220000nS and 23000nS
is that a typo?
220000nS = 4545 steps/sec
230000nS = 4347 steps/sec
mm .. can I interject?
I tink they will both be about as smooth ..
the usteppign will tend to average out the jitter
I'm trying to explain to him, not confuse him
with EMC1, my explanation was definitely correct, because it would run at one speed or the other for a full millisecond, then flip to the other speed trying to average out to the right value
for emc2 its more complex, because emc2 flips between speeds on a pulse-by-pulse basis
that is better, but more complicated to understand
anyway, I think davidf now understands why you don't want to use every last bit of the theoritical speed
but, basically, its smoother, and we all know smoother is better, because jitter saps power.
I forget where I was going with all this :-(
You were going right here, I think.
so, you now know how to calculate scale for any given screw/gear/motor/drive combo
and you know how to calculate max step frequency for any given base period
and you know that you _don't_ want to use the absolute max frequency
so, at BP = 12,000, max_freq = 41,600
yes. I sort of did already, but I just didn't understand that I shouldn't be working so near the max step frequency.
if you decide you are willing to go to 2/3 of that, max_working_freq = 27730 steps/sec
27730/40000 steps/inch = 0.693 inches/sec, or 41.6 inches/min
fast enough for a small mill for sure
That would be ok.
now - you are getting that with a base period of 12000nS
the code is running 83,000 times per second, which loads the PC quite a bit
yes a lot.
it doesn't take much to delay the PC by 12000nS (thats only 1.2 millionths of a second)
oops, 12 millionths
still, pretty damned quick
so, what can we do?
your drive can be changed from 2000 steps/rev to 1000steps/rev
buy a motion controller?
lower the uSteps yes.
that changes your scale from 40000 steps/inch to 20000steps/inch
Cut the pulse rate in half.
if you want to keep the speed the same, the pulse rate is cut in half
so you can double the base period
I had all that actually.
(or split the difference - multiply the base period by 1.5 or so, that way you reduce the CPU load, and instead of going at 2/3 of the theoritical frequency you will only go at about 1/2
such a nice and complete explanation though ...
very, on both counts.
of course, its still all speculation as far as why your machine stopped and whined at you
hence the suggestion of 16000 or 18000?
Yes. That was really strange.
question: were you doing _anything_ at all on the PC when it happened? moving the mouse? resizing a window?
gah, why is the logger serving up ".bin" files all of a sudden?
we've seen some graphics cards basically take over the PC for hundreds of microseconds, sometimes several milliseconds, when you do windowy stuff like resize or move a window
usually not "cards" actually, graphics on the motherboard seem to be the worst for that
the answer is to replace with a real graphics cards
I have the default screen saver thing that Brezzy ships with...
the Mazak at the CNC workshop had onboard video with that problem - its a servo machine, so it didn't lose steps, but when you changed windows while the machine was moving, you could hear a clunk as it tried to stop for a few milliseconds
Could the timer for that be the prob?
a $5 matrox video card fixed it
did the screensaver kick in at that instant?
Unfortunately I wasn't looking at the screen.
cradek also had a laptop that would have RT problems when the fan kicked on or off
Just the machine in dismay.
are you using ubuntu?
rtai has a "latency test" that can be used to see if your hardware does nasty stuff like that
This box has heat mgt I think. I notice the fan speeding up and slowing down occasionally.
ok, I know the latency test is on there
just have to figure out how to run it
* robin_sz preserves the discussion for posterity
never know, someone else may find it useful ...
its just a program you run, let it go for hours if you want, and it records the worst case latency (delay) in executing RT code
I think cradek and I did that once.
Let it go awhile with no prob, but I had slower settings then
the idea is to run it, then wiggle the mouse, click on windows, surf the web, let the screensaver do its thing, wait for the fan to come on, etc
BP = 50000 I think.
the latency test has nothing to do with EMC's settings
(although a small BP will make the system less tolerant of latency)
yeah, we did that
the exact list of things that can cause RT problems is hard to define
heres an idea ....
I try to disable power management and such in the BIOS, but that may or may not actually matter
Servos would be real nice.
servos are fine if that is the class of machine you are building
but the cheapest servo solution I know of (besides Jepler
jepler's PWM servo) is $200 for the card
davidf already has significant $ in the stepper drives
I'll try the 1000 uStep setting and scale = 20000
hes trying to get angular accuracies of .001 degree ....
$900.00 for 5.
degrees? I thought we were talking about a linear axis here?
Not bad, retail = $5500.00 for 5.
on his rotary axis
0.001 degrees = 360000 steps/rev
no, not exactly.
so uS the motors at 1000 steps/rev, and use a 360:1 worm gear
robin_sz, I have two separate machines.
I forget exactly what it was .. Il stop distracting ...
mini lathe and mini mill.
that explains some of it
ill shut up ;)
The rotarty axis on the mill is a 72:1 table.
The spindle on the lathe is just for utility, to roughly position stuff...
* robin_sz adds "rotarty" to his dictionary
so with 1000/rev uStepping, and 72:1 you get 0.004 degrees/step
good. It's a very useful aberation to know.
make that 0.005 degrees/step
(I should know better than to do math in my head)
+ error in the worm drive
Actually I haven't yet retro'ed the rotary table for cnc.
+ loads of other stuff
robin_sz: all that goes without saying
Only if you don't say it. :)
likewise, 40000 steps/inch is ridiculous for a linear axis using all-thread for a screw
jmkasunich, indeed, but you do have to sorta remember it ... otherwise its easy to believe you actually have that level of accuracy ...
when the real mechanical limitations are probably 0.001 or so
.001 - .0025 error in an inch
* robin_sz writes a bit more gibberish to try and sort out his tube cutter madness
The mill ships with those screws. I'll be replacing them with acme soon.
Other than that, it's a pretty nice tool though.
im accumulating my madness here http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl/emcinfo.pl?TubeCutter
keep the craziness in one place
jmkasunich, robin_sz Thanks for the help. You really dug in there & I appreciate it.
jmk did, i just talked crap
heh not really.
hint: use ballscrews
robin_sz: you kept me from going off into left field about base period and such
scale was a good place to start
hint: buy them for me. :)
jmkasunich, its good to start with a fixed thing and then work back ...
if you shop around and do the ebay thing, you can get them at similar prices
similar to acme?
cradek mentioned $36.00 / 36"
jmkasunich, scale is fixed ... mostly. you can work back and see if its sensibly going to work with the processing power youhave, then if not work around again with different jumper settigns for ustep or whatever
Actually that's just what I did...
robin_sz: replacing a 1/2" triangle screw on a minimill with ballscrews is a non-trivial mechanical project
the ballnut is probably twice as large in diameter as the original nut
and might need a _lot_ of work to fit it
Just didn't realize that I shouldn't work so close to the max vel
jmkasunich, sounds liek davidf has the gear to lathe it up ...
if there isn't enough space on the casting tho...
on say, 12 or 16mm screw, the nuts are small enough
1/2 inch screw barely fits as it is.
I think acme threads with adjustable nuts would be fine for me.
hmm, 12 mm ~ 1/2 inch, & how big are the nuts?
I bet the nut is close to 1" over the ball return tube
I might be able to fit that.
jmkasunich, any clues/suggestions for face selection on the tube cutter?
my strength is in the low level stuff, I don't know much g-code at all
was thinking about hijacking the G54,55,56,57 commands ...
you gonna use it for making fishmouths and such?
that sort of thing ...
cutting around the corner will be fun
dare I ask what a fishmouth is, other than the obvios?
a jopint between two bits of round pipe
visualize a T fitting made of steel tubes
* robin_sz nods
the center leg of the T needs to have a strange shape on the end to mate up to the crossbar
thats a fishmouth
now visualise it with a non 90 degree angle ...
and the two tubes not the same diameter
and different size tubes
gets non-trivial fast
and not onthe centre line
the generic case is rectangular tube, with radiused corners
square tube is just a special case of rectangular tube
so is round ;-)
and round tube is just square tube with big radii :)
snap .. like the card game ...
we both said the same thing ...
So, you can fit a square peg in a round hole, as long as the specs are right then.
UK game maybe (or UK name for something that has a differnet name here)
childs card game, each turns up a card, if same value, you shout snap ... first to shout, gets the pile.
would it be reasonable to put a probe on this machine?
not really. no need is there?
the tube size is known the rest is just maths
assuming the size is _really_ known, and its centered in the machine
its basically a 4 jaw roller chuck
put the tube in, center Y, start probing while rotating A
after one turn, you know everything there is to know about the tube shape
and the Z axis has capacitive height sensing too
thats your probe
i think accuracy around the corners could be suspect
configure Z to be a height tracker, rotate A
Thanks again guys. 'nite.
started building a frame for it .. got some rails for X, a 2m ballscrew and a pair of 3kw AC servos
one for X, the other for the rotational axis A
how big is this gonna be?
2m X travel?
well, theres a thing ...
but htats a bit too small to be useful
I was thinking of cutting one end at a time
needs to be 6 or 7.5m really
so am i ...
but I guess its usefull to be able to do both ends in one clamping
no no ...
think say, 300mm lengths ...
but you put the whole 7.5m slug in and it just chops and chops you a whole pile of them ...
then loads itself another length ...
barrfeeder kind of
with the far end held in a 4 jaw chuck ...
the travel really only needs to be longer than the longest part you intend to make tho
mmm ... possibly
that would mean clam and release ...
you need to grab the stick in two places, right?
other wise it will be too wobbly
the commercial designs have a huge long X axis ... clamp the tube at one end, fead it through a slaved secondary chuck just infront of the cutting head
the far end provides motion in X
the cuttign head just moves in Y and Z
the secondary chuck provides support, but isn't so tight that the part can't slide thru it?
yeah ... rollers
wait .. theres a mpeg ... I thought I already bored you with it once ...
probably bored somebody else
oh it is VERY kewl ... wait
how is it loaded? seems the X rails would complicate things
or is it end loaded thru the traveling chuck?
dang .. they have changed em to .wmv ... :(
VLC can play some .wmv's but not all
wait .. yes
they do play on my linux machine ...
[23:17:17] <robin_sz> http://www.alspi.com/videos(tube).htm
look at the sqaure tube ones ...
the top one is best ...
thats exactly what I intend to be able to do
is that actual speed?
jmkasunich, you still there?
bizzare, when I play it in VLC there are four windows with the same video
Just wanted to clear something up real quick...
the main window, and three others with just the image
[23:21:20] <robin_sz> http://www.nick-gmbh.de/detail/images/laser.jpg
^^ the full size machine ...
Just went back & started editing the ini & saw input_scale = 40000 ...
& then realized the source of confusion earlier...
at 1 in/sec,
max vel in terms of steps is 40000 as well.
ah, at 1".sec, scale and steps.sec are the same
Thats what I meant when I said max of 40000, I was talking about the max steps / second, & it happens to be the input_scale as well. :)
Then I got confused when you thought I was confused... well you get the idea...
jmkasunich, you see the coordinated Y, Z and A motion as it goes around a corner?
anyway, that's what happened. thanks again for making the inner workings clearer for me that helps a lot.
ive bought a real nice slide and servo for the Y axis
[23:26:55] <robin_sz> http://cgi.ebay.co.uk/ws/eBayISAPI.dll?ViewItem&ih=002&item=120016762206
nice big heavy casting ...
thats should nicely carry the head for the acroos the tub motion ...
I think the ballscrews I have will be too slow for X
i think it will give some little used parts of EMC a workout anyway
it will beinteresting to see if it can keep the "cotnrolled poitn" at constant velocity on those combined moves ;)
EMC has no clue about the radius from the corner of the tube to the center of the A axis
you'll have to program that move using CAM or something
imgoing to embed that move in emc itself
tell the controller the tube dimensions ...
move to the start of the rad,
ask it to switch to the next face
it should track the corner as it moves A
and how is it gonna do that?
and end up on the new face, on the edgeof the rad
well, you cant program it as Gxx moves from cam
because its not circular
you can program anything as G01 moves if you use enough of em
well, you could
but thats not workable
redesigning the TP and/or interp is?
its not that big a deal is it?
it just a question of spitting out new Z and Y values as A rotates
emc _is_ the TP and interp - everything else is just window dressing and support code
you gonna add a new canonical for that or what?
its a bit of a pain,
because it affects the Y values ...
the goal is to be able to write a program
and if say, the tube is 2mm smaller than it should be,
not have to re-write the program from scratch to make it work
in the wiki page (which I've closed and I'm too lazy to find again) you mention the idea of unwrapping the part
is that how you'd like to program it?
that was rejected
for the varying tube sizes reason
say the corner radii are different to what you hoped for ...
then the unwrapped version is fubarred
I asked if that was how you'd like to program it - adapting that program to another tube side is a separate issue
what other way is there to program it? use different coordinate systems for each face or something?
something like that
I want to be able to say "hole this far from the centreline"
that would limit you when you program a hole that spans two faces (wraps around the corner)
or "cut until this far from the edge/face"
well, you have to pick one or the other for a datum
not really ...
if Y0 is always the centreline ...
and you put the Y value of the edge/face in ta variable ... #2001
then you can do it easy enough ...
the variable would be set when the tube is loaded/measured?
holes spanning a corner are still an issue
G1 Y[#2001 - corner radius]
<select face 2>
selecting face 2 causes A to rotate and Y and Z to track the corner
so the part where you go around the corner needs to be normal to the axis of the tube
so far yes ...
what if you want to v-notch a tube so you can bend it
unrolling the tube (IMHO) is a better way to specify stuff
just need to figure out how to correct for size
thanks .. that was actually a very good test case
you can have #2001 be the center of face 1, #2002 the transition from face 1 to radius 1, #2003 the transition from ratius 1 to face 2, #2004 center of face 2, etc
and as you pass beyond #2002, it roates automagically?
yeah .. ok.
one more thought for you ...
the special case of round tube
angle is easy, just linear interpolate between #2002 and #2003
there are two ways to do a hole in round tube ...
#2001 = #2002 = 0, #2003 = #2004 = pi/2 * tube radius
one, as if unwrapped and laid flat then bashed with a cookie cutter
the other, as if drilled through whilst still a tube ...