[Emc-users] What should I do to get the performance back?

[Sven Wesley]

Guys,

I know, poor performance is a every-now-and-then-upcoming-debate...
I had pretty good performance with my old servo drives and Ubuntu 8. I
upgraded to better (more secure) and faster drives and the speed was
marvelous. And then I upgraded to Ubuntu 10 and lost 30 % speed. If I push
the values higher I get RTAI errors.
I'm not using the latest drop, and I think that's not the issue. I would
like to keep Axis, I like it. I really not want to step back to Ubuntu 8...

Anyone with a good speed up suggestion?
Should I go Debian?
Turn the graphic into monochrome?..

Regards,
Sven

[andy pugh]

On 23 October 2012 09:48, Sven Wesley <***@gmail.com> wrote:
> I really not want to step back to Ubuntu 8...

If it worked better, why not?

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Sven Wesley]

2012/10/23 andy pugh <***@gmail.com>

> On 23 October 2012 09:48, Sven Wesley <***@gmail.com> wrote:
> > I really not want to step back to Ubuntu 8...
>
> If it worked better, why not?
>
>
Because it's old, to begin with.

[Michael Haberler]

Am 23.10.2012 um 10:48 schrieb Sven Wesley:

> Guys,
>
> I know, poor performance is a every-now-and-then-upcoming-debate...
> I had pretty good performance with my old servo drives and Ubuntu 8. I
> upgraded to better (more secure) and faster drives and the speed was
> marvelous. And then I upgraded to Ubuntu 10 and lost 30 % speed. If I push
> the values higher I get RTAI errors.
> I'm not using the latest drop, and I think that's not the issue. I would
> like to keep Axis, I like it. I really not want to step back to Ubuntu 8...
>
> Anyone with a good speed up suggestion?
> Should I go Debian?
> Turn the graphic into monochrome?..

the guys wont be able to tell with the level of detail you gave, because the crystal ball is dark today

Please post a configuration, describe the hardware, and explain changing which values get you exactly which "RTAI errors" - since you talk about a servo configuration which has actually moderate requirements if it only requires a servo thread, I do not see yet how an OS version change should make much difference here.

without that information you can expect only random guesswork in response.

- Michael


>
> Regards,
> Sven
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Sven Wesley]

>
>
> the guys wont be able to tell with the level of detail you gave, because
> the crystal ball is dark today
>
> Please post a configuration, describe the hardware, and explain changing
> which values get you exactly which "RTAI errors" - since you talk about a
> servo configuration which has actually moderate requirements if it only
> requires a servo thread, I do not see yet how an OS version change should
> make much difference here.
>
> without that information you can expect only random guesswork in response.
>
> - Michael
>

I have the exact config now as in 8.04, but my config is not what I would
like to discuss. I'm interested in what type of config changes outside
LinuxCNC that can bring the speed up, for example if someone have
experience with another distribution, graphical tuning and such. Not to be
rude, but I'm quite aware of config possibilities.
I've been subscribed to the list for more than a decade, I think I see
myself as one of the "guys". ;)

/S

[Sven Wesley]

2012/10/24 Sven Wesley <***@gmail.com>

>
>> the guys wont be able to tell with the level of detail you gave, because
>> the crystal ball is dark today
>>
>> Please post a configuration, describe the hardware, and explain changing
>> which values get you exactly which "RTAI errors" - since you talk about a
>> servo configuration which has actually moderate requirements if it only
>> requires a servo thread, I do not see yet how an OS version change should
>> make much difference here.
>>
>> without that information you can expect only random guesswork in response.
>>
>> - Michael
>>
>
> I have the exact config now as in 8.04, but my config is not what I would
> like to discuss. I'm interested in what type of config changes outside
> LinuxCNC that can bring the speed up, for example if someone have
> experience with another distribution, graphical tuning and such. Not to be
> rude, but I'm quite aware of config possibilities.
> I've been subscribed to the list for more than a decade, I think I see
> myself as one of the "guys". ;)
>
> /S
>


...To correct myself, I actually don't have the same config as the jitter
went up with 30-40 % when I moved to Ubuntu 10.

[Kent A. Reed]

On 10/24/2012 3:28 PM, Sven Wesley wrote:
>>
>> the guys wont be able to tell with the level of detail you gave, because
>> the crystal ball is dark today
>>
>> Please post a configuration, describe the hardware, and explain changing
>> which values get you exactly which "RTAI errors" - since you talk about a
>> servo configuration which has actually moderate requirements if it only
>> requires a servo thread, I do not see yet how an OS version change should
>> make much difference here.
>>
>> without that information you can expect only random guesswork in response.
>>
>> - Michael
>>
> I have the exact config now as in 8.04, but my config is not what I would
> like to discuss. I'm interested in what type of config changes outside
> LinuxCNC that can bring the speed up, for example if someone have
> experience with another distribution, graphical tuning and such. Not to be
> rude, but I'm quite aware of config possibilities.
> I've been subscribed to the list for more than a decade, I think I see
> myself as one of the "guys". ;)
>
> /S
>

Nevertheless, Sven, it would helpful to know details about your
computer---motherboard, bios version, cpu, ram, etc. Like Michael said,
"I do not see yet how an OS version change should make much difference
here."

Yes, we want to help you get back your performance, but we also want to
be able to characterize how an OS version change may or may not affect
others. I personally don't believe that a change to another distribution
will recover anything like a 30-percent drop in performance.

One of the things I've been annoyed by in recent distributions is the
ever increasing requirement for hardware support of OpenGL and its
extensions. A recent rant
http://www.phoronix.com/scan.php?page=news_item&px=MTIxMTg is instructive.

With this in mind (and you did mentioned graphics first), have you tried
my favorite trick and run your LinuxCNC host in headless mode, using
another computer to provide X services? A quick test would confirm if
you are being undone by your host's graphics subsystem.

Regards,
Kent

[Sven Wesley]

>
>
> Nevertheless, Sven, it would helpful to know details about your
> computer---motherboard, bios version, cpu, ram, etc. Like Michael said,
> "I do not see yet how an OS version change should make much difference
> here."
>
> Yes, we want to help you get back your performance, but we also want to
> be able to characterize how an OS version change may or may not affect
> others. I personally don't believe that a change to another distribution
> will recover anything like a 30-percent drop in performance.
>
> One of the things I've been annoyed by in recent distributions is the
> ever increasing requirement for hardware support of OpenGL and its
> extensions. A recent rant
> http://www.phoronix.com/scan.php?page=news_item&px=MTIxMTg is instructive.
>
> With this in mind (and you did mentioned graphics first), have you tried
> my favorite trick and run your LinuxCNC host in headless mode, using
> another computer to provide X services? A quick test would confirm if
> you are being undone by your host's graphics subsystem.
>
> Regards,
> Kent
>
>
True, I could gather some HW info and post it. I'll do that. Your idea with
a headless machine is a great test! I have a small feeling that graphics is
a suspect in my system. I also had an idea of swapping the graphics card
with another one to see if there's something happening.

@Lars, in my first post I write about servo drives and speed, I'm not sure
_how_that_ can be translated into G-code loading. When EMC2 was moved to
10.04 there where quite a few who found out that the latency went up and
machine speed was lost, that was while ago and I ignored it by the time
because I stayed on the 8.04-release.

/S

[Lars Kruse]

Hi,

> @Lars, in my first post [..]

to avoid any confusion for other readers: I sent a private mail to Sven
yesterday explaining that FMPOV he needs to be more specific about the meaning
of "speed" and how he measured its decline.

cheers,
Lars

[Sven Wesley]

2012/10/25 Lars Kruse <***@sumpfralle.de>

> Hi,
>
> > @Lars, in my first post [..]
>
> to avoid any confusion for other readers: I sent a private mail to Sven
> yesterday explaining that FMPOV he needs to be more specific about the
> meaning
> of "speed" and how he measured its decline.
>
> cheers,
> Lars
>
>
Sorry Lars, didn't see that the message was privately sent. My apologies.

/S

[andy pugh]

On 25 October 2012 08:48, Sven Wesley <***@gmail.com> wrote:

> True, I could gather some HW info and post it. I'll do that. Your idea with
> a headless machine is a great test!

Software open-GL might be another interesting test along the same lines.

If this is a servo system, though, it would seem unlikely that latency
would have any effect on the performance of the CNC machine, so this
might all be a blind alley.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Sven Wesley]

>
>
> > True, I could gather some HW info and post it. I'll do that. Your idea
> with
> > a headless machine is a great test!
>
> Software open-GL might be another interesting test along the same lines.
>
> If this is a servo system, though, it would seem unlikely that latency
> would have any effect on the performance of the CNC machine, so this
> might all be a blind alley.
>
>
In fact, this is a servo based step/dir system (my big steel router) and
not a closed loop á la Mesa style servo system.

/S

[andy pugh]

On 25 October 2012 11:44, Sven Wesley <***@gmail.com> wrote:

> In fact, this is a servo based step/dir system (my big steel router) and
> not a closed loop á la Mesa style servo system.

If you are limited by software step generation then I strongly
advocate a change to a Mesa 5i25 if you have a PCI slot.
The pinout may be identical on the DB25 so you have no wiring changes
to make, and you might well find that you have very much more
performance than you had before unless the previous limit was servo
performance.

I think that counts as a way to get the performance back. Though it
will cost you $80.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Sven Wesley]

2012/10/25 andy pugh <***@gmail.com>

> On 25 October 2012 11:44, Sven Wesley <***@gmail.com> wrote:
>
> > In fact, this is a servo based step/dir system (my big steel router) and
> > not a closed loop á la Mesa style servo system.
>
> If you are limited by software step generation then I strongly
> advocate a change to a Mesa 5i25 if you have a PCI slot.
> The pinout may be identical on the DB25 so you have no wiring changes
> to make, and you might well find that you have very much more
> performance than you had before unless the previous limit was servo
> performance.
>
> I think that counts as a way to get the performance back. Though it
> will cost you $80.
>
>
Now we're talking. :)

[Gene Heskett]

On Thursday 25 October 2012 10:48:10 Sven Wesley did opine:

> 2012/10/25 andy pugh <***@gmail.com>
>
> > On 25 October 2012 11:44, Sven Wesley <***@gmail.com> wrote:
> > > In fact, this is a servo based step/dir system (my big steel router)
> > > and not a closed loop ل la Mesa style servo system.
> >
> > If you are limited by software step generation then I strongly
> > advocate a change to a Mesa 5i25 if you have a PCI slot.
> > The pinout may be identical on the DB25 so you have no wiring changes
> > to make, and you might well find that you have very much more
> > performance than you had before unless the previous limit was servo
> > performance.
> >
> > I think that counts as a way to get the performance back. Though it
> > will cost you $80.
>
> Now we're talking. :)

I'd agree, but those of us using the D525MW need a 5i25 that will fit that
teeny little slot on that board. It has crossed my mind to do that at
least once in the last year, but that is the show stopper. Its something
that I would need to get to a RELIABLE 20 ipm on the z drive of my lathe.
I think I can get to about 35ipm IF I had enough psu to hold the voltage up
while the driver was set wide open (4.2 amps, a bit under the motors needs
for full jerk wired parallel) & the 8 wire motor was wired parallel. My x
motor is wired that way now, but needs more psu and psu cooling to do that
to Z.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
One good turn deserves another.
-- Gaius Petronius

