You've missed everyone John.. hi john hi alex If you checkout the Lathe_fork, you'll get al the code with the flags set. ? Guess I need to look into how forks work... read the redbean book just the first 80 pages.. I did not see any comments on g I did not see any comments on G33 on list, any private? Nope mind you.... I did notice Fred Smith (IMservice) announcing threading support for his deskcnc shortly after.. Morning Ray, morning John... hi ray Hi guys. hi Hi Ray - back on dialup again... Right. I'd read back in the history except I don't have one. Have we started any topics this morning? dunno, I just got here I have one tho, if we aren't busy * rayh thinks we should take a few minutes with Yodaiken. that's what I was gonna say ;-) Great minds.... I've been in touch with Ebo, and have a tarball with his changes I already tried. Paul was .... well I'd really like to see a jitter comparison using their methods. My view of the (so called) patent of Yodakin's is well known. Yes and my personal feeling is that he sold out the open community by doing that. However my curiosity is still way up for a comparitive paper. I was more interested in getting anything useful back on the sourceforge and being sure they acknowledge GPL on EMC2. right paul_c: What are the GPL issues if one uses 2 with it? And did considerable damagee to the take upp of linux in the embedded fieldd True enough. Well... If RTLinuxPro is running in kernel space, then the kernel license requirees GPL and on thee use space side, any headers used by emc2 must also be GPL I neither know nor care about how RTLpro deals with the GPL issue or GPL compatable. But if it is a free running mini os like 09j.... RTLfree is GPL compatible.... if they are willing to provide working patches to ./configure, makefiles, and rtl_rtapi.c that meet our specifications, I'm willing to commit those patches I read their recent white papers. While doing that, I remembered our conversations with MAT_PLC and soft real time. the guy doing the work is not currently a FSMlabs employee - he's a consultant John was exactly right about the cost of soft once the PC load goes up any. Right. I sent EBo a bdi a couple of years ago. Need to run soon... any lathe stuff to talk about? he says he's been interested in EMC since 97/98, but never got it completely running... this time somebody paid him to do it ;-) anybody has a picture of a machined Chips? * paul_c has a Chips, and a camera I could get one of a crude example done on a Sherline by Tom Hubin at Iron Fever. Tony at Smithy has a scaled one yet. I think Paul has his first try. has anyone heard of Jam (an alternative to automake) Is the STL model of Chips available anywhere? * paul_c has a copy of that too. Rab probably has whatever the original format is Would be interesting to run that stl through weber and set a bunch of watermarks and a finer resolution. The original format was STL paul: could you mail me a picture? It will take a few days.. Could you email be a copy or a link to the STL. I would like to try generating a higher resolution G-code file for Tom Hubin. rayh: Does Synergy have STL import now ? paul_c: no problem paul_s: the STL would be also appreciated No idea about Synergy. I will be trying it on MeshCAM. I think that it's (stl) in there. * danfalck is back (gone 34:37:11) hi guys Second look, I don't see stl in Synergy. Time is up here. Will stay on line to log.... Bob had the STL and says he can import it... Mornin dan and dave. hi ray hi ray indeed it is morning...just got coffee made same here nice to have dan up bright and early Ah, The west coast stirs I've been lurking for a couple hours on and off... can we talk about this EBo guy a little more? maybe stiring more than sometimes * paul_c would like to take a look at the tarball sometime So, FMS is non-GPL and is trying to tempt us, right? Right. not really FMS produces an open version but it does not keep pace with their PRO stuff. they have patches (need work yet) that will allow emc2 (RTAPI) to work with RTLpro and RTLfree (current versions) In the back of my head is the question, why Pro and the EMCs and why now? But.... Having said that I believe that we must not look the gift horse in the mouth. Looking for new markets ? ray, paul... switch to the board channel please So, correct me if I'm wrong, but we are now using RTAI a GPL real time kernel? Rather we should do all we can to continue to drag them toward EMC. we currently support both RTAI and an older version of RTL and gpl? What worries me, and I suspect both Paul and John is the automake stuff. The automake need not be intrusive EBo David has gone well beyond just making our stuff work with their stuff. YES - BBI-Live-rc60 boots and NO segfaults !! ;}}} he's not using automake yet So I guess our question ought to be how much of thir stuff can we integrate. Doesn't need automake Just needs to generate a realtime & nonrealtime def. Ok. If that is all that we need to add, and there are no residual GPL issues, I'm for it. so just to ask dumb questions...what does this buy us? portability to one of the two competing RTOSes well, actually one of many... is that kernel any more solid? we're not willing to spend time porting to RTL (for sound reasons), but if they're willing to do it, why not accept their work? That question is why I want the comparitive jitter tests using their methods. also, the guy doing the work is not an FSM employee, he's an independent contractor, and has indicated a willingness to work on other aspects paul_c: Congrats on the rc60 build and boot. Need to be carefull with jitter tests from assorted sources.. * paul_c burns rc60 to CD... paul_c: Does this include kde-3.3? is there a download link for rc60? different set ups (even with the same hardware) can give differing results The different test methods is the reason I want it with their own. And I don't care about MonteVista -- just adeos. Don .. how are the compile wars? Nother issue, If I may? yes ray I'd like to talk about Fest 05. good idea Not NAMES again Roland, of Cardinal engineering fame, offered the use of his space -- an old three room school. He's got cnc bridgeports and lathes and manual mills and lathes and water jet and edm stuff all over the place. In Galesburg, Ill? It would be great for an integrators workshop. internet access? There's even room for camping on the playground. No HS internet. dialup only? sounds like a great site for an integrators event, but not for a coding fest Exactly my thoughts. How about two events. A code fest at NIST? any political fallout from that? I'd be game for the integrators event Security might be an issue @ NIST I think that there would be a lot of interest in such a thing. I got a room the last time I was in Galesburg for less than $20 a night. That was a week rate but the room was clean and quiet. Roland's shop is about 5 miles from town. well.. I certainly couldn't turn down an integrator event Okay. Let's concentrate on an int-fest for a minute. When? certainly NOT at the same time as any coding event maybe right after names and after we have a better selection of emc2/hal drivers done Hi Dave...Gave up on the compile wars... so codeing fest comes first Right separate times for each. Just posted the results of the mornings PID wars... 240 in / min +/- .0001 ! On a 30 pound Z axis... any funny stuff going on? No, its been strangely well behaved... that is really good news Reinstalled rc_46, and copied in vital.o and vialmod.o .... Then used my ini from the previous setup and it came right up... Is NAMES in March? For Int-Fest we will need full instructions and processes for EMC2 as well as EMC1. NAMES is last week in April Still angry enough that I threw out the last newsletter. so coding a couple of weeks ahead of NAMES? I m pretty much ready to go onto the motorization of the X and Y, and finish up the control signals work.... All right Ray, I'll meet you in Galesburg this next spring! Fantastic. I like what I see of the concept. Dave, have you played with ModelQ ? not really ... do have it on the desktop sometime in the next 2-3 months we should set dates for both events... so folks can schedule vacation time, etc. Is spring better than Summer for the Int-Fest Try out the position loop model, and some small negative Acceleration FF .... OK With Vel FF ... Summer would be better - driving over the mountains The settling error just goes away.... late spring? Time for the sunday walk here....will leave this on....Back in 2 hours... by don I'm pretty certain that several will have plans to attend NAMES. I don't think we want a head-to head time. What about Int-Fest after the kids are out of school? if we were gonna be at smithy, then immdiately after NAMES would be good at Rolands place, that doesn't matter i suspect that just after names will get more people to the int session hmmm, I guess if you're from the west right after NAMEs is still good So NAMES ends on Sunday and Int-Fest begins on Monday? after school makes it pretty late here... mid june * paul_c has no desire to haul but over to NAMES again. after school has pros and cons... lots of folk take family vacations after school's out Are you interested in an Int-Fest or Code-Fest or both. paul_c can arrive sunday night and skip names completely ditto me? both I'm not interested in NAMES ditto but integrators might be... I'll be at Int-fest as one of the "teachers", the "students" might go to names first Should we pile Code-Fest up close here? hmmm If we are to have another coding week (sic), I don't want to see it turning into another installFest. Fantastic, John. You will be the EMC2 lead man. one view - a few weeks or a month between the two would be nice, but for Paul and anyone else with long travel, putting them close together is better Do the installFest stuff with the integrators paul_c: Right. I think we want coding on it's own. exactly Paul... bar the doors for codefest That is why I was kinda thinking of NIST as the location for Code-Fest. They have plenty of hardware in place. HS internet. Conference rooms. A few motels within easy walking distance of NIST Motel costs are outrageous. and Dulles isn't too far either But there may be a few alternatives. Tents on the lawn ? Yes and any of the shuttles can find their way to NIST. need to make sure that we won't be expected to PD code, and that we won't get them in trouble again I talked with Matt about this possibility. I'll ask him to work out details. There should be no problem with PD v GPl. Will GPL'd his work on the plotter. IMO we need both Paul and John at Code-Fest. Are there advantages/disadvantages that would affect scheduling of the two. and Ray and Roland at intFest I intend to come to both, assuming they are reasonably close... for codefest I want to bring lots of stuff, so I really want it within reasonable driving distance from Cleveland... IntFest I can just bring myself and one PC, can be flying distance if needed Roland did say that one of the NAMES directors said they were sorry for our shabby treatment last year. He didn't say if he was going back. Davenport/Moline is about 40 miles. Chicago is about three or four hours. (2.5 the way I drive) I can drive to NIST (about 6-7 hours I expect) Ann Arbor/Detriot is about 3 hours I've no problem with attending both Fests at this point. sounds like Rolands place is about 10hrs from Cleveland... I can do that if sufficiently motivated (or fly) doesn't make much difference here...anyplace is a long ways...2000 mi or so. do you need to bring machinery/computers, or just yourself? I may bring some stuff for int....either drive or ship. Maybe the west coast guys can car/van pool. I've thought about that Dan is only 3 hours away. dave-e, we could do that two or more drivers would help immensely. I'll have to call the NAMES folk and get a date. intFest will be the week after? the last time I did a 1000 mi/day I was pretty beat I would probably bring a sherline lathe/mill,computer,drive box, tools how far is it from Detroit to Roland's place? I think that Roland said about 6 hours. But there is the South Chicago bottleneck in there as well. so folks who attended NAMES will have a longish drive Sunday evening, some may choose to stay in Detroit and drive Monday morning Roland does it Sunday afternoon/evening but we could start with those there on Monday. yeah see ya later... still lots of work to do on the phase converter wiring. :-) See you dave. the more I think about it, the more I think codefest should be at _least_ a month before intfest bye dave That would work well for me. boss is more receptive to two well separated weeks of vacation than one long vacation (wife is too) Any stuff I've got at NAMES will be either Sherline or Smithy so I don't need to be there. any advantage to starting on sat/sun, for folks who _don't_ attend NAMES? danfalck: Would you be driving on the weekend? ray, it's too early to tell at this point Okay. The question would be if Roland would be around. oops... he'll probably be at NAMES Not certain at all. He was pretty upset. And his Turner control is gone. That is what he had been showing the last couple of years. How is the end of march for the CodeFest. sounds reasonable Then let's get a board vote on this and open the topic to the lists. ok We can firm up the plans as folk respond. what about a code-fest at (for example) Cardiff Uni ? Roland should be home next week from his Canada job so I catch up with him. I need to leave for a bit. I will keep logging/lurking. Talk to you guys later. in addition to on in the US, or instead of? paul_c: Tell me more? * danfalck is away: I'm away See you Dan. * alex_joni is happy, after succesfully setting up a VPN with PopTop alex_joni: You'll have to explain. I just set up a virtual private network (VPN) through an encrypted tunnel, starting from a Windows client to a linux machine running PopTop (a linux implementation of a PPTP server) not emc-related ;) But you could run EMC through that tunnel? hmmm... anything is possible With a gui on the MS machine? I could run a win-gui with a emc on the other end, yes however... it's pretty slow I'm on a dial-up link right now (win-side) So e-stop might be to late! file transfer is around 4-5 kB/sec. through the tunnel so... no real-time ;) EMC has a remote GUI option We did a similar thing at NAMES a couple years ago. I have a win-package I found somewhere, but I never got to test it out that isn't too demanding on bandwidth gotta try that... first on local network ;) * paul_c ran a remote GUI on a Sherline in SoCal while in England ... to be more precise, an ssh session with emcstick. What kind of delays did you experience. hmmm. the bdi page at linuxcnc.org is a little out of date well... in ssh it always repaints the whole screen The delays weren't too bad.. on 100 MBit? eth? nah... really weird... http://sherline.com/ is coming up as an unregistered domain?! probably only getting 25-30K really weird. I tried to access sherline a couple of days ago, it didn't work at all looks like they might have lost their domain name registration www.sherline.com is coming up OK here I get "future home of a Dotster registered domain" Must have hit a cached page on a poxy server * asdfqwega is getting Dotster as well ping www.sherline.com results in: 64 bytes from redirectf.dnsix.com (66.150.161.135): icmp_seq=0 ttl=246 time=95.500 msec hey tbl, wake up! ;-) Thanks for the fest discussion. I need to spend some time with fam. ok, bye ray www.sherline.com gets redirected to http://apps5.oingo.com/apps/domainpark/domainpark.cgi?s=www.sherline.com&cid=dots5698 damit - I wanted to talk about Boot screen help menus for this Live CD paul_c: anything I could help? Not really :( ;) Much of it was geared towards a specific end user I see.. However... There is still the package selections for the nextrelease can you be a little bit more specific? everything needed to compile emc2 (gtk-devel, etc) Currently @ 212Mb, so have loads of space left. hi ebo That name looks familiar.. * jmkasunich is writing a reply to your email Hello. Cannot stay long but got things set up with IRC jmkasunich: The case for NOT putting the compile tools in... humm... missed thre reference to " case for NOT putting the compile tools in... " Explaining to XXX why you have to use the tweaked rcslib... talking about packages for the latest BDI Live ahhh... Um...if this Morphix based, you could simply have the compile tools available as a minimod, which the end user could 'morph' in did not know of the Morphix based code. Hmmm... If the end user can cope with morphing, they don't need BDI Morphix is a Knoppix type distro based on Debian Not really...morphing Morphix is pretty easy. I was looking seriously at a live cd based on DSL (damn small linux) paul_c: I was referring to emc2 compile stuff... emc2 itself won't be there, but hopefully someone could do a HD install of BDI-Live, do a cvs checkout, ./configure, make, and have an emc2 DSL is also a spinn off of Knoppix which is derived from Knoppix is that a question or comment? comment you beat me to it... Ahh... yes. I think they both are. sorry I am comming in late. What about the emc2 compile stuff ? paul asked what additional packages should be on the BDI trouble is, once you start adding one set of tools, the extra libs that seem to be required just grows... ahhh... I wanted to make sure that emc2 could be built using it as long as you use gcc-2.95, it will. currently it needs gcc, cvs, and an RTOS... it wants (but doesn't really need) GTK and GTK-dev and tcl-devel grep, sed, & awk less, cut, & find I commented to jmkasunich in a private email outlying a couple of ideas concerning using Jam (a cross platform replacement of make, autoconf, and something else). Comes in ANSI-C source and supported by the ANSI-C++ standards comittee thought jam was just a make replacement you can check it out at Boost.org To be honest, there isn't that much in the emc code that warrants autotools arent things like less, cut, find, sed, pretty much standard? basically it is, but deals with some of the configuration issues in a more graceful way. So depending on what all you need to do concerning automake/autoconf then your good yup One issue not discussed regarding less, cut, find, sed... is what platforms they reside on. *NIX yes, but are they on old Win* boxes? EBo, I was a little unclear when I said we wanted to go to autotools... we have discussed it, but no positive decision has been made... at one time Paul was a proponent, maybe not anymore emc2 is Linux only ahhh... extreme portability, to systems that really don't support RT well, was just making things messy questionable about the "extreme portability" but portability to different distros/versions of Linux, and different RTOSes, is important As a note, when I hacked together the stuff that is starting to make the rounds (and I chose to use the autotools) it was on my own and not discussed with anyone beforehand. I was specifically asked by the client not to "anounce" it untill ready. Windows CE? yuck... that's extreme, IMO WinXPEmbedded I didn't see autotools stuff in the emc2 tarball you sent me... am I blind, or did you use autotools for emc1 only? * paul_c ops pc_op ready to kick/ban alex_joni ;] Oh... I ment the emc1 tarball. Sorry bout that. I stuck with you configuration for emc2 sofar. it was a joke :) EBo: please /msg me (my client can't msg you, upper case letters hurt it) ummm... I's still learnign this interface. Let me post out and tweak some stuff... should be able to just type /msg jmkasunich and hit enter should be able to just type /msg jmkasunich and hit enter oh, never mind ;-) Sorry about the upper case thing... I did not know. jmk: what was that url for the docu, where you got chips? not a problem - I think it's a limitation of my client anyway http://home.att.net/~jmkasunich/EMC_Docs/EMC_Home.htm that was my attempt at documenting the structure of emc1, before I started on emc2 at the bottom of the page is a link to Rab's site If possible, I would like to ask some questions and make comments on a couple of issues. If I am on the same page with you concerning directions then maybe whatever work I end up doing would be generally useful I hope so ;-) ask away Ok... it was just mentioned that EMC2 is Linux only. Are there any plans of supporting any other RTOSS? I don't know. the problem is with RTOS'es Also, what interfaces are you planning to support longterm (Tcl/Tk, X, ncurses, etc.) The RTOS would have to fit into the RTAPI model, using kernel modules for RT code, etc there are a LOT out there, but most are not open-source or freely available and most have a complete different structure emc2 is GPL, not public domain, so we are primarily interested in GPL compatible platforms ahhh... I was just about to ask that ;-) Wasn't EMC1 public domain? as far as user interfaces... Ray Henry has written much of the existing GUI code, and he uses Tck/Tk ok on the I used GTK for some GUI stuff I did (halmeter, halscope) ok. Apart from the RTAI/RTLinux calls, most of the low level code is pretty generic C yes emc1 was (mostly) PD, because it was originally done by the US govt ok. So EMC2 is non govt sponsored? yep okems... Paul and I are the two main contributers to date good to know. As a note, when I was unable to get EMC working years ago I ended up rolling my own, but it used a fundamentially different approach some of it is directly from emc1, some is from emc1 with significant changes, and some is a total rewrite I worked the problem from the geometry ad forward from there. What is the easiest way to directly interface into EMC2 (via a API) for adaptive control? (ie. I have to change the motion profile in realtime) at what level to you want to modify it? changing the g-code? or making minor trims to a single axis? or somewhere in between? beyond. My original problem is best described in terms of 3D splines. I then have to modify them based on feedback on the shop floor. It would depend on the speed of the adaption.. and how realtime? the g-code interp reads ahead and queues up to a couple hundred moves, so modifying at the g-code level isn't very responsive the dt changes are relatively minor (lets bound it by +/-10% but 2% is more likely) ebo: I take it you are talking about countering flex & cutter deflections ? do you actually want to change the path, or just the speed? change path. cause feedrate override can let you modify the speed what did you mean by dt then? using dt was likely a mistake on my part. I ment that the tangent could be varried by a few percent. and caching the g-codes are not going to work. I basicall chache the expected tragectories and modify them on the side let me see if I understand ahh.. thanks for the comment on thre red and attention. you have a g-code file the describes a "nominal" path? yes and you want to make "minor" deviations from that path? or I should say something that is g-code equiv yes on the minor deviations could you express the deviations as a vector? Xtrim = Xdesired - Xnominal, etc To compensate for things like tool wear ? yes on the vector more complicated than too wear here is a made up example... It wouldn't be too hard to add a vector to the outputs of the emc core before they're sent to the motor control code Picture whating to engrave an image on a non-flat serface and then having to control the depth of the cut based on some feedback of the surface (laserscan, touch-probe, 3d optical photogrametry type thing). similar to torch height control for plasma cutters The problem for me is the automation. I already have everything else working. (something we've discussed in the past - it's based on plasma current) That would be a fairly low speed thing, so could be done at the traj level.. ahhh.. exactly! plazma cutting yes. but picture an ingraver or other tool clicking away at 0.5 to 3M/sec paul would probably differ, but I'd do it with a HAL module that adds the trim vector to the emc outputs before they go to the servo PID loops that would work at the servo rate, 1KHz or more 3m/sec - 180metres/min ?? ziiiinnnnnnng! hmmm... that would likely work for me. as for the 3m/sec - 180metres/min ?? thing. Yes. I cannot currently afford those movement, but the state of the art is 6M/sec and 3G acceleration can't tell us what you are cutting, can you ;-) laser cutting ? voice coil stat of the art is 300G acceleration re cutting ;-) not cutting but another project that is similar. I am working on a defensive pattent (ie so someone cannot come along and tell me that I cannot do muy thing without paying them a royalty for their pattent). So, I'll keep somewhat circumspect about the specifics ;-) for now that is ;-))) patents... now that is a bad word in this forum you know I feel that way to. your initial post went over like a lead ballone balloon But the sad state of the matter is that I have an industrial process that I need to shove stuff through. what intitial post? Did you know M$ has patented virtual multiple desktops ? to the developers (or was it users) list oh... you mean about gentoo, rtl-free, and rtl-pro yeah rtl pro in particular sorry to wast my time here then oh rtl-pro he wants to pay me to port emc as an example. Since I have a professional business arangment with FSM Labs, I will keep my opinion to myself concerning the RT pattent. All I will say is that I am surprised knowing what I do that it stands. regarding my own work, I have no intention of pattening the wheel, the combover, clicking on a hyperlink, etc. * paul_c keeps quiet about some of the history behind FSMLabs a defensive pattent is making sure that I have legal right to use my own work. putting it in the PD would establish prior art and make it unpatentable by anyone else ;-) I have been watching the rtlinux debate for several years... not regarding a process. oh... I am not talking about software here but an industrial process IANAL (thank god!) IANAL? do not know that acronym I Am Not A Lawyer usually a disclaimer when someone is giving advice neither am I ;-) ;-)))) My favorite is TANJ meaning? There Ain't No Justice There Ain't No Justice 8-) yep Now I have a an unbelivably honest (and possibly rude) question to ask. shoot Because I hade done paid work for FSM labs, am I to be painted with the same brush? I don't think so Even mr Yodakin would be allowed in here... ok. This is what I can offer. I will give back to the community what I can when I can. That is what I see as the heart of open source. I for one want RTAPI to support as many RTOSes as practical, including RTL-Pro but I won't work on the RTL-Pro port (except for minor tweaks) linux-based? or RTOSes in general? If Dr. Y wants to contribute the port, I will gratefully accept. in general, I think, as long as they aren't so different that everything needs restructured or filled with tons of #ifdefs RTAPI was an attempt to get away from #ifdefs I will have to ask him of course, but it is my understanding that it is to be released back in the public domain. btw, when I said I, I meant I.. official actions by emc are decided by the board Probably the better solution would be to set up different RTAPI implementaions for rtl_pro_... rtl_pro_rtapi.c? yep, and and rtl_pro_elapi.c, same thing for rtl_free_* rtai_* new_fangled_rtos_* ;-) as long as a new RTOS follows the standard API (rtapi_start_thread, etc.) does this work for you? where it really gets messy is the configure script and makefiles yep. yes, for the C and H stuff that is exactly what I had in mindf I have some ideas for that BTW (meaning config, makefiles, etc) the other problem is testing on non Linux systems there comes a point that you have to have the hardware to test anything. right - as long as that hardware looks like a PC, it isn't too hard I have an eight slot retired server here, presently has the three main BDIs on it with a little organization many of these issues can be sidestepped. I would take my que from Boost I am actuall interested in looking at putting this on one of the new X... heck what is the name of that fancy embedded processor... Xscale from Intel ? ahhh yes. thanks! or whatabout the GameBoy Advanced ? lol MillBoy there is a new env. hardened PDA that can be dumped in water up to 1m for minuites and 3 M for seconds, droped 2M on concrete and survive... Oh Boy Oh Boy... we just bought a 20K infrared camera at work, it uses a PDA as the user interface nothing realtime tho (not hard realtime anyway) I see no reason not to allow people to support a gameboy. Personally I think it is a great idea. I've wanted to reprogram a gigapet for a dataloger for YEARS! the run script for that one will be "interesting" to say the least something like a 500MHz Arm core isn't it ? which millboy? hmmm... the Mariobrothers in the machine shop! gameboy running emc ;-) donky con on the with the plazma torch! well.... There is a Linux port for the arm chip http://gbdk.sourceforge.net/ I've got someplace that has about 20 IBM thinclients with 403GCX PPC I'd love to convert those things...but that's practically BIOS work so, how difficult would it be to get one of the RTOS's running on the gameboy ;-) realistically watch those PowerPC chips - some don't have a MMU paul_c: These use EDO SIMMs Realistically... There are GNU tools for Arm chips, an RTAI patch exists... Much of it would depend on how long you wanted to be tied up in low level code hacking how do they do things like loading kernel modules, etc from disk? flash based but it has a filesystem on it yafs or affs flash chips/cards It might be easier just to use an X-box :P my embedded experience is with smaller things... to me if it has a filesystem, it isn't embedded, it's a PC ;-) a microcontroller with 2MB flash is embedded even if flash is accessed with a fs how about breaking up the code for distributed single axis machines (I remember seeing a tiny RTOS for 8-bit micros around...) yes I know... just not what I'm used to even a uC-linux the stuff we do at work doesn't have an OS at all linux running on micro-controllers sometimes OS implies a lot more power on, 1 second for self tests, then it's ready to go linux with suspend to disk ... ready to go in 10-15 seconds ;) disk, what's a disk? hard-disk VFDs don't have hard disks http://www.balloonboard.org/ sorry... missed that part we've digressed quite a bit ;-) strongarm...:) how about SRAM with battery? is that a hint to get us back in line or a to bring us back to micro's ie strongarm politics ;-) paul_c: Ooo, that'd be nice to play with but slow 500MHz is slow? 206MHz does ARM have hardware floating point I can run emc2 on a 200MHz Pentium 500 is definately not slow hmmm... could be... the VFDs we do at work use 20-40MHz processors (some 32 bit thing from Hitachi, no MMU or FPU) never tried StrongArm (I don't do coding for the VFDs, I do the power electronics side) Too much to know, too much too learn - I'll stick with x86 platforms for now, thanx my thoughts exactly... too many projects, too little time Although I have some PIC's I've been wanting to use EMC on a PIC - now there's a challenge! anything... just anything... but PIC Urgh...need a really good shoehorn for that I'm never gonna touch a PIC again ;) I don't wanna know...everybody has their preferences ebo: to get back on topic... as I mentioned in an email, your changes to the emc2 configure script broke it on RTAI and older RTL boxes... we need to come up with something that works for both before we can import it into emc CVS the last thing I did with a PIC was to run it at 50 Hz do you have the time/inclination to do any of that now? I can test on other platforms, IRC debugging kinda... jmkasunich: Wackit into a branch jmkasunich: to get back on topic ;-) As mentioned, I had throwned together stuff to work on rtl-free and -pro and this is the first pass. I would be glad to work with you to get it working on all platforms. is Victor gonna keep paying you, or will he consider the first pass the end of the job? we will see... the real issues is this is a demo to be give out and does not directly make him money. I do not expect him to pay for things that does not help in some way how hard is it to set up an RTL-Free box given a virgin hard disk? On the other hand, it does make for a nice demo well now. RTL-Free and a virgin hard disk. That is the reason I have been hacking a gentoo version ;-) gentoo does not have an easy initial install, but once it is set up the kernel build is straight forward. is RTL-Free and Pro a set of patches to Linux like the old stuff, or more of a distro in itself? I am working with a beta tester in germany right now to work out the kinks... RTL-Free is basically a patch and module set that you are used to. -Pro is a full development kit. so installing -Pro onto a virgin disk is much like installing any other distro? or do you still need to have a working Linux system first? the stuff I am setting up for gentoo is to automate the build and install. RTL-Free has been pretty stagnent for a while now ? The pro side I believe so. yes. yes (regarding rtl-free) actually, there is a U. in Itally that has supossidly take over maintance. not sure what all they are up to. Have you messed with Debian at all ? a little. the kernel build is quite painless not fr some time. agreed. gentoo is the same. want an RT kernel ? 2.4.27 with all the trimmings.. huh? what do you mean by want an RT kernel rtai? patched and ready to rock Paul: I'd be able to use that in a Morphix install, right? If so, where do I sign up? errr... yes sure. but I my work with RTL-Pro is to pay the bills. unfortunately that is an issue too 8-/ actually any kernel build is pretty painless... It's the figuring out what went wrong when the system goes tits up that is the painfull bit... the nice thing I like about portage (gentoo) is that it automates the patching process too (I think apget does the same) I have something like 200 patches to the base 2.4.19 kernel and rtl-free sources Plenty of scope for problems then... hahahaha.... ummm... yep! Hey guys - I'm going to have to take a break.. the nice thing about so many patches (assuming that was your comment) is that I can base my work on cononical sets and manage the patch lists within the ebuild specification. Food calls. Out of curiosity who is Imperator? First time I misread it as Imperiotor (a roman general) ;-) ...and the food is saying "Eat me!"... but does the tummy say YuM got to catch & burn it first Imperator is in germany * asdfqwega unwraps a Yuk-E Ration pack "Plenty of scope for problems" was more a comment on finding failed hunks that have to be applied by hand. Imperator is a roman general out of 200 patches, there mut be some... at least in german that is... Ahhh... yes. but I have to only solve it once for you. re: roman generals ;-) yep anyway.. Food. I come from the school of the spelling impaired (sp? ;-))) back to interfaces... if a machine .ini files is specificd in a ~/.emc2_config, we can then install a single interface for all configurations another bit is that the configs can be installed in a default location (.../shar/emc2/...) and then be queried from a popup list I personally don't like hidden files... (but then I also prefer the command line) the current way to run emc2 is 'scripts/emc.run configs/.ini' from the emc2 directory I was refering to the GUI. From the command line it could like like "emc -config sherline my.cnc" of course an icon can be defined that does that the problem I have with the current code is that it is not istalled in a conventional location by default. This is playing hell with the gentoo build emc1 or 2? both actually. emc1 I can't speak for... don't use it, don't work on it fair nuf' what would you like to have happen on emc2? emc2 is still in development... "make install" does nothing, I always run it from within my working copu copy what I am trying to do is set up the build scripts so that it will install. That is the default gentoo build behaviour. eventually "make install" should put things in the "proper" places, such places being determined by someone more familiar with the linux file structure than me SO, root builds and installs, then the users us it ok. you need to be root (or sudo) to run it, since running entails loading the RT kernel modules I am comfortable stuffing things in locations. at the moment yes, but there are some tricks that can get around having to be root alot of emc1 users simply log in as root... some even have no root passwd, since machine controllers are often not connected to the internet These entail setUID on the exe (which is dangerous) I want emc2 to be more secure... and loading the modules at boot. one complication... there is no "the exe" in emc agreed agreed on the security the non exe in emc... well there are several. The only part that likely needs to have root privelege is module load/unload. GUI and the interpreter are both user space exe's, then there is the rtos modules, the rtapi lib, the hal lib, driver modules, and the core motion controller module The problem with loading modules at boot is that the module parameters are passed in at load. oops, and I forgot the io controller loading modules at boot also implies that you have to reboot to reload them... my thinking along security lines... yes, but do any of them require parameterization that must be configured specifically for a machine without opreori knowledge? all modules and the run script are owned by root, and read only no, you do not have to reboot to relod them. You do have to be root to do so though. sudo is used to allow the "machine operator" to run only the run script as root fair enough on the sudo. But there are other possibilities too. yep, far more than I understand... I've only been doing Linux for a couple years my thought about loading at boot are of course affected by the fact that I'm doing a lot of testing I load and unload all the time here is an idea for you... most daemons have start/stop scripts that are run at init. Later you can run the script and stop or even reload. we did exactly that to load the realtime core... RTOS modules, RTAPI lib, and HAL lib Why do you load and reload all the time. is it strictly necessary? part of developmentt? (Paul's idea, and an execllent one) testing - run emc, find a bug, stop it, modify code, make, run again ahhh... agreed. but I am also looking for the end user ease, not just development ease. Both need to be addressed and have fundamentally different criteria right about that So, the issue as I see it is 1) the process should be seamless to the end user 2) sould be painless to the developer take a look at emc2/scripts/realtime for an init style script that loads the RTOS yes about 1 and 2 3) secure yes one moment. I am more familiar with the emc1 code... I will check the emc2 code... one moment.. more familiar with emc1... that's your problem ;-) ;-) emc2 is really a fresh start, especially as regards build system and interfacing with the RTOS ahh... realtime appears to be a conventional start script. Looks a bit different than I am acustomed to but close enough to be the same.. so, if this is the case, realtime can be run by root to restart the modules at any time. we used to have load_realtime_base, and unload_realtime_base, like emc1, but this is much better. Paul's idea well it only does the core stuff... not the emc2 modules emc2/scripts/emc.run calls realtime to load the core, then loads the rest (rt modules and user programs), and also cleans up when the GUI exits) emc.run is getting messy... I started it by copying the emc1 run script, and there's lots of commented out stuff that needs to be deleted I like Paul's take on it. Much cleaner. is there any reason that the emc modules cannot be loaded at boot time? the goal when adding RTL-Pro should be to use the same realtime script... rtapi.conf should be generated when you run ,./configure, and contain any info the realtime script needs to load the RTOS modules (like a list of modules) emc.run also need to address an issue with hardcoded names (like /sbin/insmod...) no reason not to load at boot, realtime could be copied to the rc.d/ directory tree when you do make install the script does use INSMOD agreed on the changes to emc.run and loading the realtime daemon. script uses $INSMOD, but currently only looks at /sbin/insmod to set the variable... I suppose something like "find -name insmod" would be better? ahh... now I remember why I hacked in some changes to the emc.run script. what I did in emc1 was to set up the equivelent of emc.run.ini and then did whatever I did in the build script to sort it out and simpy set INSMOD to something reasoable once... doing a find... is great as long as you do not have 200GB disk 8-0 yeah, and also a security hole... user puts a trojan insmod somewhere where find find's it and the script runs it as root Also, I have 4 different EMC/RT configurations on my machine... I have to know which tools are used to manage each particular configuration. perhaps $INSMOD should be in rtapi.conf? re: security hole... there is *that* too. re: $INSMOD in rtapi.conf. That would likely be fine. * jmkasunich has a duh moment now regarding the name emc.run... might I suggest just emc or possibly emc2? emc.run is what it was called in emc1... I have no idea what the reasoning is behind that I'd want to ask before changing it (I'm a relative newbie to emc, compared to Paul, Ray, Matt, and others) but emc or emc2 makes sense to me that boils down to a lot of personal preferences (naming conventions), but typically extensions imply things (.sh is shell, .exe is dos executables, .conf configurations...) yeah anyway, one of my goals woulf be to set up a standard distrobution of EMC2 that did not require root privledge there are a number of places where the decision is between confusing folks who are familiar with emc1, and confusing folks who are familiar with the *nix way of doing things... short question: are there multi-binaries rpm's for linux? I have no idea ;-) I learned that MAC's have smthg like this. are there any EMC rpms at all? install a rpm, and it copies the right binaries for your kernel+RT I think for emc1 there might be... but binary RPMs only work with the RTOS for which they were compiled the plan for emc2 is source distribution only srpm ./configure can then deal with RTOS variations by putting info into rtapi.conf hi Imperator_ Hi alex Hi all source *only* or just for now? I was surfing the other day and found a emc driver for a Siemens Evosoft ISA board interested? only, unless someone other than me wants to tackle the job interested in what? alex_joni: only if you're giving out free boards to go along with the driver ;-) sorry... never had one :( but I know Imperator has some of these jmk: I thought about porting the STG driver to emc2, but somebody will have to test it as it's written alex_joni: on the page of Henry ?? yup John: i wanted to buy a big parcel of this cards, nearly for less but i was testing to long, now someone other has the 120 cards. that would be a perfect solution for emc users I want (need) to get busy writing HAL drivers for other cards - STG, etc... but ..... but the first step is to establish some "standards", such as "digital inputs should present both direct and inverted signals to the hal", things like that and direction as param i can also help for encoders, index pulse handling is a thorny issue... that's why I've been avoiding those drivers know what you meen there is another thing... direction for I/O one time only? at insmod? or changeable? that depends on the hardware Alex right now, hal drivers can only export pins at insmod time so you have to know the mix of inputs and outputs when you insmod the driver Oh... that reminds me... I am havinf a problem (bug) with emc2 where every time I swith pin 8, pin 10 toggles with it. Anyone else seen this? pins on parport? yes (assuming me) 8 is an output, 10 is an input you're saying that the input always tracks the output? yes bizzarre... never saw that sure there isn't a short in the parport cable? (easy enough to test - remove the cable) john i think that it is not necessary to export pins also during operation. I think on the discussion some weeks ago, that makes everything to complex and the advantage is too little I will need to rebuild and test EMC2 to make sure that I have my discription correct. I will test the cable as soon as rebuild complete ok. please forward any bug reports to me (btw, ebo, are you aware of our various inet resources? Sourceforge project, linuxcnc.org, etc? you can submit bug reports at the SF project if you wish linuxcnc.org has general news, links to list archives, IRC meeting minutes, board info, etc back to driver pin direction config I was only marginally aware of the inet resources... it would be nice if that could be changed after the driver is loaded regarding setting the direction of pins once loaded, these are the issues that need to be addressed in order to load external at boot (if possible) yes it would be nice to have a general "re_init" function for modules. wat is the advantadge ?? i think it is only useable if you have hardware that is configureable ebo would like to be able to load all the realtime modules at boot time (since the boot code runs as root) then a normal user could run emc ok this would solve also problems discussed last week? or was it two weeks ago the entire HAL is due for a refactoring... this is only one issue registering more joints than neccessary I think the poit is that some hardware is configurable. Also, you may have more than one machie that can be hooked up to the same interface. If I wanted to try different interfaces then this would salve the problem e.g. I'm running 2 axes not 8 right alex... currently the motion module assumes 8, if you wanted to do otherwise, it would need to be told at insmod time would be nice if it could be told later, and could "unregister" unneeded pins and params I'm looking at trying to run a 4 head machine (on two carages) le me see... that makes something like 10 interdependant? wow but what has to be changed to implement this ?? is that a big deal ? you mean a reload? Imperator_: yes, it's a big deal I mean re_init? no to implement this in EMC what is "this"? not very big deal... only rewrite a LOT of code if you mean specifying the number of axis to export at insmod time, not too hard the ability to change pins at run time and so on if you mean being to un-export or export things after insmod time, a LOT of work well.. if you remember I tried that... but I just got from a problem to another specify the number of axes i think giving some parameters more at insmod time would be very good alex - I didn't mean it was trivial, just not as hard as making things changable after insmod something got messed with NML I am not sure myself. The int stuff is all in place. One thing that would possibly allow this is to register the modules internally and call their initialization routine whenever they need to be reparameterized. I know... i think changing something during operation is not the big advantage do you mean in the middle of running a machine? possibly well it helps you in some ways first... you can have all modules pretty similar yes ebo, something like that... but I've never done that before.... I have to read the linux device drivers book some more but that is exactly what I want to do with the HAL refactor I don't expect you would change things while _running_ the machine but you might load modules first, then configure them rather than having to specify part of the config when you load as a note, if the reinit is done in a controlled manner it solves the problem requiring the wrapper in the install mod... hm the next thing is security. I feel not so happy that it possible to unload modules at runtime ore change the pins and so on. Ok that makes something easyer. depends on who cand do that I don't think a user can unload a module loaded by root ebo: how familiar are you with the concepts of the HAL? Pins, parameters, etc... do you know what we are talking about? the problem I see with the int done post load is that some of the data and parameters are interdependant with other modules. In specific the base period and some other stuff. (maybe I am thinking of EMC1 again) emc2 uses HAL threads to schedule the realtime code (hal threads map to RTOS tasks) alex_joni: users can't unload modules, but as it stands, users _can_ use halcmd to unlink pins, change functions and threads, etc re: HAL. I thnk so. I have spent most of my time hacking on EMC1, and maybe ... just a sec. I am goint to look at the conde and make sure I have my details streaght. not something you'de want to read right now while online, but take a look at HAL_Introduction.pdf, if you haven't already the problem is Alex if someone configures EMC for a new machine he is root. And then he disconnects a pin and he doesen't remember that the machine is still switched on !!! then maybe everything chrashs !!! For example the machine i want to build, there you don't have time to press the estop button, because the chrash will happen before you can react one possibility I was considering for that... once you do "halcmd start", config changes would be prohibited until you do "halcmd stop" the problem with that is that there are perfectly legitimate things you might want to change on the fly I just did. What I was refering to was the wrapper function in rtl_rtapi.c. When hal_start_threads spawns the specif thread it is wrapped by rtapi because of a weird problem of when the actual code is spawned... This caused me headaches so i think the security options in EMc have also to protect the root himself maybe when halcmd start only changing of parameters is ok Imperator... IMHO, root should have very few restrictions on what he can do ebo: ok, you are talking about RTAPI internals, something that needs to be fixed for RTL-Pro/Free... Alex and Imp are talking about higher level behavior jep john but we have also to think on reestrict him. because when EMC getts bigger it will maybe control expensive hardware !!!!! but root... is root right he's supposed to do a dd if=/dev/null of=/dev/mem I must agree with jmkasunich, but Imperator_ raises a vaild point. That is when reconfigs are actually done. How about a "comit" also unloading modules should not be possible if eMC is in run mode after all, disconnecting a software "wire" is no better or worse than disconnecing a hardware wire sorry... not to do, but be able to do ;) have to be carefull here... Halscope and halmeter are both modules, but they can (and should) be loaded/unloaded while the machine is running yes ... but not using halcmd... right? jep Alex but there are also some people how think on to change this in linux. I think the way that windows treat the Administrator is also not too bad. He can do everything but something not directly regarding low level rtapi stuff... my initial comment had to do with solving the general problem also provides a solution to that specific problem. since most hal config is done by halcmd, it can check if it is running as root... if not, it might put more limits on what can be done ebo: sorry, I'm not following you re: Halscope and halmeter modules loaded/unloaded... or do they simply have to be restarted (which can be done wihtout being loaded) actually halmeter is a user space HAL module maybe limiting the whole thing to real-time modules halscope has two modules, the RT module that acquires data, and the GUI module that displays it user space modules can/should be started/stopped with no restriction... ? jmkasunich: sorry for not being clear ;-) just a sec. I am a watch-my-fingers typest and have missed to much.. I need to go back and catch up the distinction isn't really between rt and user modules maybe modules need a "critical" flag... if set, they can't be modifed while running you can have critical user modules (like the G-code interp) and non-critical rt ones (like halscope_rt) that's right... maybe the flag could come up in modinfo too we have to do the same what you do if you design a safe system actually when I do the rafactor, I'm considering using /proc entries to report info about loaded HAL modules you have to write down everything what can happen, and if it is critical ore not like /proc/realtime/hal/x ? I was just thinking /proc/hal/x, but yes, something like that for example what happens if you remove the g-code interp. does the mashine chrash ?? ore not interp was a bad example how about the I/O controller... currently that is in userspace, but it is responsible for handling estop you have to do it with everything john jmkasunich: I lost myself at this point so my appologies for lossing you ;-) it is a little fast and furious right now yep no wonder I never get any coding done on sundays 8-) (at least until the EU folks go to sleep) re: I/O controller / proc / etc. (Imp and alex are both in the EU, and Paul is in the UK) you have to make a Table with the folowing rows: Action Mashine goes in critical status mashine goes in safe status I'm still hoping to get into EU :)) well you're over the ocean from me anyway ;-) I'm sitting in Socorro (New Mexico -- southwest US -- home of the baloon festival which is currently on) it's still europe here... ;) but not EU pacific time or mountain time? me? mountain remindes me of being corrected when I was working s. England and called it the UK re: safe machine modes? What definds the boundry between safe/unsafe? a big three pole disconnect on the wall, IMHO with a lock on it Hhahah ummm... that wours. I was fishing for codable definitions I don't trust software (even mine, hell especially mine) where safety is involved LOL I second that uncle! software is a good second line of defense, to warn you when the first line (hardware) has failed john this changes at the moment. the time you can say software is always buggy is over but I sometimes have to stand in the middle of a machine to change a tool... back to point: when is it safe to change machine parameters? Imperator_: not just software bugs... are you willing to trust your life to a single transistor, or mosfet, or keyboard switch? right, let's get back on track poit of fact we do it all the time. Wether that is *SANE* is another question some parameters like PID tuning must be changable during machine setup (while running) for tuning but after the tuning is done, we don't want them changed other things, like routing of signals, you probably don't want changable while running (or at least in the middle of a run) maybe a byte would be better than a simple flag yeah with permissions different levels oh boy... in safety equipment everything is redundant !! Think on your car john you are trust your life for example to a simple metal tube between your steering wheel and the steering gear :-) how about interupting the g-code interp? evening that starts to get messy.. now you not only need to configure the machine, you need to configure the configuration protection what's the topic on right now? yes... but only when designing a module e.g. writing it hahha... good question let's say I write a driver not true, modules can be used in diffenet ways one parport could have estop signals at least in part figureing out how to do driver/module repariterization on the fly another could have the blinkin lights that keep the dumb operator from drooling... one is critical, the other is not, but both use the parport driver got me there :-b.... hey robin then ... when loading the module? Huh...too bad my machine is too small...I just had an idea for this time of year lol... haven't seen that one before CNC PUMPKIN CARVING hey robin Oooo, the mess, the humanity.... my head hurts seen which one. I like the CNC pumpkin carving project! evening guys the drooling smiley oh... that is an old one ;-) pumpkin carving? evening robin IIRC, there is/was a guy on rec.crafts.metalworking who called himself lasernerd, and had the first name Robin... but he was in Canada... Is he your alter ego? ok... I was playing a little at building my own 3D laser scanner. no, thats not me ebo: ahh, interesting, I thought about doing that ebo: line generator and a camera or proper interferometer one? but robin's scanner would turn the scannee into ashes if I cannot get my adaptive machine to work in current configuration I may go back and revisit. haha linegen and dual cameras. "hmm .. thats not right .. we scanned the object but the data file says its just flat ... whats wrong" scanning? what for? "no, thats right .. there is no fault with the data" ... flatness ;-) for flatness, an interfermoeter works well my stock is not flat and I need to cotour follow. similar to torch height control robin knows about that What kind of accuracies or tolerances? ever heard of META? how much would an interferometer cost to slap together. Whatever I do not care as long as it is cheap and realitively easy. I learnt some new methods this week ... we have such a toy in the univerity http://www.minolta-3d.com/ nice toy for how lasers do it .. with a capacative sensor but i am not so happy with the results I know our company has been using META laser scanners for following welding paths but those were pretty expensive... ebo: Oh, you were talking about this earlier, where you have to follow the surface at so many m/sec http://www.meta-mvs.com/lasersensors.html whats wrong with cpapcitive following? Or maybe I'm not remembering correctly... Time response? this is to fast for me to keep up with just a se... robin: isn't capacitive slow? precision: .002" prefered I can live with .005" dont think so ... robin: and limited to metals? I know what you mean, information overload limited to metals, yes Heh...careful you don't have a speed-reading accident re: capacitive -- non metalic non contact. I have thought of trying capacitive, but nat made the time well.... the sensors we used had their own control... precitec are the people who are the class leader for lasers so they only sent a simple signal to the robot (left, right, up, down) pretty easy to do with emc Horizontal measurement accuracy (mm) Vertical measurement accuracy (mm) MLP1/05 +/-0.05 +/-0.05 re: minolta -- thier site comes up unscalably small on my machine so I cannot easily navigate... do you have an idea of price? its usually feed a 10mhz signal, and wacth the pahse shift , the sensor is a disc about 15mm across .o5mm just in range ebo: META sensor around 30k EURO There is a new hand held laser scanner for about $20kUSD that has a 6DOF sensor in the device and can remap the 3D scan for multi-scan mesh. EBO: about 40 000 EUR I thing when hm how much would it cost to hire somone to scan somthing for you? do you mean me an0n ? the first time I do nto care... but what to do when you are in the middle of 1000 of them completely different. No this is part of an automated solution. ah.. but for $20k ;) I don't think you need more than 1 direction to scan maybe run the scanning just in front of the tool and adapt the path acordingly something like this: http://www.meta-mvs.com/images/image001.gif http://www.polhemus.com/fastscan.htm you are scanning for height, right? my app moves the tool in 3D, and the tool is in the way ;-) I was looking at possibly doing something similar with a conic ring and processing the light field yes... scanning for height there are cheap laser distance sensors. they give you the distance as a analog signal. If you place this on top of a mill and write a programm which goes row by row over your part you have a cheap scanner but not on a nominally flat surface I guess (you say 3D) well.. close enough to flat to be close, but far enought to completely shoot the QA what I mean is that your compensation can be only in Z if it is nominally flat do you have a pointer or two for the "cheap laser distance sensors"... I mean sources not laser pointer ;-) whereas if you were doing a sphere or something you would have to compensate normal to the surface I can do the image processing to calcualte the offset serface I think sharp makes them... but they are more like 4-30 inches with resolution of 0.05 or something, rather than 0-1 inch by 0.001 on a german cnc group there was somebody how has build this. but i have no details. He got the sensor at ebay. but i think they are also payable if you buy them new. Maybe about 300 EUR that is workable for me... I can do a multipass can post process. http://www.pololu.com/products/misc/0136/ it depends on the accuracy, of cause tomorow I must go play with the motion system on the sapre laser ... that could be fun oooo... now that looks promicing. have to look at precision and acuracy. (mening the posted sensor) playing with the sapre laser sounds fun too ;-) anyone here know anyting about windows and ODBC databases? the sharp things are very cheap, but not even laser.... I don't think you'll find them accurate enough ~2 volts change over 70cm distance change nowhere near accurate enough the next problem is that you have to messure the distance only in one line. If something is next to the point where you are messuring at teh moment it don't have to influence the result hmmm... you are likely correct. But they might have something else. what is your operating distance? depending on how I set things up they can be as close as 2mm, but I would like something in the range of 10 to 30mm so there is less chance of crashing the tool, etc. the sharp things start at 100mm and go up, no wonder they aren't accurate enough The variance should be within 2mm. I was just about to look at the range of devices... thanks for the post ;-) shucks! how fast are the variances (spatially)... IOW are you tracking a gently rolling hills, or a washboard well, if there are *no* defects, it should look like gently rolling hills (or lets say a sadle that deflects 2mm over 100x100mm. I have seen defects as large as 2mm high by 2mm wide. and you need to track the defects too I assume? ;-( !also ,note that the current tooling tries to guarntee a max global height. But if an operator screws up it could crash some delicate tooling (read me without enough sleep) you have to think on the principle of that sensors: they are pointing to the surface with a laser nad then they look from the side where the reflection of the laserpoint is. if it is not possible to sea the point from the side you cant messure it. For example if the point is in a hole, you cant see it from the side. in practise there are a lot of surfaces that you cant messure with lasers so you are talking about tracking a 2mm wide bump while moving in the 1-2M/sec rance yes on tracking the defects. That is the real problem! I have to move around them. If they are to bad I pitch the piece, but sometimes they are hard to spot when you are dealing with hundreds of pieces. Automating an inspection sustem is not the solution because they are all slightly warped... mineature version of nap-of-the-earth flying! yes! you go around the defects!? my current machine is not tat fast, but the problem is the same. over them. ok... for a minute there I thought the correction had to be in three axis at the specificde clearence (+.002" +.010" are the defects steps or ramps? IOW, 0 to 2mm in how little distance? ah... I see your point. No the rough geometry I already know. ummm... what do you mean by "IOW, 0 to 2mm in how little distance? " you're zooming along a relatively flat area (slope is perhaps 0.1mm per 10mm, then you come upon a defect, and suddenly it slopes up by 2mm over a short distance... is that distance 2mm? or is the 2mm the entire length of the "lump" and it has near vertical sides? is your surface mirroring ?? if so you have a problem I'm thinking of the defects as lumps, maybe that isn't right think of the bump being a half spere or worse a short cylinder. The half spere is typical no on the mirror could it be flattened? with say ... as you say, short cylinder is worse - you _can't_ track a vertical surface no matter how fast you are a small hammer? a big hammer does it for me ... another pronlem solved! no on the flatening. no with a hammer unless I want to make thousands of little pieces all the same well it was a thought ;-) I hope your Z axis is very low inertia well... you can track a vertical surface if you make a couple of simplifying assumptions (like I do not care for undercuts only for the vert.) that way I se a step rise in the piece and have to move up to avoid in time. This is a real problem that I have looked at. and yes I have software that calculates offset serfaces from point sets in realtime yes on the low initera I like the way you think, but the client would KILL me if I broke all their stuff ;-) so you need a small spot size (sub 1mm), and you need the active spot to be in front of the tool (in the direction of travel) no matter which way the tool is moving I see why you were considering light cones but most image based systems have fairly low frame rates how big is the workpiece... you mentioned 100mm before if its not too big, perhaps you could build a map in memory before you start running the tool over the part 1000x1000 grid with 8 bits per point for example can you run the parts past a video camera and oblique angle linear light beam as you load them into the machine to build the map? takes the speed part out of the picture * jmkasunich hopes it takes part processing time is several minutes, time you could spend profiling the next part it got really quiet in here just now hm, I wonder.. if you shine light in a crosshatch pattern over a part.. you are talking with yourself John :-) and check for differencies using a video camera but a good time to ask you something sorry for the delay. I will have to bugout soon... regarding the scanning etc. caching the points is exactly what I tried at first. Then I moved the scanner and post-processed. Since the tool area/travel area is a small fraction of the overall area I was looking at trying to do this on the fly. Another option is to do the cone idea and sweep only the area that I need to travel. and some image processing.. I am working on some specialized tooling that might sidestep all of this... I have most of the image processing alread developed. ah this isnt about that it's just a idea I got.. wouldnt that be a good way to measure the differencies.. of a surface? err errors.. ie scrap/pass ;) Yes ;-) camera/light on the "gantry" ie not moved by Z axis... first pass made with Z retracted... map the area of interest then extend Z and make your high speed passes John you are planning a redesign of HAL. How fast will you do this, what is your planning ?? Because i think it is not so good to change everything before it is realy running. I think time for redesign is if you have the system running for a while to collect experiences redesign? i thought it was nearly finished? I have to agree on that refactoring - most changes internal, the API shouldn't change too much we have been talking several topics... or very well.. make revisions when you've tried it out alot.. I agree that a working emc2 comes first my target for the refactor is by early 2005 * an0n does that at work.. I load the firmware I write onto some customers machine.. and I talk to them and get lots of feedback the discussion on height sensing was OT, but we should get back on track. off topic but interesting ebo: explain the track please lol sorry yes, and useful... with some reasonable solution we could build a non-contact probe for EMC! track? Oh!!! ummm... 1) reparameterize modules on the fly -- as side effect allows modules to be loaded at boot and updated as needed. Security benifit that users do not need to be root. --- the topic was hyper-threaded ;-) 2) digression into devices, device drivers (puuting EMC on a gamebot ;-) and lastly into lasers... and laser canning canning? welding the lids on, right>? oops scanning. I watch my fingers when typing not the screen. Makes for interesting post reading ;-) that works too ;-) well folks... I have a house warming party to go to (100 miles away and I still have not cooked something for the potluck)! Bye... bye bye .. bye paul: which Tom? heh * paul_c is slowly nodding off.. is GTK and GTK-devel already included? * paul_c sees an error with that url straight away.. made konqueror segfault GTK+ will be there.. konqueror is unusable in the main works for me (most of the time) quicker to load than Mozilla * paul_c has upgraded to KDE-3.2 jmkasunich: At the moment, the bare CD with the core of KDE is around 180M wow... you said 212M this morning ;-) Ah... I assume you already have the basics... browsers, IRC and email clients, compilers and the like how about Lyx? is this a general desktop package or the machining package? that's the big question isn't it 180M for the core, Synergy plus support bumps it up to 212M some folks will want to use it for machining only, small as possible others will want more Spongebob...now that's just *wrong*... I want a development worthy setup there should be a 'just enough to run a mill, with ftp and ssh for getting stuff in and out' tick box for devel stuff tick box for complete desktop sounds good to me * asdfqwega sends the link off to 3 friends :) apt-get install emc emc-devel emc-desktop? Hi Paul...just figured out the gnuplot things on rc_46.... ;} Its missing gnuplot-nox and gnuplot-x11 packages...There was also an update to one of the libraries that was needed... paul_c: the IP in the source points to www.morphix.com DId you get that into rc_60 ? nope gnuplot's nice :) gnuplot needs those two packages to work..... The saving module does not trigger correctly... I know about www.morphix.org/debian as a apt-source, but .com? It triggers no matter what you set the trigger source to, when you set the dac voltage... asdfqwega: Should have a couple of lines for your debian repositories Which makes it difficult to use... asdfqwega: http://ftp.debian.org/debian I'm on the laptop right now...would have to lug a box up from the shop to use apt And I have Debian on a 8 CD set Correction...I have Debian Stable on CD Woody Time for an apt-get upgrade ? I need a picture of a machined Chips needs a bit more depth for the splash a more 3D you mean? Ooo, I *like* that penguin... Okay, I've out in the sticks way too long http://www.nekobox.org/images/cathat2.jpg paul_c: Maybe these could be included as walpaper images on the Live? or startup screens hmmm .. I must be a true engineer that way the operator wouldn't mind waiting for the machine to boot up I look at : http://www.nekobox.org/ and immediatley I wanna work out what that big diesle engine is for ;) yeah, you're an engineer making candies of course candy well... guess i'll call it a night soon ;) time for me to make some food goodnight alex paul_c: can you send me a pic with chips when you get some time? gnight y'all right ... getting late here so ... this weeks tasks get some laser job-shop work in to pay the rent fix the big laser up so it can earn money anyway .. thats next weeks fun, no doubt I'll end up trying to start thinking about running the laser from emc too enough for now ... see ya OK - Developer's edition of BDI-Live... I now have a build enviroment that allows me to customise a CD quickly.... All I need to do is feed it a list of packages to use. nice It's not perfect, but it does the job. well that's three more weeks of minutes uploaded... I really need to do that more often As a starting point, I can pull a list of currently installed packages off this box and build a list of "patches" With a little bit of python hackery, could fine tune the boot graphics. looks like sherline (or their ISP) fixed the DNS problem I don't see the BDI-TNG iso's there, is that intentional? probably Live replaces TNG In time, I would like to see something replace BDI-2.xx why? it works fine for those with older hardware A single set of packages is much easier to maintain I don't expect you to maintain it... if 2.19 or 2.20 is the last release ever, there's nothing wrong with that Believe it or not, I had an enquiry last week with an offer to develop BDI-2.xx further With the Live's ability to do a HD install, there shouldn't be a need for much more Live needs something like 256Meg RAM and 1GHz plus CPU or it's a dog (or simply won't run at all) The problem with Live is it's memory requirement KDE3.x is a problem too, on slower boxes That can be worked round Does the memory requirement lighten up when installed on HD? Icewm for the slow boxes, KDE for the power users the way I see it, BDI-2.xx is a late 1990's distro, and works nicely on late 1990's hardware (like mine) Got a plot of my Z axis with those parameters I posted. Position looks quite nice...Does a 1 inch move in .6 seconds, no overshoot, nice tangent to tangent movement... Once installed, Live will operate with much less memory Can see the balls reversing in the ball nut in the motor voltage.... That's what I thought well if you did replace 2.xx, what would you replace it with? something that forgoes the live capability in order to use less ram? A Debian baseprobably Has anybody posted regarding the missing gnuplot packages in rc_46 yet ? so once installed, live and the 2.xx replacement would be more or less the same? yes wb9mjn: nope I see - that does have advantages One kernel, one EMC package Ok, I ll go do it...Looking at the data, the start and stop are only off by one count (1/4000 of an inch) .... and the option to deliver a Live or a traditional install distro I like it wb9mjn: Posting to the emc list(s) about missing packages won't do much good (for me the live option is just a frill... if I can't write to the HD, I can't do much that is interesting) With Live, you can mount the HDD manually, yes... and do it again on the next boot, and again, and again it definitely has good uses... just not for me ;-) Live fills a niche right I would usually install to HDD myself - I need my cupholder free :P However, since I know how to morph Morphix, once I had things set up, I might just copy over the settings and just use it Live rc60 will throw a spanner in the works then... ? With rc46, to add your own ini, you can place it in the copy/ dir and burn it as a bootable CD under Doze (if you must) with rc60, you can still use the copy/ dir, but creating a bootable image is a little more involved. I never got rc46 to work... as in ? the Live? wouldn't boot ? nope bummer. bad copy Well, time to go make some chips, sawdust, and noise Time for bed - Been up for 36 hours already.