NEWS
LinuxCNC 2.5.2 Release
There are no translations available.

LinuxCNC 2.5.2 Update Released (changelog).
 
LinuxCNC 2.5.1 Release
There are no translations available.

LinuxCNC 2.5.1 Update Released (changelog). If the Package Manager does not prompt you to upgrade see this page.

 
LinuxCNC 2.5.0 Release
There are no translations available.

New major release (changelog). See the instructions to update your system from EMC 2.4 to LinuxCNC 2.5.
 
Home Forum Hardware Computer Why not USB? (again)

Welcome, Guest
Username: Password: Remember me

TOPIC: Why not USB? (again)

Re:Why not USB? (again) 18 Okt 2011 10:26 #14028

  • eslavko
  • eslavko's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 113
  • Karma: 1
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.
The administrator has disabled public write access.

Re:Why not USB? (again) 22 Okt 2011 17:52 #14119

  • doug6949
  • doug6949's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 42
  • Karma: 2
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
The administrator has disabled public write access.

Re:Why not USB? (again) 22 Okt 2011 18:03 #14120

  • doug6949
  • doug6949's Avatar
  • OFFLINE
  • Senior Boarder
  • Posts: 42
  • Karma: 2
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
Last Edit: 22 Okt 2011 18:05 by doug6949.
The administrator has disabled public write access.

Re:Why not USB? (again) 22 Okt 2011 19:42 #14124

  • jmelson
  • jmelson's Avatar
  • OFFLINE
  • Moderator
  • Posts: 263
  • Thank you received: 10
  • Karma: 31
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
The administrator has disabled public write access.

Re:Why not USB? (again) 23 Okt 2011 01:43 #14126

  • eslavko
  • eslavko's Avatar
  • OFFLINE
  • Expert Boarder
  • Posts: 113
  • Karma: 1
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.... :D

So I stil think that USB or ethernet with guaranted 1ms feedrate can do job same as MESA boards.
The administrator has disabled public write access.

Re:Why not USB? (again) 23 Okt 2011 04:06 #14131

  • andypugh
  • andypugh's Avatar
  • OFFLINE
  • Moderator
  • Posts: 4126
  • Thank you received: 141
  • Karma: 129
eslavko wrote:
So I stil think that USB or ethernet with guaranted 1ms feedrate can do job same as MESA boards.

Yes, but it isn't so much a case of the updates being every 1mS, as them being _exactly_ every 1mS. That is where USB becomes problematical.
Ethernet doesn't have the same problem, as far as I know, so it a more promising interface.

Incidentally, EMC2 doesn't respond to limit switches and e-stops in the base thread either, as far as I am aware, so there is no response speed problem with using external step generators.

The points you raise are why there are soft limits, hitting the switches will always lead to a position loss in stepper systems.

You _can_ run a base thread with a Mesa card to access the GPIO, but it is very rarely done.
The administrator has disabled public write access.
Moderators: ArcEye
Time to create page: 1.291 seconds
Powered by Kunena Forum
© 2013 LinuxCNC.org
Joomla! is Free Software released under the GNU General Public License.