[Peter C. Wallace]

On Thu, 25 Oct 2012, Gene Heskett wrote:

>I'd agree, but those of us using the D525MW need a 5i25 that will fit that
>teeny little slot on that board. It has crossed my mind to do that at
>least once in the last year, but that is the show stopper. Its something
>that I would need to get to a RELIABLE 20 ipm on the z drive of my lathe.
>I think I can get to about 35ipm IF I had enough psu to hold the voltage up
>while the driver was set wide open (4.2 amps, a bit under the motors needs
>for full jerk wired parallel) & the 8 wire motor was wired parallel. My x
>motor is wired that way now, but needs more psu and psu cooling to do that
>to Z.
>
>Cheers, Gene
>--
>"There are four boxes to be used in defense of liberty:
> soap, ballot, jury, and ammo. Please use in that order."
>2B-Ed Howdershelt (Author)
>My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
>One good turn deserves another.
> -- Gaius Petronius


The 5i25 works fine in a D525MW...

Peter Wallace
Mesa Electronics

[Gene Heskett]

On Thursday 25 October 2012 14:54:50 Peter C. Wallace did opine:

> On Thu, 25 Oct 2012, Gene Heskett wrote:
> >I'd agree, but those of us using the D525MW need a 5i25 that will fit
> >that teeny little slot on that board. It has crossed my mind to do
> >that at least once in the last year, but that is the show stopper.
> >Its something that I would need to get to a RELIABLE 20 ipm on the z
> >drive of my lathe. I think I can get to about 35ipm IF I had enough
> >psu to hold the voltage up while the driver was set wide open (4.2
> >amps, a bit under the motors needs for full jerk wired parallel) & the
> >8 wire motor was wired parallel. My x motor is wired that way now,
> >but needs more psu and psu cooling to do that to Z.
> >
> >Cheers, Gene
>
> The 5i25 works fine in a D525MW...
>
> Peter Wallace
> Mesa Electronics

I was under the impression it was straight pci, Peter.

And my boards IIRC have a teeny little pci-e slot. But I'll sure look
again. Wet ram, at my age, isn't that dependable. :)
>
> ------------------------------------------------------------------------
> ------ Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
#if _FP_W_TYPE_SIZE < 64
#error "Only stud muffins allowed, schmuck."
#endif
-- linux/arch/sparc64/quad.c

[Stephen Dubovsky]

> I was under the impression it was straight pci, Peter.
>
> And my boards IIRC have a teeny little pci-e slot.

The 6i25 is the PCIE version of the 5i25.

Stephen

[Gene Heskett]

On Thursday 25 October 2012 16:30:11 Stephen Dubovsky did opine:

> > I was under the impression it was straight pci, Peter.
> >
> > And my boards IIRC have a teeny little pci-e slot.
>
> The 6i25 is the PCIE version of the 5i25.
>
> Stephen
>
And a careful look at the MB's connector layout, it shows the D525MW has
BOTH a single full pci slot against the left edge, AND a mini-pci-e that
takes a laydown card of limited height else it hits the pci slot or a card
in it.

And I don't recall putting anything in either slot when I unpacked them.

Am I to understand then that if I put a 5i25 in, the regular parport then
becomes available for other controls? This would be rather handy on the
mill, for stuff like controlling the air to the mister etc. Thinking... :)

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Beauty:
What's in your eye when you have a bee in your hand.

[andy pugh]

On 25 October 2012 21:38, Gene Heskett <***@wdtv.com> wrote:

> Am I to understand then that if I put a 5i25 in, the regular parport then
> becomes available for other controls?

Yes. But then for only another $120 you could add a 7i76 and have a
handy breakout and 32(?) proper IO pins in addition to the step/dir
outputs.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Gandjpappy]

Brand new to Linux and LinuxCNC. I have an old CNC Mill that I am gutting and even though it had been converted with a stand alone motion board, I am thinking about starting over with LinuxCnC.

My question is on the Mesa boards. My mill uses servos so it looks like a 5i25 and 7i77 would work but I read where someone was using a 5i20. Will they both do the job and if so what would be the advantage of one or the other?

Thanks in advance.

Greg

[andy pugh]

On 25 October 2012 23:43, Gandjpappy <***@aol.com> wrote:

> My question is on the Mesa boards.


Don't forget to look at the Pico solutions too.
http://www.pico-systems.com/motion.html

> My mill uses servos so it looks like a 5i25 and 7i77 would work but I read where someone was using a 5i20. Will they both do the job and if so what would be the advantage of one or the other?

The 5i20 / 5i21 / 5i23 boards have more pins, so you can connect more
daughter boards. They cost a bit more, and tend to be not as easy to
wire.
It's much easier to switch between firmwares and configs with those
boards, as the firmware is reloaded every time LinuxCNC starts up.

I think there are some firmwares that can't run on the *i25 boards.


--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[mark center]

The 5i25 + 7i77 is as close to dead simple easy as my limited knowledge and
ability could imagine. All of my problems were user error. The combo-pak
comes with firmwares pre-loaded. The only feature I that would have helped
was better A/D input resolution and accuracy, but that is a rather odd need.

The IRC chat is spectacular for getting these going. JThornton has a
web-page to help and one of the devs at Mesa is regularly available. I have
been super happy with mine.

Mark Center

On Thu, Oct 25, 2012 at 5:51 PM, andy pugh <***@gmail.com> wrote:

> On 25 October 2012 23:43, Gandjpappy <***@aol.com> wrote:
>
> > My question is on the Mesa boards.
>
>
> Don't forget to look at the Pico solutions too.
> http://www.pico-systems.com/motion.html
>
> > My mill uses servos so it looks like a 5i25 and 7i77 would work but I
> read where someone was using a 5i20. Will they both do the job and if so
> what would be the advantage of one or the other?
>
> The 5i20 / 5i21 / 5i23 boards have more pins, so you can connect more
> daughter boards. They cost a bit more, and tend to be not as easy to
> wire.
> It's much easier to switch between firmwares and configs with those
> boards, as the firmware is reloaded every time LinuxCNC starts up.
>
> I think there are some firmwares that can't run on the *i25 boards.
>
>
> --
> atp
> If you can't fix it, you don't own it.
> http://www.ifixit.com/Manifesto
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Gene Heskett]

On Thursday 25 October 2012 17:30:38 andy pugh did opine:

> On 25 October 2012 21:38, Gene Heskett <***@wdtv.com> wrote:
> > Am I to understand then that if I put a 5i25 in, the regular parport
> > then becomes available for other controls?
>
> Yes. But then for only another $120 you could add a 7i76 and have a
> handy breakout and 32(?) proper IO pins in addition to the step/dir
> outputs.

For me and my toys, that is serious overkill, Andy.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
I called my parents the other night, but I forgot about the time
difference.
They're still living in the fifties.
-- Strange de Jim

[Sven Wesley]

I did some testing yesterday. I upgraded the graphics driver (Nvidia) and
the latency test went from 18 000 to 150 000... I removed the driver and
reconfigured X and came down to a sweet 7 000, but there's something
messing things up as the latency all of a sudden popped up to 15 800.
Running the machine headless is on my top prio to see what happens. Mesa
card is high on the wish list too. I have a new machine project and Mesa is
the way to go in that case (5 axis 3,3 m long).

Andy, Gene and Pete, same guys replied to my questions ages ago. Good to
see you're still here. :-)

/S

[Gene Heskett]

On Friday 26 October 2012 04:29:34 Sven Wesley did opine:

> I did some testing yesterday. I upgraded the graphics driver (Nvidia)
> and the latency test went from 18 000 to 150 000... I removed the
> driver and reconfigured X and came down to a sweet 7 000, but there's
> something messing things up as the latency all of a sudden popped up to
> 15 800. Running the machine headless is on my top prio to see what
> happens. Mesa card is high on the wish list too. I have a new machine
> project and Mesa is the way to go in that case (5 axis 3,3 m long).
>
> Andy, Gene and Pete, same guys replied to my questions ages ago. Good to
> see you're still here. :-)
>
> /S

Thanks for the flowers Sven. As for still here, I had a birthday a few
days back, and can now truthfully say that I've been 39 and holding, for 39
years, so the shotgun that runs me off will probably resemble Father Time's
Scythe.

That said, the praise we've been giving the Intel D525MW motherboard is
well deserved. For about a $260 line on your card statement, a complete
box in shoebox fashion, that has latency figures in the 3 to 7 microsecond
range can be on the end of your parport cable. Both my toy mill and my toy
lathe could run faster now but would need more amps and volts from the psu
to do it, the cpu isn't the limit. Considering the spindle power either
machine has is 10% of what it needs, its working very well indeed, but is
harder on carbide chips than they should be because the cut is so thin.

IOW, don't fight with a box that is unsuitable for the job. Bin it, and
get one of these that runs things faster, on 20% or less the power
consumption of the older box that is eating your lunch with its assorted
gotchas. Once configured, these D525MW's Just Work(TM).

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
BOFH excuse #44:

bank holiday - system operating credits not recharged

[Sven Wesley]

>
> Thanks for the flowers Sven. As for still here, I had a birthday a few
> days back, and can now truthfully say that I've been 39 and holding, for 39
> years, so the shotgun that runs me off will probably resemble Father Time's
> Scythe.
>
> That said, the praise we've been giving the Intel D525MW motherboard is
> well deserved. For about a $260 line on your card statement, a complete
> box in shoebox fashion, that has latency figures in the 3 to 7 microsecond
> range can be on the end of your parport cable. Both my toy mill and my toy
> lathe could run faster now but would need more amps and volts from the psu
> to do it, the cpu isn't the limit. Considering the spindle power either
> machine has is 10% of what it needs, its working very well indeed, but is
> harder on carbide chips than they should be because the cut is so thin.
>
> IOW, don't fight with a box that is unsuitable for the job. Bin it, and
> get one of these that runs things faster, on 20% or less the power
> consumption of the older box that is eating your lunch with its assorted
> gotchas. Once configured, these D525MW's Just Work(TM).
>
> Cheers, Gene
>

Even better, a D525MW would fit _inside_ my servo controller cabinet...

/S

[andy pugh]

On 26 October 2012 11:21, Sven Wesley <***@gmail.com> wrote:

> Even better, a D525MW would fit _inside_ my servo controller cabinet...

At that point consider a 12V input PicoPSU (assuming there is 12V in
the cabinet) or possibly even a 12V input motherboard (though I don't
think we have found one which is known to be properly good in all
respects yet. The DN2800 is OK if you don't mind only having 1024x768
resolution and want to use VGA rather than HDMI. Otherwise graphics
support in Linux is problematic. Bear in mind that this PCI-E too, so
needs a 6i25.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Gene Heskett]

On Friday 26 October 2012 09:14:36 Sven Wesley did opine:

