Why not USB? (again)

PCW wrote:

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

Servo loop
rigid tapping
threading
probing
limit switches
homing

In this case real time response == closed loop controll

And of course you would not want to limit the
ability to add additional real time components

The problem with USB is that it is nowhere near real time (This problem is made worse by the fact that the USB hardware on the host is shared so if you want any of your normal USB peripherals to work you have a very interesting driver to create. There's a reason most real time USB implementations have been stalled in alpha for 5 or more years)

Because of these limitations, to make a reliable USB motion controller you end up creating a buffered
system. For a small range of problems this is fine, but as soon as you want one of EMCs more sophisticated functions, you are in trouble. For example if you wanted to do threading, you would most likely have to implement EMCs threading code on the remote buffered motion controller. Eventually you end up re-implementing EMC on the remote device. This is going to require fast floating point and a real time environment.

At this point you might as well stay with EMCs simple, powerful, flexible, single locus of control model
rather than a complicated inflexible buffered system

Thing that i tried to propose, easiest way to start is just make this buffered or open loop solution, it just needs modified version of HAL stepgen module that produces buffered step pulses.

Next step could be then implement servo HAL module etc under Arduino. For Arduino there is FreeRtos based DuinOS and with these ARM based Arduinos we have also FP.

I think that this buffered approach would cover 90% 95% ? EMC use cases, all normal milling machines and lathes excluding threading etc. Homing will be in any case slower than maximum speed and non intentional running on limits may put machine out of the sync.

Having servo loop on USB controller adds then the other use cases where we have larger machines that needs servo motors ? Just as curiosity do we have any BLDC servo controller yet ? Only one I know emulates stepper controller because it is only practical way to get data out from EMC2 to controller. Having OSN may make even easier to handle servo use cases.

What I have in my mind, there won't be any changes on flexible modular HAL structure, just couple of new HAL modules like buggered USB stepgen and USB based servo.
I don't see how this is so complicated, just loop stepgen 2000 times when it gets position command and then pass result to USB module.

Kate

BigJohnT wrote:

kate wrote:

excluding threading etc.

That alone would loose 95% of EMC users from wanting to use it...

John

I did not propose removing feature, I just said that may be all things that there are some features may not be available with USB, If you need that feature, then you don't use USB.
If you don't need these features like most milling machine users, then you could have USB as an option. Having some communication channel better than step pulses from printer port could also open some use cases like easier to use BLDC servos.

Kate

Kate

You must see how this would not interest most of the current developers...
It completely eliminates the most interesting features of EMC and stunts growth of any new ones (using USB)
To do anything interesting you must put the controller in the USB box.
That is completely a different philosophy.
Everything that makes EMC great is because the controller is in the PC.

Now if you or anyone else wants to produce code that does just what you said - limits features but uses USB - as another option
I'm sure we would look at it. But don't expect a lot of developers joining in though I'm sure they will answer any questions and offer ideas.

If you could come up with code that uses USB (or anything else) and still leaves the the PC as the controller thats completely different.
No one has ever come up with code. I'm thinking there is a reason!

As far as using BLDC servos, there are already step and direction drives that make this easy.

So in short other then USB is familiar and very common - there is no advantage to use it and one big reason not to (not realtime).

cmorley wrote:

Kate

You must see how this would not interest most of the current developers...

I understand this, all we do FOSS that we feel interesting to ourselves. Some ones are more interested as example threading,
i would like to see 5 axis mill that I could make about finished quality surfaces for composite molds

When i look result of poll www.linuxcnc.org/component/option,com_po...s/id,2/lang,english/
I am not wrong saying that around 90% uses emc2 for some kind of milling machine,plasma, laser etc and are would
benefit USB interface. It is fact that printer port is going to be extinct, it starts be very difficult
to find any more compact PC mother boards that even have the printer port and for good reason because this
port has not been used by printer any more least last decade. Having big ugly desktop PC in shop with full
of metal chips is not practical.

I succeeded to buy couple of VIA based compact boxes with printer port but then I needed to compile all
kernel, RTAI and EMC from live CD install just because these old ones does not have LAPIC ...
doing this hack is already big obstacle to basic user as addition to find motherboard with printer port.

For this 90% of use cases, it would be much, mush easier just buy a some compact box and attach
interface via USB. I understand that many developers see their interesting challenges elsewhere than
normal user.

It completely eliminates the most interesting features of EMC and stunts growth of any new ones (using USB)
To do anything interesting you must put the controller in the USB box.
That is completely a different philosophy.
Everything that makes EMC great is because the controller is in the PC.

That's different if you want just a mill or stunts. I understand that having all under same PC
allows many stunts that may be very interesting but most of users are not so interested about
these stunts. I don't blame any developers abut being interested about these stunts, FOSS
must be fun and the stunts are part of this fun. I am happy having great software.

Now if you or anyone else wants to produce code that does just what you said - limits features but uses USB - as another option
I'm sure we would look at it. But don't expect a lot of developers joining in though I'm sure they will answer any questions and offer ideas.

I understand, i just tried to say that USB interface would benefit 90% of users and there is no technical reason why it could not work.

If you could come up with code that uses USB (or anything else) and still leaves the the PC as the controller thats completely different.
No one has ever come up with code. I'm thinking there is a reason!

As far as using BLDC servos, there are already step and direction drives that make this easy.

So in short other then USB is familiar and very common - there is no advantage to use it and one big reason not to (not realtime).

I don't like call it as "not realtime", as definition realtime just means that system has guaranteed response time what ever it is, in most cases
1ms loop is considered realtime. There are certain tasks where 1ms loop is not enough as is emc2 50us loop cases like stepgen or servo.

I don't see that either open loop case, stepper motors or moving 50us closed servo loop to USB box means that PC is not a controller. How it differs in case of
"analog" brushed DC servo amplifier case, servo amplifier has it's internal 50us 100us or what ever fast control loops inside, same thing in step/dir BLDC servo controllers.

Least some M$ Win based CNC software are using USB, so it is not so uncommon.

May be we are just looking this from different viewpoint, I see that USB has great advantage for most of basic users but has disadvantage that it does
not allow some stunts that needs cross linked fast control loops. I am not proposing removal of any features needed to implement these stunts.

I really hope that no one feels this offending, I am very happy to have this great software and big thanks to all of it'd developers.
There is just different viewpoints coming from different needs.

Kate

kate wrote:

I understand, i just tried to say that USB interface would benefit 90% of users and there is no technical reason why it could not work.

No, over and over we state that there ARE technical reasons why USB will not work. It is because
USB does not allow round trip operations to a single device in a frame, and that it is a deep
hardware feature of the USB chips, and therefore can't be overridden by software.
What you are asking for is to turn EMC into Mach, and the developers have a number of reasons
not to do so. If you want to run open-loop stepper drives via software step generation, Mach
certainly works for the general case. Why do we need to duplicate what they already do?

very difficult
to find any more compact PC mother boards that even have the printer port

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. The D525MW also has a
PCI (not PCIe) slot where you can plug in an additional parallel port if needed. A complete
system can be built for about $200, if you just want the board to put into a control cabinet,
you can do it even cheaper.

So, the argument that the parallel port is unobtainable is just not true.

Jon

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.

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.

jmelson wrote:

kate wrote:

I understand, i just tried to say that USB interface would benefit 90% of users and there is no technical reason why it could not work.

No, over and over we state that there ARE technical reasons why USB will not work. It is because
USB does not allow round trip operations to a single device in a frame, and that it is a deep
hardware feature of the USB chips, and therefore can't be overridden by software.

And over and over, 90% of use cases that uses open loop stepper motors does not need this round trip
because they are open loop. I have all time admitted that in these use cases where closed loop 50us loop
is required USB does not work. This is just limit that should be accepted when choosing technology.
In similar manner, it is not possible to get as much speed and force with steppers that you could get with servomotors.
Used technology should be selected use case basis and in most use cases steppers and USB are working choice.

What you are asking for is to turn EMC into Mach, and the developers have a number of reasons
not to do so. If you want to run open-loop stepper drives via software step generation, Mach
certainly works for the general case. Why do we need to duplicate what they already do?

Once again over and over, i have never even proposed removal any existing features from EMC, just
proposed one new, USB interface that can be used with steppers. I expect that 90% of emc users
uses it just as Mach, controlling open loop stepper controlled mill, plasma or lathe.
Why then have stepper interface at all if is just duplicating Mach ?

There is many other reasons to use EMC and not Mach. To me, EMC is GREAT software, i love it
and great thanks to developer. I am currently using it with open loop steppers with mill.
I chose EMC over Mach because I wanted Linux based FOSS software that i can manage and
tailor as i like.

very difficult
to find any more compact PC mother boards that even have the printer port

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. The D525MW also has a
PCI (not PCIe) slot where you can plug in an additional parallel port if needed. A complete
system can be built for about $200, if you just want the board to put into a control cabinet,
you can do it even cheaper.

So, the argument that the parallel port is unobtainable is just not true.

I dot not say unobtainable, i just said that it becomes more and more difficult to obtain and
selection becomes smaller and smaller. Very difficult != unobtainable, Very difficult == very difficult to obtain

Kate