Welcome to LinuxCNC.org

andypugh wrote:
Isochronous and Interrupt transfers have guaranteed latency and bandwidth, 12MBit/s Full Speed USB has 1ms frame, so it is guaranteed that every frame have place for your packet.
High speed USB has 125us frame. Most of microcontrollers support however only this Full speed mode with 1ms frame.

If you compare to analog brushed DC controllers, they normally also have microcontroller even when they get speed command as input. If your motor controller has microcontroller on it, it is then about same having either speed or position control loop on it. It is just question does controller have two or three cascaded closed loops, current, speed and as extra position.

There was idea to drive BLDC phases directly from EMC2 bit-bang IO, i am still little bit curious how it can be done. It needs PWM and current loop for all motor phases and 50us is much, much too long to implement pwn. Microcontrollers have normally all needed stuff, PWM outputs and ADC ready made. It is of possibel to implement PWM and ADC interface with FPGA but it it costs much more than microcontroller and it is somehow re-inventing wheel.

Kate

kate wrote:
It might be workable, as some machines get down to < 10uS base thread. you get 20 levels of resolution at 5kHz then. Add a bit of dither and it might work.
I was going to suggest PDM, but that can't phase-lock correctly.

There is a module for the Mesa FPGA cards that does a real 3-phase PWM see "3pwmgens"
www.linuxcnc.org/docview/2.5/html/man/man9/hostmot2.9.html

Also, somebody has managed to use a 7i43 and a USB connection for a Plasma cutter:
thread.gmane.org/gmane.linux.distributions.emc.user/25467

andypugh wrote:I found the smooth stepper board for 155 $, and a mesa PCI 5i20 for 199 $
Are there cheaper PCI boards ?

Gerd

Edit:
have seen the 5i25 for 89 $, but unfortunately not available at the european distributor.

step4linux wrote:

PCW wrote:
Hello...

I have my opinion to for that.
As Paralel port's are obsolete now we need to seek just right board for that.
So if someone have $5000 machine sprending $200 for some motherboard is bargain. But if some hobyst make own CNC for $200 then $200 for motherboard is a lot of money. On the other hand cheap used PC's and laptop's are available for near no money. But a lot of them have just little too bad latency. For example 20uS base thread yelds max 25.000 steps per second with just TOO BAD acceleraton. As I tested the maximum usable steprate is aprox 1/10 of base thread or even less. But finding computer (old one) with jitter under 15us is not so easy. I have tested aprox 20 different computers but just only one has jitter under 15us (well under 5us realy) all other are in 20..80 range or the realy bad one over 1ms. As that computer's are in secondhand shop I can run live CD and do latency test, but can't open case and change graphic card for example. So I think computer with under 100us jitter is easy to find. (even laptops).

But that is not good for software stepgen. So let's go hardware step gen.. As I understand Mesa, Pluto and other FPGA board's do just that. the EMC runs only servo thread (at 1kHz) and base thread is not existing. And all input lines are managed under servo thread(1kHz). So if we can comunicate with that hardware stepgen every 1ms (that should be possible) then all things should work as with already existing hardware stepgens. Now the closed loop problem. Rigit tapping in cheap homemade CNC is near inpossible as spindle is to weak (or to fast) for job. but let's be real. When I home machine they go full speed to home switch and owershots. Then goes back to release switch and can go again to hit switch. But that small movments are done with speed limit so stepprate is under 1kHz. So All functions in practice works if steprate is small enought.

so problems with:
Servo loop - I talking stepper here. Software servo is near inpossible (reading encoders) just use special boards
rigid tapping - with router as spindle is not possible, If you buy real spindle then buy special boards to do that.
threading - can be done if lathe has strong enought motor to have small speed jitter.
probing - it's already done with weri slow speed.
limit switches - they will be overshooted in any case if axis with full speed reach it. (but EMC2 software limit can do job correctly)
homing - do coarse home with fullspeed with owershot and then fine tune with small speed (alrady done)

So for my opinion I see no problem if communication is dome once per milisecond or so.

I have intention to make hardware stepgen with AVR controller (opensourced) for EPP port to enable ussage of computers with not so good lattency.

sorry for long post....

eslavko wrote:No, I have been demonstrating rigid tapping on my desktop minimill for a number of
years. I even did production tapping with a combined drill-tap for a while until I
got this function working on my Bridgeport. It does a fine job of it. You probably
couldn't do it on a Sherline or Taig, but the slightly larger machines can definitely
handle this.
Chris Radek and Jeff Epler have some machines that are implemented entirely by
software encoder input and servo drive, just needing a motor drive in hardware.But, most small hobby-level lathes do NOT have strong spindle motors, and will slow
down when threading.And, there's the problem, the "OR SO". USB gives no guaranteed delivery of packets.
They get there when the USB hardware FEELS like getting it there. If there is other
traffic, it gets totally unpredictable. If the operation is totally handled in the USB device
and the PC is just the G-code interpreter, this may work. If the PC is much more
involved in sensing conditions and responding to them, then it will always be a
second or more behind the real actions as it needs that much buffer to be sure the
queue never runs empty. (And, even there, greater than one second delays may
occur from time to time. This will be catastrophic when a machine is running at
full speed and suddenly it runs out of data.)Well, great. I hope you have success with it, but I think it may be very hard to
make it work reliably, under all situations.

Jon