> > Thanks for the flowers Sven. As for still here, I had a birthday a
> > few days back, and can now truthfully say that I've been 39 and
> > holding, for 39 years, so the shotgun that runs me off will probably
> > resemble Father Time's Scythe.
> >
> > That said, the praise we've been giving the Intel D525MW motherboard
> > is well deserved. For about a $260 line on your card statement, a
> > complete box in shoebox fashion, that has latency figures in the 3 to
> > 7 microsecond range can be on the end of your parport cable. Both my
> > toy mill and my toy lathe could run faster now but would need more
> > amps and volts from the psu to do it, the cpu isn't the limit.
> > Considering the spindle power either machine has is 10% of what it
> > needs, its working very well indeed, but is harder on carbide chips
> > than they should be because the cut is so thin.
> >
> > IOW, don't fight with a box that is unsuitable for the job. Bin it,
> > and get one of these that runs things faster, on 20% or less the
> > power consumption of the older box that is eating your lunch with its
> > assorted gotchas. Once configured, these D525MW's Just Work(TM).
> >
> > Cheers, Gene
>
> Even better, a D525MW would fit _inside_ my servo controller cabinet...
>
> /S

There you go. :) Its psu is different, which is why I bought the whole box
with a 250Gb rotating drive, and an optical drive to facilitate the install
from our cd based on 10-04.4 LTS. Apparently total compatibility. Go into
the bios (update it to latest first), turn off the hyperthreading, install
from the cd, then add "isolcpus=1" to the kernel command line in grub.conf,
and its off to the races. I have cat5 to both boxes, and update-manager
scans for updates daily, so when I go out to do something, I usually let
them do the updates while I'm mounting the work.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
The best way to make a fire with two sticks is to make sure one of them
is a match.
-- Will Rogers

[Kent A. Reed]

On 10/26/2012 2:10 AM, Sven Wesley wrote:
> I did some testing yesterday. I upgraded the graphics driver (Nvidia) and
> the latency test went from 18 000 to 150 000... I removed the driver and
> reconfigured X and came down to a sweet 7 000, but there's something
> messing things up as the latency all of a sudden popped up to 15 800.
> Running the machine headless is on my top prio to see what happens. Mesa
> card is high on the wish list too. I have a new machine project and Mesa is
> the way to go in that case (5 axis 3,3 m long).
>
> Andy, Gene and Pete, same guys replied to my questions ages ago. Good to
> see you're still here. :-)
>
> /S
>

Glad to hear you are making progress, Sven.

I know it's wrong but the little boy in me wants to do a victory dance.
People keep downplaying the impact of the graphics subsystem but in my
experience it still ranks ahead of other problems when latency kicks up.
We remain blissfully ignorant of the interplay between the graphics
hardware, its drivers, and the BIOS, in which direct-memory-access
figure prominently. For a while I was hoping the open-source BIOS
initiative would prevail but it remains irrelevant in the face of rapid
advances in Intel x86 and ARM technology. I don't see any hope we'll
ever have BIOSes we can not only examine but also fix (like when Intel
screwed up its EPP-setting scheme).

Running systems headless is one of the tests I routinely perform before
posting latency-test results to the Wiki.

On the plus side, I expect someday to see someone successfully exploit
the GPU to offload some of our CNC calculations from the CPU. The
horsepower is there; it's a matter of timing.

Regards,
Kent

[dave]

On Fri, 2012-10-26 at 11:36 -0400, Kent A. Reed wrote:
> On 10/26/2012 2:10 AM, Sven Wesley wrote:
> > I did some testing yesterday. I upgraded the graphics driver (Nvidia) and
> > the latency test went from 18 000 to 150 000... I removed the driver and
> > reconfigured X and came down to a sweet 7 000, but there's something
> > messing things up as the latency all of a sudden popped up to 15 800.
> > Running the machine headless is on my top prio to see what happens. Mesa
> > card is high on the wish list too. I have a new machine project and Mesa is
> > the way to go in that case (5 axis 3,3 m long).
> >
> > Andy, Gene and Pete, same guys replied to my questions ages ago. Good to
> > see you're still here. :-)
> >
> > /S
> >
>
> Glad to hear you are making progress, Sven.
>
> I know it's wrong but the little boy in me wants to do a victory dance.
> People keep downplaying the impact of the graphics subsystem but in my
> experience it still ranks ahead of other problems when latency kicks up.
> We remain blissfully ignorant of the interplay between the graphics
> hardware, its drivers, and the BIOS, in which direct-memory-access
> figure prominently. For a while I was hoping the open-source BIOS
> initiative would prevail but it remains irrelevant in the face of rapid
> advances in Intel x86 and ARM technology. I don't see any hope we'll
> ever have BIOSes we can not only examine but also fix (like when Intel
> screwed up its EPP-setting scheme).
>
> Running systems headless is one of the tests I routinely perform before
> posting latency-test results to the Wiki.
>
> On the plus side, I expect someday to see someone successfully exploit
> the GPU to offload some of our CNC calculations from the CPU. The
> horsepower is there; it's a matter of timing.
>
> Regards,
> Kent
>
Hi Kent,

Offloading to the GPU is a most obvious approach ....in the manner of
math profs with chalk in the right hand and the eraser in the
left ..."it is obvious that". <grin>

Most of the present day GPU's wouldn't even strain handling motion the
problem is simply that processors (GPU) are a moving target and
reinventing the wheel with each new generation of GPU would be a pain to
the most dedicated programmer. Now if one is bright enough (don't look
at me) to build an engine that does the development the the strain gets
lowered some.
Sharing a video chip between motion and display would certainly present
some interesting problems unless one has two boards and dedicates one to
motion.

Along different lines I keep waiting for someone to write a driver
between linuxcnc and something like mesa's softdmc.

Both of these rather break the original philosophy of emc/linuxcnc but
nothing in technology is really static.

Nomex suit is donned. Have at it.

Dave


>
> ------------------------------------------------------------------------------
> The Windows 8 Center
> In partnership with Sourceforge
> Your idea - your app - 30 days. Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Charles Steinkuehler]

On 10/26/2012 11:19 AM, dave wrote:
> Hi Kent,
>
> Offloading to the GPU is a most obvious approach ....in the manner
> of math profs with chalk in the right hand and the eraser in the
> left ..."it is obvious that". <grin>
>
> Most of the present day GPU's wouldn't even strain handling motion
> the problem is simply that processors (GPU) are a moving target
> and reinventing the wheel with each new generation of GPU would be
> a pain to the most dedicated programmer. Now if one is bright
> enough (don't look at me) to build an engine that does the
> development the the strain gets lowered some. Sharing a video chip
> between motion and display would certainly present some interesting
> problems unless one has two boards and dedicates one to motion.

At my day job, we do a *LOT* of processing with the GPU, and it isn't
really applicable to the LinuxCNC work-load. There aren't nearly
enough parallel calculations required, and latency is a significant
issue. The GPU excels when you need massively parallel calculations
and can wait a bit for the results. Our use for the GPU is mixing and
manipulating HD video images in real time, and we are operating on
(very) large data sets in apx. 15 mS 'chunks', which would make for
pretty lousy servo loop timing.

> Along different lines I keep waiting for someone to write a driver
> between linuxcnc and something like mesa's softdmc.

I'm looking into the AM335x family of ARM chips from TI (ie:
BeagleBone and friends). This part includes not only a 700+ MHz ARM
core with 3D processor for running Linux, but two 32-bit
microcontrollers that run at 1/2 the ARM clock frequency and have
direct access to hardware I/O.

I think this could make an excellent inexpensive LinuxCNC platform by
crafting a software version of the normal Mesa/Pico hardware running
hard real time on the embedded micro-controllers. Real hardware would
still be faster and more capable, but the programmable
micro-controllers would run rings around a normal x86 based parallel
port software solution.

There are also 3 high-performance PWM generators and hardware encoder
inputs, so you could have 3 very high-performance channels and an
arbitrary mix of slightly lower performance I/O implemented in software.

...oh, and there's a 12-bit A/D on board too.

