Hello Guest it is March 29, 2024, 09:02:51 AM

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - simpson36

701
Rick, I do not have time to answer individual e-mails from forums, but I will post here on the parallel port question where everyone might benefit. I can post the drivers, but would need to know the operating system you need them for, and whether 32 bit or 64 bit.

I am using the WHQL Windows XP 32 bit drivers from the MOSCHIP web site.

In general, I suggest using a straight PCI to LPT card with NO other goodies on it, and avoid multi purpose chips if possible. Mach obviously has some hard coded expectations and it seems intolerant of deviation from the original IBM port standards and will ignore any 'slight-of-hand' tricks where a vendor is intercepting software port calls and redirecting those to their own super slick setup. Mach appears to talk to the hardware and will not utilize such 'do everything' chips.

As noted on another post, converters also do not play nice. USB to parallel and the like regardless if it is in an external purpose-built box, special cable or a chip built onto a board. FTDI makes converter chips (smoothstepper is an example for this CNC group) and the required drivers can interfere with other USB processes. Certain active FTDI interfaced devices can cause file corruption in USB connected hard drives, for example. The FTDI scheme is a codec of sorts, but most people do not realize this and believe such devices are native USB.

Best rule in interacing mach with anything is, in my experience, keep it old school, keep it simple.

 

702
5C tailstock mock up:

Little better shot of the part:

Brand new integrated pneumatic caliper. Latest articulated verison on the right:

Lock and disc:

New belt drive setup:

FInally just some frames and various components:


I'll update this thread with the new tailstock and trunnion table progress and development continues on those projects.

703
Development has continued during the last several months and I finally have a few picture of the latest iteration of the 4th axis. It is quite a different animal at this point. I do not have time to do a 'build thread' and I will have very limited time to answer questions, but I will try.

The 4th axis is bigger, has a 6" 6 jaw chuck and an entirely new pneumatic lock system. The previous pocket bike mechanical caliper actuated by a linear air cylinder works OK, but had reached it's max potential and I needed more holding power. The solution finally was to design and build a new integrated pneumatic caliper from scratch. Subequently I went with a new rotor, this time from a highway legal vehicle and as large as I could possibly cram into the enlarged frame. I then went on to design an articulated version of the caliper which not locks up the spindle so tight you cannot turn it by hand even with a 12" long lever.

The single and two stage reduction now use the same belt. You just need to move it.

So, the 4th axis development is now completed and I am moving on to work on the 5C tailstock and then the trunnion table. These new items are what most people are interested in. I have included a photo of the first tailstock mock up for proof of concept. It works great. Instead of an aluminum 'nonsense' test piece, what is shown here is an actual finished 4thaxis part. It is an  integral one piece shaft extension with the pulley teeth cut right on the same piece of steel.  This pulley is for a 750 watt Mitsubishi industrial AC servo motor that is going on one of the 4th axis. I am currently using a 400 watt Mitsubishi AC servo motor on my new prototype. Pictures in next post.

704
General Mach Discussion / Re: Question on using DC chokes on SCR drives
« on: September 06, 2010, 06:20:45 AM »
3 phase is not an option for me. The motor controller operates on 220V single phase.

I was able to acquire the motor I wanted, so I will be using the big SRC drive. What I decided to do in this instance is use the exact filters recommended and/or supplied by the manuf of the motor controller.

The in filter is a commercial device and the out filter is supplied by Minarik specifically for their RG series controllers. Together, these filters cost $120, about one third the cost of the controller itself.

The motor is actually a 140V DC servo motor and ultimately I plan to add an encoder and run it as a servo using my Granite Devices VSD drive, powered by a pair of 70V power supplies in series, but for now the SRC will get the job done.

Thanks for your comments.

706
General Mach Discussion / Re: Smoothstepper and probing, home and THC
« on: September 05, 2010, 04:31:52 AM »
. . . .  there is too much latency for the THC to work correctly.  This could be fixed by handling THC in much the same way as probing - "closing the loop" within the SS itself, but that is not how it currently works.
Fortunately, I'm sure the fix will come with Mach4 or Smoothstepper II . . . in 'the next few weeks' . . 

I am not content to sit back and just toss another complaint on a very tall pile. What made this topic interesting was to discuss the possibility of performing the missing Mach functions outside of the SS as I did with swapaxis. As I mentioned at the onset, I don't know much about THC, but on the surface, it does not seem terribly complex. More so than swapaxis, perhaps, but certainly not more than a dynamic balancer. It just needs a team of people with expertise in different areas willing to donate the time to come together and come up with something doable, starting with a clear explanation of exactly what is required for THC. I have a smoothstepper now and was willing to contribute, but staying on topic has proved impossible whenever Smoothstepper is part of the discussion and it quickly becomes uninteresting. I have no need for THC or backlash compensation, so I will not persue it further. 

