Cannot configure the drive.

[Xerxes]

Hi Steve,

How does the GDtool on new computer exactly fail? One reason may be some other plugged-in USB device that uses the same FTDI usb chip that software can confuse to USB adapter. So, if GDtool fails at very beginning when connecting, try unplugging other USB devices (except mouse & keyb) on the new computer.

You may also try the latest FTDI driver from chip manufacturer:
http://ftdichip.com/Drivers/CDM/CDM%...0Certified.zip

[stevespo]

The failure happens when I go through the connection process. I follow the instructions and when I apply power to the drive, and press the Next button, a popup message that says:

"Connection failed - Error - Connection failed. Please check connections."

There isn't anything interesting in the event log, but I could attach that if you thought it might help.

I did unplug my other USB device (Netgear WG111v2) and actually uninstalled all the drivers and utilities for it. Then I reinstalled the GDTool USB driver. Same result. Mouse and keyboard are non-USB. So, the only attached USB device is the cable to the VSD-E.

I will go ahead and install the latest FTDI driver. My machine is now at XP SP3, with all the updates installed, and that didn't help either.

I am beginning to think it must be this particular PC's hardware (IBM ThinkCentre S50-8183). The parallel port had some issues in the past, so it's possible that the USB could be a bit funky. I can use my old machine for the time being, and ultimately the drives will be connected to my "production" machine, which is a Dell. This is just a testing setup.

Any other thoughts or ideas would be appreciated. Thanks,

Steve

[stevespo]

I have a workaround. If I unplug my parallel port cable from the VSDE-PI, then I can connect to the VSD-E drive with the USB cable.

As I suspected, it's nothing to do with USB, GDTool, etc. It has something to do with the parallel port on that machine - which I know has issues. There were several pins where the voltages were inconsistent. It never affected step/direction, so I felt like it would still be ok for testing.

I haven't had time to really diagnose it and understand what is going on, but at least I can connect and configure the drives from the new machine.

Thanks for the pointers.

Steve

[Xerxes]

Steve,

Yes, the CMD flat cable should be unplugged from drive when using GDtool. The CMD cable will disturb the connection as some pins are shared between drive's SPI and CMD connectors.

[ftec]

I had a lot of problems with the BL150, i.e. the smaller one of the GD servo motors with VSD-A drive, while the BL300 servos work nicely. Apart what Xerxes says in his reply #7, I found out how to avoid the "Connection failed - Error in my machine with the small motor.

In the HV circuit I have a main contactor which must be closed to power the motors. When I turn the power on, all drives first get the logic voltage and only after the contactor is closed from a separate switch the drives will get the HV. GDtool always connects to drives without problem if the HV circuit is open and only logic voltage is present.

Then, if the current values in the Motor Setting or PID values are too high or wrong in some other way, the connection will instanly fail when HV is applied. Starting with low current and PID values helped with this machine. So, if connection fails you could first try with logic voltage only.

One other thing (not directly related to this topic but good to be aware of anyway) is the Acceleration Limit in Trajectory Planner. One so easily wants to set the Acceleration-Time-to-Full-Speed value to a low value and this, with heavy loads, can lead to over current faults.

For a heavy CNC machine - which are so different from light and fast moving pick and place robots - this value can be set to meet the acceleration needed for machining. Acceleration value of appr 500 mm/s/s (~20i/s/s) is what is recommend by some end mill manufacturers, say, like precisebits.com. This same value was used in a "ship size" metalworking CNC machine to size all the motors and gears- i.e. a generally accepted value. I have set the Acceleration Time to 0.3s which gives me appr 555 mm/s/s leaving a little reserve for the 500 mm/s/s I have in Mach for acceleration for all axes. With this value even the X axis with a heavy load works nicely.

[stevespo]

I guess I'm still a little confused (no surprise there).

The VSDEPI config file has User I/O "Disable In" as Analog 2, inverted, non-filtered.
The cooresponding Mach setting has pin 14 as Enable1, Active High.

So, it seems the drive will connect to GDTool with the ribbon cable detached, but the drive is not enabled (blue led flashing) and doesn't respond to movement commands (the test doesn't do anything) without the signal present on pin 14, and passed through to the drive.