The catch will be to see what the latency numbers look like (I don't
have hardware in-hand to play with yet, I'm waiting to see if my TI
rep will get me one of these: http://www.ti.com/tool/tmdssk3358#3 or
if I'll have to buy it myself).

- --
Charles Steinkuehler
***@steinkuehler.net

[Kent A. Reed]

On 10/26/2012 12:36 PM, Charles Steinkuehler wrote:
> At my day job, we do a*LOT* of processing with the GPU, and it isn't
> really applicable to the LinuxCNC work-load. There aren't nearly
> enough parallel calculations required, and latency is a significant
> issue. The GPU excels when you need massively parallel calculations
> and can wait a bit for the results. Our use for the GPU is mixing and
> manipulating HD video images in real time, and we are operating on
> (very) large data sets in apx. 15 mS 'chunks', which would make for
> pretty lousy servo loop timing.
Like I said, it's a matter of timing. I don't care if the GPU is
underloaded but freely admit I didn't know how bad the timing issue is.

By the way, I haven't gotten around to congratulating you on getting
your MendelMax into operation. Good work! I'm still putzing with the
extruder on my Mendel.

Regards,
Kent

[cogoman]

On 10/26/2012 12:36 PM, Charles Steinkuehler wrote:
> The catch will be to see what the latency numbers look like (I don't
> have hardware in-hand to play with yet, I'm waiting to see if my TI
> rep will get me one of these:http://www.ti.com/tool/tmdssk3358#3 or
> if I'll have to buy it myself).
It looks like it could be usable for LinuxCNC, but are they kidding
about using it as a thermostat? $199 for a smart thermostat, and you
still have to add temperature sensing AND the switch to drive the
heating system. Seems link TI doesn't know what applications this thing
would really be good for.

[Kent A. Reed]

On 10/26/2012 12:19 PM, dave wrote:
> On Fri, 2012-10-26 at 11:36 -0400, Kent A. Reed wrote:
>> <blah blah blah>
>>
>> On the plus side, I expect someday to see someone successfully exploit
>> the GPU to offload some of our CNC calculations from the CPU. The
>> horsepower is there; it's a matter of timing.
>>
>> Regards,
>> Kent
>>
> Hi Kent,
>
> Offloading to the GPU is a most obvious approach ....in the manner of
> math profs with chalk in the right hand and the eraser in the
> left ..."it is obvious that". <grin>

I always liked the Sydney Harris cartoon.
http://www.sciencecartoonsplus.com/images/miracle_sharris.gif

> Most of the present day GPU's wouldn't even strain handling motion the
> problem is simply that processors (GPU) are a moving target and
> reinventing the wheel with each new generation of GPU would be a pain to
> the most dedicated programmer.

Agreed, this makes the problem hard, but not unsolvable, I think. In
general form, the hardware shaders are pretty well understood (after
all, Microsoft manages to keep DirectX alive). I can think of several
programming techniques (and I'm not up to date) for separating the what
from the how so we could port more easily from one GPU to another. I
have lost touch with a fellow NIST'er (also retired) who was exploring
this in the context of solving massive sets of coupled differential
equations that arise in analyses of heat- and mass- transfer in
practical machines and systems.

Too bad we can't make this a Google "Summer of Code" project.

> Now if one is bright enough (don't look
> at me) to build an engine that does the development the the strain gets
> lowered some.
> Sharing a video chip between motion and display would certainly present
> some interesting problems unless one has two boards and dedicates one to
> motion.

Who said "sharing"? Remember, I'm the guy who likes to run headless
systems so why not take advantage of the built-in GPU? Besides, a second
graphics card is small beer these days---always assuming there's a spare
slot :-(

> Along different lines I keep waiting for someone to write a driver
> between linuxcnc and something like mesa's softdmc.
>
> Both of these rather break the original philosophy of emc/linuxcnc but
> nothing in technology is really static.

Fortunately, we---the LinuxCNC community---have been lucky finding folks
willing to try new things.

> Nomex suit is donned. Have at it.

Flames? Nah. Smile, maybe.

>
> Dave

Regards,
Kent

[John Stewart]

Hmmm -

On 2012-10-26, at 12:44 PM, Kent A. Reed wrote:
> On 10/26/2012 12:19 PM, dave wrote:
>> On Fri, 2012-10-26 at 11:36 -0400, Kent A. Reed wrote:
>> Most of the present day GPU's wouldn't even strain handling motion the
>> problem is simply that processors (GPU) are a moving target and
>> reinventing the wheel with each new generation of GPU would be a pain to
>> the most dedicated programmer.
>
> Agreed, this makes the problem hard, but not unsolvable,


OpenCL on Linux is ok. At least it was last time I tried it. I started a blog on some stuff I did OpenCL wise:

http://gpucomputes.blogspot.com

(It was set up not as a technical treatise, but for students) (oh, and I ran the code on OSX for the blog, but the code does/did run on Linux)

Unfortunately, about the time of the last entry, I had to move to development off of the iPhone and to Android, which does not support OpenCL. So, I have not done much with the blog in a year.

The GPU is massively parallel, but takes time to send/retrieve data. If you have a massively parallel task, then things are possibly ok.

JohnS.

----

John Alexander Stewart
***@crc.ca

[cogoman]

On 10/26/2012 02:47 PM, John Stewart wrote:
> OpenCL on Linux is ok. At least it was last time I tried it. I started a blog on some stuff I did OpenCL wise:
>
> http://gpucomputes.blogspot.com
>
> (It was set up not as a technical treatise, but for students) (oh, and I ran the code on OSX for the blog, but the code does/did run on Linux)
I don't mean to try to make work for someone else (my C skills are
modest at best), but could this be the opportunity to try to break out
of the one line look ahead limitation? OpenCL program reads a bunch of
lines ahead, and maps out the best trajectory for the path to keep the
tool moving quickly, then lets the real time software know how fast it
can step through the result.

[Peter C. Wallace]

On Fri, 26 Oct 2012, cogoman wrote:

> Date: Fri, 26 Oct 2012 19:21:01 -0400
> From: cogoman <***@optimum.net>
> Reply-To: "Enhanced Machine Controller (EMC)"
> <emc-***@lists.sourceforge.net>
> To: "Enhanced Machine Controller (EMC)" <emc-***@lists.sourceforge.net>
> Subject: Re: [Emc-users] Using GPU horsepower,
> was Re: What should I do to get the performance back?
>
> On 10/26/2012 02:47 PM, John Stewart wrote:
>> OpenCL on Linux is ok. At least it was last time I tried it. I started a blog on some stuff I did OpenCL wise:
>>
>> http://gpucomputes.blogspot.com
>>
>> (It was set up not as a technical treatise, but for students) (oh, and I ran the code on OSX for the blog, but the code does/did run on Linux)
> I don't mean to try to make work for someone else (my C skills are
> modest at best), but could this be the opportunity to try to break out
> of the one line look ahead limitation? OpenCL program reads a bunch of
> lines ahead, and maps out the best trajectory for the path to keep the
> tool moving quickly, then lets the real time software know how fast it
> can step through the result.


AFAIK (and I am no expert) the lookahead limitation is not "compute bound"
but rather structural based on a early design decision to be able to stop at
the end of any block.

It does seem like the GPU would be great for compute bound things like cutter
path visualization and the like.


Peter Wallace
Mesa Electronics

[andy pugh]

On 27 October 2012 00:34, Peter C. Wallace <***@mesanet.com> wrote:

> AFAIK (and I am no expert) the lookahead limitation is not "compute bound"
> but rather structural based on a early design decision

Indeed not. On modern hardware most paths can probably be fully
computed before the end of the first segment.

It is also true that the current lookahead is not a problem on a large
percentage of code. If the code is reasonably long lines and
reasonably large arcs then it works excellently

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Kirk Wallace]

On Fri, 2012-10-26 at 11:36 -0400, Kent A. Reed wrote:
... snip
> People keep downplaying the impact of the graphics subsystem but in my
> experience it still ranks ahead of other problems when latency kicks up.
> We remain blissfully ignorant of the interplay between the graphics
> hardware, its drivers, and the BIOS, in which direct-memory-access
> figure prominently.
... snip

I'm not sure this is related, but I just installed to an Intel
motherboard and an xorg.conf with only an entry for vertrefresh and
horizsync to match my monitor was the difference between a boot crash
and running just fine.

--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA

[Sven Wesley]

2012/10/26 Kirk Wallace <***@wallacecompany.com>

> On Fri, 2012-10-26 at 11:36 -0400, Kent A. Reed wrote:
> ... snip
> > People keep downplaying the impact of the graphics subsystem but in my
> > experience it still ranks ahead of other problems when latency kicks up.
> > We remain blissfully ignorant of the interplay between the graphics
> > hardware, its drivers, and the BIOS, in which direct-memory-access
> > figure prominently.
> ... snip
>
>
To me it's annoying that I can get 15 800 only (which I've lived with since
last spring) when I had less than 10 000 before the upgrade.

GPUs are extremely well performing when it comes to shoveling lists. One of
my old work mates are nowadays using a server cluster of servers with 8
graphic cards each running fund and exchange predictions. It's seems pretty
messy to integrate with though.
Me, I stay with the must-not-be-fast-but-never-die-programming. But that
doesn't include my CNC machines, they should be really fast. :)

/S

[Jon Elson]

Sven Wesley wrote:
> I did some testing yesterday. I upgraded the graphics driver (Nvidia) and
> the latency test went from 18 000 to 150 000... I removed the driver and
> reconfigured X and came down to a sweet 7 000, but there's something
> messing things up as the latency all of a sudden popped up to 15 800.
>
If 15,800 is the worst it gets, that really isn't too bad. You may be
able to turn off some
acceleration options in the video driver. Big bit block transfers from
screen memory
to main memory can bog the CPU down and cause latency hiccups. Or, it
could be the
network interface, which you can't change. If you have a hyperthreading
CPU, you
generally want to turn that off in the BIOS screen. Running glxgears
puts up
a 3-D display that mimics the load the Axis 3-D preview creates. Also,
hide and bring
back to foreground a couple windows on the screen. If those operations
don't
cause your latency bump, then it may be the network, you can try a few
sftp file
transfers to see if that is the cause.

Jon

[Bruce Layne]

I'm doing a LinuxCNC conversion of a huge CNC saw and dual gantry
router. I call it The Beast. It's a gantry machine with a 7.5 HP
radial arm saw, two 15 HP routers, and two air drills. It's made the
enclosures for some of the finest loudspeakers ever built, and needs to
do so again.

http://209.197.93.201/beast/Beast04.jpg

For a sense of scale, the aluminum bed is 4 feet by 8 feet. Note
LinuxCNC running in the lower right of the image. Also note the 44
ounce Mountain Dew next to the monitor... one a night, for too many
nights to count.

I'm finally close to finishing this LinuxCNC project, but progress has
now come to a halt as I try to get the Allen Bradley Ultra3000 servo
drive to work with the old Siemens brushless DC servo motor. Depending
on the PID parameters, attempts to auto tune result in either a locked
rotor or slow jerky motion in one or both directions, but auto tuning
always fails.

These are ancient motors, some of the first brushless DC motors to be
used in CNC machines. Online info is almost nonexistent. Here's all of
the data I have on the Z axis motor.

Z Axis Motor: Siemens 1FT-5064-0AC01
4.5 Nm = 39.8 inch pounds = 3.32 foot pounds
2000 RPM Max
16.0 Amps Max
7.2 Amps Continuous
4.5 Kp(I) (current controller integral gain)
1.7 ohms (measured with a meter)
11.54 mH (measured with a meter)
100K PTC thermistor
6 pole
3 phase tachometer: 40V @ rated RPM
short designation A18, A28, A38, H18, H28 or H38

The motor database in Ultraware, the Allen Bradley Ultra3000 servo drive
configuration software, is asking for the motor's rotational inertia
which I don't have, and the torque constant, which I don't have unless
it's related to the 4.5 Kp(I) shown above. I made some (probably bad)
guesses.

I think part of the problem I'm having might be caused by not using the
Hall Effect sensors. The old Siemens motor uses 15V Hall Effect sensors
and the Ultra3000 wants them to be modern 5V Hall Effect sensors, so
rather than making a custom circuit for voltage translation, I've been
trying to get the Ultra3000 to self-sense the commutation at startup.

The old Heidenhain encoders work as they should, for both the Ultra3000
servo drive and LinuxCNC.

Does anybody have any suggestions that might get the Siemens motors to
work with the Ultra3000 drives? Please contact me off list if you'd prefer.

[andy pugh]

On 25 October 2012 13:56, Bruce Layne <***@thinkingdevices.com> wrote:

> I think part of the problem I'm having might be caused by not using the
> Hall Effect sensors. The old Siemens motor uses 15V Hall Effect sensors
> and the Ultra3000 wants them to be modern 5V Hall Effect sensors, so
> rather than making a custom circuit for voltage translation, I've been
> trying to get the Ultra3000 to self-sense the commutation at startup.

Not doing his would be my first approach so fixing things.
Though, converting might not help if the commutation patterns are different.

If the drives are using the encoders for commutation after an auto
sense then the locked-rotor situation might be caused by the encoder
and motor having a different idea of clockwise.
I would certainly try swapping two motor power leads to reverse the
motor relative to the encoder.

The drives are going to need to know the encoder counts per rev and
motor pole count, I guess you have configured these? (I assume that it
is _possible_ to configure these)

It is possible to run Hall-pattern translation inside the LinuxCNC
software. The "bldc" component can do this, but it would not be the
optimum solution.


--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Bruce Layne]

On 10/25/2012 11:41 AM, andy pugh wrote:
> If the drives are using the encoders for commutation after an auto
> sense then the locked-rotor situation might be caused by the encoder
> and motor having a different idea of clockwise.
> I would certainly try swapping two motor power leads to reverse the
> motor relative to the encoder.

My thoughts exactly. That was the last thing I tried. I bought an LCR
meter so I could measure the armature inductance. It was 3X my "best
guess" value I had been using. I plugged in the correct value and the
auto tuning failed as before. Then I swapped two of the motor leads at
the servo drive. It did behave a bit differently. It moved a little bit
(still jerky) and then generated an E39 error - Self-sensing Commutation
Startup Error. I had seen that before, when I first connected the motor
and tried to move it before doing the commutation diagnostics. That
suggested to me that the servo drive probably did know the correct
commutation.