707
General Mach Discussion / Re: Smoothstepper and probing, home and THC
« on: September 05, 2010, 03:53:28 AM »
Not a "Real" USB device?  It's either a USB device or it isn't.  USB is USB.
There are all manner of interface converters on the market. Parallel to 'serial', USB to parallel, USB to IDE, etc. In my view, a 'legacy' printer with only a parallel port does not become a 'USB device' if a USB to parallel cable is used to connect it to a PC. I can see now that instead of 'real', perhaps 'native' might be a better word. That said, many of these 'converted' interfaces do not have all of the features of the native devices, for example in USB, the inability to run thru a hub.
Quote
FTDI makes USB chips, and provides drivers, that emulate serial and parallel ports.  That emulation is *entirely* a software feature on the PC side, and has no effect whatsoever on timing. latency, or anything else.  It is purely in how the driver presents itself to the OS. 
The FTDI that I have seen require hardware as well as the driver. In most cases, the chip is in the device, as is the case with the SS. However, FTDI sells a series of cables that include the chip in the cable itself. Granite devices drives use this method, for example, and if one was not aware that the chip was in the cable, then it would appear that the drive was a 'native' USB device, but it is not. Emulation or conversion of any kind would introduce latency, it seems to me. There is no 'pin 15' in USB speak, for example, so this must be codec somewhere in the process, and that is going to take time in each direction . . which = latency.  It would be a question of how much and if that amount had any significance to a 'real time' process.
Quote
This is done so software written to talk to a COM: port will see an FTDI device as a COM: port, even though it really isn't.
This is my point exactly, down to the use of the word 'really'. There is not one universal method of doing this. I have older converted USB devices that have drivers that attach to a specific physical USB port. If you want to use a different USB port, you have to reinstall. Others show up as a virtual LPT or COM port. The SS shows up as a device on the the USB bus.


 

708
General Mach Discussion / Re: Smoothstepper and probing, home and THC
« on: September 04, 2010, 04:45:41 PM »
Your original post made assumptions that were just not factual, such as the SmoothStepper not being a 'real' USB device.
From the FTDI site page one: Welcome to FTDI - specialists in converting legacy peripherals to Universal Serial Bus (USB).

There is no assumption for you to label as factual or not. Smoothstepper uses the FTDI interface. That is not good or bad, it IS simply fact. FTDI has a single purpose and if my saying that this is not 'real' USB offends your fanboi sensibility, then please feel free to choose whatever word you like, it is really not relevant to the discussion.The only point to be made is that any signal conversion is going to impose some latency and when speculating about the inability of the smoothstepper to perform certain function that require 'real time' response, the FTDI or ANY other device that would create latency is a logical suspect. I did not say it does or does not, I merely pointed out that this is the method smoothstepper uses, and obviously therefor the potential exists.

As to insulting your character, Jeff, that was not my intention at all. I was simply making an observation based on what I have read many times. This is a forum. Words vs words. It is what it is and not more than that. You are very helpfull on this forum as are many others and that is admirable, but that does not give you immunity from consequences if you choose to sarcastic remarks, even if you backpedal later. Put another way, if you start a fight, don't cry if you go home with a bloody nose.  :'(

709
General Mach Discussion / Re: Smoothstepper and probing, home and THC
« on: September 04, 2010, 12:31:25 PM »
Well, in fact USB is serial, and so is Ethernet, using a serial connection in and of itself does not say anything about the potential data rate. If you'll look at the FTDI chip on the SS you'll find it is a parallel FIFO.

I'm not trying to be a smart ass guys, just trying to dispel myths.

Jeff, again you are commenting before reading. Data rate is not at issue, and is irrelevant in any case. The discussion was about latency, so if you care to 'dispel some myths' about that topic, then you would be on topic.

710
General Mach Discussion / Re: Smoothstepper and probing, home and THC
« on: September 04, 2010, 12:13:07 PM »
Quote
99% of the Smoothstepper install is actually that driver
I don't know much about THC, and I don't know much about smoothstepper either at this point

Interesting to claim that you don't know very much about something right after making several huge assumptions about how something works  ::)
Jeff, as usual, it seems you are looking for a fight. So be it, I shall accomodate you this time. The difference between us is that I have no problem saying what I do NOT know and when I am speculating on something so that people know exactly what they are reading. Other people  ::) just throw out answers that they are in fact 'guessing' at, but do not state so and have little or even zero actual knowledge of the topic they are commenting on.

I made no assumptions about how smoothstepper works. I made only the observation that there are many, many posts from people having various problems with the device and that certain functionality such as THC, backlash compensation, swapaxis, etc are NOT supported. This info as you know comes from very reliable sources, one of which, ironically is you. However, again some people  ::) just hype the product and forget to mention the shortcomings . . .  perhaps because they sell the product.
Quote
Actually about 99% of the SmoothStepper functionality is the plug-in.
Irrelevant in this instance as the discussion, if you had bothered to read it,  was about the interface and not the functionality, and in any case, my comment was on the installation, a point which which you obviously also missed.

Quote
The FTDI driver provides a 'translator' between the USB hardware and an application.
I already made note of that interface, except that I correctly identified the interface as a driver AND hardware . . which is not an assumption, it is fact. Again, you may want to actually read a post and perhaps do some homework before you make sarcastic remarks. And incidentally, the FTDI driver does not 'translate' between the USB hardware and any application.