Machsupport Forum

Mach Discussion => General Mach Discussion => Topic started by: davidimurray on May 20, 2014, 10:47:45 AM

Title: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: davidimurray on May 20, 2014, 10:47:45 AM
Have had a CNC Mill and Lathe that I converted to mach 3 / parallel port operation for getting on for 10 years. Mach has always been great and done everything I wanted. I am now looking at adding a few extra features and 4th axis to my mill and a toolchanger to my lathe so need some extra I/O. At the same time it would also seem an opportune moment to try and move away from the Parallel Port - but is there a solution that will do what I want?

Minnimum 4 axis stepper outputs
Plenty of digital I/O
Supports Lathe Threading
Support probing / tool setting.

USB or ethernet would be fine.

Any thoughts on what is out there. Had a look at Pokeys, UC100/300 Smooth stepper etc - but they all seem limited on what they can do.

Cheers

Dave
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Hood on May 21, 2014, 05:59:05 AM
The Smoothstepper should do all you want, preferrably the Ethernet one.

Personally I prefer the CS Labs controllers due to 24v I/O and analogue etc but the smaller one does not do Lathe threading, so you would need the IP-S or IP-A.
Both these do threading but there is a delay in the pullout at the end of each pass so you will end up with an annular groove, if that is a problem then they will not be any use at the moment, hopefully soon they will get that sorted. I have heard that Steve has worked out the problem when using full encoders for threading (as IP-A and IP-S and Galil do) but I am not sure if he has passed the info on to CS Lab or not.

Hood
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Dubble on May 24, 2014, 03:55:31 PM
The UC100 and UC300 can cut thread with the index pulse feedback and there is no lag like what Hood mentioned, because the thread cutting commands are executed and sync-ed by the external device, so there is no delay...
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: DICKEYBIRD on May 24, 2014, 08:20:43 PM
Got a link to the UC100 & 300 controllers you're referring to?
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: ger21 on May 24, 2014, 08:38:58 PM
http://cncdrive.com/UC100.html

http://cncdrive.com/UC300.html
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: DICKEYBIRD on May 24, 2014, 08:51:46 PM
Thanks Gerry, I know my google-fu is puny & weak but man, UC100 & 300 was bringing up wierd stuff!
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: ger21 on May 24, 2014, 09:43:35 PM
Try UC100 and CNC
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Hood on May 25, 2014, 02:59:33 AM
The UC100 and UC300 can cut thread with the index pulse feedback and there is no lag like what Hood mentioned, because the thread cutting commands are executed and sync-ed by the external device, so there is no delay...

The lag I mentioned was with controllers which use the full encoder rather than just the index pulse. The advantage of a device using the full encoder is that the Z axis tracks the spindle completely, in other words the spindle can slow or speed up or even stop and restart and the Z axis will still be in sync.
 Steve has worked out the issue but whether he has passed on the info to the people that make such controllers I have no idea.
Hood
Hood
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: RICH on May 25, 2014, 08:31:19 AM
Quote
in other words the spindle can slow or speed up or even stop and restart and the Z axis will still be in sync

Hood,
A little off thread, but your comment rang a bell, as another controller ( i don't use it anymore ) allowed slaving of the spindle to the Z as you described.
ie; So on a wee llittle lathe, using an encoder, you could just manualy turn the spindle and make or adjust to a perfect say 0-80 thread
going forward or back and forth 

FWIW,
RICH
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Dubble on May 27, 2014, 07:25:04 AM
Quote
The lag I mentioned was with controllers which use the full encoder rather than just the index pulse. The advantage of a device using the full encoder is that the Z axis tracks the spindle completely, in other words the spindle can slow or speed up or even stop and restart and the Z axis will still be in sync.
Steve has worked out the issue but whether he has passed on the info to the people that make such controllers I have no idea.
Hood

I got it now, thanks for the explanation Hood.
And I agree, using an encoder gives you higher resolution and closer tolerances than using a single pulse per rev feedback signal, ofcourse assuming that the follower algorithm works correctly and stabile.
It's not a simple task, we currently working on the same, implementing the encoder feedback thread cutting to the UC100 and UC300, should be ready and released soon .. still testing the algorithms... :)
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: davidimurray on May 29, 2014, 08:01:47 AM
Thanks for the feedback everyone. Smoothstepper seems to do everything I need so is the top candidate at the moment.

Dubble - i take it you are the UC********* developer? You're the first mention i've found of the threading capability on the internet.
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Dubble on May 29, 2014, 03:23:43 PM
Yep, I'm one of the developers at CNCdrive Kft.
And the UC100 and UC300 can basicly do all what the SS can do, except it has not that high output stepping frequency, but especially the UC300 has some advanced functions compared to the SS,
like the analog inputs which you can use for example to feedrate override and spindle speed override with externally connected potentiometer, or just map that input into an internal variable and control other things using the variable value... it has analog outputs too. And there is a setup screen where you can attach any Mach3 internal functions to any inputs with simply selecting the function from a dropdown list.
And I was not talking about that the UC300-5LPT has 84 I/Os in total, can be useful for complex machines.
So, we have some advanced functions....

The UC devices could always (I mean from the very beginning) do threading with the single slot sensor, this is the same what MAch3 is capable of doing by itself.

And you know finding real info on the internet is mostly not easy or the informations can be missleading, because customers who are satisfied with a device mostly not writting anything on forums, because they are satisfied and using the device instead of writting on forums. :)
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: khalid on June 24, 2014, 04:47:16 AM
I am using UC100 and i really loved it:) The weired thing is i can't run the machine (Router 5ft x 5ft) at a speed higher than 200IPM in CV mode, if i go higher the rounding cornor in CV make the 3D carving pathetic:(. My router can rapid at 2100IPM using UC100 at 100KHz. ithout loosing step.
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Hood on June 24, 2014, 05:04:17 AM
Acceleration is what leads to corner rounding, the faster the accel you have the less potential for rounding you have.
Hood
Title: Re: Any Practical, Working, Supported Alternatives to the Parallel Port
Post by: Dubble on June 24, 2014, 05:21:03 AM
Khalid.

Mach3 is who precalculates the path and not the UC100, so the rounding of the corners are calculated by Mach3.
Also it is logical that it rounds the corners in CV mode, because the controller tries to keep the velocity constant which is not possible
in sharp corners as the machine axis need to be deccelerated and accelerated to go into and out of the corner.
The corners could be more sharp if you set the acceleraions of the machine axis higher.
(If your machine mechanics can tolerate that.)

If your machine could do infinate acceleration and decceleration then the corners would be sharp,
because then there would be no need to do any acceleration/decceleraion paths, so the time for these could be zero.

And you may set the CV stop angle to for example 89° then for corners on rectangle shapes will still be sharp
as Mach3 will cancel the CV mode on 90° angles.