> The drives are going to need to know the encoder counts per rev and
> motor pole count, I guess you have configured these? (I assume that it
> is _possible_ to configure these)

There is a place in the motor configuration database for the motor
poles, which I've correctly configured.

There's a place in Ultraware for the encoder counts. This may be the
crux of the biscuit. I'm not that sure of the encoder counts per
revolution. I've been so focused on the motor that I forgot about that
gross assumption. This is the top of my list of things to do tonight.
Put the motor leads back the way they were so the E39 error goes away,
and take a long hard look at the encoder. It's mounted on the motor so
I assume it's turning in a 1:1 ratio with the motor, but I'm not that
sure of my facts, including the 2000 line encoder count. At the very
least, it won't take long to try different encoder counts and see if the
auto tuning changes. Of course, what I failed to do in my Mountain Dew
addled sleep deprivation was put a mark on the motor pulley, manually
rotate the motor one complete turn, and see how much the encoder count
changes in Ultraware. That's DUH obvious now in the light of day.



> It is possible to run Hall-pattern translation inside the LinuxCNC
> software. The "bldc" component can do this, but it would not be the
> optimum solution.

That's another great suggestion that I hadn't considered. The Ultra3000
servo drive wants to be first in line to the encoders (doesn't
everyone?) and they offer the option of buffering the encoder signals
before sending them to the CNC controller. Currently, I'm running the
Ultra3000 and the MESA 7i77 connected to LinuxCNC in parallel on the
unbuffered encoder signals. I did measure to make sure that the
combination of the Ultra3000 and 7i77 didn't load the encoder signal too
much when I originally wired it. But I never considered using the very
versatile 7i77 as the voltage translation device, buffering the signal
for the Ultra3000. BTW - Todd gets credit for this suggestion because
he answered off list, 30 minutes before Andy. :-)



On 10/25/2012 02:14 PM, John figie wrote:
>
> Voltage translation of the 24V hall sensor outputs to 5V would be
> straight forward. Inside the Ultra the hall sensor inputs are pulled
> up to 5V by 1K and also the input goes through 1K to the input of a
> 74HCT14. There are clamp diodes at the 74HCT and a small cap.
>
I had already looked ahead that far, so I wasn't too concerned about the
15V encoder signals into the Ultra3000. I hadn't looked into the 7i77
encoder inputs yet, and was thinking that in the worst case, I might
need to use the Ultra3000 to buffer the encoder signals to the 7i77.
Mostly, I wasn't happy about soldering a new high density D-sub
connector cable to get the Hall Effect sensor data into the three
Ultra3000 servo drives. There was also the ugliness of using a zener
diode to make 15V from 24V that I was hoping to avoid if it wasn't
necessary.



All of these are viable suggestions. My prioritized To Do list:

1) Verify the encoder counts per revolution.
2) Verify that the Ultra3000 is configured for the proper encoder
resolution.
3) See if the Hall Effect sensors will operate from 5V.
4) If not, run the Hall Effect sensors from 15V.
5) Sell the antique Siemens servo motors on eBay for outrageous prices
to some desperate souls who need to keep their ancient CNC machines
running, buy shiny new plug-n-play Allen Bradley servo motors, and let
Joe the brilliant maintenance guy figure out how to mount them to The
Beast. :-)



Big thanks to everyone for taking the time to reply to my desperate cry
for help. Your replies were very helpful, and are much appreciated.

[John figie]

Voltage translation of the 24V hall sensor outputs to 5V would be straight
forward. Inside the Ultra the hall sensor inputs are pulled up to 5V by
1K and also the input goes through 1K to the input of a 74HCT14. There are
clamp diodes at the 74HCT and a small cap.
On Oct 25, 2012 8:02 AM, "Bruce Layne" <***@thinkingdevices.com> wrote:

> I'm doing a LinuxCNC conversion of a huge CNC saw and dual gantry
> router. I call it The Beast. It's a gantry machine with a 7.5 HP
> radial arm saw, two 15 HP routers, and two air drills. It's made the
> enclosures for some of the finest loudspeakers ever built, and needs to
> do so again.
>
> http://209.197.93.201/beast/Beast04.jpg
>
> For a sense of scale, the aluminum bed is 4 feet by 8 feet. Note
> LinuxCNC running in the lower right of the image. Also note the 44
> ounce Mountain Dew next to the monitor... one a night, for too many
> nights to count.
>
> I'm finally close to finishing this LinuxCNC project, but progress has
> now come to a halt as I try to get the Allen Bradley Ultra3000 servo
> drive to work with the old Siemens brushless DC servo motor. Depending
> on the PID parameters, attempts to auto tune result in either a locked
> rotor or slow jerky motion in one or both directions, but auto tuning
> always fails.
>
> These are ancient motors, some of the first brushless DC motors to be
> used in CNC machines. Online info is almost nonexistent. Here's all of
> the data I have on the Z axis motor.
>
> Z Axis Motor: Siemens 1FT-5064-0AC01
> 4.5 Nm = 39.8 inch pounds = 3.32 foot pounds
> 2000 RPM Max
> 16.0 Amps Max
> 7.2 Amps Continuous
> 4.5 Kp(I) (current controller integral gain)
> 1.7 ohms (measured with a meter)
> 11.54 mH (measured with a meter)
> 100K PTC thermistor
> 6 pole
> 3 phase tachometer: 40V @ rated RPM
> short designation A18, A28, A38, H18, H28 or H38
>
> The motor database in Ultraware, the Allen Bradley Ultra3000 servo drive
> configuration software, is asking for the motor's rotational inertia
> which I don't have, and the torque constant, which I don't have unless
> it's related to the 4.5 Kp(I) shown above. I made some (probably bad)
> guesses.
>
> I think part of the problem I'm having might be caused by not using the
> Hall Effect sensors. The old Siemens motor uses 15V Hall Effect sensors
> and the Ultra3000 wants them to be modern 5V Hall Effect sensors, so
> rather than making a custom circuit for voltage translation, I've been
> trying to get the Ultra3000 to self-sense the commutation at startup.
>
> The old Heidenhain encoders work as they should, for both the Ultra3000
> servo drive and LinuxCNC.
>
> Does anybody have any suggestions that might get the Siemens motors to
> work with the Ultra3000 drives? Please contact me off list if you'd
> prefer.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Sven Wesley]

2012/10/25 Kent A. Reed <***@gmail.com>

> ...[snip]...
>
With this in mind (and you did mentioned graphics first), have you tried
> my favorite trick and run your LinuxCNC host in headless mode, using
> another computer to provide X services? A quick test would confirm if
> you are being undone by your host's graphics subsystem.
>
> Regards,
> Kent
>
>
Unfortunately the graphics card didn't like me playing around with the
drivers and it got really hot. I replaced it with a dirt cheap card just to
get the PC back up again.
Did a remote X session test five minutes ago.
ssh -X connection from my CAM workstation, played Youtube videos,
downloaded LinuxCNC, copied files locally in Nautilus.
Latency maxed out at 10 200 ns. Performance increase 55 %.
I'm starting to believe that Torvalds' Nvidia ranting is justified...

/S

[Sven Wesley]

>
>
> Unfortunately the graphics card didn't like me playing around with the
> drivers and it got really hot. I replaced it with a dirt cheap card just to
> get the PC back up again.
> Did a remote X session test five minutes ago.
> ssh -X connection from my CAM workstation, played Youtube videos,
> downloaded LinuxCNC, copied files locally in Nautilus.
> Latency maxed out at 10 200 ns. Performance increase 55 %.
> I'm starting to believe that Torvalds' Nvidia ranting is justified...
>
> /S
>

Sigh, I don't remember that I had any problems when I installed the machine
once upon a time, nor when I upgraded it. LinuxCNC on 10.04 can't drive the
new graphics card and the two internal NICs aren't working even if I do the
tricks listed on the Internet. Went back to 8.04. Graphics came up without
boot-options, but the NICs are still dead. Time to go to the computer store
and get a cheap NIC not built by Nvidia... :(
I think I'll order that Mini ITX board at the same time.

[Sven Wesley]

>
>
> I think I'll order that Mini ITX board at the same time.
>

For the record, I ordered two ITX boards. Better safe than sorry. ;)

[John Stewart]

Hi all;

On 2012-10-29, at 11:14 AM, Sven Wesley wrote:

>> I think I'll order that Mini ITX board at the same time.
> For the record, I ordered two ITX boards. Better safe than sorry. ;)


I just got my 2nd Intel D525MW board last Friday; it took about a month to come in to my local store.

What was the name of the "Rock" board, or the "Asus" board that is similar?

BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25 should fit, the PCI-e slot is not the same as the Mesa 6i25.

John Alexander Stewart

[Sven Wesley]

2012/10/29 John Stewart <***@crc.ca>

> Hi all;
>
> On 2012-10-29, at 11:14 AM, Sven Wesley wrote:
>
> >> I think I'll order that Mini ITX board at the same time.
> > For the record, I ordered two ITX boards. Better safe than sorry. ;)
>
>
> I just got my 2nd Intel D525MW board last Friday; it took about a month to
> come in to my local store.
>
> What was the name of the "Rock" board, or the "Asus" board that is similar?
>
> BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25 should
> fit, the PCI-e slot is not the same as the Mesa 6i25.
>
> John Alexander Stewart
>
>
My computer store have them in stock, but they where not in the store. At
latest I have them on friday.

/S

[Viesturs Lācis]

2012/10/29 John Stewart <***@crc.ca>:
>
> BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25 should fit

And it does fit very well :)) I put this combination in one of my
machines, works like a charm. And the slim profile of the card does
not disturb wiring the cables.

--
Viesturs

If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Gene Heskett]

On Monday 29 October 2012 13:38:32 Viesturs Lācis did opine:

> 2012/10/29 John Stewart <***@crc.ca>:
> > BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25
> > should fit
>
> And it does fit very well :)) I put this combination in one of my
> machines, works like a charm. And the slim profile of the card does
> not disturb wiring the cables.

Good to hear Sven, thanks for posting.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
A committee is a life form with six or more legs and no brain.
-- Lazarus Long, "Time Enough For Love"

[Gene Heskett]

On Monday 29 October 2012 13:33:20 John Stewart did opine:

> Hi all;
>
> On 2012-10-29, at 11:14 AM, Sven Wesley wrote:
> >> I think I'll order that Mini ITX board at the same time.
> >
> > For the record, I ordered two ITX boards. Better safe than sorry. ;)
>
> I just got my 2nd Intel D525MW board last Friday; it took about a month
> to come in to my local store.
>
> What was the name of the "Rock" board, or the "Asus" board that is
> similar?
>
> BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25
> should fit, the PCI-e slot is not the same as the Mesa 6i25.
>
That I found John, thanks, but that other slot looks more like a PCMCIA
than pci-e to me, plus its a right angle socket, meaning anything bigger
than a lappy side plugin card will run out of room for length.

> John Alexander Stewart
>
>
>
>
>
>
>
> ------------------------------------------------------------------------
> ------ The Windows 8 Center - In partnership with Sourceforge
> Your idea - your app - 30 days.
> Get started!
> http://windows8center.sourceforge.net/
> what-html-developers-need-to-know-about-coding-windows-8-metro-style-app
> s/ _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users


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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
Lensmen eat Jedi for breakfast.

