Why not USB? (again)

kostas wrote:

jmelson wrote:

Intel just released the D525MW, a compact Atom board with a parallel port on the rear panel, even
more convenient that the D510MO with the parport on a header.

Just for the record, I'm using an Intel D425KT with a parallel port, which I think is still in production. Very nice board with low latency jitter values.

I succeeded to find VIA CPU based Travia C134, small compact box with parallel port. It just happened to have single core CPU without LAPIC and i needed to recompile kernel, rtai and emc from Live CD. I noticed that this was very common case because it was on FAQ but about no-one of basic users were able to do it.

Btw, having jumped from the parallel port's software stepping to an FPGA hardware solution with closed pid loop, I'm sure I don't want to go back again. Closed loop is probably the top of the features that most people should value and use EMC for.
I also think (and this is probably an overstatement, but just to make my point here) that USB is a piece of crap for pretty much everything except keyboards and mice.
So, from my perspective, I'm pretty happy that EMC's developers make things this way and not Mach's way.

What i have been looking, i estimate than more than 90% is running with steppers, so open loop. Closed loop is great thing in places where it is needed but when interface is open loop steppers, it is simply not needed. So, i value it as closed loop as a great feature that really gives more value in certain use cases but it just happens that my use case or use case of 90% of EMC users just does not need it. I still don't propose it's removal, it is important feature even it not needed in every use case.

I hope having some day BLDC servos replacing steppers. I would get more speed and torque. There is no technical reason why USB could not be used with BLDC when 50us servo PID loop is running on microcontroller, just similar way that it runs on brushed DC servo controller. Only difference is that pid loop runs with position mode, not speed mode, When input to controller is position command coming from 1ms loop, USB is enough fast .

Kate

andypugh wrote:

(Note that the SmoothStepper is significantly more expensive than several of the PCI cards supported by EMC2)

Do you also know, how does SmoothStepper's performance compare with other similar FPGA cards, Andy? Mesa's 7i43 for example.
I always wondered how does it perform using the USB interface under Windows.

andypugh wrote:

When input to controller is position command coming from 1ms loop, USB is enough fast .

I am not sure that this is necessarily true, though.
The motion commands are sent to the hardware on the assumption that very nearly exactly 1ms later there will be another update. The acceleration and deceleration curves rely on this. I think that USB is allowed a worst-case latency of 4mS (but might be wrong). To an extent you can compensate with buffering the position commands, but I am not sure how you recover the buffer. I suppose running a few % fast might be allowable assuming that the long-latency packets are rare.
Sending the axis positions direct to a driver in HAL seems emminently doable, and is certainly no worse than using a step-dir servo drive. I don't think that sending the positions back to close the loop would work too well, as the data might get quite stale.

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.

However, compared to using a realtime-friendly PCI card, using a USB-connnected uC seems like re-inventing the wheel, but giving it 4 corners in the process. (Note that the SmoothStepper is significantly more expensive than several of the PCI cards supported by EMC2)

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

andypugh wrote:

(Note that the SmoothStepper is significantly more expensive than several of the PCI cards supported by EMC2)

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.

PCW wrote:

There are several parts of EMC that need real time response:

Servo loop
rigid tapping
threading
probing
limit switches
homing

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:

. Now the closed loop problem. Rigit tapping in cheap homemade CNC is near inpossible as spindle is to weak (or to fast) for job.

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.

Servo loop - I talking stepper here. Software servo is near inpossible (reading encoders) just use special boards

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.

threading - can be done if lathe has strong enought motor to have small speed jitter.

But, most small hobby-level lathes do NOT have strong spindle motors, and will slow
down when threading.

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

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.)

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....

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