MarkusBec is now known as MarkusBec_away
ok i see...
allright... so lets move on.
so, do you have the XML file being loaded by AXIS, or as a separate window?
loaded by axis
in that case, you shouldn't need to manually load pyvcp
defined in the ini?
either way would be in the ini
ok the ini loads the xml
you should only need to make connections in your POSTGUI_HALFILE, since the parport driver should already be loaded, and the panel should already be added to the AXIS screen
only the "net" command`?
I don't know what the pin names will be though (loading as part of AXIS), so maybe comment out the net commands also and find the names with halcmd
yes, you should only need the net commands
now he don't knows "btn01"
so you can see the panel in AXIS?
he doesn't even load axis...
he gives an error
heh, probably three pages with one relevant line near the bottom or close to the top :)
comment out the problem line (or all the lines in your postgui_halfile), run, and use halcmd interactively (or the gui tool 'show hal configuration') to find out what the corrected line is.
custom_postgui.hal:3: pin 'ptest.btn01' does not exist...
yes, as jepler said, and I also said, comment out all the net lines (actually everything) in the POSTGUI_HALFILE, then start EMC
ah allright pyvcp.btn01
I guess you don't get a choice of "base name" when you stick the panel in AXIS
isn't this the "base name"? pyvcp.btn01
pyvcp is what I was calling the base name
if you add another button, it will be pyvcp.btn02
rather than ptest, which is what you would get loading it the way you had it (pyvcp -c ptest ... )
ok.. mom hardware testing
scotty beam me up! ^^ it takes function!! thanks!
that makes it a lot more simple to do more in pyvcp ^^
a lot easier
ok next question: how do i make a switch out of the button?
then I'll have to set checkbuttons
but now that the problem is solved i can go to sleep... 4 o clock in the morning here in germany.. thanks and bye!
tomp is now known as tom3p
pretty cool widgets from freshmeat http://tegesoft.com/products/gics
morning? damn you guys are behind the times
time starts in England we are right!
exactly! we invented it didnt we?
i thought as much
does annoy the french
time starts at some upstart place west of NZ that decided they were GMT +14 just so they can be first at stuff
that was probably done on purpose by the brits when we 'own3d' them (au and nz)
* archivist points Valen at the term GMT :)
thats the "middle" though
we are in front of that by 10 hours atm
we are the centre of the world
we are at the fashonable outer edge
archivist LOL re the centre of the world, but u are correct of course
* archivist restores the British Empire to its former glory
yeah i think the UK was foolish to give all our bits of the 'empire' back
we need to strike back
send some more convicts to .au
sorry we are full
archivist that was particularly politically correct, well done!
we do have a history of convict export, we even export to Libya now
doesn't seem to actually have done much in terms of reducing criminality there
I cam back from Libya in 1965 not long before the current nutter took power
MarkusBec_away is now known as MarkusBec
Lead-in moves by g41 are located at exactly wrong sides of the contour. The change of directions of arcs, at least first arcs at the start of the contour, helps, but it's a double work. Am I right to think it's a default EMC2 behaviour?
It looks like there are problems when I add tool diameter compensation to the g-code produced by some program. Lead-in moves are exactly at wrong sides of the contour!
are you sure you mean G41?
maybe it's G42
alex_joni: when i try g42, contour is cut from the wrong side.
I wanted to create programs without compensations, and programer would use g43.1 h- and g41 d-
And e.g. clockwise mean g42 but lead-in happens at the left to the circle and the detail is cut.
So I had to know the diameter of the tool when I create the program.
Standard ISO output <>Linux Enhanced Machine Controller ??
it is not cw or ccw - it is if you are going compinsate 'left' or 'right' of the path when 'walking' down the cutter path.
lead-in moves are programmed in EMC2 and are at wrong sides -> I have to create g-code for different diameters of the tools to be vegan and sane, or drink coffee, bread and dairy and read boring manuals.
the problem could be, circles are started ad lef, not at right, and lead-in moves are always at left in EMC2
Is there any default behaviour for lead-in moves to be at left to the contour? Otherwise, are they alwas at the right (g42) or left (g41) side of the contour.
bread doesn't help you read manuals does it?
afaik coffee is vegan. might cause insanity though
fenn: you know whta I mean. After an hour of attempts, I just create programs with compensations, and machine operator can not use "g10 l1 ..."
fenn: insanity? oh yeah, it can
you've looked at nc_files/comp* right?
left! No, not yet.
fenn: compensations comes as lead-in moves at left to the contour in .cnc files from HeeksCNC.
HeeksCNC is probably wrong then
At winter, they come in a white dress, / At spring, they come in a blue dress, / At summer, they come in a green dress, / At autumn, they come in a gold dress
i noticed it always gouges a pocket on lead-in moves unless you manually pick the start and end point
what season is it in russia?
fenn: you are a though man to talk to about cam! :)
fenn: it's russian song about the love, which comes in various dresses
f^x_ is now known as f^x
kanzure: I'm fine, thanks; and you?
kanzure: quick, what is lim(f^x) as f->x_
x_ is what?
x in power of x
[15:14:13] <EbiDK|AWAY> http://www.furaffinity.net/full/2515242/
1:1 scale GUNDAM
fenn: you can derive the value from the variable under lim | and solve it
fenn: Do you solve some maths for university?
ilya: just making fun of kanzure, who is doing calculus homework right now
fenn: oh, okey.
but the creation of g-code for contours, with some known values for tool diameters and length offsets works just fine in HeeksCNC
fenn: What time of the day is there where you are?
morning at work?
don't ask me, i'm on mars time
on mars time? Which time is it now then?
fenn: or some work in the morning? :)
ilya: /ctcp user time
alex_joni: it's for server. I'm in Russia and my servers are in the U.S. and everywhere.
11:47:48 -04:00 -- and it's mifnight +7
i had a problem with emc - it doesn't seem to take g70/71, had to replace with g20/g21 - is there a reason? (ubuntu emc2 live cd)
edison: yes, emc uses g20/g21 to define units.
emc doesn't claim compatability with any other control's dialect of gcode
i'm new to this so i kind of wondered why a known program like siemens nx cam outputs g7x by default (instead of g2x)
s/known/well known, much used/
because some other control probably expects g70/g71 to define units
gcode is about as standard as BASIC was in the 80s -- almost not at all
i see, well at least g0/g1/g2/g3 usually kindda works :)
usually programs for creating gcode have a "postprocessor" aka "post" which is used to make the output compatible with a specific dialect of gcode
jepler: really? I mean, really there are lots of differences?
is it a known "problem" that some cam systems dont use g2/g3 but instead interpolate manually? on my emc2 setup the path will be much faster if the cam outputs g2/g3
because there seems to be some inherent per-gcode-line delay in emc (or am i missing something)
edison: E.g. HeeksCNC offers to save G-code as /Standard ISO Output/ or /Linux Enhanced Machine Controller/, and as a few of other formats.
EMC will limit the speed of motion such that the machine can always be brought to a stop by the end of the current or next block
ilya: yes, i understand. i helped my friend define an emc2 "postprocessor" for siemens nx
without violating acceleration constraints
(and it works with arcs/circles, yey :)
so if you only output 0.001 inch segments, then EMC will never move the machine so fast that it can't decelerate to a stop in 0.001
edison: by default (in G64 mode) emc plans each movement so that it touches each specified movement in at least one spot, and can stop by the end of each movement.
that should explain why a list of small moves is much slower than proper g2/g3 then, thanks
SWPadnos_: Would G64.1 P- mode help?
if the segments are short enough (this also depends on your machine's acceleration) then yes, emc may not meet your requested feed rate
having smarter cam helps, but if you are stuck with dumb cam then you can use the "naive cam detector" G64 P- which internally combines movements that are within a tolerance of being a straight line
ilya, I think it can in some cases, because it will coalesce multiple collinear or nearly collinear segmengs into one
I am pretty sure you mean g64, not g64.1
SWPadnos_: although, it wouldn't try to move without stops?
while you experts are here, what's the current state of the art open source cam? which accepts cad formats with proper curves and circles..
edison: HeeksCNC, DXF2GCODE
tried both, i never got the heekscnc "adaptive roughing" to work
do you have success with it?
I couldn't use adaptive roughing, also :(
i noticed there was much svn activity though
but i was depressed to see that the python scripts seemed to segfault in the c++ library.. libactp or something (which implements the actual algorithm?)
edison, good bug reports are needed
edison: fenn or someone here said adaptive roughing is for high-sped machines and small depths of cutting.
ilya: suits me nice, since i dont know what high-speed is :)
few codes for pocketing in sequense could replace adaptive roughing
edison: simply fast moves with small amount of material machined. Helps to not heat up the detail.
there's "starting/ending depth' and 'step' for pocketing. But it's for 2.5D
(I think he's a former president of the USA.)
i'm doing aluminium at 1200mm/min feed rate, .15mm depth of cut right now.. making a bracket for my new spindle motor :)
what is a tool diameter?
you're at work :)
home :) got my first stepping xyz table a week ago!
but yes, its fun!!
What a machine? Of a table-size?
ily1 is now known as ilya_
edison: How much did it cost, this macchining centre, to you?
SWPadnos_ is now known as SWPadnos
anyone have emc2 working on ubuntu 9.04?
only as a simulator of machining
running pretty stable as a sim on 9.04 for you?
yes, read 5.5 of Installing EMC2
I worked in Kubuntu 9.04
install also "python-xml"; and "python-numeric" or similar for the /image-to-gcode/ program
Guest650: read wiki-pages. I would help you, but I have no free data traffic left.
no worries, i appreciate the heads up
"Installing EMC2 in simulator mode to Ubuntu or Kubuntu 9.04." is the header somewhere in 5.5 chapter of "Installing EMC2"
"python-xml" is for a Lathe
are you a machinist ilya?
no, i 'm only starting to working with cnc. cad>cam>gcode
word .. , e.g i see
I see no the word .. :)
Guess650:i don't think EMC2 works in 9.04 yet
it works, but it's not trivial to set up
Guess650: can you use ubuntu 8.04 ?
you have to xompile a realtime kernel and EMC2 to make it happen
SWPadnos: ny idea if or when they may upgrade EMC2 to 9.04 ?
I suspect it will happen when 10.04 comes out :)
since 10.04 will be an LTS release
they're may 10.04 as we speak(type) ?
i don't keep up with all the releases
10.04 willbe released in April of 2010 (hence the 10 and 04)
9.10 will be this october (10 / 2009)
THAT"S how they do that :) ?
i get it now
it's possible that there will be a new RTAI kernel + EMC2 packages before then, but I don't advise holding your breath
that would be cool, mine works great now(thanks to ya'll),so i'll breathe
SWPadnos: Why do not offer patched kernels?
we don't maintain RTAI, we only distribute an RTAI kernel because it makes installation of EMC2 easier
i guess Guess650 left
you can get RTAI from anyone you like
SWPadnos: It has patches for usual kernel...
My? Offer patched with RTAI kernels for Ubuntu 9.04 for various platforms. For newbies like me.
we don't have the manpower to make nre RTAI kernels all the time. making them work on a lot of machines (as opposed to just my test machine or something) is not easy
SWPadnos: Why many machines are needed? Couldn't it be x86/amd64bit?
I don't mean architectures, I mean different PC designs
making something that works on a Core2, an Athlon,, P3, P4, P2, and whatever else, with the variations in chipsets and peripherals, is the problem
designs? Patches differ with only architectures, I thought.
building reliable RT kernels seems to depend on the phase of the moon, among other things
SWPadnos: why not patch kernels and offer patched kernels to compile
that's no better than telling you to go get the patches yourself
getting the patches and patching the kernel is not a problem
coming up with a viable configuration is the problem
Last time, I couldn't patch kernel. There were no needed kernel for set of RTAI patches
and LTS-releases of Ubuntu Linux make you precomplie one reliable kernel?
lts is just sensible!
sensible for your feelings?
I would help if I could do anything useful in programming.
no, rebuilding machines is a pain dont need to do it every week
rtai patches are only for the vanilla kernel, not for the kernel which come with ubuntu
as volunteers the work should be the minimum necessary
acemi: you say with mystries and tales!
the kernel which is distributed by Linus
ubuntu has another kernel, from debian, right?
Mostly right... What's left then?
Debian has a better support for drivers, hasn't it?
ubuntu and debian have no big difference
acemi: ubuntu kernels change more often then official linux kernels?
debian and ubuntu kernel is not vanilla kernel
it's patched by maintainer of the dist.
acemi: And for ubuntu, I'm taking a vanilla kernel to patch with RTAI and compile it?
if you configure it corectly, it works
all the options? One manual told I should leave default options.
there are some critical options
for ex. acpi, hpet etc
which are defined by the patch?
they're configured by the patch
I wil be ready to read something when compile kernel.
[19:08:31] <acemi> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Debian_Lenny_Compile_RTAI#Configuring_kernel
What does AXIS manual toolchange window is for?
acemi: I read this page, but last time I did it, RTAI had no patch for kernel version I had, and I hadn't downloaded another kernel. Following to this page, everything is easy.
you can use any kernel, no need to use the same kernel with your distro
mostly a newer one is better
acemi: I know, I just had one from marth's issue of xakep.ru
OT: you can test first working vec2ngc cam (very good dxf support, output gcode for emc): source are at: 'svn co https://vec2ngc.svn.sourceforge.net/svnroot/vec2ngc
acemi: You're the man to ask at :)
micges: contours, or also pocketing and zigzag?
simply 3d milling for now
3d milling of upper surface?
Can I use wget -r https://vec2ngc.svn.sourceforge.net/svnroot
to get the source code?
now you can download latest tgz from https://sourceforge.net/projects/vec2ngc/
micges: I will do it, I hopefully think, tomorrow.
micges: Saying about the adaptive roughing in HeeksCNC: for 3D objects with no many slopes, it is possible to use pocketing with many steps down and assign higher feedrates. And then, after all, change a tool if you want and add a ZigZag.
cradek: today, g92.1 cancels g92 x- offset. I spent few hours last day trying it on a lathe with no effect.
* ilya_ has his pocket money, he's well-fed
[19:53:43] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?CoordinateSystems
skunkworks exactly a "Coordinate Systems"? g92 and g92.- are not enough?
It's strange. As I said once in a while, HeeksCNC let no non-integer numbers for a tool diameter and for steps down. Therefore, pocketing should be in an "O<programme1> sub" and should be called each time you se an offset with g92 z-.
* ilya_ is reading file:///home/hornygirl/emc-version1/docs/html/gcode_coordinates.html