[Viesturs Lācis]

2012/10/29 Gene Heskett <***@wdtv.com>:
> On Monday 29 October 2012 13:33:20 John Stewart did opine:
>
>> Hi all;
>>
>> On 2012-10-29, at 11:14 AM, Sven Wesley wrote:
>> >> I think I'll order that Mini ITX board at the same time.
>> >
>> > For the record, I ordered two ITX boards. Better safe than sorry. ;)
>>
>> I just got my 2nd Intel D525MW board last Friday; it took about a month
>> to come in to my local store.
>>
>> What was the name of the "Rock" board, or the "Asus" board that is
>> similar?
>>
>> BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25
>> should fit, the PCI-e slot is not the same as the Mesa 6i25.
>>
> That I found John, thanks, but that other slot looks more like a PCMCIA
> than pci-e to me, plus its a right angle socket, meaning anything bigger
> than a lappy side plugin card will run out of room for length.

>

[Kirk Wallace]

On Mon, 2012-10-29 at 13:37 -0400, Gene Heskett wrote:
> On Monday 29 October 2012 13:33:20 John Stewart did opine:
>
> > Hi all;
> >
> > On 2012-10-29, at 11:14 AM, Sven Wesley wrote:
> > >> I think I'll order that Mini ITX board at the same time.
> > >
> > > For the record, I ordered two ITX boards. Better safe than sorry. ;)
> >
> > I just got my 2nd Intel D525MW board last Friday; it took about a month
> > to come in to my local store.
> >
> > What was the name of the "Rock" board, or the "Asus" board that is
> > similar?
> >
> > BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25
> > should fit, the PCI-e slot is not the same as the Mesa 6i25.
> >
> That I found John, thanks, but that other slot looks more like a PCMCIA
> than pci-e to me, plus its a right angle socket, meaning anything bigger
> than a lappy side plugin card will run out of room for length.


See Page 3:
http://www.intel.com/content/www/us/en/desktops/desktop-board-d525mw-innovation-brief.html

Looks like PCI Express Mini:
http://en.wikipedia.org/wiki/PCI_Express#PCI_Express_Mini_Card


--
Kirk Wallace
http://www.wallacecompany.com/machine_shop/
http://www.wallacecompany.com/E45/index.html
California, USA

[Sven Wesley]

2012/10/29 John Stewart <***@crc.ca>

> Hi all;
>
> On 2012-10-29, at 11:14 AM, Sven Wesley wrote:
>
> >> I think I'll order that Mini ITX board at the same time.
> > For the record, I ordered two ITX boards. Better safe than sorry. ;)
>
>
> I just got my 2nd Intel D525MW board last Friday; it took about a month to
> come in to my local store.
>
> What was the name of the "Rock" board, or the "Asus" board that is similar?
>
> BTW Gene - the Intel D525MW has a PCI slot on it, so the Mesa 5i25 should
> fit, the PCI-e slot is not the same as the Mesa 6i25.
>
> John Alexander Stewart
>
>

John, what's your latency?

I installed the boards and actually it's a bit disappointing. I installed
one to my wife's office to replace an old Dell, and watching a video clip
on Vimeo doesn't simply work, it lags and flickers pretty heavily. Even
worse; Ubuntu 12.10 doesn't recognize the graphics and it goes black screen
with 64bit and ends up with half the screen size in 32bit! I was hacking
around with xrandr to get it a decent display and never got it running well
(The board is configured as a laptop by Ubuntu, no wonder it's mostly
laptop harware. But why on earth is a second non existing display
configured?..). Ubuntu 10 installs fine and finds the correct resolution
right away but the heavy lag is still there. My LTS support towards Ubuntu
is on the edge now...

I installed LinuxCNC on my board and ran latency tests and it was quite
easy to ramp it up to 14 250 ns. That's worse than my existing
configuration at the reconfigured PC that's in use now that this thread
from the beginning was about. I also made the remote X tests as discussed
earlier in this thread and then the PC maxed out at 9 920 ns.

4 GB high quality RAM
60 GB SSD super fast disc
Hyper threading disabled/enabled tested
isolcpu=1

6-7 ms? No chance.

[Sven Wesley]

>
> I installed LinuxCNC on my board and ran latency tests and it was quite
> easy to ramp it up to 14 250 ns. That's worse than my existing
> configuration at the reconfigured PC that's in use now that this thread
> from the beginning was about. I also made the remote X tests as discussed
> earlier in this thread and then the PC maxed out at 9 920 ns.
>
>
Correction: 18 250 ns.

[John Stewart]

Sven;

My D525MW boards are not beside me ATM, but your correction seems to be about right, IIRC.

Certainly not blindingly fast, but not too bad either, and little noise/heat. I hope that their lifetime is long in my applications.

My numbers, like yours, were higher than seen on the "latency numbers" on the LinuxCNC web site; I wonder if, as you have done, running headless is really the way to go for best latency.

I'm thinking seriously about the Mesa 5i25; I'll need one for the spindle encoder for my CNC lathe project.

BTW - I'd not bet on Windows to be a secure bet for long term CNC either; don't really know what either LinuxCNC or the Mach camp are going to do a few years down the road.

JohnS.

On 2012-11-04, at 10:00 AM, Sven Wesley wrote:

>>
>> I installed LinuxCNC on my board and ran latency tests and it was quite
>> easy to ramp it up to 14 250 ns. That's worse than my existing
>> configuration at the reconfigured PC that's in use now that this thread
>> from the beginning was about. I also made the remote X tests as discussed
>> earlier in this thread and then the PC maxed out at 9 920 ns.
>>
>>
> Correction: 18 250 ns.
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Sven Wesley]

2012/11/4 John Stewart <***@crc.ca>

> Sven;
>
> My D525MW boards are not beside me ATM, but your correction seems to be
> about right, IIRC.
>
> Certainly not blindingly fast, but not too bad either, and little
> noise/heat. I hope that their lifetime is long in my applications.
>
> My numbers, like yours, were higher than seen on the "latency numbers" on
> the LinuxCNC web site; I wonder if, as you have done, running headless is
> really the way to go for best latency.
>
> I'm thinking seriously about the Mesa 5i25; I'll need one for the spindle
> encoder for my CNC lathe project.
>
> BTW - I'd not bet on Windows to be a secure bet for long term CNC either;
> don't really know what either LinuxCNC or the Mach camp are going to do a
> few years down the road.
>
> JohnS.
>
>
>
Thanks John.
I actually hit near 30 000 ns when I closed a tab i Firefox. If you really
want to load FF, go to Smartclient.com or Vaadin.com and run the demo sites.
Seems I've found a good reason to actually have a Raspberry Pi inside the
cabinet, a perfect X host to unload the controller.
I'm not in a hurry to replace the controller all of a sudden...

@Kent, Max base jitter(ns). Shouldn't be ms of course, my bad quick
spelling slipped and I mean micro and not milli...
The rumour said that the D525MW should be able to make it in the 3-7 micro
region, seems not possible to me though.

/S

[Kent A. Reed]

On 11/4/2012 10:48 AM, Sven Wesley wrote:
> 2012/11/4 John Stewart <***@crc.ca>
>
>> Sven;
>>
>> My D525MW boards are not beside me ATM, but your correction seems to be
>> about right, IIRC.

And I thought it was high, but I don't have a D525MW here.

I don't mean to sound snarky, but have you isolated one cpu?

>> Certainly not blindingly fast, but not too bad either, and little
>> noise/heat. I hope that their lifetime is long in my applications.
>>
>> My numbers, like yours, were higher than seen on the "latency numbers" on
>> the LinuxCNC web site; I wonder if, as you have done, running headless is
>> really the way to go for best latency.
>>
>> I'm thinking seriously about the Mesa 5i25; I'll need one for the spindle
>> encoder for my CNC lathe project.
>>
>> BTW - I'd not bet on Windows to be a secure bet for long term CNC either;
>> don't really know what either LinuxCNC or the Mach camp are going to do a
>> few years down the road.
>>
>> JohnS.
>>
>>
>>
> Thanks John.
> I actually hit near 30 000 ns when I closed a tab i Firefox. If you really
> want to load FF, go to Smartclient.com or Vaadin.com and run the demo sites.
> Seems I've found a good reason to actually have a Raspberry Pi inside the
> cabinet, a perfect X host to unload the controller.
> I'm not in a hurry to replace the controller all of a sudden...

My thought exactly. I used to use an old Via board as an X server, but
these ARM boards beat it for their modest size and power consumption,
not to mention I can buy 4 or 5 RPis for what I paid for the Via.

> @Kent, Max base jitter(ns). Shouldn't be ms of course, my bad quick
> spelling slipped and I mean micro and not milli...

I thought that might be the case, but I read things very literally, to
the consternation of my wife and kids. My grandkids, however, find it
amusing.

> The rumour said that the D525MW should be able to make it in the 3-7 micro
> region, seems not possible to me though.

Like I said, I don't have a D525MW. I did get such decent numbers for my
ASUS AT5NM10-I (Atom D510 equipped) and even my old Intel D945GCLF2
(Atom 330) did pretty well (based on latency-test reports, of course,
not real world measures as John notes).

It's seriously annoying to have to test every new board for suitability.

Good luck.

Regards,
Kent

[John Stewart]

Kent;

On 2012-11-04, at 12:27 PM, Kent A. Reed wrote:

>>>
>>> My D525MW boards are not beside me ATM, but your correction seems to be
>>> about right, IIRC.
>
> And I thought it was high, but I don't have a D525MW here.
>
> I don't mean to sound snarky, but have you isolated one cpu?

Not snarky; my CNC mill one certainly does have the cpu isolation (thanks for your help back then) my 2nd one just has the LinuxCNC install installed from CD, so I'm just running the latency tests from the pull down menu. I was downloading installing the full Android app development environment at that point in time, so it was something to do while waiting for a server to serve me. ;-)

I'll have to go out and run both settings to see if there's a difference, or, more correctly, see what the difference is.

Actually, I'm not worried about the figures, as the CNC mill runs just fine (™) as it now stands; the new lathe still needs lots of work before I even contemplate moving this new one downstairs.

I just noted someone pointing out the latency numbers and thought that, as I was installing the full Android developer tools on it, that I'd just run the latency test and see what I got.

John Alexander Stewart.

[dave]

