Re: [Emc-users] Is there an open source program similar to Vericut?
On 04-Dec-13 8:22 PM, Gregg Eshelman wrote: On 12/4/2013 6:53 AM, bigengineer wrote: Hi, I am interested in this too. I have been silent here for a long time, (and was never really active either). But this is something where I might, semi-intelligently, help. :-) Long ago I tried what openscad could do with substracting a cylinder moving along a path. I wasn't impressed with the speed. Unless things have really changed I don't think this will work. Anders' solution however, is something I was thinking about but couldn't really envision how to get started. If there is someone picking this up I would like to help. Although I am not certain how helpfull I will be. I can at least provide complex toolpaths. I am a (siemens) NX user and wrote all postprocessors for the machines we have at work. So, I do know a bit, but very specific for NX of course. Dirk It's not just simulating the tool shape and the material being cut, it needs to simulate the parts of the machine and work and tool holders that could be hit by the tool. There would need to be some quick method of taking measurements of the sizes and locations of clamps, vises etc and entering them into the simulation. The machine would only need to be done once and files for those could be shared so others with the same machine wouldn't have to repeat the measuring and could refine the data. Common sizes of clamps and vises could also be a library for the simulator, resizable to match measurements taken from the users own set. I understand. I have this working for NX for a 5 axis milling machine. Not only simulating toolpaths, but also capable of simulating postprocessor output and simulating actual nc files. Including material removing. But showing and moving machine and vises is a minor thing compared to material removal I think. Although I don't think it is trivial. Dirk -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Is there an open source program similar to Vericut?
On 5 December 2013 10:40, Dirk bigengin...@gmail.com wrote: But showing and moving machine and vises is a minor thing compared to material removal I think. Although I don't think it is trivial. I wonder if a voxel-based approach is simpler, but it rather depends on the required precision. If 1mm voxels on a 100mm cube give a good enough preview then you only need 125kB of data. If you want to simulate 1' cubes to 0.001 then you start looking at 200GB of data. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Is there an open source program similar to Vericut?
On 12/05/2013 11:52 AM, andy pugh wrote: But showing and moving machine and vises is a minor thing compared to material removal I think. Although I don't think it is trivial. I wonder if a voxel-based approach is simpler, but it rather depends on the required precision. If 1mm voxels on a 100mm cube give a good enough preview then you only need 125kB of data. If you want to simulate 1' cubes to 0.001 then you start looking at 200GB of data. The voxel approach is a valid one. You can reduce the data-set size by merging voxels in a plane and volume. There are tree-algorithms to handle such cases and there is an advantage that you only need to split, never merge. However, using trees can be computationally (a lot) more work. But then, it can be used for very high resolution and can be parallelized quite well. -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Is there an open source program similar to Vericut?
On 12/05/2013 12:05 PM, Bertho Stultiens wrote: The voxel approach is a valid one. You can reduce the data-set size by merging voxels in a plane and volume. There are tree-algorithms to handle such cases and there is an advantage that you only need to split, never merge. However, using trees can be computationally (a lot) more work. But then, it can be used for very high resolution and can be parallelized quite well. BTW, the splitting is usually done with the octtree approach (which was mentioned before). It can still generate a huge amount of data. If you want a block of 10 split down to 1mil (0.001), or 4 orders of magnitude, then you need a tree-depth of 14. That would be worst case 10^12 leaf nodes, which is computationally unfeasible. Even a measly 1% fill is 10^10 leaf nodes, which no ordinary computer would want to deal with. My guess is that you could get max. ~2.5 orders of magnitude resolution for any result that should complete in the near future. -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
Well I tried like Andy said increasing the ferror and I can work a lot better. Also my acceleration was too much so I decreased it and now I have a error of 0.2 mm without fine tunning and with the motor moving air for now, I guess that when it's attached to the screw this will be a lot better. One thing about that error is that the motor keeps oscillating between those two points but never stops. Is this a normal behaviour on a bad tunned motor? If I tune it well I would expect the oscillation to dissapear or at least stop at some moment? Thanks as always! Leonardo. 2013/12/4 Leonardo Marsaglia leonardomarsagli...@gmail.com Thanks Andy and Kirk. I think there's nothing activated on the VFD by now, the last whing was the acceleration. About what you say andy, this VFD it's capable of handle a smooth turn without load at 1 hz, but I don't know what's going to happen when the motor is attached to the screw. I will try tomorrow with your advice of using more following error and try to eliminate the oscilation. I thought it was tricky this way because without the screw all the inertia has to be stopped without help. When it's connected to the screw it will behave a lot different, I'll be ataching the motor in the next days because I'm finishing the mechanical adaptation for the encoder. 2013/12/4 andy pugh bodge...@gmail.com On 4 December 2013 22:19, Leonardo Marsaglia leonardomarsagli...@gmail.com wrote: I managed to move the motor and do some tests but I can't get rid of the oscillation from the PID. If I follow the classic way of tunning the algorithm when I increment P I don't see any oscillation until I disturb the motor. When that happens I get a really strong vibration and right after that a following error. What I'm saying is I can't even start to test my error to decrease it. Firstly I would set the folllowing error to about 16, two full turns. (if you get more than that, then you probably do want to stop). Then see if you can kill the oscillation with some D term. Tuning a bare motor is often hard even when it is a real servo, and an induction motor is likely to be worse. One problem you are likely to have, and which I had, was that my VFD didn't do anything at all unless the frequency demand was more than 5Hz. The solution to this might be some sort of inverse deadband, so that even a small velocity demand is at least 5Hz. (1V to the VFD or thereabouts) One way to do this, with a fair bit of tunability is with the lincurve HAL component. You could set that up to give no output with +/- 0.1V demand, 1V with 0.1V demand with X = -10, -0.1. -0.1, +0.1, +0.1 +10 and Y = -10, -1, 0, 0, 1, 10. -- atp If you can't fix it, you don't own it. http://www.ifixit.com/Manifesto -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- *Leonardo Marsaglia*. -- *Leonardo Marsaglia*. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
On 12/05/2013 07:44 AM, Leonardo Marsaglia wrote: Well I tried like Andy said increasing the ferror and I can work a lot better. Also my acceleration was too much so I decreased it and now I have a error of 0.2 mm without fine tunning and with the motor moving air for now, I guess that when it's attached to the screw this will be a lot better. One thing about that error is that the motor keeps oscillating between those two points but never stops. Is this a normal behaviour on a bad tunned motor? If I tune it well I would expect the oscillation to dissapear or at least stop at some moment? Thanks as always! Leonardo. There often is a difference between the feedback resolution and the motor resolution. For instance, if your motor can be moved to within a degree of position, but your encoder feed back can report in tenths of a degree. When you command a position, the motor will get to within a degree, but your encoder says you are not there yet. Over time, your PID will increase its power to make a correction and finally move the motor. The motor moves another degree and over shoots the original position, the encoder reports this and the PID tries to correct in the other direction, causing an oscillation of +/- one degree or more. There should be a deadband parameter you can set to tell the PID to ignore a certain amount of error. Using HALscope to show the position or velocity command and feedback show show this hunting and may give you an idea how much there is. Posting your HALscope screen may help too. -- Kirk Wallace http://www.wallacecompany.com/machine_shop/ http://www.wallacecompany.com/E45/ -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Is there an open source program similar to Vericut?
BTW, the splitting is usually done with the octtree approach (which was mentioned before). It can still generate a huge amount of data. If you want a block of 10 split down to 1mil (0.001), or 4 orders of magnitude, then you need a tree-depth of 14. That would be worst case 10^12 leaf nodes, which is computationally unfeasible. Even a measly 1% fill is 10^10 leaf nodes, which no ordinary computer would want to deal with. My guess is that you could get max. ~2.5 orders of magnitude resolution for any result that should complete in the near future. The problem with a simple voxel model is that for a resolution r, the storage requirement scales with the volume as r^3 (or 1/r^3 depending on how you define resolution). Dan Heeks's cutting simulation uses this approach I think. http://code.google.com/p/voxelcut/ The adaptive approaches subdivide only when necessary, at the stock surface, and so in theory the memory requirement scales with the area or r^2. I'd suggest the future insanely-great linuxcnc cutting-simulator should allow for easily swapping out the stock-model / cutting-engine. The voxel approach might be faster but coarser, and we all have 32 gigs of RAM anyway right? For slower and more accurate work an adaptive octree might be preferable. I'm probably sounding like a broken record player, but I'll repeat anyway: what is needed now is a sound basic framework for pushing these ideas forward - the basic algorithms or individual parts already exist. we need: - a GUI that displays G-code in one window, and a 3D opengl view in another window. - play, pause, stop buttons that run the interpreter on said G-code, and produces internal 'canon' calls for the cutting-engine - a sound, minimal but complete, API for the cutting engine -- tool library (G-code does not define tools!) -- method for defining stock (G-code does not define stock!) -- 'canonical' G-code moves -- graphics output for the 3D view. probably vertex-arrays and polygon-arrays in memory that is shared between the cutting-engine and the 3D view. This should probably run in two or three separate threads, to keep the 3D view and G-code view/buttons responsive. Anders -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Beaglebone USB
2013/12/4 Charles Steinkuehler char...@steinkuehler.net Please try the following. At a command prompt run: sudo aptitude install lightdm When prompted to pick a default display manager, choose lightdm instead of xdm. Once everything is installed, reboot and see if your USB issue is fixed. This only seems to pull in a few additional packages, and the lightdm is trusted by ConsoleKit, so things like the shutdown and reboot icons work (and hopefully your USB disk mounting). First I tried the solution from the thread http://linux.derkeiler.com/Mailing-Lists/Debian/2011-10/msg01232.html No good for USB, though shutdown has been working. Now I tried lightdm, no success either. Andrew -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Beaglebone USB
On 12/05/13 13:16, Andrew wrote: First I tried the solution from the thread http://linux.derkeiler.com/Mailing-Lists/Debian/2011-10/msg01232.html No good for USB, though shutdown has been working. Now I tried lightdm, no success either. Hmm...lightdm fixes the shutdown and reboot GUI features, but there's apparently still something missing for dynamic mounting. Could you walk through exactly what you're doing, what you expect to happen, and what does happen? I'll see if I can replicate your specific error and try to figure out what's wrong. -- Charles -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
[Emc-users] Slow G code
Hi All, As some of you know already, I'm working on an improvement to the linuxcnc trajectory planner that will allow much faster movement for engraving-type programs with lots of short segments. As part of this effort, I need test cases, both to find rare errors, and to estimate performance improvements. If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. Thanks! Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
On 12/06/2013 01:46 AM, Robert Ellenberg wrote: As some of you know already, I'm working on an improvement to the linuxcnc trajectory planner that will allow much faster movement for engraving-type programs with lots of short segments. As part of this effort, I need test cases, both to find rare errors, and to estimate performance improvements. You could use the wheels.gcmc example from gcmc (contributed by Alan Battersby). It creates a lot of small segments of 10..100um. You can even increase the number of segments by decreasing the angle-interval of the calculation (currently at 0.01 degrees). I am a bit reluctant to attach the file due to the size (1.1MByte uncompressed, 450k gzip, 380k bz2 and ~200k with 7-zip). You should easily be able to generate the example yourself. Otherwise let me know. -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
On Thu, Dec 5, 2013 at 8:20 PM, Bertho Stultiens ber...@vagrearg.orgwrote: You could use the wheels.gcmc example from gcmc (contributed by Alan Battersby). It creates a lot of small segments of 10..100um. You can even increase the number of segments by decreasing the angle-interval of the calculation (currently at 0.01 degrees). Thanks, Bertho, I'll give this a shot. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
On 12/06/2013 02:37 AM, Robert Ellenberg wrote: You could use the wheels.gcmc example from gcmc (contributed by Alan Battersby). It creates a lot of small segments of 10..100um. You can even increase the number of segments by decreasing the angle-interval of the calculation (currently at 0.01 degrees). Thanks, Bertho, I'll give this a shot. Great. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. Running gcmc with no file as input will read input from stdin (the command-line) as in good unix tradition. If you do not specify an output file (-o option) then all output is written to stdout. This is done so you can form command-chains with pipes on the command-line. The behavior is described in the man-page (http://www.vagrearg.org/content/gcmc-man). You can terminate with ^C (break) or ^D, which is EOF on *nix systems (or, if using windows, ^Z to indicate EOF). -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
On Dec 5, 2013 8:52 PM, Bertho Stultiens ber...@vagrearg.org wrote: On 12/06/2013 02:37 AM, Robert Ellenberg wrote: You could use the wheels.gcmc example from gcmc (contributed by Alan Battersby). It creates a lot of small segments of 10..100um. You can even increase the number of segments by decreasing the angle-interval of the calculation (currently at 0.01 degrees). Thanks, Bertho, I'll give this a shot. Great. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. Running gcmc with no file as input will read input from stdin (the command-line) as in good unix tradition. If you do not specify an output file (-o option) then all output is written to stdout. This is done so you can form command-chains with pipes on the command-line. The behavior is described in the man-page (http://www.vagrearg.org/content/gcmc-man). You can terminate with ^C (break) or ^D, which is EOF on *nix systems (or, if using windows, ^Z to indicate EOF). Ahh, I see, that's a clever feature! -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
On 12/05/2013 09:44 AM, Leonardo Marsaglia wrote: Well I tried like Andy said increasing the ferror and I can work a lot better. Also my acceleration was too much so I decreased it and now I have a error of 0.2 mm without fine tunning and with the motor moving air for now, I guess that when it's attached to the screw this will be a lot better. One thing about that error is that the motor keeps oscillating between those two points but never stops. Is this a normal behaviour on a bad tunned motor? If I tune it well I would expect the oscillation to dissapear or at least stop at some moment? Is this a flux vector drive, or a standard VFD? A flux-vector drive can perform the computations to keep the rotor excited without moving it. A standard VFD cannot, it has to move the motor to excite the induced field in the rotor. So, it will keep dancing. Jon -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
2013/12/5 Kirk Wallace kwall...@wallacecompany.com There often is a difference between the feedback resolution and the motor resolution. For instance, if your motor can be moved to within a degree of position, but your encoder feed back can report in tenths of a degree. When you command a position, the motor will get to within a degree, but your encoder says you are not there yet. Over time, your PID will increase its power to make a correction and finally move the motor. The motor moves another degree and over shoots the original position, the encoder reports this and the PID tries to correct in the other direction, causing an oscillation of +/- one degree or more. There should be a deadband parameter you can set to tell the PID to ignore a certain amount of error. Using HALscope to show the position or velocity command and feedback show show this hunting and may give you an idea how much there is. Posting your HALscope screen may help too. Well I guess that depends on the VFD itself. I'm still getting used to this VFD since it has a lot of options, even it can work as a PLC, also it has an optional internal PID for positioning works using an extra board for encoder reading. I'm gonna take a look to the deadband component and see if it can help. I also noticed today that I have a little offset between the 0 volts that the mesa sends to the variator and what the VFD thinks is 0 volts so when the command for velocity from LinucCNC is 0 I still have 1 hz or so. I can tune this within the VFD. Tomorrow I will take a look and then I'll tell if I can improve the behaviour of the motor. -- *Leonardo Marsaglia*. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
2013/12/5 Jon Elson el...@pico-systems.com Is this a flux vector drive, or a standard VFD? A flux-vector drive can perform the computations to keep the rotor excited without moving it. A standard VFD cannot, it has to move the motor to excite the induced field in the rotor. So, it will keep dancing. It says that is a FOC (field oriented control) ac drive, so I guess it's not a standard VFD. Anyway it has a lot of options even an autotunning feature so may be I'ts not well configured to get the maximum out of it. Now I have set it to work only with +/- 10 volts and without any acceleration or breaking assistance, so all the acceleration a deceleration it's done by the PID of LinuxCNC. -- *Leonardo Marsaglia*. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
On 12/05/2013 09:35 PM, Leonardo Marsaglia wrote: 2013/12/5 Jon Elson el...@pico-systems.com Is this a flux vector drive, or a standard VFD? A flux-vector drive can perform the computations to keep the rotor excited without moving it. A standard VFD cannot, it has to move the motor to excite the induced field in the rotor. So, it will keep dancing. It says that is a FOC (field oriented control) ac drive, so I guess it's not a standard VFD. Anyway it has a lot of options even an autotunning feature so may be I'ts not well configured to get the maximum out of it. Now I have set it to work only with +/- 10 volts and without any acceleration or breaking assistance, so all the acceleration a deceleration it's done by the PID of LinuxCNC. Ah, then do the autotune and turn off most of the PID features in LinuxCNC. Don't use any I, a low P value and just a little D, and no FFx. Let the drive do most of the hard work. You will probably need to redo the autotune when the motor is connected to a load. Jon -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
Robert has been working very hard on the new TP. Here is an example This program I found on the internet. (small line segments) http://electronicsam.com/images/KandT/testing/internet.ngc 533228 line program running G64P.005 Old TP 2:37:42 New TP 1:38:49 Quite an improvement!! The spiral.ngc program now starts at almost 400 ipm vs 110 ipm currently. There are some issues to work out yet - but as little time it has taken Robert to get this far - I don't think it will take long to get to a beta.. Using this config for testing http://electronicsam.com/images/KandT/testing/circblendlatest/ (500ipm max and 30in/sec^2 acc) sam On 12/05/2013 06:46 PM, Robert Ellenberg wrote: Hi All, As some of you know already, I'm working on an improvement to the linuxcnc trajectory planner that will allow much faster movement for engraving-type programs with lots of short segments. As part of this effort, I need test cases, both to find rare errors, and to estimate performance improvements. If you'd like to contribute to this effort, I'm looking for G-code that runs slower than the requested feed rate. In particular, I'm looking for programs that have lots of short segments that approximate smooth paths. If you have a program that you think should run faster and are willing to share it, please email it to me. While my fixes won't improve every issue, part of my goal here is to survey how common some problems are. If it turns out that a slowdown I consider rare is common in your programs, it will justify some additional work in that direction. Thanks! Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] C2000 vfd + AC inductor motor + LinuxCNC
I will try it with load tomorrow or next monday, because I'm finishing with the encoder coupling for the screw. I never tried the autotunning but it is supposed to tune all the motor parameters to get better torque. I hope that helps to improve the positioning. Anyway as I told before I don't need centesimal accuraty, but now I need to ged rid of that oscillation that doesn't stop. I will try and see what happens the I'll tell you. Off course I'll be uploading some videos when it's working :). Thanks as always! 2013/12/6 Jon Elson el...@pico-systems.com On 12/05/2013 09:35 PM, Leonardo Marsaglia wrote: 2013/12/5 Jon Elson el...@pico-systems.com Is this a flux vector drive, or a standard VFD? A flux-vector drive can perform the computations to keep the rotor excited without moving it. A standard VFD cannot, it has to move the motor to excite the induced field in the rotor. So, it will keep dancing. It says that is a FOC (field oriented control) ac drive, so I guess it's not a standard VFD. Anyway it has a lot of options even an autotunning feature so may be I'ts not well configured to get the maximum out of it. Now I have set it to work only with +/- 10 volts and without any acceleration or breaking assistance, so all the acceleration a deceleration it's done by the PID of LinuxCNC. Ah, then do the autotune and turn off most of the PID features in LinuxCNC. Don't use any I, a low P value and just a little D, and no FFx. Let the drive do most of the hard work. You will probably need to redo the autotune when the motor is connected to a load. Jon -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- *Leonardo Marsaglia*. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
Glad to hear your making progress. Might your modifications work with more than XYZ axis. (I need to run it on 4 axis xyzw.) Would it be ok to send the sample g-code directly to your email? If so I'll try to dig up some extra slow stuff tomorrow at work. - Original Message - From: Robert Ellenberg rwe...@gmail.com To: Enhanced Machine Controller, (EMC) emc-users@lists.sourceforge.net Sent: Thursday, December 5, 2013 9:06:47 PM Subject: Re: [Emc-users] Slow G code On Dec 5, 2013 8:52 PM, Bertho Stultiens ber...@vagrearg.org wrote: On 12/06/2013 02:37 AM, Robert Ellenberg wrote: You could use the wheels.gcmc example from gcmc (contributed by Alan Battersby). It creates a lot of small segments of 10..100um. You can even increase the number of segments by decreasing the angle-interval of the calculation (currently at 0.01 degrees). Thanks, Bertho, I'll give this a shot. Great. By the way, I launched gcmc accidentally with no input, and it seemed to hang. Running with --help listed the arguments nicely, so you might want to treat no arguments the same as --help. Running gcmc with no file as input will read input from stdin (the command-line) as in good unix tradition. If you do not specify an output file (-o option) then all output is written to stdout. This is done so you can form command-chains with pipes on the command-line. The behavior is described in the man-page (http://www.vagrearg.org/content/gcmc-man). You can terminate with ^C (break) or ^D, which is EOF on *nix systems (or, if using windows, ^Z to indicate EOF). Ahh, I see, that's a clever feature! -- Greetings Bertho (disclaimers are disclaimed) -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
Re: [Emc-users] Slow G code
On Thu, Dec 5, 2013 at 11:57 PM, Todd Zuercher zuerc...@embarqmail.comwrote: Glad to hear your making progress. Might your modifications work with more than XYZ axis. (I need to run it on 4 axis xyzw.) It will be compatible with 4+ axes, but most of the improvement will be for XYZ moves only. It falls back to simple parabolic blending if there's movement in the other 6 axes. Would it be ok to send the sample g-code directly to your email? If so I'll try to dig up some extra slow stuff tomorrow at work. Absolutely, that's a good way to avoid the attachment size limit. That's also my dropbox email address, so if you have dropbox and want to share a folder, that works too. Thanks! Rob -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk ___ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
