Why not USB? (again)

Huh....
let's to check where problem is. Assume that machine has no backslash issues and other mechanical problems.

So let's check Rigit tapping.
To do it correctly the (for mill) Z axis should be in some relation with spindle speed
Assume that spindle has 200CPR encoder. So for that encoder the limit is pure speed of spindle.
at 1kHz the spindle is limited to 300RPM. So under 300RPM the tapping is possible. With 100CPR encoder the limit is at 600RPM. So if you need over that then system will fail. But the 200CPR is overkill. I don't know what other's uses there as I doesn't have that. (yet). The Z axis moves wery slow compared to spindle so no problems expected here.

ServoLoop
Of course It's possible. Just the encodes should be coarse enought or speed slow. The problem lies to correct read encoder's and that can be very fast. I see implementation with pure software (EMC) and when hit Y axis with hand the encoder just make few fast pulses that have be missed and position lost. The user's say that in 'job' that newer occour and that should be not problem. And I just pick ful trashbox and put it on the bench where cnc was. The Z axis went wrong. So servo with base period of 20us is just unreliable as there is big chance to lost some pulse from encoder.

Threading
The problem is if the spindle is so unstable that cutter can't folow that fast changes. But there we are lucky. Is spindle is slow then cutter movment is slow too and problem dissapear. If spindle is fast then there is a lot of kinetic energy that doesn't alow fast change of speed. So no big problem too.
What can be problem is entry and exit path of thread. If spindle is fast here can be 'jerky' path if cuter doesn't have space to accelerate. So start from some sharp corner with thread starting in same corner is not possible.

Nad now that 'OR SO' problem.
Native USB is probably out of question. At least shared one. I think that if we use USB port with only one device the timming can be done.
I didn't check any USB master datasheet to check.
But if We can make own driver for USB master then we can use shortest packets and make reliable link. Just I'm afraid that this simplicyty isn available for USB. Probably there is more chances with ETHERNET card.


and about AVR card...
I does little study on stepgen source. I intend to implement stepgen.make.pulses in AVR and all other leave to PC. So just integer part comes to AVR. For now interfacing is EPP port as I already does some thing with it and know how they work and pitfails.
With base thread jitter under 0.5us and base thread somewhere in 5 to 10us range I think the machine will respond better.

p.s.
I forget to say that all speed problem's can be avoided with proper velocity setting.

kate wrote:
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.
.
.

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[/quote]

The form of buffering you describe leads to a delay between initiation of a feed hold and the actual stop. This violates established safety practices making it unsuitable for anything but small hobby machines.

Perhaps 90-95% of emc users do fall into this category. The developers, however, have higher goals than appeasing the masses. Mach is an example of how that would turn out.

Doug

step4linux wrote:

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

Gerd

Generic PCI parallel port card - $20-$30

DIY CNC builders were worried about the demise of the parallel port in 1998. They disappeared from motherboards for a few years but the cards were and still are readily available.

On board LPT headers are once again becoming common, particularly on ITX motherboards which are popular for car PC applications.

Doug

kate wrote:
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.

Well, I think you may be underestimating the number of people using
EMC specifically because of its better support for real servo systems.

Jon

Hello...

Just thinkering....
I don't use MESA board but Just looking doc's and drivers..
Seems that board is updated in servo thread (1ms). No base thread exists.
So if we do over 1kHz steprate the data has time lag. And as I know the limit's doesn't stop the stepgenerator onboard but is just passed to the EMC to do the job.
So if machine runs at 10kHz and hit limit switch it can make another 10 steps before EMC know that there is limit switch activated. And in real seems even worse as seems that fetched data is used for next period so 20 steps can be out.
So what now? Unusable board as is out of sync?
No. Hiting limit with 10kSteps is stupid. It's shouldn't happend. (at least if soft limit is correct). But if does happend the stepper will overshot and lost step (there is not rampdown if limit is reached). So part is ruined with or without lag.

I didn't look in servo module. But I think the PID is salculated on PC not in the board. So same problems can be there. Just less obvious as encoder feedback 'stable' in hardware and thus position. If PID is calculated onboard then just sorry MESA....

So I stil think that USB or ethernet with guaranted 1ms feedrate can do job same as MESA boards.

eslavko wrote:

Hello...

Just thinkering....
I don't use MESA board but Just looking doc's and drivers..
Seems that board is updated in servo thread (1ms). No base thread exists.
So if we do over 1kHz steprate the data has time lag. And as I know the limit's doesn't stop the stepgenerator onboard but is just passed to the EMC to do the job.

The scheme here, just like on the Pico Systems stepper board is that this works
like a servo. EMC tells the step generator what step rate it is to run at, and
the step generator does it. The board counts the steps going out, so it
can make sure the exact number of steps have been sent.

My board also can read position from an encoder, I think the Mesa
can also do this.

So if machine runs at 10kHz and hit limit switch it can make another 10 steps before EMC know that there is limit switch activated. And in real seems even worse as seems that fetched data is used for next period so 20 steps can be out.
So what now? Unusable board as is out of sync?

Again, I think the Mesa does this, but I know my board does. Even though EMC
is only sampling at 1 KHz, the encoder counter in the board can sense the
index pulse with sub-microsecond accuracy and know exactly which step
pulse it saw the index on. You could wire your limit switch to the index input,
or use real encoders with index pulse to get the most accurate home
position.

Jon

Again, I think the Mesa does this, but I know my board does. Even though EMC
is only sampling at 1 KHz, the encoder counter in the board can sense the
index pulse with sub-microsecond accuracy and know exactly which step
pulse it saw the index on. You could wire your limit switch to the index input,
or use real encoders with index pulse to get the most accurate home
position.

Jon

If I'm understand that right then if your board was directed in some direction and hit limit the board itself stop? (not as emc feedback)
And you direct board like go 12345 steps in cw direction with x speed and y acceleration and board does rampup, go and rampdown???
I was thinking like software stepgen that acceleration and frequency is calculated onboard just for few steps if they are faster than servo period. Actual start of deceleration is calculated in emc every 1ms. So when motors are decelerated to under 1kHz the motor is virtualy under the emc control with all parameters. So I thinking just stepgen.makepulses(integer math) to be in hardware. Or I miss something...

eslavko wrote:

If I'm understand that right then if your board was directed in some direction and hit limit the board itself stop? (not as emc feedback)

No, it doesn't. EMC should never let the machine hit a limit when properly set up and homed.
So, precise sensing of limits isn't necessary (except when the limit switch is also used for
homing, and then only when it is homing.)

And you direct board like go 12345 steps in cw direction with x speed and y acceleration and board does rampup, go and rampdown???

No, the ramping is done in EMC, which knows all about the acceleration limits for each
axis.

Jon

Ok.
Then I understand all correct.... And think that can be putted on simple AVR microcontroller and have latency under 0.5us and base thread somewhere up to 10us.

About limit as home. In my machine I do rapid to home. When hit limit (home) switch the machine owershot and stop. Then real homing is done very slow (well under 1ms servo thread) so timing should be precise.