On Sun, 2012-11-04 at 12:27 -0500, Kent A. Reed wrote:
> On 11/4/2012 10:48 AM, Sven Wesley wrote:
> > 2012/11/4 John Stewart <***@crc.ca>
> >
> >> Sven;
> >>
> >> My D525MW boards are not beside me ATM, but your correction seems to be
> >> about right, IIRC.
>
> And I thought it was high, but I don't have a D525MW here.
>
> I don't mean to sound snarky, but have you isolated one cpu?
>
> >> Certainly not blindingly fast, but not too bad either, and little
> >> noise/heat. I hope that their lifetime is long in my applications.
> >>
> >> My numbers, like yours, were higher than seen on the "latency numbers" on
> >> the LinuxCNC web site; I wonder if, as you have done, running headless is
> >> really the way to go for best latency.
> >>
> >> I'm thinking seriously about the Mesa 5i25; I'll need one for the spindle
> >> encoder for my CNC lathe project.
> >>
> >> BTW - I'd not bet on Windows to be a secure bet for long term CNC either;
> >> don't really know what either LinuxCNC or the Mach camp are going to do a
> >> few years down the road.
> >>
> >> JohnS.
> >>
> >>
> >>
> > Thanks John.
> > I actually hit near 30 000 ns when I closed a tab i Firefox. If you really
> > want to load FF, go to Smartclient.com or Vaadin.com and run the demo sites.
> > Seems I've found a good reason to actually have a Raspberry Pi inside the
> > cabinet, a perfect X host to unload the controller.
> > I'm not in a hurry to replace the controller all of a sudden...
>
> My thought exactly. I used to use an old Via board as an X server, but
> these ARM boards beat it for their modest size and power consumption,
> not to mention I can buy 4 or 5 RPis for what I paid for the Via.
>
> > @Kent, Max base jitter(ns). Shouldn't be ms of course, my bad quick
> > spelling slipped and I mean micro and not milli...
>
> I thought that might be the case, but I read things very literally, to
> the consternation of my wife and kids. My grandkids, however, find it
> amusing.
Well, certainly! That is a result of the way you think and your
training. Orders of magnitude do count and not only in paychecks. :-)
Think of the differences if our accepted physical constants were (only)
one order of magnitude larger or smaller.
Yes, wives tend to be that way. Like, "doesn't your head hurt", to which
a friend of mine replies to his wife after doing a 'back of the envelope
calculation', not any more the thoughts let the pressure out. :-)


>
> > The rumour said that the D525MW should be able to make it in the 3-7 micro
> > region, seems not possible to me though.
>
> Like I said, I don't have a D525MW. I did get such decent numbers for my
> ASUS AT5NM10-I (Atom D510 equipped) and even my old Intel D945GCLF2
> (Atom 330) did pretty well (based on latency-test reports, of course,
> not real world measures as John notes).
>
> It's seriously annoying to have to test every new board for suitability.

Indeed, but that is what pressures us to find a better solution. A
static world is unnatural. Thermodynamics wins every time.

Dave
>
> Good luck.
>
> Regards,
> Kent
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users

[Sven Wesley]

>
> Indeed, but that is what pressures us to find a better solution. A
> static world is unnatural. Thermodynamics wins every time.
>
> Dave
>
>
Define static. Mount Everest hasn't changed much since EMC2 was born.
A better solution seems to be two machines; one for LinuxCNC and one for X.

/S

[Ray Mitchell]

Did you verify that the D525MW has the latest Intel BIOS installed?


Ray

--J. Ray Mitchell Jr.
***@gmail.com
[phone]


A foolish faith in authority is the worst enemy of truth.
- Einstein





On Sun, Nov 4, 2012 at 7:48 AM, Sven Wesley <***@gmail.com> wrote:

> 2012/11/4 John Stewart <***@crc.ca>
>
> > Sven;
> >
> > My D525MW boards are not beside me ATM, but your correction seems to be
> > about right, IIRC.
> >
> > Certainly not blindingly fast, but not too bad either, and little
> > noise/heat. I hope that their lifetime is long in my applications.
> >
> > My numbers, like yours, were higher than seen on the "latency numbers" on
> > the LinuxCNC web site; I wonder if, as you have done, running headless is
> > really the way to go for best latency.
> >
> > I'm thinking seriously about the Mesa 5i25; I'll need one for the spindle
> > encoder for my CNC lathe project.
> >
> > BTW - I'd not bet on Windows to be a secure bet for long term CNC either;
> > don't really know what either LinuxCNC or the Mach camp are going to do a
> > few years down the road.
> >
> > JohnS.
> >
> >
> >
> Thanks John.
> I actually hit near 30 000 ns when I closed a tab i Firefox. If you really
> want to load FF, go to Smartclient.com or Vaadin.com and run the demo
> sites.
> Seems I've found a good reason to actually have a Raspberry Pi inside the
> cabinet, a perfect X host to unload the controller.
> I'm not in a hurry to replace the controller all of a sudden...
>
> @Kent, Max base jitter(ns). Shouldn't be ms of course, my bad quick
> spelling slipped and I mean micro and not milli...
> The rumour said that the D525MW should be able to make it in the 3-7 micro
> region, seems not possible to me though.
>
> /S
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> Emc-users mailing list
> Emc-***@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/emc-users
>

[Sven Wesley]

2012/11/4 Ray Mitchell <***@gmail.com>

> Did you verify that the D525MW has the latest Intel BIOS installed?
>
>
> Ray
>
>

No difference before or after BIOS upgrade. Now running rev.0126 i.e.
latest from Intel. 26 000 ns easily within 30 seconds caused by a terminal,
glxgears and Firefox.

/S

[Eric Keller]

On Sun, Nov 4, 2012 at 10:48 AM, Sven Wesley <***@gmail.com> wrote:

> Seems I've found a good reason to actually have a Raspberry Pi inside the
> cabinet, a perfect X host to unload the controller.
>
I would really like to know if this works
Eric

[Kent A. Reed]

On 11/5/2012 11:43 AM, Eric Keller wrote:
> On Sun, Nov 4, 2012 at 10:48 AM, Sven Wesley <***@gmail.com> wrote:
>
>> Seems I've found a good reason to actually have a Raspberry Pi inside the
>> cabinet, a perfect X host to unload the controller.
>>
> I would really like to know if this works
> Eric
>

It's easy in principle, Eric. Anything that can run an Xserver can be
the user terminal. I've done it a number of times with computers ranging
from simple evaluation boards like the RPi to full-up engineering
workstations. The beautry of X is that an Xserver is an Xserver is
an.... (Don't ask me about the warts on X:-))

In practice, there's a lot of niggly details that have to be attended to
if it is to be bullet-proof and be seen as the user interface to a
machine tool and not as a computer.

1) the RPi should be able to boot up without manual intervention into a
"kiosk" mode with, say, just an Xwindow open and ready for business. A
very stripped-down Linux will do.
2) it should be able to establish communication automagically to the
machine controller. In my case, I'd put a cheap ethernet switch in the
cabinet so the RPi and the controller can talk to each other and to
other parts of my network. There are other ways to establish the
intercommunication but this is easiest for me.
3) both the RPi and the controller should be able to boot into a
functional state, each without depending on the other
4) the RPi "terminal" should allow some sort of debug mode for those
days when nothing is going well.

Regards,
Kent

[andy pugh]

On 4 November 2012 15:48, Sven Wesley <***@gmail.com> wrote:

> Seems I've found a good reason to actually have a Raspberry Pi inside the
> cabinet, a perfect X host to unload the controller.

This sounds like a really difficult way to solve the wrong problem.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Ralph Stirling]

The big problem I've had with trying to put RPi's inside control
cabinets is that they *really* don't like to be powered off at
arbitrary times without a proper "shutdown -h now". Less than
a half-dozen power cycles and the SD card was corrupted.
I have yet to find a satisfactory solution to this problem. Shutdown
takes ~20 seconds with the stock OS image.

-- Ralph

On 4 November 2012 15:48, Sven Wesley <***@gmail.com> wrote:

> Seems I've found a good reason to actually have a Raspberry Pi inside the
> cabinet, a perfect X host to unload the controller.

[Przemek Klosowski]

On Mon, Nov 5, 2012 at 12:52 PM, Ralph Stirling <
***@wallawalla.edu> wrote:

> The big problem I've had with trying to put RPi's inside control
> cabinets is that they *really* don't like to be powered off at
> arbitrary times without a proper "shutdown -h now". Less than
> a half-dozen power cycles and the SD card was corrupted.
>

There are ways to mount the root disk read-only, with a small ramdisk for
temp files. There's even a way to layer a ramdisk over a readonly primary
disk, where the ramdisk only holds the changing bits. You gain
robustness---the boot always starts from the same pristine image, and
nothing is ever written to the primary SD storage; no shutdown is required.
You loose modifiability: no changes are ever recorded on the persistent SD
storage.

[Ralph Stirling]

The problem I seemed to be observing (and seemed to be
reported by others) was that the SD card gets corrupted
even with RO file systems. Power cycling glitches cause
inadvertent write cycles to the SD card.

-- Ralph
________________________________________
From: Przemek Klosowski [***@gmail.com]
Sent: Monday, November 05, 2012 10:09 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] What should I do to get the performance back?

On Mon, Nov 5, 2012 at 12:52 PM, Ralph Stirling <
***@wallawalla.edu> wrote:

> The big problem I've had with trying to put RPi's inside control
> cabinets is that they *really* don't like to be powered off at
> arbitrary times without a proper "shutdown -h now". Less than
> a half-dozen power cycles and the SD card was corrupted.
>

There are ways to mount the root disk read-only, with a small ramdisk for
temp files. There's even a way to layer a ramdisk over a readonly primary
disk, where the ramdisk only holds the changing bits. You gain
robustness---the boot always starts from the same pristine image, and
nothing is ever written to the primary SD storage; no shutdown is required.
You loose modifiability: no changes are ever recorded on the persistent SD
storage.

[Przemek Klosowski]

On Mon, Nov 5, 2012 at 1:32 PM, Ralph Stirling <
***@wallawalla.edu> wrote:

> The problem I seemed to be observing (and seemed to be
> reported by others) was that the SD card gets corrupted
> even with RO file systems. Power cycling glitches cause
> inadvertent write cycles to the SD card.
>

Even with the SD card hardware write lock switch turned on? I find it hard
to believe, but ... not impossible...

[Sven Wesley]

2012/11/5 Przemek Klosowski <***@gmail.com>

> On Mon, Nov 5, 2012 at 1:32 PM, Ralph Stirling <
> ***@wallawalla.edu> wrote:
>
> > The problem I seemed to be observing (and seemed to be
> > reported by others) was that the SD card gets corrupted
> > even with RO file systems. Power cycling glitches cause
> > inadvertent write cycles to the SD card.
> >
>
> Even with the SD card hardware write lock switch turned on? I find it hard
> to believe, but ... not impossible...
>
>
I have an old laptop as TV media center running Portheus in "Fresh Mode"
which means that everything is copied to RAM during bootup. I can assure
you that my kids - and I and my wife - have shut it off brutally at least
1000 times. Still boots up like normal and that's exactly what Fresh Mode
is for.
If you don't want to wait 20 seconds for a shut off, then try Portheus. On
the other hand, how do you shut off the LinuxCNC PC? As an alternative you
could leave the RPi left on, not a power consumer so to speak.

@Andy, why is it difficult and why is it the wrong problem? I clearly
measure a performance boost running the controller PC headless.
Would it be easier and cheaper to order a Mesa board? No. Could the
To-me-useless-as-CNC-PC ITX boards act like X servers in a dual PC setup?
Yes indeed. And what I paid for the complete ITX computer is not more than
a 5I25 will cost me with shipping, import VAT and customs fees. And when
something breaks i can stroll away to the electronics store and get the
spare part I need.

/S

