[LBodnar]

I was trying to set up a VSD-A drive. I had only logic +24v connected and a USB cable.

After establishing initial communication I have pressed "Reset Drive" in menu.

Now I have lost and cannot establish communication and get the message "Card not found, please check cabling and power"

USB cable is showing up OK in devices list on COM3. Restarted, rebooted, reinstalled GDtools, tried two different PCs, tried starting the drive in firmware bootload mode. Nothing helps.

Do I have any other options or just use it as an expensive paperweight? It had only worked for less then two minutes...

[scrambled]

LBodnar


I am having the same type of problem. I am using the VSD-E version, but right now I am having the same problem as you are. According to the manual, it says that loosing communication is caused by excessive noise.

I am waiting for some 330 UF capacitors to connect to my HV. The manual says that this will help reduce noise.

I will let you know what I find out. If you figure anything out, please let me know


Steve

AKA Scrambled

[LBodnar]

I had some progress!

I have checked and re-plugged all connectors but it did not help. Connectors seem to be clean and tight fitting, no corrosion, etc.

Then I have taken my meter and started checking voltages on the CMD connector. After I have measured and checked everything including +5V supply voltage on pin 5 I have tried to connect to the drive and magically connection did happen this time.

I have no explanation to this. I hope it was some sort of latch-up of either optocouplers or FTDI cable.

scrambled, does VSD-E really need HV supply to establish communication with the PC? I was able to connect to VSD-A and observe drive information including undervoltage fault condition with only logic supply and FTDI cable.

[radiantheat]

" Does VSD-E really need HV supply to establish communication with the PC? I was able to connect to VSD-A and observe drive information including undervoltage fault condition with only logic supply and FTDI cable. ? "


to confirm : I connected to my "E" with just 12V dc and had perfect communication. Have never had signal problems that I know of , although not full running yet .

[scrambled]

LBodnar, and radiantheat--

You are correct, I can connect to the drive with the HV unplugged. But when I try to configure the drive, the drive communications locks up tighter than a drum.

So unless I figure the communication problem out, I have a nice looking paperweight with a solid blue led.

thanks



Steve

[LBodnar]

I have VSD-XE returned by the customer as giving comm errors.

After rewiring the assembly and re-adjusting the controller firmware I am trying to connect to VSD-XE with an FTDI cable. I cannot.

If I am starting the drive with USB cable attached as per GDtool instructions it produces solid green and blinking red (firmware update?) and still refuses to connect to GDtool. If I start the drive and then try to attach to it with GDtool I still get connection "Error. Connection failed. Please check connections."

I can see the FTDI cable as COM4 with no problems in Windows.

If I disconnect FTDI and controller and restart the drive it tries to align the motor as it should. The only problem we have replaced the motor and encoder resolution has changed. Customer is waiting for overnight return...

I am so frustrated I am close to smashing the darn thing to bits.

Edit: I have checked that cable is more or less operational by shorting Tx/Rx pins (yellow/orange) according to http://www.ftdichip.com/Documents/Da...ABLES_V201.pdf and checking loopback response in Hyperterminal.

Any suggestions?

[Xerxes]

Top 3 reasons (covering about 99% cases) why communication fails:

1. Interference (only when HV supply is on). Motor cable & motor case shielding are very important. Also wrapping USB cable thru a ferrite core may help.
2. Drive is not in correct mode to receive SPI commands. In VSD-A this is set by jumpers and in VSD-E it is set by special power-up sequence (follow GDtool instructions).
3. USB adapter may be faulty or broken. We have seen such cases, few cables has come faulty from factory and some fail from improper connection. Use attached program to test it (not 100% foolproof though).

I have only once seen a fault in drive (VSD-A) that prevented communication. It was bad soldering in jumper header so jumper setting did not work.

[Xerxes]

I hope the #1 reason is finally history since VSD-E Rev2 got much more noise tolerant optoisolator for SPI. In my tests I was not able to lose communication even when no shielding at all was used and 200VDC was supplied to drive (the worst case combination).

[LBodnar]

Connect YELLOW and BROWN cable pins
Press any key to start test

Scanning devices...Ok
1 USB cables found.
Opening Device...Ok
Configuring cable:
Bit bang mode...Ok
Timeouts...Ok
Latency...Ok
Baudrate...Ok
Cable IO test
Sending data...Ok
Reading data...Ok
Comparing data...
Error
Possible problem here!
Test FAILED

I have used this cable just two week ago and it worked fine
VSD-XE was OK for playing around but it turned out it has too many sharp ends and little problems for production use. When customer hits the problem you don't even know where to start troubleshooting so the whole system has to be sent back and forth... It's a shame since it's a great product on paper...

[Xerxes]

So it seems that FTDI cable is broken for some reason. There should be no way to kill it if its connected correctly to drive SPI connector since it drives only optoisolators. Also nothing should be plugged to CMD connector same time since it shares pins (whatever is connected to CMD could potentially kill the cable). If cable still fails, it must be quality issue of FTDI. If this kind of issues start occurring too much, I must develop an alternative to that cable. Luckily it's not critical part for production machines as it is needed only for one time when setting parameters.

If you wish to try the improved Rev 2 (160V) drives, just email me and we could arrange you a chance to try it.

BTW, could you also list the other sharp ends and little problems you have encountered? That info would be used to iron them out

[stevespo]

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

I just setup a "new" computer for testing and I'm unable to connect to my VSD-E R1 with the new PC. All my other PC USB devices work fine, and I can see the device in the Device Manager as USB Serial Port (COM3), manufacturer FTDI.

I can't imagine anything happened to the cable because it was working fine just a few hours ago. No changes in terms of interference, etc. I disconnected the HV inputs and this did not help.

I already went ahead and uninstalled the driver, uninstalled/reinstalled GDTool 2.5.1. The USB device appeared to get recognized by XP and told me it was ready to use - but I'm still not having any luck connecting with GDTool. The port settings are 9600 baud, 8 data, No parity, 1 stop bit, No flow control.

Above Xerxes suggested:

2. Drive is not in correct mode to receive SPI commands. In VSD-A this is set by jumpers and in VSD-E it is set by special power-up sequence (follow GDtool instructions).

I've gone through the docs and can't find any mention of this special sequence. I'll try and hook up the old PC and see what happens. Would appreciate any advice or ideas on this one. The drive works just fine with Mach3, I just can't connect with GDtool.

Thanks,

Steve

[stevespo]

The "old" computer works just fine, with the same cable, same power config, etc. So this is apparently a local config issue with my new XP machine.

I compared settings between the old/new and didn't see any issues. I changed the COM port number from COM3 -> COM4, but that didn't make a difference.

This XP install is so fresh, maybe I'll let the auto updates happen and see if that helps anything.

I really don't want to go back to the old machine. It's too slow!

Steve

[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