Re: Windows timing subroutines, how do they work?

Howdy Mariss..

I agree. I have some old opto22 b1/racks that have a onboard cpu..
You can dump pulses to i.o positions and forget them. They will output
a near perfect square wave, problem is no tuneable ramp up and down.
They do have a communication watchdog timer onboard kinda like the
pump you designed. They are from the 80s, in my automation tech days.
I guess I am a dinosaur too. All thier hardware has gone to IP
addressable. I kinda liked the 422 stuff.

We had a discussion on another forum about what a drive should do,
I thought being repairable, cooling easily (cpu remote from heat
makers and a very large heatsink/fan) and being easy to tune for
varied loads was the "most desireable". Knowing I could Purchase ONE
time and fix it myself would be a Great. You are just the man to make
that happen. I think the Larken drives I have in my bridgeport were
designed after your geckos, except they have a unused com port on
them, they are LARGER than your products, And I have yet to break
them. ANd I can break a anvil. They just keep clunking along like a
big ole model T truck.
One other advantage to building a modular drive? your system could be
used on 7amp, or 500 amp drives by changing out the end drivers/heat
sink. Nothing else on the market is like that.. With a fast enough
cpu/eprom you could trigger multiple drives with less electronics. I
don't like any of the ONE board 3 axis units out there. WHen one
smokes, all have to be replaced.

Problem is, Most us home shop people use what we can get to work
together. Software is Pulse/pin related, not usb or (godsent)
bluetooth compatible. Until more software goes to usb, networking axis
we are stuck with what we can do. Till you or someone else solves that
problem for us (Mach2/3 or EMC?).

I like the open source EMC, Like Linux, but am not up on the
installation/configuration as of yet. I guess I don't have enough hats
to wear (yet).

I bought a brainstem moto board, it has two servo outputs and quad
encoder inputs, minor programming capabilities. It could be used as I
described, Devantech motor driver boards are in the mail. BUT, that is
a mobile project and not a cnc one. You could get on board that train
if you wanted. Same cnc-robotic people, different end uses. Even Golf
carts need drivers, electric cars?

Imagine just the connection between the chinese scales and a drive
positioner? All the mini mill owners would get on board. That chinese
scale is a slow talker at 4800 baud tho.

David Cofer



--- In CAD_CAM_EDM_DRO@yahoogroups.com, "Mariss Freimanis"
<mariss92705@y...> wrote:

> In my opinion it should not be the task of a PC to do the 'donkey
> work' of generating step pulses be it Linux, DOS or Windows. That is
> a task that belongs to dumb dedicated hardware.
>
> A PC is an 'intelligence engine'. It's task is to do a lot of math
> and make decisions. Its output product should go to a 'pulse engine',
> hardware finely tuned to the task of generating of producing pure and
> clean frequencies on demand from the PC.
>
> These are tasks are so diametrically opposed it's like using a claw
> hammer for a screwdriver. In a pinch you can do it but it's not
> pretty.
>
> That also pretty much surmises what I have seen from most PC based
> CNC programs. The step pulse phase jitter is horrible even from the
> most popular out there. The motors sound like a barrel of agitated
> monkeys and I have the scope pixs to prove it.
>
> If things are going to be done right, the PC has to interface to some
> kind of step pulse engine.
>
> The 'agitated monkey' part. Motors that sound like that are being
> robbed of their potential torque especially at high speeds. Phase
> modulation imposes unnecessary torque demands (infinite impulse
> functions) on the motors. Said more simply, you pay for all that
> noise in performance.
>
> Mariss
>
>
>
> --- In CAD_CAM_EDM_DRO@yahoogroups.com, Jon Elson <elson@p...> wrote:
> > Jack Hudler wrote:
> >
> > >Turn off multitasking: NO. You could try elevating your process to
> realtime
> > >status, but I can tell you it probably will not fix your issue.
> Doing so
> > >would probably make the user experience unpalatable.
> > >
> > >You're trying to do realtime work on an operating system that
> isn't designed
> > >for realtime work (Linux or Windows). Even if you use a special
> realtime
> > >build you just run into CPU bandwidth issues with your
> requirements and the
> > >requirements of other devices (clock, comports, disk, mouse,
> display, sound,
> > >dma, pci, usb, etc). There are other interrupts and processes that
> require
> > >service and the OS has no idea that doing so will crash your
> machine tool.
> > >
> > >
> > So, you are saying that EMC (using a real-time Linux) simply has
> never
> > worked, and
> > perfoms unpredictably? The way they fixed this is to make the real
> time
> > extension
> > to Linux able to pre-empt the kernel, and all of its tasks. The
> > interrupt latency
> > is around 5 uS on a 100 MHz pentium classic, and vastly faster on
> newer
> > hardware.
> > The jitter in the regularly scheduled interrupts is under 1 uS!
> And,
> > that is an absolute,
> > not some statistical average. It NEVER stutters by more than 1 uS,
> > EVER, no matter
> > how long you sample for.
> >
> > >
> > >
> > I've been running a servo Bridgeport mill since 1998 using EMC
> under
> > real-time Linux,
> > and I can tell you with great authority that the timing is not
> corrupted
> > by "clock, comports,
> > disk, mouse, display, sound,dma, pci, usb, etc."
> >
> > Jon