why is the angle in the XY plane the only one that is interesting (out of all possible, um, 36 pairs?)
what is the outut when there's no movement on that plane?
does this angle "wind up" or not, say if you do G2 circles forever
does it do much better than using a custom ddt+atan2-type component
Dave911_ is now known as Dave911
I don't think that's adequate for a knife machine anyway, and I agree it sounds like clutter
seems to me knife machines can be run excellently by writing smart gcode. this is especially true for emc because we can interpolate a rotary (C) move during an arc
I suspect anything else is just not going to work very well
you could even use a gcode filter to add the rotary moves
micges_work1 is now known as micges_work
cradek: is there any threading improvement that is not part of 2.3.4-1 ?
yeah, totally redone
got a friend that has issues with a 30-slot wheel
using interpolated position?
jepler_ is now known as jepler
[17:10:12] <skunkworks_> http://cnczone.com/forums/showthread.php?t=94452&highlight=emc2
I feel like Frank T. deserves an answer about rtnet and timing, but the only answer I have is "you gotta try it and let us know for the sake of posterity"
I couldn't care less about ethernet; I don't understand the excitement about it
it's got neat connectors
and pretty decent isolation.
what I think: It would be neat if there was an "open source" fpga board design that could run hostmot2, even if not many people would use it
or ethernet connected?
pci or parport would be the obvious choices imo
hmm.. jone is doing a lot of work because he's afraid parport is going away
I doubt that will happen in the next 5 years though
this hypothetical board would be intended to work with emc with as few driver changes as possible. ethernet means big driver changes. parport, pci (or any fast local bus) mean almost no changes required
if you ask me again in the future after there's a proven ethernet design that works with emc2 (hostmot2 or other), I'd change my answer on whether you should combine hostmot2 and ethernet into a tasty fermented beverage
I think mesa is working on an ethernet connected 7i37
err.. not 7i37
putting an ethernet jack on the same board as an fpga is the easy part
"if I've understand right, beagle-board is a small computer, based on CPU and memory. This architecture is not favorable to this embedded system."
hmm, I kept reading, and I guess I just don't agree with his goals - I wish him all success.
he sure wants to re-invent a lot
sounds like I used to sound
jmkasunich: used to?
I haven't wanted to re-write EMC for a long time ;-)
jmkasunich: you took something inflexable and made it flexable.
I think you're excused from rewriting software from the ground up after the first time
I wish we (?) had rewritten task too, before we all got tired
cradek: it's just a break
EMC: 03micges 07joints_axes3 * rb907c86d9210 10/src/emc/usr_intf/axis/scripts/axis.py: In Axis show current velocity in joint mode
micges: how does that display make sense
at least the metric/inch conversion is obviously senseless
unless, uhhhh, are you displaying cartesian velocity together with joint positions? that also doesn't seem to make sense
* jepler scratches his head
yep this isn't correct
Hi guys ... since you were talking about tangential knife type applications ... is the thought that a component can be added to the hal to derive the tangential vector without messing with the Motion component? Has that been done for things like a vinyl cutting machine?? Big X-Y gantry machine with a Z air cylinder and a C axis for the knife direction.
I'm thinking that the FPGA proposal guy is about 23 years old ....... ;-)
Dave911: here messing with knife will be done soon
Dave911: I've never had a blade machine like that, but it seems like you need to have the blade oriented at the beginning of the move before the tip enters the paper. so you can't just look at the current tangential velocity.
I am pretty much sure you should just suck it up and program the blade direction through C-axis moves :-P
jepler: hahaha .... if only my customers had such expectations .... all of the commercial tangential apps do the C axis moves as part the CNC control.... I like your thinking though... Where are those CAM guys when you need them! ;-)
micges: cool ... so you have an active application...
I would think that could also be written as an input filter.. (pre-proccess the gocode coming in to add the c axis)
Dave911: I have the luxury of not caring about customers
I know of a customer who has been struggling with WinCNC for about 3 years trying to get a decent CNC control out of them for a tangential knife app.
jepler: I'm jealous ..... ;-) There seems to a be a lot of bonehead customers right now ... way cheap... (of course they are not my customers ... ;-) )
skunkworks: Input filter .... yep I can see that as a solution also ..
cradek: I was chatting with you about Python Debuggers before. WinPdb or something similar. I loaded up a Java IDE known as Eclipse and it has a add in called PyDev. I just got it loaded but it looks pretty cool. Editor and Debugger all in one... It took a little while to get it setup but it is very interesting ..
git seems down
cradek is aware of the problem.
Guys .... what would be a good example program to look at for creating an input filter.. Any come to mind - right off the top of your head?
micges: if you merge master into joints_axes3 it'll fix the buildbot failures that just happened
well, maybe it wont fix the "update failed" ones, but the "runtests" ones should work again ;-)
I know, thanks :)
EMC: 03micges 07joints_axes3 * r802b44003473 10/src/emc/usr_intf/axis/scripts/axis.py: Revert "In Axis show current velocity in joint mode"
for tangential knife: you "just" need an input filter or a custom interpreter
doing it at the backend won't work - you have to do it at the front end (IMO)
since it's a 2D problem maybe it would be more appropriate to accept dxf/hpgl than gcode
didn't someone make a input filter for dxf..
or start to..
[21:38:29] <skunkworks_> http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?Simple_EMC_G-Code_Generators
this is so easy to do if you have the vectors... later when it's chopped up into servo cycle rate position samples, it's way way too late
if you're at some position and you know the tangent there is theta, you don't want to slew to that angle over the next 1ms .. you want to be at that angle at the start of that ms
yes and I can't see how it's possible to ever start a move
you would have to predict the future.
Input filter for DXF ... wow, that would be no easy task. I'm just thinking about how much stuff I need to tell a CAM package to turn a DXF file into Gcode ....
I think that Mach3 handles the C axis generation at the planner stage. I've tested Mach3's tangential knife operation and it works... sort of. At the time the project was delayed anyway and then I ran into some things that really turned me off as far as a Mach3 solution and tangential knife. I wouldn't propose it to a customer.
taking a 2d import is easier for a knife machine, since the output is 2d
yes you could certainly handle it in emc. you could handle it in the gcode too. but adding a hal output that says "I'm going left now!!" is totally useless
EMC: 03micges 07joints_axes3 * r5d7864b71179 10/ (15 files in 7 dirs): Merge branch 'master' into joints_axes3
Perhaps the entire filter idea is the right way to go... I can see that once it is at the hal level it is probably way to late as there is no way to look ahead and see what is next...
Mach3 picks up the knife when the turning angle is greater than a specified number of degrees. That way the material doesn't tear when making a right turn due to the blade spinning in place.
yep that's just another case like the start of a move
depending on the knife involved, maybe that angle is different
the control should do what the gcode says
we have some commercial knife cutting machines.. I would have to look and see if it picks up the knife on sharp corners.
I am having trouble putting on the hat which allows me to say that G0X1 / G0Y1 should perform Z moves
I can sure imagine a knife machine that takes 2d vector input and cuts along it in a useful way
on the other hand, I have a stubborn friend who says that cutter comp mode should never "add arcs", and that's clearly nuts, so maybe in a similar way I'm on the wrong side of this argument.
I don't know/care if gcode would be involved
jepler: nah - he's just wrong :-)
stubborn does not make right
cradek: but do you see the analogy I'm making?
forget it then
I think the two sane approaches are 'special pluggable interpreter' (not necessarily taking gcode - infrastructure not yet present) and 'input filter' (that makes gcode including Z moves)
jepler: I was trying .... ;-)
since I re-added biarcs to truetype-tracer I'm wondering if 2.4 shouldn't get a new text on its splash screen. http://emergent.unpy.net/files/sandbox/new-splash.ngc http://emergent.unpy.net/files/sandbox/new-splash.png
the letter shapes look excellent zoomed in, too
but ... all those youtube videos of the old one...
I guess all those people will have to submit new videos
(italicize the rectangle?)
anyway, it'll be a way to gauge penetration of 2.4
I like how it meets the g
what's the font?
fwiw.. that is nice!
#define TTFONT "/usr/share/fonts/truetype/freefont/FreeSerifBoldItalic.ttf"
whatever the old one was didn't exist on my new system
this one exists on all of 5.10 (who cares), 6.06 (who cares), 8.04, and 9.10
I like it
micges: seen http://www.linuxcnc.org/component/option,com_kunena/Itemid,20/func,view/catid,31/id,1366/lang,en/#1366
jepler: those are the best font outlines ever. that's slick.
I find this oddly scifi http://www.youtube.com/watch?v=RmsjTILE9ik
jepler: maybe we should put a truetype-tracer plug in the comments
alex_joni: yes I've tested it for him yesterday, it works
[22:03:44] <jepler> http://emergent.unpy.net/files/sandbox/new-splash-r2.png http://emergent.unpy.net/files/sandbox/new-splash-r2.ngc
those feel a bit too flowy for me
e.g. not really technical
how big is it compared to the old logo?
the old is 0.45 .. 6.92" and the new is 0.42 .. 6.94
so it's .04" bigger
and .02" taller
what it should really do is set the scaling factor #3 so it always fits on the current machine
are the limits of the machine accessable?
to the GUI? sure
the GUI would modify the #3=... line before loading the part program
no, they're not available from gcode
that might freak people out. ;)
another idea would be to have a splash gcode contest .. 2D, under 1500 lines, fits within some reasonable limit like 4x7" that should work in all but the smallest systems..
alex_joni: point taken about the font
I wanted something curvey because ttt does that so well now :-P
we could always go with http://emergent.unpy.net/files/sandbox/retro-splash.png
(from the font called 'CBM')
jepler: lol :)
between the two, I like the curvey one better :D
heh, I love it
it looks like it should have the space invaders sprites attacking from above
or a pac-man or something
cradek: new task should have many cool feature like reverse gcode run, jog during pause, definable RFL, hal pins for task, clear interface to interpreter (to allow interp change), support for adding new NML messages, have some infrastructure to definable G and M gcodes
just named few ;)
I'll create wiki for some thoughts about it
good night all