If I unplug the ribbon cable, I have to then manually set "Disable In" to non-inverted (no signal present = drive enabled) and refresh the drive. The blue led goes to solid and then I can run my test and perform tuning.

I guess I could leave my setting alone and supply TTL +VDC to the correct pin on the VSD-E 16 pin connector.

What are people doing when they need to switch between Mach and GDTool? Changing software settings (drive) or faking the enable signal? Does this make sense?

Steve

[Xerxes]

Ftec, that communication problem is related to electrical interference typically escaped from motor power cable and/or motor case. Cable should be shielded and grounded to drive GND and motor frame should be grounded too (via cable shield). This usually prevents the errors. Some people also have wrapped USB cable thru ferrite core to workaround in difficult cases.

Steve, that is normal behavior. Drive will disable for safety reasons if CMD cable is unplugged. You can workaround this just the way you're doing from GDtool or you can insert a jumper between CMD connector pins 14 and 16 which will enable it.

[stevespo]

Xerxes, thanks so much. The jumper worked perfectly.

I'm in the process of mounting everything in a box (PC mATX case) and just wanted to understand how to go about configuring things so that I can do my motor tuning when everything is finally installed. I think I have a handle on it.

It sure would be nice if GDTool could enable the drive without having to install the jumper. It might be easier to do it via the GUI and save trying to get into that tight space.

This is a really nice product. So far, I'm very impressed with the hardware, docs, software, support - everything.

Thanks,

Steve

[ftec]

Originally Posted by Xerxes Ftec, that communication problem is related to electrical interference typically escaped from motor power cable and/or motor case. Cable should be shielded and grounded to drive GND and motor frame should be grounded too (via cable shield). This usually prevents the errors. Some people also have wrapped USB cable thru ferrite core to workaround in difficult cases.

All cables are well shielded high quality cables and shields connected to drive GND as well as the motor case. Attention has been paid to minimize interference. The communications error only happened with the small motor type and with high current /PID values in it's setup. It's not a problem at the time being, I managed with the setup the way I described and the motor has been working since.

[keebler303]

Few Comments:

Some newer USB ports (esp. laptops) have less than 5V supply, which means that the ftdi device may not be able to drive the optocoupler hard enough to provide reliable communication. To be sure this is not the issue, a powered USB hub can be used.

When the drive first turns on, if there are a few encoder counts of error, the high gain of the controller might cause a brief pulse of power to correct the error. This would look like a step error input to the drive, which would command a step current response. A sharp voltage or current pulse will tend to introduce electrical noise. Maybe a sort of "soft start" feature would be nice here to avoid the jolt when the drive is first turned on, similar to the soft error recovery which I think already exists. This is pure speculation by me but I would think that applying the HV and then enabling the drive would be much better than applying HV while the drive is already enabled, if that is even possible.

Matt

[Xerxes]

VSD optocouplers are 3.3V compatible, so USB voltage will be always enough.

Also haven't seen connection break on current peaks in motor output. Instead a mechanical switch contacting/arcing can introduce additional clock pulse to SPI bus wires which causes an error in connection. Most connection error problems are caused by a interference spike in the SPI clock signal.

I found out that optoisolator makes a huge difference in noise sensitivity. In VSD-A the original socketed HCPL-2531 optocoupler can be replaced by HCPL-2631 to improve noise tolerance (also a 1-1.5 kOhm opto pull-up resistor may be needed because the original is 10k in VSD-A). We started using that opto in VSD-E-160 and the connection errors have been almost inexistent since then.

[ftec]

Originally Posted by Xerxes ... Also haven't seen connection break on current peaks in motor output. Instead a mechanical switch contacting/arcing can introduce additional clock pulse to SPI bus wires which causes an error in connection. Most connection error problems are caused by a interference spike in the SPI clock signal. ...

In our case the contactor is more than 30cm away from the VSDs and the SPI wire even further away from it so I doubt that was the case in this cabinet/machine. Besides, it does not explain why only the small size motors were problematic. But as I said this has been overcome.

For Matt: I haven't noticed any jolts with the VSD-As, IMO they seem to start quite softly. I don't know exactly how VSD initiates the motors but seems as if the rotor is first aligned with the smaller programmable current? When step pulses are applied the rotation then starts from this initial position?