From: Shen M. <su...@16...> - 2006-05-26 23:28:40
|
Hello everyone, I am trying to write my own caculations into genhexkins.c, but I find I am not quite sure what exactly is "pos->a". Is "pos->a" an angle between axis-X and the pose-vector of cutting tool? Or is it a rotation angle of X-axis? If the latter, what's zero point? On May 27, 2006, at 1:12 AM, emc...@li... wrote: > Send Emc-users mailing list submissions to > emc...@li... > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.sourceforge.net/lists/listinfo/emc-users > or, via email, send a message with subject or body 'help' to > emc...@li... > > You can reach the person managing the list at > emc...@li... > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Emc-users digest..." > > > Today's Topics: > > 1. EMC2 / USC install problems. (ei...@eu...) > 2. Re: EMC2 / USC install problems. (Ray Henry) > 3. Re: CMS_SERVER error (Jeff Epler) > 4. Re: CMS_SERVER error (Nathan Allen Stratton) > 5. Re: CMS_SERVER error (Jeff Epler) > 6. Re: GUI for EMC (Jon Elson) > 7. Re: Was: Getting EMC running. FUD or facts? Mine is not > running. (Jon Elson) > 8. Re: Was: Getting EMC running. FUD or facts? Mine is not > running. (Jon Elson) > > --__--__-- > > Message: 1 > From: ei...@eu... > To: emc...@li... > Date: Fri, 26 May 2006 10:28:40 +0200 > Subject: [Emc-users] EMC2 / USC install problems. > Reply-To: emc...@li... > > Ray, > > Thanks for looking at my problem. > This is a reply to "Getting EMC running. FUD or facts? Mine is not > running= > " in case > the included text does not seem to make sense. > >> Ah this is a USC problem not a Ubuntu install issue. Thanks for the > It's a USC problem that revealed some EMC2 problems (I believe) and > not Ub= > untu install. > Not really problems if the install succeeds, but if it don't it > leaves the= > installer without much > clues when he is not versed in Linux (that's me). > >> They are a bit touchy about the parport used, cabling, and bios >> settings. > I know. That's why I emphasized that the same machine/cable/USC > combo work= > ed with EMC(1). > >> Before I go on however, I want to make clear to the casual reader >> that >> MACH DID NOT SOLVE the USC problem. My guess is that the common >> parport > No. Mach does not run USC. > >> I looked at your link listed below and got confused momentarily. >> This >> says Ubuntu but it also says emc1. The Feb date should have been an >> okay set of source files. There was a bug then when using multiple >> cards but I don't think that you'd have seen it. That was about >> when I >> was testing and building the USC configs here. > The EMC1 .ini file I put there to show the settings that worked for > me in = > EMC1. > Like the parport address. > >> What I say next should be taken as coming from an interested >> bystander >> rather than from the maker of the PPMC system. > And from a person experienced in EMC2 I am sure. > >> Notes based on your file at http://www.sjaavik.com/emc2/emcmessages. > >> I like the proc and board. This seems like it should be a reasonably >> clean system. I'd have unplugged the usb stick during boot but >> that is >> just something I tend to do. There are a couple of things I'd >> have done >> different. > >> This is pretty generic parallel port stuff except that I'd have >> edited >> the bios to make it EPP rather than ECP. I am aware that the Pico >> stuff >> should handle either but why make it fight it's way. Notice below >> that >> it looks in the right address > > Now that is probably one thing to check! > I did not notice that it told me it is running ECP. > >> On my athalon64, the startup handshake was a problem because the >> parport= > >> I was using was faster than Jon had designed the outboard firmware >> for. = > We >> solved that problem by snipping the wire from pin 13. I believe >> that he= > has >> since modified the firmware on these boards. > > Hopefully Jon reads this too. The serial EEPROM on my board is > marked U9/1= > 9/02. > >> On some parports, there is no way to get the communication channel >> set u= > p >> properly even if you were using the parallel port cable sent with >> the board rather than a generic cable. Many of these cables are >> not up >> to the task even though they say they are compatible. > > I had to make a special short cable w. twisted wires for the EMC1 > install. > But since it have worked since, I believe it to be OK. If timing > changed, = > that > may of course show to be a false assumption. For EMC1 there was a > board > test. Can I use this with Ubuntu? > >> Once you get the "pc + USC system" to live, it is a very nice >> communication protocol. The USC can produce very fast, very smooth >> pulse trains. > I know. I run fairly hefty steppers (10nM) and they run rough as > =A4%@ if = > not > microstepping. And with microstepping comes the need for high > pulserates. > >> Let me restate my frustration that you chose to ignore Pico's >> advice and >> then blamed the system failure on EMC2 and Ubuntu. > What advice? > >> Further afield you >> stated that MACH cured the problem when you know as well as I do >> that it >> did not solve the USC system problem. I'm glad that you got the >> parts >> made but a single click on the stepper_mm definition after the >> above USC >> failure would have produced an EMC2 system that could have been >> tuned in >> less than an hour to handle your machine in much the same manner >> as the >> other software. > If I gave the impression Mach solved the USC problem, it must be my > loss i= > n > expressing (in a foreign language) the facts. Mach3 never can, it > have no = > possibility > to use external pulse generating hardware. But my opinion is still > that it= > is much more > difficult to install EMC, and the rewards for doing it is greater. > So unti= > l something changes > my mind I still want EMC2, but expect to spend some time figuring > out how = > to. > >> And last but not least, lest you take another right turn and cite the >> pulse rate of MACH as being essential to your success. I'd be really >> surprised if your athalon and via chipset would produce significantly >> slower pulses. I got mine to about 48k, much faster than my little >> machine could handle. > > Pulse rate of Mach3 is advertized to 45k. But that I find that > rather unin= > teresting as my > drives does not tolerate much jitter on pulses. So the max speed > will be d= > etermined by > increasing jitter rather than inability to output enough pulses. > Enter USC= > which seems > to smooth out software jitter. Just what I found after some scope > traces, = > I have not made > any in-depth logging. But fact is it runs my machine faster without > positi= > oning errors or > stalling than Mach3 (or EMC with parport pulsing). > > There seems to be other solutions to this, but USC have served me > well so = > far. And Jon's > (Pico Systems) support impressed me when I had trouble with the > initial in= > stall. It was largely > due to using a fairly long and unspecified parport cable if I > remember rig= > ht. > > So I will check out the EPP issue in the BIOS. You may have hit the > nail o= > n it's head there. > I made no changes in the BIOS since running EMC1, but I think a > program wa= > s included to > do something with it. I do not remember the details, so I may be > wrong on = > this. > > Thanks > Einar > > > > --__--__-- > > Message: 2 > Subject: Re: [Emc-users] EMC2 / USC install problems. > From: Ray Henry <re...@up...> > To: emc...@li... > Organization: rhe > Date: Fri, 26 May 2006 06:56:50 -0500 > Reply-To: emc...@li... > > > Hi Einer > > Thanks for the quick and thorough reply. This list is the place to > share experience and to work through problems. That is exactly what > you've done in these posts. =20 > > Several of us were ordering breakfast during Fest. AramK answered a > long list of questions, "How do you want your eggs," "what kind of > toast," "bacon, sausage, links, or patties." After the waitress left > he remarked, "so many choices, it's like EMC." A failure to run > can be > extremely frustrating. Part of that frustration comes from the > fact of > the wide variety of hardware available to EMC. =20 > > It sounds like you have a good handle on most of the issues involved > between the PC and the USC card. Our experience with these cards and > EMC2 is a bit thin at the moment. I believe that the HAL hardware > driver works properly and that JonE is working through the > communication > issues. If I remember my handshake problem the driver did find the > card > but could not come out of estop. That would mean that the pin 13 > problem is probably not your issue. =20 > > I have heard of a few hardware issues where the BDI was better able to > cope. Paul has had years of experience with kernel builds and > distribution development. The Ubuntu/EMC does not have as long a > record > nor as broad a variety of machine installs. =20 > > I don't see an EPP test program anywhere in the typical EMC2 > build. Now > I'm having memory issues because I thought I ran such a program with > EMC2 for all of my cards. I'll dig more as I get a chance. > > Ray > > > > On Fri, 2006-05-26 at 10:28 +0200, ei...@eu... wrote: >> Ray, >> =20 >> Thanks for looking at my problem. >> This is a reply to "Getting EMC running. FUD or facts? Mine is not >> runn= > ing" in case >> the included text does not seem to make sense. >> =20 >>> Ah this is a USC problem not a Ubuntu install issue. Thanks for the >> It's a USC problem that revealed some EMC2 problems (I believe) >> and not= > Ubuntu install. >> Not really problems if the install succeeds, but if it don't it >> leaves = > the installer without much >> clues when he is not versed in Linux (that's me). >> =20 >>> They are a bit touchy about the parport used, cabling, and bios >>> settings. >> I know. That's why I emphasized that the same machine/cable/USC >> combo w= > orked with EMC(1). >> =20 >>> Before I go on however, I want to make clear to the casual reader >>> tha= > t >>> MACH DID NOT SOLVE the USC problem. My guess is that the common >>> parp= > ort >> No. Mach does not run USC. >> =20 >>> I looked at your link listed below and got confused momentarily. >>> Thi= > s >>> says Ubuntu but it also says emc1. The Feb date should have been an >>> okay set of source files. There was a bug then when using multiple >>> cards but I don't think that you'd have seen it. That was about >>> when= > I >>> was testing and building the USC configs here. =20 >> The EMC1 .ini file I put there to show the settings that worked >> for me = > in EMC1. >> Like the parport address. >> =20 >>> What I say next should be taken as coming from an interested >>> bystande= > r >>> rather than from the maker of the PPMC system. >> And from a person experienced in EMC2 I am sure. >> =20 >>> Notes based on your file at http://www.sjaavik.com/emc2/emcmessages. >> =20 >>> I like the proc and board. This seems like it should be a >>> reasonably >>> clean system. I'd have unplugged the usb stick during boot but >>> that = > is >>> just something I tend to do. There are a couple of things I'd >>> have d= > one >>> different. >> =20 >>> This is pretty generic parallel port stuff except that I'd have >>> edite= > d >>> the bios to make it EPP rather than ECP. I am aware that the >>> Pico st= > uff >>> should handle either but why make it fight it's way. Notice >>> below th= > at >>> it looks in the right address >> =20 >> Now that is probably one thing to check!=20 >> I did not notice that it told me it is running ECP. >> =20 >>> On my athalon64, the startup handshake was a problem because the >>> parp= > ort=20 >>> I was using was faster than Jon had designed the outboard >>> firmware fo= > r. We=20 >>> solved that problem by snipping the wire from pin 13. I believe >>> that= > he has >>> since modified the firmware on these boards. >> =20 >> Hopefully Jon reads this too. The serial EEPROM on my board is >> marked U= > 9/19/02. >> =20 >>> On some parports, there is no way to get the communication >>> channel se= > t up=20 >>> properly even if you were using the parallel port cable sent with=20 >>> the board rather than a generic cable. Many of these cables are >>> not = > up=20 >>> to the task even though they say they are compatible.=20 >> =20 >> I had to make a special short cable w. twisted wires for the EMC1 >> insta= > ll. >> But since it have worked since, I believe it to be OK. If timing >> change= > d, that >> may of course show to be a false assumption. For EMC1 there was a >> board >> test. Can I use this with Ubuntu? >> =20 >>> Once you get the "pc + USC system" to live, it is a very nice >>> communication protocol. The USC can produce very fast, very smooth >>> pulse trains. >> I know. I run fairly hefty steppers (10nM) and they run rough as >> =C2=A4= > %@ if not >> microstepping. And with microstepping comes the need for high >> pulserate= > s. >> =20 >>> Let me restate my frustration that you chose to ignore Pico's >>> advice = > and >>> then blamed the system failure on EMC2 and Ubuntu. >> What advice? >> =20 >>> Further afield you >>> stated that MACH cured the problem when you know as well as I do >>> that= > it >>> did not solve the USC system problem. I'm glad that you got the >>> part= > s >>> made but a single click on the stepper_mm definition after the >>> above = > USC >>> failure would have produced an EMC2 system that could have been >>> tuned= > in >>> less than an hour to handle your machine in much the same manner >>> as t= > he >>> other software. =20 >> If I gave the impression Mach solved the USC problem, it must be >> my los= > s in=20 >> expressing (in a foreign language) the facts. Mach3 never can, it >> have = > no possibility >> to use external pulse generating hardware. But my opinion is still >> that= > it is much more >> difficult to install EMC, and the rewards for doing it is greater. >> So u= > ntil something changes >> my mind I still want EMC2, but expect to spend some time figuring >> out h= > ow to. >> =20 >>> And last but not least, lest you take another right turn and cite >>> the >>> pulse rate of MACH as being essential to your success. I'd be >>> really >>> surprised if your athalon and via chipset would produce >>> significantly >>> slower pulses. I got mine to about 48k, much faster than my little >>> machine could handle. >> =20 >> Pulse rate of Mach3 is advertized to 45k. But that I find that >> rather u= > ninteresting as my >> drives does not tolerate much jitter on pulses. So the max speed >> will b= > e determined by >> increasing jitter rather than inability to output enough pulses. >> Enter = > USC which seems >> to smooth out software jitter. Just what I found after some scope >> trace= > s, I have not made >> any in-depth logging. But fact is it runs my machine faster >> without pos= > itioning errors or >> stalling than Mach3 (or EMC with parport pulsing).=20 >> =20 >> There seems to be other solutions to this, but USC have served me >> well = > so far. And Jon's >> (Pico Systems) support impressed me when I had trouble with the >> initial= > install. It was largely >> due to using a fairly long and unspecified parport cable if I >> remember = > right. >> =20 >> So I will check out the EPP issue in the BIOS. You may have hit >> the nai= > l on it's head there. >> I made no changes in the BIOS since running EMC1, but I think a >> program= > was included to >> do something with it. I do not remember the details, so I may be >> wrong = > on this. >> =20 >> Thanks >> Einar >> =20 >> =20 >> =20 >> ------------------------------------------------------- >> All the advantages of Linux Managed Hosting--Without the Cost and >> Risk! >> Fully trained technicians. The highest number of Red Hat >> certifications= > in >> the hosting industry. Fanatical Support. Click to learn more >> http://sel.as-us.falkag.net/sel? >> cmd____________________________________= > ___________ >> Emc-users mailing list >> Emc...@li... >> https://lists.sourceforge.net/lists/listinfo/emc-users >> =20 > > > > --__--__-- > > Message: 3 > Date: Fri, 26 May 2006 07:11:17 -0500 > From: Jeff Epler <je...@un...> > To: emc...@li... > Subject: Re: [Emc-users] CMS_SERVER error > Reply-To: emc...@li... > > On Thu, May 25, 2006 at 10:31:00PM -0400, Nathan Allen Stratton wrote: >> P.S. How do I use the patch you sent? I saved it and tried patch - >> p1 < and >> it asked for the file but did not worked so I just did it by hand. > > The patch was probably broken because I pasted it into the e-mail > message. > > What compiler are you using? I'm curious why others haven't seen > these > errors---we test with everything from egcs to gcc 4.0.2 on ubuntu. > > I don't see any 'long' on line 83 of my file. Here's the line > numbering > I have after my earlier change: > 80 CMS_SERVER * server, long request_type, long > buffer_number, long > 81 received_serial_number); > 82 }; > 83 > 84 class TCP_BUFFER_SUBSCRIPTION_INFO { > 85 public: > 86 TCP_BUFFER_SUBSCRIPTION_INFO(); > > Jeff > > > --__--__-- > > Message: 4 > Date: Fri, 26 May 2006 08:50:17 -0400 (EDT) > From: Nathan Allen Stratton <na...@ro...> > To: emc...@li... > Subject: Re: [Emc-users] CMS_SERVER error > Reply-To: emc...@li... > > On Fri, 26 May 2006, Jeff Epler wrote: > >> On Thu, May 25, 2006 at 10:31:00PM -0400, Nathan Allen Stratton >> wrote: >>> P.S. How do I use the patch you sent? I saved it and tried patch - >>> p1 < and >>> it asked for the file but did not worked so I just did it by hand. >> >> The patch was probably broken because I pasted it into the e-mail >> message. > > Yep, so once I typed it in correctly it all worked fine! I passed that > part. > >> What compiler are you using? I'm curious why others haven't seen >> these >> errors---we test with everything from egcs to gcc 4.0.2 on ubuntu. > > Hmm, if I tell you then you will not keep helping me... : ) Just > kidding, > I understand if you don't have time to help since I am not on a > suported > system. I am running on SUSE 10.1 with GCC 4.1 > > Thanks for fixing the last error, compile goes much farther now, > but runs > into: > > Compiling emc/task/emcsvr.cc > g++ -o ../bin/emcsvr objects/emc/task/emcsvr.o ../lib/libemc.a > ../lib/libnml.so > Compiling emc/task/emctask.cc > emc/rs274ngc/rs274ngc.hh:377: error: extra qualification Interp:: on > member control_save_offset > emc/rs274ngc/rs274ngc.hh:382: error: extra qualification Interp:: on > member control_find_oword > emc/rs274ngc/rs274ngc.hh:386: error: extra qualification Interp:: on > member control_back_to > emc/rs274ngc/rs274ngc.hh:390: error: extra qualification Interp:: on > member convert_control_functions > emc/rs274ngc/rs274ngc.hh:392: error: extra qualification Interp:: on > member doLog > make: *** [objects/emc/task/emctask.o] Error 1 > > -Nathan > > > --__--__-- > > Message: 5 > Date: Fri, 26 May 2006 10:22:21 -0500 > From: Jeff Epler <je...@un...> > To: emc...@li... > Subject: Re: [Emc-users] CMS_SERVER error > Reply-To: emc...@li... > > On Fri, May 26, 2006 at 08:50:17AM -0400, Nathan Allen Stratton wrote: >> Compiling emc/task/emcsvr.cc >> g++ -o ../bin/emcsvr objects/emc/task/emcsvr.o ../lib/libemc.a >> ../lib/libnml.so >> Compiling emc/task/emctask.cc >> emc/rs274ngc/rs274ngc.hh:377: error: extra qualification Interp:: on >> member control_save_offset >> emc/rs274ngc/rs274ngc.hh:382: error: extra qualification Interp:: on >> member control_find_oword >> emc/rs274ngc/rs274ngc.hh:386: error: extra qualification Interp:: on >> member control_back_to >> emc/rs274ngc/rs274ngc.hh:390: error: extra qualification Interp:: on >> member convert_control_functions >> emc/rs274ngc/rs274ngc.hh:392: error: extra qualification Interp:: on >> member doLog >> make: *** [objects/emc/task/emctask.o] Error 1 > > I suspect that the fix is again to remove the extra '<class name>::' > from the declarations. I've checked in fixes for > emc2/src/libnml/cms/tcp_srv.hh and emc2/src/emc/rs274ngc/ > rs274ngc.hh on > the HEAD, but it's my hope that these fixes will also appear in the > upcoming 2.0.1 release. > > Without gcc 4.1 on my system it's not easy for me to check whether > there > are any further errors. If there are, please do a build with "make > -k" > and send the full output. That should allow me to fix the rest of > them. > > Jeff > > > --__--__-- > > Message: 6 > Date: Fri, 26 May 2006 10:55:17 -0500 > From: Jon Elson <el...@pi...> > To: emc...@li... > Subject: Re: [Emc-users] GUI for EMC > Reply-To: emc...@li... > > David A. Neese wrote: > >> Is it possible to change the appearance of Mini, axis, etc. So that >> only the program number is entered and displayed on the screen? This >> is a unique situation and machine. > > I would think this is fairly easy. The "program number" means the > file > name of the program? > If you need it to extract a text field from the first line of the > program file, that might take just a > little coding. otherwise, it is mostly deleting various blocks of > information that are displayed > on the EMC window. I'm more familiar with TkEMC, but I think it would > be a similar project > for each of these GUIs. > > Jon > > > --__--__-- > > Message: 7 > Date: Fri, 26 May 2006 11:19:15 -0500 > From: Jon Elson <el...@pi...> > To: emc...@li... > Subject: Re: [Emc-users] Was: Getting EMC running. FUD or facts? > Mine is not > running. > Reply-To: emc...@li... > > ei...@eu... wrote: > >> I did mail my problems, and some helped me get to view the messages, >> which brought me further. But there were no reply to my following >> mails. >> >> So I still have no clue why the USC board is not recognized by >> EMC2 when it is with EMC. >> http://www.sjaavik.com/emc2/emcmessages >> >> >> > If you have a problem with a Pico Systems product, there is no better > source of info than > the guy who makes them (Jon Elson). I've seen most of the possible > problems, and know how > to fix most of them. There's plenty I don't know about EMC, and I'm > still learning EMC2, but as > far as communication between the hardware and software, I know this > area > pretty well. > > One major comment is that earlier .ini files cannot be used > directly in > EMC2. Also, there > is a change in EMC2 that has made the sample config files > incompatible. > Specifically, > the references to the index-pulse-in have been changed. If you don't > use index pulse > signals in your axis encoders, just comment out the following lines in > the file > .../emc2/configs/univstep/univstep_io.hal > > newsig Xindex bit > newsig Yindex bit > newsig Zindex bit > linksp Xindex <= ppmc.0.encoder.00.index > linksp Xindex => axis.0.index-pulse-in > linksp Yindex <= ppmc.0.encoder.01.index > linksp Yindex => axis.1.index-pulse-in > linksp Zindex <= ppmc.0.encoder.02.index > linksp Zindex => axis.2.index-pulse-in > > > >> And yes, I need some of those features when I get around to my >> lathe. The hardware is ready, >> but I hit a wall with EMC2/USC. So if anyone can tell me what my >> next step should be, I'd appreciate that. >> >> >> > If you can be a little more specific about the problems, I will try to > help. I'm out of town for a few days, but > I'll try to keep up with my email. > > Jon > > > --__--__-- > > Message: 8 > Date: Fri, 26 May 2006 12:23:15 -0500 > From: Jon Elson <el...@pi...> > To: emc...@li... > Subject: Re: [Emc-users] Was: Getting EMC running. FUD or facts? > Mine is not > running. > Reply-To: emc...@li... > > Ray Henry wrote: > >> Notes based on your file at http://www.sjaavik.com/emc2/emcmessages. >> >> >> > Well, the PPMC driver doesn't see the USC board. There are several > causes. Assuming this is a > good USC and parallel port cable that work on another computer with an > older EMC system : > 1. Parallel port should be set to EPP mode in the BIOS setup screen > 2. Some computers need the program "pcisetup" to select the EPP mode, > the BIOS setup > just seems to enable that mode. That program can be > loaded from > http://pico-systems.com/codes/pcisetup > You run it with this command : > sudo ./pcisetup 378 > You may need to set the executable bit on thiese with : > chmod u+x <program name> > > 3. If this quick fix doesn't help, you need to run the diagnostic > programs to see if you are > getting unreliable - or any - communication between the board and CPU. > http://pico-systems.com/codes/univstepdiags.tgz > >> [ 189.864999] PPMC: installing driver >> [ 189.865022] PPMC: checking EPP bus 0 at port 0378 >> >> but that it is using EPP. >> >> On my athalon64, the startup handshake was a problem because the >> parport >> I was using was faster than Jon had designed the outboard firmware >> for. We >> solved that problem by snipping the wire from pin 13. I believe >> that he has >> since modified the firmware on these boards. >> >> >> > But, this ONLY affected the ability to come out of estop. The board > should have been identified, > and other functions should have worked. > >> On some parports, there is no way to get the communication channel >> set up >> properly even if you were using the parallel port cable sent with >> the board rather than a generic cable. >> > I don't generally send a cable with the units, but Einar has had a > working (I hope) system for several > years. > >> Many of these cables are not up >> to the task even though they say they are compatible. >> >> > Well, I have not had too much trouble with them, but I buy all my > cables > from Digi-Key, from > the manufacturer Assmann. > >> JonE has not recommended EMC2 as a platform for this USC device until >> very recently. He has favored the BDI. In fact he favored and >> installed BDI-Live rc46 on a system as late as April of last year. I >> know that Jon was using EMC2 during Fest and had a working PWM >> system. >> >> >> > There IS a learning curve. And, I HATE to learn new software, after > going to great effort to > learn something first. But, all the development work is on EMC2, > and I > have to stay current. > I now (just barely) know how to set up EMC2 and tune the servos with > halscope. > > Jon > > > > --__--__-- > > _______________________________________________ > Emc-users mailing list > Emc...@li... > https://lists.sourceforge.net/lists/listinfo/emc-users > > > End of Emc-users Digest > |