Back
[00:54:16] <eric_unterhausen> anyone know a linux tool to edit pdfs?
[01:07:26] <Jymmm> PDF is typically a publishing format, not edit.
[01:27:23] <kanzure> eric_unterhausen: you can export to PDF from OpenOffice.org
[01:27:31] <kanzure> (the software suite, not the actual website)
[01:45:58] <LawrenceG> eric_unterhausen, I have used pdfedit ... mostly for adding and deleting pages in pdf's
[01:46:37] <LawrenceG> eric_unterhausen, it like to crash, so save often
[01:46:45] <eric_unterhausen> that's what I ended up with. It does have bugs
[01:46:51] <eric_unterhausen> "save as" doesn't
[01:47:36] <LawrenceG> at least it works for removing ad pages from pdf's
[01:48:00] <eric_unterhausen> that's nice
[01:48:33] <eric_unterhausen> I thought about removing a page, but it wasn't immediately obvious how so I skipped that
[01:48:53] <skunkworks> 1 garage door opener installed. slick.
[01:48:56] <LawrenceG> yah... no point in wasting ink on printing some nonsense
[01:49:53] <skunkworks> I should get the rest of the doors and windows installed - huh?
[01:50:05] <eric_unterhausen> good idea
[01:50:14] <skunkworks> priorites ;)
[01:50:18] <LawrenceG> skunkworks, good work
[01:50:40] <LawrenceG> now the other 2 should be much easier
[01:50:45] <skunkworks> yes
[01:51:53] <skunkworks> 'any idiot can do it' should be the slogan. very easy to install
[01:51:54] <LawrenceG> Its like the garage doors... I only install one about every 10 years and it always is a learning experience
[01:54:29] <skunkworks> I didn't even have to futs around with the light sensors. The 'just worked' tm
[01:54:38] <skunkworks> they
[01:55:22] <eric_unterhausen> mine weren't bad, but the brackets are easily bumped out of position
[01:56:09] <LawrenceG> I think you need to servo your opener.... quick open/close in the winter
[01:56:32] <eric_unterhausen> quick open is nice
[01:56:50] <skunkworks> these are kinda neat - they clip on the rail - then you have a thumb nut to tighen/aim.
[01:57:28] <LawrenceG> fast cycle is always good when the cops are chasing ya home!
[01:58:05] <skunkworks> these are not the fastest. but I can deal
[02:01:10] <skunkworks> oh well - time for bed
[02:01:12] <skunkworks> night
[02:01:59] <Jymmm> skunkworks: ug ug ug MORE POWER!!!!!!!!!!!!!!!!!!!!!!!!!!!
[02:02:06] <skunkworks> heh
[02:02:18] <LawrenceG> night
[02:08:36] <Valen> need starwars blast door style open/close
[02:08:46] <Valen> .something of a second
[02:16:35] <tom2> tom2 is now known as tom3p
[02:17:36] <Jymmm> a seconds is FAR too long
[02:17:48] <Jymmm> maybe 100ms
[02:19:08] <tom3p> geo01005: what the idea of resetting the position? do you just want to reset depth at 1st spark ? use rel (G91) or set a zero in a work coord system and chg to that system.
[02:29:15] <tom3p> the system im using now (not emc) only has one work coord system, but i save the present Z value when i probe the surface, set it to 0 (G92) then cut the user's depth, retract to 0 + some clearance, and restore the orig reference.
[02:29:40] <tom3p> same idea for electrode length offsets
[02:29:40] <tom3p> all in macros
[02:46:01] <Valen1> Valen1 is now known as Valen
[03:15:48] <geo01005_home> tom3p: The application that I'm using hal with doesn't really have anything like a Z axis.
[03:16:10] <geo01005_home> I ended up using the offset component, and used ClassicLadder to set the offset.
[03:22:26] <dmess> hi all
[03:22:33] <dmess> dmess: i made a part for the test rig tonite... 3000 rpm ...1.4 IPM hss uncoated #69 drill mike's .0690"- brand dormer
[03:22:33] <dmess> (22:07:01) dmess: they went straight to the ferarri last week .. and we had a MUD hole get thru.... I ended up reeling in the reighns on Fri. after 750 dollars HADNOT made a hole..
[03:24:00] <dmess> dmess: the other drills wer 180 a pop .. and you didnt hear ANYTHING ...
[03:24:00] <dmess> (22:08:17) dmess: mine 1.99
[03:24:00] <dmess> (22:26:03) dmess: thats 180.00 dollars verses 1.99 dollars no typo
[03:24:00] <dmess> (22:27:57) dmess: fenn..i made a g72 $drill call to a sub called drill and nested the up and downs there so they wound ALLWAYS be the same..
[03:26:27] <dmess> oh its a 0.029" drill in a CAT 50 taper
[03:26:36] <tom3p> geo01005: maybe the torch height controller code would be useful? it's motion that is numerically controlled by a gap voltage. so might be used in edm ( my work is building custom cnc edms)
[03:29:27] <tom3p> and the work done with wedm and a speed reduction algorithm to find a better rate ( not really gap control, but gap affected)
[03:29:27] <tom3p> those 2 ideas are emc implementations
[03:31:12] <a-l-p-h-a> sup dmess?
[03:37:22] <Jymmm> WOW Speak of the dead and they appear
[03:37:28] <Jymmm> cool
[03:45:32] <dmess> well... workin... livin single with 3 kids....
[03:46:21] <dmess> who me.... Jymmm
[03:46:21] <tom3p> geo01005 i think BJT was using the offset component, but i never read how he resolved removing the offset. at first it seemed the joint would jolt back into position when the offset was removed
[03:46:39] <Jymmm> dmess: No, a-l-p-h-a
[03:47:54] <a-l-p-h-a> ?
[03:48:03] <a-l-p-h-a> i just f'd up my NAS... lol
[03:48:15] <a-l-p-h-a> I changed it's root password, and it's not what I thought I typed.
[03:48:21] <dmess> we are 15-20 km apart after all.. so your intuition just needs a fine tweekin'
[03:48:22] <a-l-p-h-a> oooh F.
[03:48:47] <dmess> nas block>???
[03:49:01] <a-l-p-h-a> dlink dns-323, with debnas installed.
[03:49:31] <a-l-p-h-a> worse case scenario, I format it.
[03:50:11] <dmess> oh not the test block i have anear PERFECT one behind (my) machine..
[03:52:15] <dmess> well got hit the pit... more baby holes to make ... 0.029" holes dont make them selfes
[04:01:42] <toastyde1th> and sometimes, you don't make them either
[04:01:46] <toastyde1th> no matter how many drills you break
[04:06:13] <Jymmm> SWPadnos: On thos cheapy RAID cards, do you remember the name of the bad/icky chipset?
[04:07:22] <SWPadnos> highpoint rocketraid maybe?
[04:10:17] <Jymmm> SWPadnos: No, the chipset name, like Marvel or some such thing
[04:10:29] <Jymmm> I just coldn't remember the name of the BAD one.
[04:10:34] <SWPadnos> noidea atm
[04:11:03] <Jymmm> SWPadnos: $29 may not be bad to revive an older computer
http://www.newegg.com/Product/ProductReview.aspx?Item=N82E16815124020
[04:20:03] <a-l-p-h-a> wow...
[04:20:09] <a-l-p-h-a> that took a long time to get that sorted out.
[04:20:10] <a-l-p-h-a> fuck!
[04:20:17] <a-l-p-h-a> NAS root password changed.
[04:20:25] <a-l-p-h-a> hacking your own systems is not fun...
[04:29:11] <Jymmm> SWPadnos: If nothing else, that card might be nice just to transer data off of old systems.
[04:31:58] <SWPadnos> I use a USB -> (IDE / mini IDE / SATA) doodad
[04:32:13] <Jymmm> SWPadnos: Yeah, but slooooooow
[04:32:20] <Jymmm> I have one too
[04:32:21] <SWPadnos> not really
[04:32:37] <SWPadnos> it depends on the interface, but most old slow hard disks are much much slower than USB2
[04:32:55] <SWPadnos> ah - this one:
http://www.newegg.com/Product/Product.aspx?Item=N82E16812156102
[04:34:20] <Jymmm> does it do 2.5" IDE too?
[04:35:00] <Jymmm> SWPadnos: This is the one I have...
http://www.dealextreme.com/details.dx/sku.474 works great, even under linux
[04:35:13] <SWPadnos> yes, mine does 3.5, 2.5, and sata
[04:35:29] <SWPadnos> and min is fine under Linux as well
[04:35:35] <SWPadnos> I'm not sure I've tried it on Windows :)
[04:35:43] <Jymmm> LOL "limit 100 per customer"
[04:36:22] <SWPadnos> I don't remember which one it is, but there's one of those that lets you use multiple connectors at the same time
[04:36:29] <Jymmm> well, a $29 card in case a old ide hdd fails doens't seem too shabby
[04:36:57] <SWPadnos> I agree in principle, but I don't know that it would help
[04:37:17] <SWPadnos> on a Linux machine, maybe (assuming that the chipset is supported by the installed kernel)
[04:37:55] <SWPadnos> on a Windows machine, almost definitely not, unless XP is a heck of a lot better than anything prior at using "whatever" disk interface is found
[04:38:19] <SWPadnos> (it used to be that if you changed chipsets, sometimes even from the same vendor, that it wouldn't be able to boot)
[04:46:08] <Jymmm> SWPadnos: Yeah, there that, but I mean if there's nothing wrong witht the machienother than the ide hdd, just rebuilt it back to what it was just using a sata hdd
[04:46:54] <SWPadnos> sure
[04:47:01] <SWPadnos> on that note, good night :)
[04:47:05] <Jymmm> Hey, a emc2 pendant
http://www.dealextreme.com/details.dx/sku.26910
[04:47:34] <SWPadnos> USB, so it should work with hal_input
[04:48:24] <Jymmm> SWPadnos: did you ever get your logitech gamepad working?
[04:48:38] <SWPadnos> sure, though I've only "used" it in sim
[04:48:43] <Jymmm> k
[04:49:11] <Jymmm> G'Night SWPadnos
[08:58:54] <roh> Jymmm you can get away a bit cheaper by building a jog box yourself
[09:20:01] <piasdom> g'mornin all
[10:00:34] <ilya_> CYCLE_TIME=0.100 in ~/configs/sim/axis.ini file. If I make it to be 0.200, will it save some CPU time?
[10:05:26] <Valen1> Valen1 is now known as Valen
[10:24:18] <ilya_> Parameter `MAX_LINEAR_VELOCITY = 1.2' offers strange 1800 mm/s even when 50 mm/s is set as maximum. Why does the multiplier assigned to `1.2' when default value is `0.25'?
[10:26:47] <ilya_> What is `CYCLE_TIME = 0.001'? What if I assign a far larger value as `0.01'? Could it save some CPU time?
[10:28:20] <piasdom> ilya: repeating your question will not get it answered...wish i could help you
[10:29:04] <ilya_> piasdom: these are three different questions related to /sim/axis.ini file
[10:29:58] <piasdom> ilya: sorry...i seen CYCLE_TIME and thought they were the same
[10:31:12] <piasdom> * piasdom minding his own business :)
[10:31:36] <ilya_> When EMC2 in sim mode shows the milling entities order, CPU has a one third to half a load. It's probably because video card is built-in, it's a laptop, right?
[10:33:34] <piasdom> ilya: i know they say that a built-in video is not advised...something to do with power draw
[10:34:29] <Valen> if its got 3d stuff on the screen, and you are running without 3d acceleration then you are using the CPU to render it all
[10:34:46] <Valen> if your only running sims you can run with 3d acceleration
[10:34:54] <ilya_> CPU participates in creation of beauty AXIS interface
[10:35:05] <Valen> the no built in video thing is mainly a latency thing
[10:35:31] <ilya_> Valen: and 3d acceleration = fglrx driver for ATI vidocards?
[10:35:49] <Valen> thats the open source version i think yes
[10:36:15] <ilya_> how can driver reduce CPU time in `painting' 3d view?
[10:36:40] <Valen> because the video card does all the work to render the 3d scene
[10:36:41] <ilya_> so, i can try my proprietary driver right now
[10:36:59] <Valen> will you ever use the machine you are running it on for production?
[10:37:49] <Valen> IE actually running a real mill
[10:38:06] <ilya_> Valen: i want to use it for .dxf-to-suitable G-code tasks
[10:38:26] <Valen> but not actually running a mill
[10:38:49] <Valen> if thats the case then yeah you could use the best 3d driver you can find for your card
[10:39:25] <Valen> If its a multi processor machine you can also look at using the SMP kernel and a SMP version of EMC which will give you a bit more response
[10:39:30] <ilya_> Valen: yes, latency is 15000 to 100'000, and this laptop works, but one another doesn't work at all in RTAI mode
[10:39:58] <Valen> thats pretty bad already lol, might as well turn on the real 3d drivers
[10:40:04] <Valen> whats the specs on the machine?
[10:40:38] <ilya_> Valen: no, for fglrz i should download xorg-fglrx-dev (two files totalling 10 Mb in size)
[10:40:49] <ilya_> i will have to wait too much time
[10:40:51] <Valen> i dunno for ATI stuff anymore
[10:41:43] <ilya_> Valen: ASUS X51RL laptop, 2GHz M550 Celeron, 2Gb RAM
[10:43:44] <Valen> yeah the fglrx is probably the way to go, you can turn compiz on then too for the shiny effects
[10:44:49] <ilya_> Valen: with proprietary driver, 'Composite' extensions as compiz have to be turned off to see graphisc in axis EMC2 interface
[10:45:30] <Valen> thats odd, I have the nvidia driver working with compiz and showing axis fine
[10:46:19] <ilya_> Valen: i usually edit the xorg.conf file, there can be other ways to go with compiz and axis
[10:46:39] <Valen> i just ran the propriatry driver installer
[10:46:47] <ilya_> Compiz reduces latency, anyway. It always spends some CPU time
[10:47:04] <Valen> because otherwise you need to muck with recompiling kernel modules and the like
[10:47:17] <ilya_> I'm too, then sudo /etc/X11/xorg.conf
[10:47:26] <ilya_> *nano or gedit
[10:47:48] <Valen> why? it seems to work without any of that
[10:48:05] <ilya_> Valen: my words about it are in the 5.5 Installing EMC2 in wiki
[10:48:44] <ilya_> Valen: graphics are 'in shadow' if you do not disable the composite extensions as compiz.
[10:49:13] <Valen> all i can say is what I did.
[10:49:20] <Valen> ./NVIDIA
[10:49:22] <ilya_> Section "Extensions" | Option "Composite" "disable" | EndSection
[11:04:45] <ilya1> CPU load seems to be the same
[11:05:59] <ilya1> ilya_: when will the connection will be reset by peer?
[11:19:15] <Valen> if you register with nickserv you can kick your old usernames
[11:19:44] <ilya1> ilya1 is now known as ilya_
[11:19:52] <ilya_> only one username
[11:20:19] <ilya_> ilya_ is now known as ilya
[11:20:32] <archivist> see /help ghost
[11:21:08] <ilya> ilya is now known as ilya__
[11:22:04] <ilya__> Anyway, i still try to make heekscad to mill inner countours at first
[11:23:17] <ilya__> it follows the order entities of dxf were created, while DXF2GCODE follows the order from last created object to the first created object
[11:30:22] <ilya__> Does anyone creates g-code from drawings? Is it a common practice to redraw whole drawing, starting from contours to be milled first?
[13:59:48] <ilya_> Can I add G41 and G42 codes later, when to the created drawing?
[14:00:06] <ilya_> With freeware t
[14:00:24] <SWPadnos> G-code is text, you can edit it however you like after it's created
[14:00:27] <ilya_> !@#$%^
[14:01:10] <ilya_> SWPadnos: the problem is, I have to redraw whole dxf file to be able to add G41 or G42
[14:01:25] <SWPadnos> then you're doing something wrong
[14:02:05] <ilya_> it gas mixed lines and arcs -- which are to be milled either clockwise and counter-clockwise -- until I try to redraw it.
[14:02:40] <SWPadnos> drawing and milling are separate steps, separated by CAM. if you have to redraw things to mill them with cutter comp, then your CAM is broken
[14:03:13] <ilya_> one arc goes clockwise, another goes counter-clockwise -- it means two appearances of G41 and G42 in the code. Is it normal?
[14:03:27] <cradek> I think you are confused
[14:03:36] <ilya_> I'm using QCad -> HeeksCNC
[14:03:39] <cradek> g41/g42 are cutter-on-left/right
[14:03:49] <cradek> has nothing to do with cw/ccw
[14:04:46] <ilya_> cradek: yeah. And i have to redraw arcs to be able to CUT CONTOUR COUNTER-CLOCKWISE TO ADD g41 BEFORE IT
[14:06:06] <cradek> sorry, I still don't understand what you mean
[14:06:48] <ilya_> 1. I'm given a someone's dxf file with a sheet of metal and arranged details on it. 2. I'm trying to create a program. At first, an inner contours of a first detail goes.
[14:08:17] <Valen> try explaining it without using the word contour
[14:08:43] <cradek> if cutting stuff out of sheet, I understand that you need to do the inner contours/things first
[14:08:48] <ilya_> if arc was saved or "created" in a clockwise direction, i should add G41, otherwise g42. But i have a 20-40 objects, which direction in DXF is mixed, so tool goes right and left
[14:09:24] <ilya_> i wish i can use pastebin.ca or so due to limited traffic.
[14:09:38] <cradek> your software needs to join them together in a continuous path for cutter compensation to make sense
[14:09:50] <ilya_> exactly!
[14:10:40] <cradek> say your internal contour is a square. you can cut it cw (using g42) or ccw (using g41) but you cannot cut it randomly (left, then right, then top, then bottom)
[14:11:11] <archivist> I think heekscnc is buggy in that respect
[14:11:28] <ilya_> imaging, that this square has chamfers, which break left/right direction.
[14:11:33] <cradek> there are two approaches with dxf: use polylines (REALIZE does this), or don't use polylines and guess contours by looking for endpoints that match or almost match (most other dxf-reading software does this)
[14:12:06] <cradek> ilya_: not if you cut them continuously in order
[14:12:39] <cradek> ilya_: any combination of lines/arcs are just fine if they're in order, end-to-end
[14:12:57] <ilya_> cradek: to cut continuously in order, HeeksCNC can arrange ID numbers.
[14:13:10] <cradek> I don't know what ID numbers are
[14:13:20] <SWPadnos> ilya_, I think what cradek is saying is that you need CAM software that sorts the drawing entities into continuous paths, it can't generate good G-code in the (random) order the entities appear in the DXF
[14:13:31] <archivist> dan falk reported a left/right arc bug the other day
[14:13:47] <ilya_> cradek: yeah, but heekscnc reads dxf as they appear in the dxf.
[14:14:04] <archivist> heekscnc is very alpha at the moment
[14:14:10] <cradek> it has to do other reordering too - for instance doing inside contours first - I think often this is done interactively because it's hard to guess from a drawing
[14:14:59] <ilya_> archivist: HeeksCNC has ID numbers for entities of the sketch. This way, i have arranged my small drawing. I'm just curious if it's normal that it takes some time (sometimes) and ain't automatic.
[14:15:33] <archivist> Im not using the cnc part of heeks
[14:16:25] <ilya_> cradek: I used relatively cheap CAM Expert (30 USD) -- and everything was good. Now I need freeware, and DXF2GCODE or HeeksCNC seems good, but it's a bit tricky sometimes to get everything working.
[14:17:01] <archivist> HeeksCNC needs good bug reports
[14:17:03] <cradek> perhaps you could help improve it
[14:17:23] <ilya_> cradek: I'm not a programmer
[14:17:55] <ilya_> I'm poor (in both ways) mechanic with GPRS internet access :'(
[14:18:27] <archivist> bug reports dont cost
[14:18:34] <ilya_> archivist: how can I add a comment, not a bug, to HeeksCNC?
[14:18:49] <archivist> add issues
[14:18:57] <archivist> and add to the wiki
[14:19:09] <archivist> and also send to the email list
[14:19:12] <ilya_> archivist: usual sourceforge.net webpage costs 1 Mb or about 0.2 USD at a daytime
[14:19:15] <Valen> lots of places take feature requests as bug reports
[14:19:23] <Valen> ouch
[14:19:27] <ilya_> OK
[14:19:41] <archivist> ilya_, HeeksCNC is on google code
[14:19:50] <Valen> mailing list is probably low bandwidth
[14:20:04] <ilya_> archivist: i know, i just emphasize my problem
[14:20:42] <cradek> if I was a developer I'd like to get a report with a sample drawing (simplest possible that shows the problem), a description of why the generated gcode is inadequate, and an example of how the generated gcode should look for that drawing
[14:20:42] <Jymmm> ilya_: Cosider it a low cost fee to have a useful product
[14:21:12] <cradek> that's my idea of what a good bug report/request for help would be like in this case
[14:21:36] <ilya_> Jymmm: It's actually so.
[14:23:17] <cradek> IMO, the cam should add g41/g42 for you, with suitable entry and exit moves. to do this, it has to know which contours are inside and which are outside. I don't know how heeks would do that - it probably would need the user to specify somehow.
[14:23:44] <ilya_> I think if I try to change ID numbers of entities, HeeksCNC offers to re-order the drawing. In this case, program seems to understand that what i try to do.
[14:23:46] <cradek> also, ideally, you could tell it to use climb or conventional milling by contour
[14:23:52] <skunkworks_> you should go to #cam and ask
[14:24:08] <ilya_> skunkworks thanks
[14:25:13] <renesis> is heekscnc free or what
[14:25:34] <archivist> free
[14:25:47] <ilya_> free and is being developed. Useful, anyway.
[14:26:03] <renesis> says not done =\
[14:26:09] <Valen> there is an irc # that the guy who makes heeks hangs out in
[14:26:39] <cradek> no software is done
[14:26:45] <archivist> #cam is the place but dan heeks is not in at the moment
[14:27:08] <renesis> cradek: so why would you point it out, is my point
[14:27:15] <ilya_> archivist: anyway, i can not say i've tried all the features.
[14:28:48] <ilya_> HeeksCNC has more options to produce code without redrawing, than DXF2GCODE
[14:29:15] <renesis> also how is it broken
[14:29:40] <ilya_> There's still a way to create g-code for inner contours, and then add g-code for outside contour
[14:30:12] <ilya_> renesis: it's OK, just start to work and see
[14:30:30] <renesis> hmm
[14:30:48] <renesis> mostly using gcam or mastercam right now
[14:31:05] <ilya_> gcam? is it free?
[14:31:20] <renesis> yes i did alot of beta testing for it
[14:31:46] <renesis> dev doesnt hang out in our smallchan anymore but it looks like hes still working on it
[14:31:50] <ilya_> I think i could create g-code with DXF2GCODE, then manually add g41/g42 for different contours.
[14:32:04] <renesis> thats work
[14:32:16] <renesis> http://gcam.js.cx/index.php/Main_Page
[14:32:41] <ilya_> thanks, will see after 1.5 hours
[14:34:20] <als_> logger_emc: bookmark
[14:34:20] <als_> Just this once .. here's the log:
http://www.linuxcnc.org/irc/irc.freenode.net:6667/emc/2009-07-30.txt
[14:36:44] <ilya_> HeeksCNC: Sketch > entities of the sketch > id's -- this should be changed to get one-to-another pathes.
[14:37:55] <archivist> ilya_, make comments like that in #cam, devs monitor the log of the channel
[14:38:08] <ilya_> ok
[14:38:36] <als_> just noticed that the linuxcnc. home page does not show the newest 2.3.3 release FYI
[14:41:46] <ilya_> It's easy to change the axis direction for arcs and therefore their direction, poor me mathematician
[14:42:20] <ilya_> MS W1nd0ws made me a thoughtless consumer...
[14:42:28] <ilya_> :)
[15:09:28] <geo01005> hmm, it looks like classic ladder dosen't handle floats correctly....
[15:11:35] <cradek> it only manipulates bit and s32 hal types
[15:12:04] <geo01005> I'm confused why there are float pin then?
[15:12:17] <cradek> classicladder doesn't have float pins
[15:12:20] <geo01005> Is this just for the future?
[15:12:23] <geo01005> Yeah it does.
[15:12:32] <cradek> oh? what are they called?
[15:12:39] <cradek> (I don't see it in the man page)
[15:12:49] <geo01005> yeah there aren't in the man page.
[15:13:16] <geo01005> classicladder.0.floatin-00 and classicladder.0.floatout-00
[15:13:32] <cradek> you are right, hmm
[15:13:36] <geo01005> apparently it just chops them.
[15:13:38] <cradek> I don't know what (if anything) those do
[15:13:49] <cradek> chops?
[15:13:49] <geo01005> 1.125 is 1
[15:14:27] <cradek> sounds not too useful
[15:14:56] <cradek> I'm not sure floats belong in ladder at all
[15:15:01] <geo01005> yeah... looks like I'll have to get creative.
[15:15:11] <cradek> what are you trying to do?
[15:15:35] <geo01005> Well most commercial PLC handle float now.
[15:15:56] <geo01005> I was just going to do some calculations for homing.
[15:16:15] <cradek> I guess you could compare them with < and > (but not =)
[15:16:29] <cradek> we have hal components to do that kind of thing with full double precision
[15:16:39] <geo01005> I'll have to use some external mux's or something like that.
[15:17:28] <geo01005> I was assigning float with CL, and that clearly won't work.
[15:18:43] <geo01005> it sure explains why I couldn't get things to work right :)
[15:29:15] <geo01005> I think it may be easier to do most of what I was going to do with classic ladder in a realtime component with comp.
[15:30:57] <cradek> if you have to do a bunch of float manipulation, I bet you're right
[15:32:11] <geo01005> Well it is really just assignments, but the numbers are not know ahead of time. I don't see a good way to do it with the stock components.
[15:32:34] <cradek> what's the task? sounds interesting
[15:34:16] <geo01005> It is really quite simple... Just homing a joint.
[15:35:06] <geo01005> Go in the negative direction till a proximity sensor is triggered, then backup and additional .25"....
[15:35:08] <cradek> must be something unusual about it
[15:35:35] <cradek> doesn't one of the existing homing methods just work? there are so many.
[15:35:49] <SWPadnos> if you need to latch a value, you can use a mux2 to do it
[15:36:04] <geo01005> The go forward at a slow velocity still the sensor is triggered,
[15:36:28] <SWPadnos> hmm. actually that's a sample and hold, so you'd need some extra logic to keep the latched value
[15:36:37] <seb_kuzminsky> cradek: doesnt homing apply an offset above the joint level? the hm2 stepgen geo's using (and the sw stepgen) dont support a "reset the feedback to 0 right now"
[15:36:59] <geo01005> stop motion and change change to position mode go forward some pre determined distance and set that to be zero.
[15:37:20] <SWPadnos> seb_kuzminsky, that is the case when you're using emc2, but if you're using a bare HAL (which I think I remember this being), then it has to be done in HAL
[15:37:20] <geo01005> Btw I'm not using emc, just the hal and classic ladder.
[15:37:32] <seb_kuzminsky> SWPadnos: right
[15:37:35] <cradek> oh
[15:38:16] <SWPadnos> geo01005, write a simple .comp that has a couple of bit inputs (track and hold), and a float input and output
[15:38:18] <cradek> no wonder I was confused
[15:38:45] <geo01005> Yeah SWPadnos, I think that is what I'll do :)
[15:38:48] <SWPadnos> when the track input gets turned on, (regardless of the state of the hold input), out=in
[15:39:11] <SWPadnos> when the hold input gets turned on (regardless of the track input), stop updating the output
[15:39:30] <SWPadnos> track is fed from the "homing" procedure in CL, hold is fed from the switch
[15:40:24] <SWPadnos> alternatively, you can use CL and the existing mux2 to do the same thing
[15:40:47] <SWPadnos> from CL, you need an output that turns on when "tracking", and off when the value should be held
[15:41:13] <SWPadnos> you then use a mux2, with its output tied to one of its inputs, an dthe other input connected to stepgen feedback
[15:41:51] <SWPadnos> when the selector selects stepgen feedback, the output will track. when it flips to the other input, it will remain at the last seen value
[15:41:57] <SWPadnos> (since out is fed back to in1)
[15:42:07] <geo01005> I see.
[15:42:12] <geo01005> (I think :) )
[15:42:17] <SWPadnos> heh
[15:42:55] <geo01005> There is still the issue of commanding velocities and positions from CL
[15:43:10] <SWPadnos> yes, you'd need some float work
[15:43:16] <SWPadnos> so it might be easier in a .comp
[15:44:16] <geo01005> I just might make a little "Joint Controller" comp.
[15:45:07] <ilya_> Withing last hour, i've downloaded 220 Kb of 574
[15:46:29] <malem-cnc> Hi, someone ever used optical rotary encoder with step motors?
[15:46:54] <malem-cnc> I want to use theese as an indexer
[15:47:08] <malem-cnc> to detect missed steps
[15:47:15] <SWPadnos> for what purpose?
[15:47:22] <SWPadnos> (detecting missed steps I mean)
[15:47:49] <malem-cnc> safety, and measure precision
[15:48:10] <malem-cnc> I run motion experiments on the machine (on top of cnc duties)
[15:48:18] <SWPadnos> ok
[15:48:46] <SWPadnos> well, you can sense position with an encoder connected to a stepper, but it won't do much good as far as control goes
[15:48:55] <SWPadnos> ie, you can't use PID like you would on a servo
[15:49:17] <geo01005> Can't you do that with velocity mode?
[15:49:34] <malem-cnc> I don't want to improve the control (for now)
[15:49:53] <malem-cnc> I'd only want emc to know the current error
[15:50:52] <malem-cnc> is it complicated to set up (sensing position)
[15:51:31] <SWPadnos> shouldn't be. just connect the encoder to the same interface you use for the step outputs (parport / mesa / whatever)
[15:51:38] <malem-cnc> I have access to renco's 512
[15:52:00] <SWPadnos> geo01005, not really. once a step is missed, the stepper is more or less stalled and you have to slow down (orstop) to get it moving again
[15:52:15] <malem-cnc> okay, to the parport inputs for instance
[15:52:26] <SWPadnos> malem-cnc, as long as the resolution is close to your step size, it shouldn't be a problem
[15:52:50] <SWPadnos> if you're using 10 microstep drives, then a 2000-count (or so) encoder should be fine
[15:53:06] <SWPadnos> if you want much higher resolution, then count speed will be a factor
[15:54:02] <malem-cnc> well, They are 512 counts per rev
[15:54:26] <malem-cnc> and I use 200 steps with 10 uSteps so I'm short
[15:54:28] <skunkworks_> malem-cnc: good thread
http://www.cnczone.com/forums/showthread.php?t=37309
[15:54:29] <SWPadnos> is that 2048 in quadrature?
[15:54:42] <malem-cnc> but, 512 would be precise enough for me
[15:57:30] <malem-cnc> RCML15D4-512/0-1/4+-ME-5-VO/0-6
[15:58:55] <SWPadnos> I'm betting that's 512 cycles, which will be 2048 counts
[15:59:31] <malem-cnc> digging..
[16:00:55] <SWPadnos> http://wwwpdb.renco.com/ansicht/Renco/media/img/RCML15_646770.pdf
[16:01:00] <malem-cnc> found this on ebay :
[16:01:02] <malem-cnc> http://cgi.ebay.com/RENCO-Low-Profile-Encoder-RCML15-512-0_W0QQitemZ200055585379QQcmdZViewItemQQptZLH_DefaultDomain_0?hash=item2e943dfa63&_trksid=p4634.c0.m14.l1262
[16:01:27] <SWPadnos> yep. saw that :)
[16:01:49] <malem-cnc> so its a 512 line count
[16:02:10] <SWPadnos> it's very likely that you will get 2048 transitions per revolution
[16:02:21] <SWPadnos> (count and line are different units, sometimes :) )
[16:02:22] <eric_unterhausen> looks thin
[16:02:31] <SWPadnos> 8.9mm
[16:02:48] <SWPadnos> and only 38.9mm across
[16:02:51] <SWPadnos> it is pretty small
[16:03:23] <malem-cnc> yes its quite thin, it fits on the stepmotor very well
[16:04:02] <malem-cnc> so, I'd need 3 inputs per encoder?
[16:04:14] <malem-cnc> (ABZ)
[16:04:17] <SWPadnos> two is the minimum, three if you want to see index
[16:04:18] <SWPadnos> yes
[16:04:37] <malem-cnc> it's a lot
[16:04:44] <malem-cnc> only 6 per par port
[16:05:08] <SWPadnos> you'll need additional I/O if you want feedback. there's no getting around that
[16:05:10] <malem-cnc> I could sample these with an mcu maybe?
[16:05:34] <SWPadnos> you'll still need to get the data into EMC2 in realtime, which means you'll need to use port pins anyway
[16:05:36] <malem-cnc> and send the data via ttl?
[16:06:35] <malem-cnc> more latency.. but if I only want to synch befor each gcode command (for example)
[16:06:38] <SWPadnos> you will probably want to look at positions 1000 times a second, so you'd need a way of sending all the data from as many encoders as you want in that time
[16:06:48] <SWPadnos> without burning up CPU time waiting for slow I/O instructions
[16:07:03] <SWPadnos> which means you should buy a Mesa card and skip all that :)
[16:07:23] <malem-cnc> what other input interface yo see other that parport
[16:07:28] <malem-cnc> mesa
[16:07:32] <geo01005> Mesa cards are well worth it.
[16:07:51] <SWPadnos> there are several, but if you want to use steppers and encoders, the mesa is the only hardware that will work well
[16:08:25] <jepler> actually, jon elson's (pico systems) setup for servo geckos might be useful in this situation too...
[16:08:31] <SWPadnos> nope
[16:08:33] <jepler> no?
[16:08:40] <SWPadnos> you can only read back one thing from each channel
[16:08:55] <SWPadnos> so you either get the stepgen output position or the encoder feedback position, but not both
[16:10:38] <jepler> with the servo geckos that's more or less the point .. I can see where it might not be what you want in this case
[16:10:46] <SWPadnos> right
[16:10:53] <SWPadnos> it made sense at the time, and for the intended use
[16:11:01] <malem-cnc> browsing for mesa cards
[16:11:12] <malem-cnc> they dont appear to be on ebay
[16:11:16] <SWPadnos> it is annoying though that you can't attach a jog wheel to the unused encoder inputs on a stepper system
[16:11:22] <SWPadnos> go to www.mesanet.com
[16:11:32] <malem-cnc> where to find them cheap?
[16:11:37] <SWPadnos> the parallel-port connected unit is $89, and has 48 I/Os
[16:11:51] <SWPadnos> and it's got FPGA-based stepgen and encoder feedback
[16:11:59] <SWPadnos> I don't know if anyone sells them used
[16:12:33] <geo01005> Why would anyone want to get rid of a Mesa card? :)
[16:12:49] <SWPadnos> only if they have too many I guess
[16:13:16] <skunkworks_> I have 2 - but I will not sell them :)
[16:13:59] <malem-cnc> worried about the interface
[16:14:03] <malem-cnc> PCI is dying...
[16:14:23] <cradek> I have not seen any sign of that
[16:14:48] <SWPadnos> PCI will be around longer than the parallel port, I'm sure
[16:14:57] <geo01005> Mesa will develop cards based on another interface if PCI interfaces ever do become "unavailable"
[16:15:06] <jepler> they have pci-express cards coming out already
[16:15:07] <malem-cnc> 7I43 FPGA based USB/EPP Anything I/O card
[16:15:41] <SWPadnos> that's the one
[16:16:09] <SWPadnos> unless you want the PCI card, which is faster and doesn't depend on a parallel port
[16:16:30] <malem-cnc> this one is usb
[16:16:43] <SWPadnos> no it's not, at least not used with EMC2
[16:16:59] <malem-cnc> I see
[16:17:23] <SWPadnos> ub is inherently "not realtime enough" for us
[16:17:25] <SWPadnos> USB
[16:17:35] <archivist> yet
[16:17:38] <jepler> EPP is parport
[16:18:13] <malem-cnc> yeah I wondered, since it appears to be USB-TTL bridge of some sort
[16:18:17] <malem-cnc> (FTDI)
[16:18:34] <malem-cnc> so even worse latency
[16:19:27] <malem-cnc> the good thing with a parport is that you will always be able to by a parport card
[16:19:36] <malem-cnc> *buy
[16:21:39] <malem-cnc> 200K or 400K gates?
[16:22:06] <SWPadnos> I think either would be fine
[16:22:18] <SWPadnos> if you want to play around later, I'd get the 400k gate one
[16:22:34] <SWPadnos> you can write your own VHDL for them, so they can be interesting toys
[16:22:37] <SWPadnos> (or verilog)
[16:22:57] <malem-cnc> should I drive my geckos from it also, or will it over-stress the parport
[16:23:03] <SWPadnos> uh
[16:23:30] <SWPadnos> the mesa connects to the entire parport, and all data goes through the 48 I/Os on the 7i43
[16:23:56] <SWPadnos> you will need some interface hardware on the machine side, to isolate the FPGA pins
[16:24:03] <SWPadnos> there is no "stress" on the parport
[16:25:01] <malem-cnc> okay, the motion computations are done one the FPGA?
[16:25:16] <jepler> no, just waveform generation
[16:25:22] <SWPadnos> not motion, but all fast-thread stuff like encoder counting and step / PWM generation
[16:25:28] <geo01005> Mesa makes a protection/break out board (7I37TA) but there is no electrical isolation.
[16:25:53] <SWPadnos> the 7i37 is isolated
[16:26:57] <malem-cnc> 16 in 8 out
[16:27:03] <malem-cnc> so I need 2
[16:27:12] <geo01005> oh, sorry I copied and pasted the wrong heading...
[16:27:12] <malem-cnc> (5 axis)
[16:27:14] <geo01005> 7I42TA
[16:30:11] <malem-cnc> Could I plug the outputs in the parport inputs of my G540?
[16:30:34] <malem-cnc> and skip the electrical isolation for these
[16:31:42] <jepler> (there's not a 5 stepgen + 5 encoder firmware for 7i43 .. it would have to be compiled specially)
[16:32:14] <malem-cnc> can the controllers be mixed?
[16:32:36] <malem-cnc> (4 axis parport, 1 axis 7i43)
[16:32:54] <malem-cnc> (2 parport)
[16:35:57] <jepler> yes, you can use one hal_parport and one hm2_7i43 (the name of the hal driver for the 7i43 card)
[16:36:56] <malem-cnc> good, and I could use the 7i43 for the 5axis inputs?
[16:38:01] <jepler> the only pre-built firmwares that have more than 4 encoders have no step generators, so you could do all encoders on 7i43 and all step generators on the second dumb parport
[16:38:36] <jepler> if you want to venture into the world of building fpga firmwares, there are no technical barriers to having 5 encoders + 5 step generators on 7i43; it's just that this isn't provided in precompiled form
[16:39:47] <jepler> but I don't blame you if that doesn't sound like fun
[16:40:25] <malem-cnc> well, I think I have enough free parport outputs for a 5th axis on the 540 (plus a separate g250)
[16:41:00] <malem-cnc> so I could also use the hostmot only for inputs
[16:43:23] <malem-cnc> I'd may adapt the firmwares later on, I did a very little bit of pfga programming long time ago
[16:43:37] <malem-cnc> but for the moment I need indexers
[16:43:55] <jepler> bbl
[16:44:09] <malem-cnc> me too, hungry
[16:44:11] <malem-cnc> thanks
[16:44:19] <jepler> you guessed my motivation
[17:18:14] <DaViruz> hmm odd, the disc in this encoder implies that it's an absolute encoder
[17:18:22] <DaViruz> but the output is A / B / S
[17:19:48] <malem-cnc> the remco?
[17:20:10] <malem-cnc> I think it's because of the index pulse
[17:20:38] <DaViruz> don't think its a remco, it's from a omron servo
[17:20:54] <DaViruz> seems to be like 6 orbits on the discs
[17:21:20] <malem-cnc> sorry, wrong thread
[17:21:28] <malem-cnc> (me)
[17:21:32] <DaViruz> hm, should be 10 orbits since it's a 1024 encoder
[17:33:27] <Larry> Epler has a cool A2D input scheme posted on his blog at:
http://axis.unpy.net/01198594294 I would like to use this technique and map a channel as my feed override. Is there any info out there that shows this configuration? Thanks!
[17:37:57] <skunkworks_> Larry: hello. I cannot help you - but jeff will probably be back in a few..
[17:39:05] <skunkworks_> (jepler)
[17:40:53] <malem-cnc> SWPadnos : I think this
http://pico-systems.com/univstep.html would be a clean solution
[17:44:45] <SWPadnos> no
[17:45:03] <SWPadnos> you can't use the encoders and still find out how many steps the stepgens have generated
[17:45:37] <malem-cnc> well, the board knows
[17:45:46] <SWPadnos> no, it doesn't
[17:45:56] <SWPadnos> that boards stepgens are just frequency generators
[17:45:57] <malem-cnc> and send back the encoder's output
[17:46:03] <SWPadnos> they do not do positioning
[17:46:08] <malem-cnc> so EMC can apply PID
[17:46:46] <malem-cnc> its the purpose of the board, no?
[17:47:42] <SWPadnos> yes, but not driving steppers with encoders
[17:47:50] <SWPadnos> steppers can't be PID-controlled like servos
[17:48:01] <SWPadnos> once they lose position, it's over
[17:48:02] <PCW> DaViruz: The tracks may be A/B/I, HallA.HallB,HallC
[17:48:13] <SWPadnos> a servo can give a little extra juice if needed
[17:48:43] <DaViruz> PCW: i checkd it more closely, it's definitely a 10 track grey code absolute encoder
[17:48:51] <DaViruz> which outputs a, b, index
[17:48:53] <malem-cnc> so what is the use for this board
[17:49:03] <DaViruz> no hall output
[17:49:35] <malem-cnc> higher step frequency?
[17:49:49] <skunkworks_> yes
[17:49:53] <PCW> OK I thought you said 6 tracks, And I've seen 6 track encoder wheels
[17:50:38] <skunkworks_> malem-cnc: pcw is mesa
[17:50:43] <DaViruz> oh, yeah, couldn't get a good look at first and it was a rough estimate
[17:50:49] <DaViruz> *at it
[17:51:17] <PCW> Does the encoder have absolute output as well? Otherwise wouldn't make economic sense
[17:51:55] <DaViruz> it doesn't, not that i can tell anyway
[17:52:11] <DaViruz> 9 pin connector which is a+, a-, b+, b-, s+, s-, 5v, gnd, shield
[17:52:12] <PCW> wierd...
[17:52:14] <DaViruz> yeah
[17:53:16] <PCW> SWPadnos: stepgen does give position (step counts)
[17:55:24] <malem-cnc> SWPadnos: they can't "loose" position, the board make the stepper appears as servos
[17:55:59] <malem-cnc> so emc2 is relying on encoders only
[17:56:12] <malem-cnc> you can use the board without encoders
[17:56:47] <malem-cnc> and THEN you can loose position since the board simulates the encoders out of steps generated
[17:57:07] <malem-cnc> http://pico-systems.com/univstep.html
[17:57:33] <eric_unterhausen> firefox is receiving my typing in strange order, like an arrow key is stuck
[17:57:42] <skunkworks_> you cannot use that board with encoders 'and' steppers
[17:57:43] <malem-cnc> the 7i43 would be much more economical, though
[17:58:17] <PCW> Malem-cnc: The way step motors are used currently is open loop, the closed loop part just guarantees that the step generator
[17:58:19] <PCW> generates the proper number of steps (feedback is from count of steps generated, not motor position)
[17:59:05] <malem-cnc> from the www : This board makes any step/direction drive appear to the computer as a servo system. Even if encoders are not used, the step rate generators provide a simulated encoder signal for the encoder counters to count.
[17:59:48] <DaViruz> i can't see why it wouldn't be possible to hook up real encoders to the pc instead of using the simulated encoder from the board?
[18:00:05] <eric_unterhausen> it's not impossible, start writing
[18:00:27] <PCW> Some user (gtom?) has a system with linear encoders and runs the stepgen in velocity mode for a close loop system
[18:00:29] <PCW> Note that this system can still lose steps and stall, it willl detect this via a FE however
[18:02:41] <malem-cnc> From this page :
[18:02:42] <malem-cnc> http://pico-systems.com/univstep_pins.html
[18:02:47] <malem-cnc> it looks possible
[18:02:58] <DaViruz> sounds like a nice way to get rid of backlash if nothing else
[18:04:12] <DaViruz> but yeah once a stepper looses steps it usually stalls so i suppose rotary feedback wouldn't be of too much use
[18:04:21] <PCW> Its entirely possible to make a full FOC unstallable servo outs of a step motor with encoder feedback
[18:04:23] <PCW> but its requires:
[18:04:24] <PCW> 1. Fast PID loop say 30 KHz or better
[18:04:26] <PCW> 2. Current controlled driver (Step+dir is not what you want)
[18:04:27] <PCW>
[18:05:16] <DaViruz> if you're going to put encoders on something it makes more sense (to me at least) to put them on a dc/ac motor and get a true servo
[18:05:34] <skunkworks_> hear! here!
[18:05:59] <malem-cnc> I can't afford it
[18:06:14] <PCW> A step motor can be a true servo, just 2 phase AC, inefficient, high torque but low speed
[18:06:29] <DaViruz> that being said, i'm very happy with my steppers for xyz and will probably never replace them
[18:08:25] <malem-cnc> so in the end of the day, is it possible to used the feedback from encoder on servo system in some usefull way
[18:08:27] <geo01005> I believe that all the malem-cnc want is to measure the position of the steppers so that detect if there are steps being lost.
[18:09:09] <malem-cnc> yes, and maybe have EMC stop or correct when the offset is too large
[18:09:42] <malem-cnc> the best would be to have EMC "learn" in wich situation it looses steps dans never try that again
[18:10:00] <PCW> Stop is easy the 'correct' part is where the problem lies
[18:10:27] <DaViruz> even stopping would probably be nice
[18:10:30] <malem-cnc> yes, I realize that
[18:10:39] <geo01005> http://www.quicksilvercontrols.com/ <-- this company sells closed loop stepper drivers... might as well go for an AC servo at their prices though.
[18:11:24] <PCW> If a step motor is about to lose a step due to resonance or excessive load, nothnig you can do with step+dir will help
[18:11:39] <malem-cnc> in fact, for my very need, just reporting the true position would be enough, as long as EMC applies the soft limits using it
[18:12:01] <geo01005> PCW could probably whip one up a 2-phase driver/control system for steppers in a few hours ;)
[18:12:09] <malem-cnc> I already have the drivers
[18:12:24] <geo01005> (closed loop)
[18:13:29] <PCW> Its really no different than a 3 phase AC servo drive, just 2 phase and very high drive frequency
[18:15:11] <malem-cnc> PCW: is EMC prepared for such a functionnality (react to a delta between DRO and encoder
[18:17:17] <DaViruz> should be entirely possible to create a system in hal that tracks error between commanded position and encoder feedback and halts machine if it goes out of limit
[18:17:44] <geo01005> that system is already there :)
[18:18:08] <geo01005> the following error is the difference between the commanded position and the feedback postion.
[18:18:13] <PCW> For full servo, no I think it would be a stretch because of the loop rate
[18:18:15] <PCW> for using stepmotors with encoder feedback a high microstep count step+dir driver
[18:18:16] <PCW> in close loop velocity mode: sure, known to work
[18:19:35] <malem-cnc> I have a g540 (g250) driving 200 step/r steppers
[18:19:55] <malem-cnc> and a 512counts encoder with index
[18:20:08] <PCW> for just checking for missed step, should be simple: if abs (step_counts - scaled_encoder_counts) > FEL --> FE
[18:22:14] <PCW> You will have to get the initial offsets fixed and scale factors right but should be easy
[18:23:15] <DaViruz> i'm actually tempted to do this on my own machine now
[18:23:27] <DaViruz> too bad i can't spare the i/o
[18:23:31] <skunkworks_> you can actually set that up now. Instead of using feedback from the stepgen - you use feeback from the encoder. a few have done this. then setting emc's ferrors works
[18:24:08] <malem-cnc> ah, I wondered what these (FERROR) where used for
[18:24:29] <cradek> sure you can use encoders for feedback. you cannot make the machine magically work perfectly even though you ask it to do something it can't - just don't confuse these two things
[18:24:36] <Jymmm> http://www.boston.com/bigpicture/2009/06/recent_scenes_from_the_iss.html
[18:25:24] <skunkworks_> heh
http://www.youtube.com/watch?v=w1_h_LNCJ94
[18:25:26] <malem-cnc> I don't expect the machine to do moves that it could't before
[18:25:28] <cradek> malem-cnc: FERROR is how you tell EMC to stop if the actual machine position deviates too far from the commanded position
[18:26:22] <malem-cnc> great, so I wont have to code anything once I configure the encoders
[18:28:46] <malem-cnc> I may try to code some algorithm so that the control learns how not to miss steps
[18:28:51] <geo01005> hmm, this machine that I have has a new install of the live CD on it and it says:
[18:29:04] <geo01005> bash: comp: command not found.
[18:30:35] <geo01005> I don't remember having to do anything special to get comp to work on my other EMC boxes...
[18:31:11] <DaViruz> what's comp?
[18:31:32] <cradek> component compiler
[18:32:10] <geo01005> http://www.linuxcnc.org/docs/devel/html/hal_comp.html
[18:32:29] <DaViruz> oh.
[18:32:54] <cradek> geo01005: what does dpkg -l emc2 say about which emc2 package you have installed?
[18:34:11] <geo01005> version 1:2.3.3
[18:34:25] <geo01005> I'm not sure what the rest means.
[18:34:50] <cradek> at the beginning of the line does it say in?
[18:35:13] <cradek> or ii?
[18:35:20] <geo01005> II
[18:35:21] <geo01005> ii
[18:36:15] <geo01005> what does that mean?
[18:36:33] <alex_joni> isn't comp part of emc2-dev ?
[18:36:36] <cradek> it means 2.3.3 is installed
[18:36:38] <cradek> ohhhhhh
[18:36:41] <cradek> * cradek points at alex
[18:36:47] <cradek> duh
[18:37:47] <geo01005> oh, I thought that was the point of comp, so that you could install a component without emc2-dev?
[18:38:16] <alex_joni> geo01005: nope
[18:38:26] <alex_joni> emc2-dev is a minimal package which helps you do things like comp
[18:38:36] <alex_joni> it doesn't mean get the full emc2 source + all dependencies to build it
[18:38:44] <geo01005> oh ok.
[18:38:50] <alex_joni> sudo apt-get install emc2-dev
[18:38:54] <alex_joni> and you should be set
[18:39:08] <alex_joni> (it's probably installed by default in the LiveCD, so that might be how you got it)
[18:40:10] <geo01005> why isn't that part of the live install?
[18:40:24] <jepler> and build-essential
[18:40:30] <cradek> I see it's not mentioned here:
http://www.linuxcnc.org/docs/devel/html/hal_comp.html
[18:40:50] <cradek> geo01005: no room for build-essential
[18:41:50] <geo01005> so am I going to need build-essential as well?
[18:41:57] <cradek> yes
[18:42:43] <jepler> 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 have a license accepted under the [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.
[18:42:48] <jepler> * For all types of file, include the standard license block indicated by the license being used.
[18:42:51] <jepler> * For ".c" components, also specify MODULE_LICENSE("...");.
[18:42:51] <jepler> I meant:
http://wiki.linuxcnc.org/cgi-bin/emcinfo.pl?ContributedComponents#How_to_compile_and_install_a_component
[18:42:55] <jepler> * For ".comp" components compatible with EMC2.1 and later, also specify MODULE_LICENSE("...");.
[18:42:58] <jepler> argh
[18:43:01] <jepler> mentions emc2-dev and build-essential
[18:43:38] <jepler> I could have sworn bjt had added a mention of it in the comp docs though :-/
[18:48:41] <geo01005> thanks jelper... One last question.
[18:49:38] <geo01005> when I do sudo comp --install component.comp after I have already installed a component with the same name it will simply replace the old component wit the new one right?
[18:49:59] <alex_joni> it should
[18:50:32] <geo01005> good, that is the only way I know how to test/debug my comp code.
[18:51:03] <Larry> (jepler) Jeff, you have a cool A2D input scheme posted on his blog at:
http://axis.unpy.net/01198594294 I would like to use this technique and map a channel as my feed override. Is there any info out there that shows this configuration? Thanks!
[18:52:32] <cradek> Larry: use an encoder knob for feed override, and it will cooperate with the other feed override controls
[18:56:48] <jepler> if you specifically want to use a pot and adc, then you can hook the analog value to motion.adaptive-feed.
[18:56:52] <jepler> When adaptive feed is enabled with M52 P1, the commanded veloc‐
[18:56:54] <jepler> ity is multiplied by this value. This effect is multiplicative
[18:56:56] <jepler> with the NML-level feed override value and motion.feed-hold.
[19:18:56] <Larry> Thanks -- there is a pot already in the old machine -- so I will look at both solutions, the commport solution may be easier for me in the short term. Thanks again!
[21:26:52] <pjm> btw EMC 2.3.3 is working perfectly here, thanks to all the developers working on it!
[21:44:19] <cradek> yay!
[22:11:01] <geo01005> So say that I have a filter on my machine that needs to be replaced every 200 hours of operation. I would like to have my machine keep track of how long the current filter has been in the machine.
[22:11:32] <SWPadnos> good luck with that :)
[22:11:35] <geo01005> Is there an good way to save the time that the filter has been in the machine when I exit the hal?
[22:11:45] <geo01005> oh that fun huh?
[22:11:50] <SWPadnos> yeah
[22:11:57] <SWPadnos> there are no time functions in HAL
[22:12:16] <geo01005> Well you could have CL count the time for you.
[22:12:23] <bill2or3> you could do a little wrapper shell script to start emc, and have it log the time.
[22:12:23] <SWPadnos> but you could certainly have a program that runs in userspace and writes the time when it's told to exit
[22:12:32] <SWPadnos> he's not using EMC, just HAL
[22:12:40] <SWPadnos> same principle applies though
[22:13:04] <SWPadnos> loadusr timekeeper logfilename
[22:13:20] <SWPadnos> when it runs, it notes the time and reads elapsed from logfilename
[22:13:45] <SWPadnos> when it's told to stop, it saves the (current time - startup time)+previously read running total to the file
[22:13:49] <geo01005> So in the main hal file that I run the last line is the one that waits for the pyvcp window to close.
[22:14:15] <geo01005> I was wondering if I could just have the next line be "save all temp.hal"
[22:14:21] <SWPadnos> the last line would be one that sends some nice signal to your timekeeper
[22:14:37] <SWPadnos> hmmm. maybe
[22:14:52] <geo01005> then if the number of minutes the thing had been on was a hal pin or parameter then it could be saved.
[22:15:02] <SWPadnos> halcmd setp component.initialtime $(cat logfile)
[22:15:15] <SWPadnos> (to read the time at the beginning)
[22:15:34] <SWPadnos> and halcmd -s show pin component.totaltime > logfile
[22:15:38] <SWPadnos> to save it
[22:16:13] <SWPadnos> then all it needs to do is keep track of when its started and stopped, and output (initialtime + $now-starttime) on the totaltime pin
[22:17:08] <geo01005> That would work.
[22:17:39] <SWPadnos> userspace even - doesn't need to be an RT component
[22:17:40] <geo01005> here I am not very savvy with linux, $(cat logfile) does mean a ton to me...
[22:18:08] <geo01005> doesn't
[22:18:32] <geo01005> * geo01005 goes to read about cat
[22:18:38] <SWPadnos> $(...) executes the command inside () and sticks it on the command line for execution
[22:18:54] <SWPadnos> so do backquotes: `ls`
[22:19:19] <geo01005> this is just by the nature of halcmd?
[22:19:22] <SWPadnos> that will put the output of ls in the command to be executed
[22:19:29] <SWPadnos> no, that's a shell thing
[22:19:58] <geo01005> so are most shell thing valid in halcmd?
[22:20:07] <SWPadnos> no, almost none of them are
[22:20:17] <geo01005> or rather halcmd is executed in the shell...
[22:20:29] <SWPadnos> halcmd is executed by the shell
[22:20:46] <SWPadnos> so any substitutions are done by the shell before halcmd gets them
[22:20:54] <geo01005> I see.
[22:20:56] <SWPadnos> in a hal file, that isn't so true
[22:21:18] <geo01005> so that wouldn't work in a hal file ?
[22:21:19] <SWPadnos> so if you do "halcmd -f myfile.hal", that uses halcmd's command parsing
[22:21:22] <SWPadnos> right
[22:21:31] <SWPadnos> there is limited substitution in hal files
[22:22:00] <SWPadnos> but if you run the system with a script (the one that runs "halcmd -f config.hal"), then you can add those two commands to the file
[22:22:09] <SWPadnos> in fact, you can just do the work in the shell in the first place
[22:22:47] <SWPadnos> you can set a variable to the start time, then add the elapsed time to the saved time value
[22:23:13] <SWPadnos> (the shell has a reasonably powerful set of features)
[22:24:34] <geo01005> Sorry I have to reread this a bunch of times before I get it. :)
[22:24:40] <SWPadnos> heh
[22:25:08] <SWPadnos> ok, the date command can output seconds since 1970 (but it will have to be changed over to 64-bit numbers by 2037 or 2038 I think)
[22:25:26] <SWPadnos> date +%s
[22:25:36] <SWPadnos> will print a large number, in seconds
[22:27:25] <geo01005> I see.
[22:27:51] <geo01005> Is there somewhere that shows what halrun does to setup the rt stuff?
[22:28:54] <geo01005> I suppose the source.
[22:29:20] <SWPadnos> yeah. halrun would be a good place to look :)
[22:30:32] <geo01005> I'll have to mull this over... The other thing I was thinking of was using the sampler component... But that doesn't look any easier, and I don't need real time stuff.
[22:38:53] <SWPadnos> sampler won't help with time tracking
[22:39:25] <geo01005> well only if you had a component that was keeping track of time.
[22:40:03] <geo01005> then I would still have to get the initial time back in on start up.
[22:40:50] <geo01005> I may not have read the little bit of doc in the source for the sampler component very well.
[22:42:55] <SWPadnos> try this
http://pastebin.ca/1513005
[22:43:41] <SWPadnos> I may have made some typos - I was transcribing from a one-line "script" on another non-net-connected machine
[22:44:26] <SWPadnos> just run it a few times and see what happens
[22:44:36] <geo01005> Ok, I'll try that.
[22:45:07] <geo01005> But one note, I'm would like to only count the time that a certain pump in the system is on.
[22:45:22] <SWPadnos> well too bad. you can't do that :)
[22:45:38] <SWPadnos> how fast does it cycle?
[22:45:48] <SWPadnos> (once a minute, once a second ...)
[22:45:58] <geo01005> oh it will be one for minutes to hours at a time.
[22:46:16] <SWPadnos> controlled by a HAL pin?
[22:46:21] <geo01005> yeah.
[22:47:18] <SWPadnos> well, that script has the general idea. You'll need to add some complexity to get it to work based on a HAL pin
[22:47:20] <geo01005> in that case a userspace python component or something like that may be the best option.
[22:48:11] <SWPadnos> sure. the thing I cleverly avoided with the script was dealing with signals, which is how programs get stopped
[22:48:51] <SWPadnos> you could have a HAL pin that causes the starttime variable to get set when it goes high, and then write to the file when the pin goes low
[22:49:31] <bill2or3> raise a pin, and use an analog chart recorder. :-)
[22:49:32] <SWPadnos> but you could lose some time if your component stops running while that pin is high (or before it manages to write the file)
[22:49:52] <SWPadnos> big big cap and resistor plus a comparator - just do it analog :)
[22:50:10] <geo01005> that would be fun :)
[22:50:22] <bill2or3> or a electro-mechanical timer, like for a tractor or something.
[22:51:12] <geo01005> SWPadnos, I'm not sure I get what you are saying by "which is how programs get stopped".
[22:51:18] <geo01005> RT delay?
[22:51:21] <SWPadnos> no
[22:52:32] <SWPadnos> I think all HAL/RTAPI programs get sent the "TERM" signal when you exit from halcmd (using halrun)
[22:52:49] <SWPadnos> and if they don't shut down, they get the KILL signal, which kills them whether they like it or not
[22:53:26] <SWPadnos> if you want the program to do something when it exits, you need to catch that signal (and probably INT, maybe others) and do something in the signal handler
[22:54:01] <SWPadnos> google will be your friend for specifics
[22:54:11] <geo01005> I see.