[andy pugh]

On 5 November 2012 19:10, Sven Wesley <***@gmail.com> wrote:

> @Andy, why is it difficult and why is it the wrong problem? I clearly
> measure a performance boost running the controller PC headless.
> Would it be easier and cheaper to order a Mesa board? No.

It won't be cheaper _and_ easier, but it could well be easier and more
expensive.

I think that the improvement would be much more significant than going
for a hybrid ITX / RPi combination.
(and the ITX PCs are probably fine for a Pico/Mesa style setup).

A 5i25 is €95 + shipping from CZ (no further EU customs or VAT to pay)
http://www.retrofit-plus.at/en/MESA/Mesa-5I25-Superport-FPGA-based-PCI-Anything-I-O-card.html

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Viesturs Lācis]

2012/11/5 andy pugh <***@gmail.com>:
> On 5 November 2012 19:10, Sven Wesley <***@gmail.com> wrote:
>
>> @Andy, why is it difficult and why is it the wrong problem? I clearly
>> measure a performance boost running the controller PC headless.
>> Would it be easier and cheaper to order a Mesa board? No.
>
> It won't be cheaper _and_ easier, but it could well be easier and more
> expensive.

Are You serious?!? How is a setup of 2 PCs - one for LinuxCNC with
software step generation and other of graphical frontend - more easy
than simply adding an FPGA card either to LPT port or in PCI slot? And
how is it easier to configure such a double-PC system than take a
sample config in LinuxCNC and adjust some lines to fit particular
machine?
And where do You get whole PC (MB + RAM + HDD + PSU) for less than 100
EUR (based on 5i25 price, provided by Andy)?

IMHO any attempts to combine 2 PCs, when adding an FPGA card is not
even considered, certainly is way more difficult way to solve wrong
problem. It not only adds a whole layer of complexity to overall
system, it also does not introduce any additional functionality. Using
FPGA card adds new features (way more I/O bits, pwmgens, stepgens and
encoder modules can handle much higher pulse frequencies etc.) and
IMHO does not make the system significantly more complex.
Generally using FPGA card certainly is easier _and_ cheaper. Try it
for Yourself :)

--
Viesturs

If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Sven Wesley]

2012/11/5 Viesturs Lācis <***@gmail.com>

> 2012/11/5 andy pugh <***@gmail.com>:
> > On 5 November 2012 19:10, Sven Wesley <***@gmail.com> wrote:
> >
> >> @Andy, why is it difficult and why is it the wrong problem? I clearly
> >> measure a performance boost running the controller PC headless.
> >> Would it be easier and cheaper to order a Mesa board? No.
> >
> > It won't be cheaper _and_ easier, but it could well be easier and more
> > expensive.
>
> Are You serious?!? How is a setup of 2 PCs - one for LinuxCNC with
> software step generation and other of graphical frontend - more easy
> than simply adding an FPGA card either to LPT port or in PCI slot? And
> how is it easier to configure such a double-PC system than take a
> sample config in LinuxCNC and adjust some lines to fit particular
> machine?
> And where do You get whole PC (MB + RAM + HDD + PSU) for less than 100
> EUR (based on 5i25 price, provided by Andy)?
>
> IMHO any attempts to combine 2 PCs, when adding an FPGA card is not
> even considered, certainly is way more difficult way to solve wrong
> problem. It not only adds a whole layer of complexity to overall
> system, it also does not introduce any additional functionality. Using
> FPGA card adds new features (way more I/O bits, pwmgens, stepgens and
> encoder modules can handle much higher pulse frequencies etc.) and
> IMHO does not make the system significantly more complex.
> Generally using FPGA card certainly is easier _and_ cheaper. Try it
> for Yourself :)
>
>
Wow, sensitive subject. Are _you_ serious? I didn't even have to buy
another PC to run a dual PC setup, it's all in the workshop already. All it
takes is ONE freakin' command line and it's running. I bought the
to-me-pretty-useless ITX computer for €150. I get fully functional laptops
for free that works better than the ITX board, a Raspberry costs less than
€50 with a card and casing and shipping. I don't NEED extra I/O's for an
already running machine. I have also already stated that latency dropped
with 50 % on the existing controller when it was running headless. And on
top of that I have given the Mesa credits already. Did you even read the
rest of the discussion before you jumped the train?
I think not.

/S

[andy pugh]

On 6 November 2012 00:28, Sven Wesley <***@gmail.com> wrote:

> Wow, sensitive subject. Are _you_ serious?

Getting cold up there in the Baltic? It seems you are both getting a
bit too excited by this subject. You can skate across and fight it out
in the middle soon :-)

> I have also already stated that latency dropped
> with 50 % on the existing controller when it was running headless

If 50% improvement is all that you need, then this might be worthwhile.
My scepticism is based on a more subtle consideration which applies to
stepper systems, however I think yours is a step-servo system so this
might not apply.

When you are pushing software step generation to its limits you find
that the gaps between the available step rates get wider.
Taking the example of a 25uS base thread, you can either step every 1,
2 or 3 threads, giving you top-end pulse frequencies of 40kHz, 20kHz
or 13kHz. At some point the steps become bigger than the physical
system can follow and the motors will stall somewhere short of the
theoretical top speed.
In systems where the step generation clock is a few MHz (Pico or Mesa
FPGAs, SmoothStepper, other stuff I can't recall right now) this
"granularity" limit is well above the practical speed limits of a
stepper system.
A step-servo system will have its own internal position-tracking
control loops and may be immune to this issue.

--
atp
If you can't fix it, you don't own it.
http://www.ifixit.com/Manifesto

[Sven Wesley]

2012/11/6 andy pugh <***@gmail.com>

>
> If 50% improvement is all that you need, then this might be worthwhile.
> My scepticism is based on a more subtle consideration which applies to
> stepper systems, however I think yours is a step-servo system so this
> might not apply.
>

A 50 % drop in latency is a 100 % improvement. ;)

When you are pushing software step generation to its limits you find
> that the gaps between the available step rates get wider.
> Taking the example of a 25uS base thread, you can either step every 1,
> 2 or 3 threads, giving you top-end pulse frequencies of 40kHz, 20kHz
> or 13kHz. At some point the steps become bigger than the physical
> system can follow and the motors will stall somewhere short of the
> theoretical top speed.
> In systems where the step generation clock is a few MHz (Pico or Mesa
> FPGAs, SmoothStepper, other stuff I can't recall right now) this
> "granularity" limit is well above the practical speed limits of a
> stepper system.
> A step-servo system will have its own internal position-tracking
> control loops and may be immune to this issue.
>
>
Good info. I'm not sure if a servo step/dir is immune, I haven't thought
about the technical implementation but I'll ask the vendor where the limits
are. If I don't remember it all wrong I think I'm close to the max rpm of
the servo's with the figures I'm getting now.

I'm in a need of a 5-axis and that will be a Mesa-driven machine, no doubt
about that.

/S

[Jim Coleman]

has anyone done any tweeking of RAM timings past those provided by SPD and
compared latencies? I've seen a stick of "quality" DDR400 have slower SPD
timings than a cheap-o stick of DDR-400. I know that in benchmarks the RAM
timing can net quite a bit of improvement. I have no idea if the intel
boards even have settings to lower the timings, and if they do I'm sure
there'd be differing opinions on stability issues running RAM at tighter
timings than are defined by SPD, but even if the timings do impact
latencies considerably enough, one could look for ram rated by it's
manufacturer for lower timings.

This is just a thought I've had concerning latencies, and I don't recall it
ever being discussed.

Jim

[Ralph Stirling]

The write lock switch does not connect to anything
on the RPi board. There is no write lock function
provided.

-- Ralph
________________________________________
From: Przemek Klosowski [***@gmail.com]
Sent: Monday, November 05, 2012 10:42 AM
To: Enhanced Machine Controller (EMC)
Subject: Re: [Emc-users] What should I do to get the performance back?

On Mon, Nov 5, 2012 at 1:32 PM, Ralph Stirling <
***@wallawalla.edu> wrote:

> The problem I seemed to be observing (and seemed to be
> reported by others) was that the SD card gets corrupted
> even with RO file systems. Power cycling glitches cause
> inadvertent write cycles to the SD card.
>

Even with the SD card hardware write lock switch turned on? I find it hard
to believe, but ... not impossible...

[Przemek Klosowski]

On Mon, Nov 5, 2012 at 2:27 PM, Ralph Stirling <
***@wallawalla.edu> wrote:

> The write lock switch does not connect to anything
> on the RPi board. There is no write lock function
> provided.
>

One learns something every day: indeed the write protection is done by the
reader, it's not a circuitry on the card (it's just a plastic slider,
detected by a switch in the reader, like the floppy drive write protect
tab). I didn't know that---thanks for the clue stick.

[Gene Heskett]

On Monday 05 November 2012 14:14:57 Przemek Klosowski did opine:

> On Mon, Nov 5, 2012 at 12:52 PM, Ralph Stirling <
>
> ***@wallawalla.edu> wrote:
> > The big problem I've had with trying to put RPi's inside control
> > cabinets is that they *really* don't like to be powered off at
> > arbitrary times without a proper "shutdown -h now". Less than
> > a half-dozen power cycles and the SD card was corrupted.
>
> There are ways to mount the root disk read-only, with a small ramdisk
> for temp files. There's even a way to layer a ramdisk over a readonly
> primary disk, where the ramdisk only holds the changing bits. You gain
> robustness---the boot always starts from the same pristine image, and
> nothing is ever written to the primary SD storage; no shutdown is
> required. You loose modifiability: no changes are ever recorded on the
> persistent SD storage.

I don't think you have to loose the modifiability. dd-wrt has been booting
from compact flash with multiple "partitions" for several years. The main
boot is read-only of course, but the optional config info, is written to a
read/write partition that generally might get written to several times at
initial configuration time by mounting it r/w to write to it, then is
remounted read-only, usually for life. Added iptables rules, network setup
info is all protected. I have never had a power cycle of any kind
including me pulling the power cord from the wall plug contaminate it even
when using it on an old x86 box with a CF adapter on the end of an IDE
drive cable. I see no reason why the RPi can't do much the same thing.

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)
My web page: <http://coyoteden.dyndns-free.com:85/gene> is up!
When the going gets tough, the tough go shopping.

[Jon Elson]

On 11/04/2012 09:00 AM, Sven Wesley wrote:
>> I installed LinuxCNC on my board and ran latency tests and it was quite
>> easy to ramp it up to 14 250 ns. That's worse than my existing
>> configuration at the reconfigured PC that's in use now that this thread
>> from the beginning was about. I also made the remote X tests as discussed
>> earlier in this thread and then the PC maxed out at 9 920 ns.
>>
>>
> Correction: 18 250 ns.
>
If this is a dual-core CPU, better results are almost always seen by
disabling
hyperthreading in the BIOS setup screen before the system boots. These
can often be improved even more by reserving one CPU for real time with
the isolcpu=1 option in the boot command in GRUB.

Jon

[Kent A. Reed]

On 11/4/2012 9:59 AM, Sven Wesley wrote:

<...>
> I installed the boards and actually it's a bit disappointing.

What boards are these, Sven?