On Thu, Dec 5, 2013 at 11:57 PM, Todd Zuercher wrote:
> 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 si
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: "Ro
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
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
On 12/05/2013 09:35 PM, Leonardo Marsaglia wrote:
> 2013/12/5 Jon Elson
>
>> 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
2013/12/5 Jon Elson
> 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".
2013/12/5 Kirk Wallace
> 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 ge
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
On Dec 5, 2013 8:52 PM, "Bertho Stultiens" 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 d
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
On Thu, Dec 5, 2013 at 8:20 PM, Bertho Stultiens 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 (curr
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
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 impro
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
2013/12/4 Charles Steinkuehler
> 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
> 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 n
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
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.
On
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 tree
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
On 5 December 2013 10:40, Dirk 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
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 t
22 matches
Mail list logo
