Re: [Emc-users] Emc vs modern lcd monitors
gene heskett wrote: Since true 4x3 monitors are about as plentiful as hens teeth these days, and the axis interface seems to ignore this unsquare pixel, is there a way I can fix this that anyone knows about short of just using the center 2/3rds of the screen via the button on the monitor? Gene I am currently looking at a pair of 1920 by 1200 monitors fully populated by the Linux box, so at least some of the information you are getting has to be incorrect ;) You will need to load the the Linux ATI driver if you want the monitor resolution to be set automatically, http://support.amd.com/us/gpudownload/linux/Legacy/Pages/radeon_linux.aspx?type=2.4.1product=2.4.1.3.12lang=English ( Is that available via packag manager in a EMC setup? Not got a network connection on that machine here ) it is also possible as Przemek has said to manually set up the resolution in xorg.conf, and that is something I've been familiar with for many years, but recent distributions of linux ARE making that a bit more difficult. In my own case, the computers are the other side of a KVM switch arrangement, and - for example - currently the script I run in SUSE11.3 to give me the dual screen will not run in SUSE11.4 because that is defaulting to 1024x768 rather than ignoring the fact there is no feedback from the monitor :( 'nomodeset' is apparently no longer your friend ... -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
On Tuesday, August 16, 2011 05:46:26 AM Przemek Klosowski did opine: On Tue, Aug 16, 2011 at 12:15 AM, gene heskett ghesk...@wdtv.com wrote: On Tuesday, August 16, 2011 12:02:31 AM Przemek Klosowski did opine: On Mon, Aug 15, 2011 at 6:06 PM, gene heskett ghesk...@wdtv.com wrote: On Monday, August 15, 2011 05:15:23 PM Przemek Klosowski did opine: Section Monitor Modeline 1360x768 85.5 1360 1424 1536 1792 768 771 777 795 EndSection Many thanks, I just added that to the top of an extensive list in that machines xorg.conf, and I will go reboot it now for effects. I tried variations of 1360x768 and 1366x768. The log contains a long list of available modes, which do not include either of those, and are uniformly within a pixel of a 4x3 aspect ratio. Does that list of modes come from the card? Or from the vesa driver? It's possible that your xorg.conf is messing you up---I bet you it's a remnant of the old setup, and quite possibly not necessary. The long list of modelines was how I learned to do X11 back in the days when we had to whittle ones and zeros out of oak timbers but nowadays, xorg.conf is just few lines long, and the Xorg server finds out the video hardware, reads the monitor parameters over the video cable and matches it to the built-in list of VESA standard modes. It'd be interesting to try with a virgin minimalistic xorg.conf Section Device Identifier Videocard0 EndSection Section Screen Identifier Screen0 Device Videocard0 DefaultDepth 24 EndSection and maybe it'll figure something out on its own. I don't know if 1360x768 is on the VESA list so maybe you do need it after all. The log says 136nx768 is not used because there is no mode of that name even though I have added it to the Monitor section. It has to match the Monitor section your Screen section is using; there could be multiple Monitor sections (Monitor1,myOldCRT,LCDmonitor2, etc). Say something like Section Screen Identifier Screen0 Device Videocard0 Monitor MyMonitor ... Section Monitor Identifier MyMonitor Modeline . ... If its the card, I wonder if it is flashable to add that mode? Nope, I doubt it, every VGA card is capable of any resolution from like 320x320 (?) to 8000x8000 (???) within the memory capabilities and video clock speed; the limitations come from the monitor and driver limitations. Or should I shelve the card, an ATI X1650 and replace it with something else that knows about 16x9 aspect ratios? I will bet you a beer that your card is capable of driving your monitor resolution. According to Alex D. at xorg, no. If the mode is not available in the vesa bios, and it isn't, every mode available is a 4x3 variant, so no twiddling with modelines will help. I think there's some sort of misunderstanding. The mode may be absent in VESA table, but the video hardware is almost certainly capable of producing it. Try the monitor/modeline I mentioned. I did, both for 1360 and 1366 x 768. I remain stuck at 1024x768, a 4x3 mode. The problem is that the vesa specs were carved in nice hard stone back in crt days, so all these widescreen monitors have never worked their way into Yes, true, it's not in VESA---that's why we're not using VESA but writing our own Modeline. But I am using the vesa driver. the vesa bios, and likely never will. The card of course is capable of the mode, but only when running the fglrx drivers. The last time I tried that, Nope, any video card made after 2000 or so can do this mode. You just need to program the clock and shift registers to cycle at 13?? and 7?? basic video clocks---that's what the modeline tells teh server to do. I couldn't nuke it fast enough, the backplot was running 3-5 seconds behind the machine and I had to slow the base period to about a 3rd of what its doing now to stop the stalls. Even then the motors were making very rough tones. OK, performance might be an issue, but it's not related to the resolution!! Performance of rtai, with the proprietary driver blobs, might be possible with servo systems, but I am running steppers, which need a nice steady heartbeat. Only vesa can give that. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) If swimming is so good for your figure, how come whales look the way they do? -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev
Re: [Emc-users] Emc vs modern lcd monitors
On 16 August 2011 10:52, gene heskett ghesk...@wdtv.com wrote: Performance of rtai, with the proprietary driver blobs, might be possible with servo systems, but I am running steppers, which need a nice steady heartbeat. Only vesa can give that. Vesa does give that, but that is not the same as only Vesa giving that. It is possible that other drivers might perform adequately. I am not sure i would fancy doing the experiments to find out, though. -- atp Torque wrenches are for the obedience of fools and the guidance of wise men -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
On Tuesday, August 16, 2011 06:00:53 AM Lester Caine did opine: gene heskett wrote: Since true 4x3 monitors are about as plentiful as hens teeth these days, and the axis interface seems to ignore this unsquare pixel, is there a way I can fix this that anyone knows about short of just using the center 2/3rds of the screen via the button on the monitor? Gene I am currently looking at a pair of 1920 by 1200 monitors fully populated by the Linux box, so at least some of the information you are getting has to be incorrect ;) You will need to load the the Linux ATI driver if you want the monitor resolution to be set automatically, http://support.amd.com/us/gpudownload/linux/Legacy/Pages/radeon_linux.as px?type=2.4.1product=2.4.1.3.12lang=English ( Is that available via packag manager in a EMC setup? Not got a network connection on that machine here ) I do, but the downloadable driver available there has no support for an AGP version of the ATI Technologies Inc Radeon X1650 Pro family of stuff. Which is typical of ATI, by the time they get poor, crashy support in a linux driver, that card is obsolete and 2 years out of the supply pipelines. I have played this game with ATI vs linux for damned near 13 years now, and 4 cards, with this card being the latest. That really is twice more than I should have been burnt, but I bought that particular card based on Alex Deutcher saying it had linux drivers. They were an unmitigated disaster. The very next catalyst release for linux removed the ability to drive that old a card, it was obsolete at 18 months according to their marketing idiots. Their (AMD/ATI) whole business model is driven by sales of new cards to every user on about a 1 year cycle. Enforced by releasing new drivers that won't drive the card you have that hasn't even had a chance to get dusty yet. But just to test, I will run the latency-test with vesa and note it down, then switch the 'vesa' to 'ati' which auto-detects the card and loads the proper radeon driver, and see if the radeon performance is usable. The last time I tried that, on 8.04 LTS, it was a disaster complete with pixelization contamination and the video was a second behind the machine. At the same base thread, keyboard response to control the machine was often several seconds. For desktop non-emc use, nvidia throws a new driver over the fence at about 30 day intervals and I use them on this house machine. I would love it if they were usable for EMC, but the latency's jump into the 100 milliseconds range, so even nvidia cards must be used in the vesa mode if EMC is to be used. it is also possible as Przemek has said to manually set up the resolution in xorg.conf, and that is something I've been familiar with for many years, but recent distributions of linux ARE making that a bit more difficult. In my own case, the computers are the other side of a KVM switch arrangement, and - for example - currently the script I run in SUSE11.3 to give me the dual screen will not run in SUSE11.4 because that is defaulting to 1024x768 rather than ignoring the fact there is no feedback from the monitor :( 'nomodeset' is apparently no longer your friend ... Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Peace was the way. -- Kirk, The City on the Edge of Forever, stardate unknown -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
gene heskett wrote: I do, but the downloadable driver available there has no support for an AGP version of the ATI Technologies Inc Radeon X1650 Pro family of stuff. Which is typical of ATI, by the time they get poor, crashy support in a linux driver, that card is obsolete and 2 years out of the supply pipelines. I have played this game with ATI vs linux for damned near 13 years now, and 4 cards, with this card being the latest. That really is twice more than I should have been burnt, but I bought that particular card based on Alex Deutcher saying it had linux drivers. They were an unmitigated disaster. The very next catalyst release for linux removed the ability to drive that old a card, it was obsolete at 18 months according to their marketing idiots. Curious ... I've various ATI-AGP cards in Linux machines here without any problem. But I only run the real time stuff on ITX boxes, with 4x3 monitors ;) Admittedly the nvidia drivers are better though, and with cards only costing £30 they tend to be what is on the spares shelf nowadays. That and the AGP motherboards go in the bin when they need replacing anyway :) -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC2 error at startup related to Parallel Port
Dear EMC users, I have a problem when starting EMC2. I have enclosed the error-file with this email. Sometimes I do not have this problem at all when exiting EMC and running it again many times. But I cannot run EMC when the problem starts. It keeps on giving the same error (non stop). I have to restart the computer to be able to run EMC again. What should I do to get rid of it? Do you think if it is related to mother-board or some other hardware or BIOS configuration? Thanks for the help in advance. Farzin ParportProblem.rtf Description: RTF file -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors - OT observation
Gene: In the good old days that Przemek alluded to, when US$10K-US$100K Unix-based workstations were being sold just because they could run even more expensive CAD/CAM software and there were only a few choices being offered in graphics hardware, the software driver situation was barely tolerable. Yes it took a lot of sweat equity to hew a solution out of the 'oak,' to use Przemek's metaphor, but it worked forever once done. That's the era in which I developed a true love/hate relationship with X-windows. In the world of Linux on PC-based hardware the situation is totally intolerable. Neither the hardware nor the software costs anything, the technology turns over in 6 mo to 18 mo, and there simply is no money for driver development. Even in the Windows gaming and multimedia arenas, where all the profits appear to lie, the drivers are constantly being tinkered with because they are put together with baling wire and chewing gum to begin with. Every new application reveals yet another problem with the drivers. The emergence of LCD technology has screwed them up too. The VESA specification guys have tried to keep up but Unlike graphics card development, which can be done on a project-by-project basis, software driver development is continuous. I can't imagine product managers cheerfully paying for lots of software developers. Figure it costs a company US$100K to run one good, full-time software developer for one year (yes, I'm including overhead and benefits). It would just come out of the managers' annual bonuses. The reason professional graphics cards cost so much more than consumer cards is because of the software-driver development costs, not the hardware. Making OpenGL, rather than DX, run well on them is a particularly high-cost item. I haven't even mentioned designing for acceptable real-time performance, which is a non-issue for 99.9+ percent of the buyers and, hence, of the sellers. Bottom line---I don't think you should hold your breath waiting for better drivers in Linux that work well with EMC2. The market forces are all wrong. To add to your misery, every Linux distribution appears to go its own way on its X-server and graphics drivers, so you can't be sure that what worked in Ubuntu, say, will work in PCLOS, etc. Herding cats is the metaphor that comes to mind. At least we could start a spreadsheet on the wiki to aggregate information like card, m/b, driver, distribution, etc., along with some crude measure of performance. It could even be an expansion of the existing latency-test spreadsheet, although I believe we would be better served with a separate one. I expect it would be mostly a place to say this works for me, this doesn't work for me, and watch out for these gotchas. Regards, Kent -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 error at startup related to Parallel Port
On Tuesday, August 16, 2011 09:54:51 AM Farzin Kamangar did opine: Dear EMC users, I have a problem when starting EMC2. I have enclosed the error-file with this email. Sometimes I do not have this problem at all when exiting EMC and running it again many times. But I cannot run EMC when the problem starts. It keeps on giving the same error (non stop). I have to restart the computer to be able to run EMC again. What should I do to get rid of it? Do you think if it is related to mother-board or some other hardware or BIOS configuration? Thanks for the help in advance. Farzin Just a SWAG here Farzin, but I wonder if something is causing the printer driver 'lp' to be loaded, which would grab that port, making it un- available for emc? When this occurs, do an lsmod, (and post it here) there should not be any parport 'lp' stuff showing when emc is not running as it has its own module for that. On my machine I see this in my lsmod output: parport_pc 25637 2 parport30764 3 lp,ppdev,parport_pc However I also have a startech 1 port extra parport card in the box, and I am using it for emc, so there is no conflict. IIRC the module you do NOT want to see is the 'lp' module. Can you try forcibly unloading it? I just did here without any errors, just this warning: gene@shop:~$ sudo modprobe -r lp [sudo] password for gene: WARNING: All config files need .conf: /etc/modprobe.d/emc2, it will be ignored in a future release. Here is that file for completeness: --- # Remove the '#' before 'install' below to prevent regular Linux programs # from accessing the parallel port. This also means that the linux # parport number may not be used to identify the port in loadrt hal_parport. #install parport_pc /bin/true --- So the disabled load (the last line) is not in effect on my box ATM. You can remove that last comment, it may well fix your problem for good. To remove the warning I just got, cd to /etc/modprobe.d and do a 'sudo mv emc2 emc.conf' That may not be the problem, in which case you can safely ignore me. ;-) Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Q: How does a Unix guru have sex? A: unzip;strip;touch;finger;mount;fsck;more;yes;umount;sleep -- unknown source -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors - OT observation
On Tuesday, August 16, 2011 10:28:02 AM Kent A. Reed did opine: Gene: In the good old days that Przemek alluded to, when US$10K-US$100K Unix-based workstations were being sold just because they could run even more expensive CAD/CAM software and there were only a few choices being offered in graphics hardware, the software driver situation was barely tolerable. Yes it took a lot of sweat equity to hew a solution out of the 'oak,' to use Przemek's metaphor, but it worked forever once done. That's the era in which I developed a true love/hate relationship with X-windows. In the world of Linux on PC-based hardware the situation is totally intolerable. Neither the hardware nor the software costs anything, the technology turns over in 6 mo to 18 mo, and there simply is no money for driver development. Even in the Windows gaming and multimedia arenas, where all the profits appear to lie, the drivers are constantly being tinkered with because they are put together with baling wire and chewing gum to begin with. Every new application reveals yet another problem with the drivers. The emergence of LCD technology has screwed them up too. The VESA specification guys have tried to keep up but Unlike graphics card development, which can be done on a project-by-project basis, software driver development is continuous. I can't imagine product managers cheerfully paying for lots of software developers. Figure it costs a company US$100K to run one good, full-time software developer for one year (yes, I'm including overhead and benefits). It would just come out of the managers' annual bonuses. The reason professional graphics cards cost so much more than consumer cards is because of the software-driver development costs, not the hardware. Making OpenGL, rather than DX, run well on them is a particularly high-cost item. I haven't even mentioned designing for acceptable real-time performance, which is a non-issue for 99.9+ percent of the buyers and, hence, of the sellers. Bottom line---I don't think you should hold your breath waiting for better drivers in Linux that work well with EMC2. The market forces are all wrong. To add to your misery, every Linux distribution appears to go its own way on its X-server and graphics drivers, so you can't be sure that what worked in Ubuntu, say, will work in PCLOS, etc. Herding cats is the metaphor that comes to mind. There is a lot of stuff that just won't, and likely never will, work on pclos. FPGA board devel stuff like quartus is one, building heekscad is another, and Sketchup is very unstable. However, it its defense, what does work, is dead stable. It the what doesn't work that has me contemplating jumping to ubuntu 10.4 LTS so I would be running the same distro on all machines here. But that slices open a can of audio worms and user interface worms. In short, if you like kde, and I do, install ubuntu and then pull in kde, its hundreds of times more stable than installing kubuntu. At least we could start a spreadsheet on the wiki to aggregate information like card, m/b, driver, distribution, etc., along with some crude measure of performance. It could even be an expansion of the existing latency-test spreadsheet, although I believe we would be better served with a separate one. I expect it would be mostly a place to say this works for me, this doesn't work for me, and watch out for these gotchas. Regards, Kent +100 Kent. If we have to solve these problems, it would be great to make the solutions each of us find available on the wiki. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) Thirty days hath Septober, April, June, and no wonder. all the rest have peanut butter except my father who wears red suspenders. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
I will throw this out there and see what happens. Gene, have you ever been to phoronix.com? They cover open source drivers for video cards from time to time. Including more often than not the drivers for ATI cards. I wish I could say look at driver xxx.x, but I don't really know which one is useful for your card. Kyle -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
On Tuesday, August 16, 2011 11:34:42 AM Kyle Kerr did opine: I will throw this out there and see what happens. Gene, have you ever been to phoronix.com? They cover open source drivers for video cards from time to time. Including more often than not the drivers for ATI cards. I wish I could say look at driver xxx.x, but I don't really know which one is useful for your card. Kyle I am going to try the ati driver (not catalyst) again later today since that is very easily switched. I will post, or note on IRC, how it works. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) All that glitters is not gold; all that wander are not lost. -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] On the status of BLDC component and Hostmot2
Andy, greetings There is an SVTP7_7i39 bitfile which I believe should arrive with a apt-get install emc2-firmware (and which you might already have) The current release (2.4.6) has the bldc_hall3 component, but doesn't seem to have the three-phase PWM Hostmot2 function so you will need 2.5 to use the 7i39. I have installed the emc2-firmware package and in the 5i20 folder the changelog for firmware release 0.8 says there is a 5i20/SVTP_7I39.PIN The actual file installed is SVTP6_7I39.PIN. The changelog says there is a ti23/SVTP6_7I39.PIN. I take it that ti23 is a typo for 5i23. Now for some wild guessing on naming. SV starts ever name, TP = three phase, 6 is a version number and 7i39 is the daughter board expected. If 6 is the version then it sounds as though the released firmware is behind the version (SVTP7_7i39) to which you refer. Release was December 19 2010 by Jeff Epler. I have not yet found where the actual bit files (and VHDL stuff) are stored. Any advice/help welcomed - I have so many unknowns that I at least want to start with the latest versions of everything. Thanks John Prentice -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] On the status of BLDC component and Hostmot2
On 16 August 2011 21:16, John Prentice j...@castlewd.freeserve.co.uk wrote: Now for some wild guessing on naming. SV starts ever name, TP = three phase, 6 is a version number and 7i39 is the daughter board expected. Not quite. (but partly my fault) SV = Servo, TP = Three Phase, 6 = Supports 6 servos. If 6 is the version then it sounds as though the released firmware is behind the version (SVTP7_7i39) to which you refer. No, sorry, that was a typo. I meant SVTP6. The one you have is, as far as I know, the latest version. I have not yet found where the actual bit files (and VHDL stuff) are stored. The bit files should be in /lib/firmware/hm2 -- atp Torque wrenches are for the obedience of fools and the guidance of wise men -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] On the status of BLDC component and Hostmot2
On Tue, 16 Aug 2011, John Prentice wrote: Date: Tue, 16 Aug 2011 21:16:48 +0100 From: John Prentice j...@castlewd.freeserve.co.uk Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net Subject: Re: [Emc-users] On the status of BLDC component and Hostmot2 Andy, greetings There is an SVTP7_7i39 bitfile which I believe should arrive with a apt-get install emc2-firmware (and which you might already have) The current release (2.4.6) has the bldc_hall3 component, but doesn't seem to have the three-phase PWM Hostmot2 function so you will need 2.5 to use the 7i39. I have installed the emc2-firmware package and in the 5i20 folder the changelog for firmware release 0.8 says there is a 5i20/SVTP_7I39.PIN The actual file installed is SVTP6_7I39.PIN. The changelog says there is a ti23/SVTP6_7I39.PIN. I take it that ti23 is a typo for 5i23. Now for some wild guessing on naming. SV starts ever name, TP = three phase, 6 is a version number and 7i39 is the daughter board expected. SV means servo, TP means ThreePhase, 6 is the number of servo channels (3x 7I39) 7I39 means pinout matches 7I39 If 6 is the version then it sounds as though the released firmware is behind the version (SVTP7_7i39) to which you refer. Release was December 19 2010 by Jeff Epler. I have not yet found where the actual bit files (and VHDL stuff) are stored. Any advice/help welcomed - I have so many unknowns that I at least want to start with the latest versions of everything. Thanks John Prentice -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
On Tue, Aug 16, 2011 at 5:52 AM, gene heskett ghesk...@wdtv.com wrote: But I am using the vesa driver. Nomenclature clash: VESA modes are a set of standardized video resolutions that work on VESA compatible monitors. As you found out, they don't support 16:9 modes very well. They are fixed/enshrined/hardwired in the video card driver (hardware-specific or VESA BIOS based, doesn't matter), but pertain to the monitor VESA driver is a simple video card driver in the X server that uses standard VESA BIOS calls therefore is mostly hardware independent. I am suggesting of forcing your X server (could be VESA or hardware specific, doesn't matter) to use a non-standard non-VESA video mode. Save your existing xorg.conf to xorg.conf.save1 and try this xorg.conf file: Section Device Identifier Videocard0 Driver vesa EndSection Section Screen Identifier Screen0 Device Videocard0 Monitor MyMonitor DefaultDepth 24 SubSection Display Depth 24 Modes 1360x768 EndSubSection EndSection Identifier MyMonitor Modeline 1360x768 85.5 1360 1424 1536 1792 768 771 777 795 EndSection -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
On Tuesday, August 16, 2011 09:13:45 PM Przemek Klosowski did opine: On Tue, Aug 16, 2011 at 5:52 AM, gene heskett ghesk...@wdtv.com wrote: But I am using the vesa driver. Nomenclature clash: VESA modes are a set of standardized video resolutions that work on VESA compatible monitors. As you found out, they don't support 16:9 modes very well. They are fixed/enshrined/hardwired in the video card driver (hardware-specific or VESA BIOS based, doesn't matter), but pertain to the monitor VESA driver is a simple video card driver in the X server that uses standard VESA BIOS calls therefore is mostly hardware independent. I am suggesting of forcing your X server (could be VESA or hardware specific, doesn't matter) to use a non-standard non-VESA video mode. Save your existing xorg.conf to xorg.conf.save1 and try this xorg.conf file: Section Device Identifier Videocard0 Driver vesa EndSection Section Screen Identifier Screen0 Device Videocard0 Monitor MyMonitor DefaultDepth 24 SubSection Display Depth 24 Modes 1360x768 EndSubSection EndSection Identifier MyMonitor Modeline 1360x768 85.5 1360 1424 1536 1792 768 771 777 795 EndSection But AO about an hour ago, I am no longer using the vesa driver. It turns out the radeon driver has been markedly improved since my last test under 8.04. Using the Driver ati in the xorg.conf, it loops through the modline list about 25 times getting started and finally settles on a 1366x768 screen that has square pixels! I can full screen the emc gui and circles are still circles! Motion wise it is not more than a few milliseconds behind the machine, apparently dead accurate and an even bigger wonder is that in 2 startups of emc, I have not seen an un-expected realtime delay! That was a 100% startup fuss running vesa. I an amazed, dumb-founded, slack jawed, and happier than a pig in a well used sty. Beat on me, as a stubborn old fart, I have a good session out behind the woodshed coming. Now if it didn't just loop for about 30 seconds, generating a megabyte plus log file at startx time, it would probably boot the x server 30 seconds faster. But I doubt that is anything _we_ can fix. Thanks for prodding me to at least re-try it. I am pleased as can be that someone has been giving that code some sorely needed TLC. ;-) Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I'm pretending that we're all watching PHIL SILVERS instead of RICARDO MONTALBAN! -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
Comment out most of the unused modelines and it should start faster. On Tuesday, August 16, 2011, gene heskett ghesk...@wdtv.com wrote: On Tuesday, August 16, 2011 09:13:45 PM Przemek Klosowski did opine: On Tue, Aug 16, 2011 at 5:52 AM, gene heskett ghesk...@wdtv.com wrote: But I am using the vesa driver. Nomenclature clash: VESA modes are a set of standardized video resolutions that work on VESA compatible monitors. As you found out, they don't support 16:9 modes very well. They are fixed/enshrined/hardwired in the video card driver (hardware-specific or VESA BIOS based, doesn't matter), but pertain to the monitor VESA driver is a simple video card driver in the X server that uses standard VESA BIOS calls therefore is mostly hardware independent. I am suggesting of forcing your X server (could be VESA or hardware specific, doesn't matter) to use a non-standard non-VESA video mode. Save your existing xorg.conf to xorg.conf.save1 and try this xorg.conf file: Section Device Identifier Videocard0 Driver vesa EndSection Section Screen Identifier Screen0 Device Videocard0 Monitor MyMonitor DefaultDepth 24 SubSection Display Depth 24 Modes 1360x768 EndSubSection EndSection Identifier MyMonitor Modeline 1360x768 85.5 1360 1424 1536 1792 768 771 777 795 EndSection But AO about an hour ago, I am no longer using the vesa driver. It turns out the radeon driver has been markedly improved since my last test under 8.04. Using the Driver ati in the xorg.conf, it loops through the modline list about 25 times getting started and finally settles on a 1366x768 screen that has square pixels! I can full screen the emc gui and circles are still circles! Motion wise it is not more than a few milliseconds behind the machine, apparently dead accurate and an even bigger wonder is that in 2 startups of emc, I have not seen an un-expected realtime delay! That was a 100% startup fuss running vesa. I an amazed, dumb-founded, slack jawed, and happier than a pig in a well used sty. Beat on me, as a stubborn old fart, I have a good session out behind the woodshed coming. Now if it didn't just loop for about 30 seconds, generating a megabyte plus log file at startx time, it would probably boot the x server 30 seconds faster. But I doubt that is anything _we_ can fix. Thanks for prodding me to at least re-try it. I am pleased as can be that someone has been giving that code some sorely needed TLC. ;-) Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) I'm pretending that we're all watching PHIL SILVERS instead of RICARDO MONTALBAN! -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Mesa 5i23/7i33TA servo instability question
All- I'm about a month into retrofitting an older Anilam 1100M 3-axis mill to EMC2 using a Mesa 5i23 PCI board with a 7i33TA for servo interfacing and 7i37TA for general I/O. I'm documenting the build here: http://code.google.com/p/sector67-sandbox/wiki/ProjectSheetCake with my build notes here: http://code.google.com/p/sector67-sandbox/wiki/SheetCakeBuildLog although my documentation is a work in progress, you can get a feel for where I am at with this project. It's volunteer work for a hackerspace and eventually EMC2 is going to enable us to do all sorts of interesting stuff with this hardware. I have been extremely impressed with the overall maturity and capability of the EMC2 ecosystem. The live CD was an absolute time saver and wonderful resource. The sample configurations got me basically going out of the box, pncconf has been unbelievably helpful as I've advanced in what is hooked up, and halmeter and halscope are pure genious. Great job to all involved, and I hope to do my small part by documenting another mill conversion in (hopefully) very accessible detail. To the point, though, I am having one not-so-minor problem. When I enable the servos, they are not completely stable, and I'll get following error almost immediately after enabling them. They don't run away, but the encoders show them moving ever so slightly, and physically the motors actually are moving. The Anilam system I'm converting is a servo drive with velocity feedback directly to the servo amps and rotary encoder output that I've wired to the 7i33TA board. The servo amps take +/-10V for direction and velocity. I can move the axis using the pncconf tuning page, and have tried to stabilize them using the DAC compenstation, but there is not a fixed amount of DAC compensation that seems to work. The Anilam controls still work perfectly fine and the servos are stable when that control is running. I suspect a problem like ground differential, but the cable to the servo amp has ground, signal and shielding, so I was thinking I should be OK. Despite the schematic on the wiki above, I am not powering the 7i33TA or 7i37TA on-board, but instead am using cable power (but I believe that is the only inaccuracy in the schematic). The 50 pin ribbon cables are ~3 feet. Would it be better to power the boards from the 5V supply already in the chassis? Is this a problem that can be solved with PID tuning? Has anyone seen anything like this? I've searched the email list and have not been able to find anyone with the same problem. Thanks very much in advance, Scott -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Mesa 5i23/7i33TA servo instability question
Scott Hasse wrote: To the point, though, I am having one not-so-minor problem. When I enable the servos, they are not completely stable, and I'll get following error almost immediately after enabling them. They don't run away, but the encoders show them moving ever so slightly, and physically the motors actually are moving. Is this between pressing F1 and F2? In that state, when the system is configured a certain way, you can have the F1 enable the servo amps, but not start the positioning loop until F2 is pressed. There will always be some tiny offsets in the DAC outputs or the servo amp zero velocity. So, the motors will creep slowly. This is not a malfunction, and you can never zero out the drift completely. Since a following error will go to the out of estop but machine-off state, you really don't want to leave the machine in this condition. So, you want to set things up so the servo amps are only enabled when in the machine-on state. You would connect a HAL signal such as axis.0.amp-enable-out to the servo amp enable output. If this problem exists when in the machine-on state, then the servo loop is not responding to position errors, and you need to work on the PID tuning. It may be that the output of the PID is not connected to the DAC inputs of the Mesa driver. Jon -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] EMC2 datapoint
Here it is actually working... EMC2 picking and placing. I have lots of software to do now, but it's getting there, and at this point the concept/system has been proven that it will work. http://www.youtube.com/watch?v=OUKeabHpYIc Cheers, -Neil. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Emc vs modern lcd monitors
On Tuesday, August 16, 2011 11:46:25 PM John Murphy did opine: Comment out most of the unused modelines and it should start faster. In between going crazy over a radio, I'll try that tomorrow too. Thanks John. Cheers, gene -- There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order. -Ed Howdershelt (Author) God made the world in six days, and was arrested on the seventh. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 datapoint
Neil wrote: Here it is actually working... EMC2 picking and placing. I have lots of software to do now, but it's getting there, and at this point the concept/system has been proven that it will work. http://www.youtube.com/watch?v=OUKeabHpYIc Well, that is pretty cool. It looks like XYZ, with no rotation? A big part of the pickplace thing is recovering from errors, centering the parts better than they come out of the tape, and handling parts with many different shapes and sizes. Jon -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 datapoint
Oh yes, LOTS to do still, but this is the first successfully working PnP test. The A-axis works but we didn't do any rotation for this test. I also still need to build feeders, add camera image recognition, add positive pressure solenoid for extracting components, and eventually build a nozzle-changer. And lots of software to work with centroid files, etc. And I'm thinking I should design some type of spring-loaded nozzle system to compensate for any minor height differences. Cheers, -Neil. Quoting Jon Elson el...@pico-systems.com: Well, that is pretty cool. It looks like XYZ, with no rotation? A big part of the pickplace thing is recovering from errors, centering the parts better than they come out of the tape, and handling parts with many different shapes and sizes. Jon -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Mesa 5i23/7i33TA servo instability question
On Tue, 16 Aug 2011, Scott Hasse wrote: Date: Tue, 16 Aug 2011 22:15:43 -0500 From: Scott Hasse scott.ha...@gmail.com Reply-To: Enhanced Machine Controller (EMC) emc-users@lists.sourceforge.net To: emc-users@lists.sourceforge.net Subject: [Emc-users] Mesa 5i23/7i33TA servo instability question All- I'm about a month into retrofitting an older Anilam 1100M 3-axis mill to EMC2 using a Mesa 5i23 PCI board with a 7i33TA for servo interfacing and 7i37TA for general I/O. I'm documenting the build here: http://code.google.com/p/sector67-sandbox/wiki/ProjectSheetCake with my build notes here: http://code.google.com/p/sector67-sandbox/wiki/SheetCakeBuildLog although my documentation is a work in progress, you can get a feel for where I am at with this project. It's volunteer work for a hackerspace and eventually EMC2 is going to enable us to do all sorts of interesting stuff with this hardware. I have been extremely impressed with the overall maturity and capability of the EMC2 ecosystem. The live CD was an absolute time saver and wonderful resource. The sample configurations got me basically going out of the box, pncconf has been unbelievably helpful as I've advanced in what is hooked up, and halmeter and halscope are pure genious. Great job to all involved, and I hope to do my small part by documenting another mill conversion in (hopefully) very accessible detail. To the point, though, I am having one not-so-minor problem. When I enable the servos, they are not completely stable, and I'll get following error almost immediately after enabling them. They don't run away, but the encoders show them moving ever so slightly, and physically the motors actually are moving. As Jon Elson mentioned, if this is creep before the EMC has the servo loop closed, this is expected and should be prevented by not enabing the servo drives until EMC is in control. One 7I37TA output can be used for enabling all servo Axis. The Anilam system I'm converting is a servo drive with velocity feedback directly to the servo amps and rotary encoder output that I've wired to the 7i33TA board. The servo amps take +/-10V for direction and velocity. I can move the axis using the pncconf tuning page, and have tried to stabilize them using the DAC compenstation, but there is not a fixed amount of DAC compensation that seems to work. The Anilam controls still work perfectly fine and the servos are stable when that control is running. I suspect a problem like ground differential, but the cable to the servo amp has ground, signal and shielding, so I was thinking I should be OK. Despite the schematic on the wiki above, I am not powering the 7i33TA or 7i37TA on-board, but instead am using cable power (but I believe that is the only inaccuracy in the schematic). The 50 pin ribbon cables are ~3 feet. Normally servo drives have differential inputs (IN+, and IN-) and a ground line. The 7I33TA analog outputs and adjacent grounds should go the the servo drives IN+ and IN- pins respectively. This differential input is what rejects ground (common mode) noise. If you leave an input (like IN-) disconnected you would expect some noisy, flakey behaviour. But at this point its still not clear if you have a noise problem, a creep problem because the drives are enabled before they should be, a servo drive input connection error, or simply that you have not tuned (or even closed) the PID loop yet. (I think pncconf just does an open loop test so it will not hold position) If you make the ferror larger what happens? Would it be better to power the boards from the 5V supply already in the chassis? Is this a problem that can be solved with PID tuning? Has anyone seen anything like this? I've searched the email list and have not been able to find anyone with the same problem. I would not change the default power arrangements unless you have too low 5V power at the 7I33 (say 4.5V) Thanks very much in advance, Scott -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users Peter Wallace Mesa Electronics (\__/) (='.'=) This is Bunny. Copy and paste bunny into your ()_() signature to help him gain world domination. -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2
Re: [Emc-users] EMC2 datapoint
Neil wrote: Oh yes, LOTS to do still, but this is the first successfully working PnP test. The A-axis works but we didn't do any rotation for this test. I also still need to build feeders, add camera image recognition, add positive pressure solenoid for extracting components, and eventually build a nozzle-changer. And lots of software to work with centroid files, etc. And I'm thinking I should design some type of spring-loaded nozzle system to compensate for any minor height differences. Yup, some capacitors vary in thickness from one part to the next in the tape. I have a 12 year-old or so Philips CSM84, with no nozzle changer, no vision, no Z axis. But, it has 3 heads and chuck centering jaws on the heads, plus a large component centering station. It uses a single-pixel camera for picking up fiducials from the board (moves heads in XY while watching the sensor for dark or reflection). It has a human-only camera for locating the pick-up location of parts on the vibratory feeder. It has vacuum sensors on each nozzle and will perform a bunch of different cycles to continue running when something goes wrong. So, if a part gets stuck to the nozzle, it will pop up and down and blow to try to get it to drop off in the dump bucket. If it doesn't get the right vacuum when picking up or just before placing it will dump the part in the bucket, but if the vacuum goes back to normal after using the centering jaws, it will place the part. (Sometimes the part is not picked up well from the tape, but the centering jaws restore it to the proper position.) It does real well with 0805 and SOIC parts, but is pushing the capabilities for SSOP and fine-pitch chips. I was lucky to get about 60 feeders with it, and they are quite complex. Each feeder certainly has over 50 parts in it. All the small feeders are actuated by the same air cylinder that makes the head go up and down. The larger feeders (16 mm tape and up) are operated by an air cylinder in the feeder that is controlled by a valve tripped by the head air cylinder. Jon -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] EMC2 datapoint
Mechanical centering is quite primitive. I'm looking into OpenCV for the image recognition. I have to be able to place 0603's and SSOP's. I do have pressure sensors already but not using it yet in code to detect issues. For feeders though, I'm only building some grooved tracks to guide the tapes, but the head mechanism will have another arm (a spike of sorts) that will feed the tape before taking a part from it. Yes, slower, but so much simpler. Cheers, -Neil. Quoting Jon Elson el...@pico-systems.com: Yup, some capacitors vary in thickness from one part to the next in the tape. I have a 12 year-old or so Philips CSM84, with no nozzle changer, no vision, no Z axis. But, it has 3 heads and chuck centering jaws on the heads, plus a large component centering station. It uses a single-pixel camera for picking up fiducials from the board (moves heads in XY while watching the sensor for dark or reflection). It has a human-only camera for locating the pick-up location of parts on the vibratory feeder. It has vacuum sensors on each nozzle and will perform a bunch of different cycles to continue running when something goes wrong. So, if a part gets stuck to the nozzle, it will pop up and down and blow to try to get it to drop off in the dump bucket. If it doesn't get the right vacuum when picking up or just before placing it will dump the part in the bucket, but if the vacuum goes back to normal after using the centering jaws, it will place the part. (Sometimes the part is not picked up well from the tape, but the centering jaws restore it to the proper position.) It does real well with 0805 and SOIC parts, but is pushing the capabilities for SSOP and fine-pitch chips. I was lucky to get about 60 feeders with it, and they are quite complex. Each feeder certainly has over 50 parts in it. All the small feeders are actuated by the same air cylinder that makes the head go up and down. The larger feeders (16 mm tape and up) are operated by an air cylinder in the feeder that is controlled by a valve tripped by the head air cylinder. Jon -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Mesa 5i23/7i33TA servo instability question
To the point, though, I am having one not-so-minor problem. When I enable the servos, they are not completely stable, and I'll get following error almost immediately after enabling them. They don't run away, but the encoders show them moving ever so slightly, and physically the motors actually are moving. The Anilam system I'm converting is a servo drive with velocity feedback directly to the servo amps and rotary encoder output that I've wired to the 7i33TA board. The servo amps take +/-10V for direction and velocity. I can move the axis using the pncconf tuning page, and have tried to stabilize them using the DAC compenstation, but there is not a fixed amount of DAC compensation that seems to work. The Anilam controls still work perfectly fine and the servos are stable when that control is running. I suspect a problem like ground differential, but the cable to the servo amp has ground, signal and shielding, so I was thinking I should be OK. Despite the schematic on the wiki above, I am not powering the 7i33TA or 7i37TA on-board, but instead am using cable power (but I believe that is the only inaccuracy in the schematic). The 50 pin ribbon cables are ~3 feet. Would it be better to power the boards from the 5V supply already in the chassis? Is this a problem that can be solved with PID tuning? Has anyone seen anything like this? I've searched the email list and have not been able to find anyone with the same problem. If I'm understanding the setup correctly, you have encoders providing position feedback. It's possible there is some offset in the servo amps which is driving the motors slowly even though there is zero at the amp inputs. The PID loops, once tuned, should stop that motion but it likely requires some non-zero value for the Igain (integral) parameter. If you short out the inputs to the servo amps right at the amplifiers themselves, do the motors still move? If so, is there a zero adjustment on the amp? If you've already got a reasonable PID Igain parameter, another possibility is that there is noise in the encoder signal and it is accumulating counts when there is actually no movement. The PID loop thinks it's seeing movement and drives the motor to compensate (trying to maintain zero position on the encoder output). The result is motor movement. One way to determine this is to put a load on the motor. If it's the PID loop driving the motor, it should increase the drive when load is applied, trying to maintain speed. A good way to tell is to monitor the voltage to the motor and see if it increases when the motor is loaded. If it's not the PID integral parameter doing it, the voltage will stay the same and the motor will likely stop under load. I can't say what would be reasonable PID parameters without knowing the scale factors for the PWM output going to the servo amps. Karl -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Mesa 5i23/7i33TA servo instability question
although my documentation is a work in progress, you can get a feel for where I am at with this project. It's volunteer work for a hackerspace and eventually EMC2 is going to enable us to do all sorts of interesting stuff with this hardware. Excellent documentation! When you are finished this I hope you add a link to the wiki. This would be a good example for some to read when thinking about retrofitting particularity servo systems. It's the fact of the problems you encountered and the solutions that helps so much to paint a complete picture. To the point, though, I am having one not-so-minor problem. When I enable the servos, they are not completely stable, and I'll get following error almost immediately after enabling them. They don't run away, but the encoders show them moving ever so slightly, and physically the motors actually are moving. One thing I seemed read in your docs (though you may have done this since) is not getting the encoder scaling set properly. If the scaling is way off you can follow error too soon before PID gets to control much of anything. One way to to measure it, if you can turn the axis by hand is to fire up PNCconf's open loop test - but don't enable the amps. Depending how you power the encoders you maybe able to move the axis a know distance and read the raw counts of the encoder then use that to calculate the scale. What version of EMC are you using? Chris M -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
