1. Does VSD-E have independent or paralleled SPI ports on 6 pin SPI header and 16 pin user CMD connector? As soon as I connect my SPI controller to CMD I lose the connection to GDtools over FTDI USB cable. I guess there is just one SPI command port and it just hardwired to two connectors?
2. User manual states that there is an SPI watchdog that can be set to a range of 0 to 0xFFFF PID cycles. How do I switch it on and set its value?
I found that VSD-E SPI output data is inverted and is coming from CMD pin 12 and not 11 as stated in the user manual (v1.05)
IS anybody [successfully] using SPI here?
Looks like no SPI type control users here then...
Some initial progress has been made meanwhile.
I can now successfully communicate to VSD-XE through SPI having tested the speed of up to 150 kbit/s. This takes absolute position update rate to about 1500/sec. It is nice to have direct 16 bit positioning available since it eliminates the need to clock thousands of pulses and avoids relative nature of incremental control. It also provides immediate position feedback at the same rate (I operate in torque mode and read back the encoder position and then pass it over to external application for closed loop control.)
The issues I have so far is that if VSD-E locks up due to SPI error (e.g. controller/drive power has been interrupted) the only way to recover the drive is power cycling.
Is there a way to force reset through one of the user inputs?
I am still confused as to why I am getting SPI output data on CMD pin 12 (OUT1.) GDtools has "Force SPI" set as a control type.
Last edited by LBodnar; 05-10-2009 at 02:59 PM.
There certainly aren't many SPI users as it's not officially documented.
What kind of SPI error are you talking about? There are a "clear faults" command (you can assign an input pin for this, too) and also "reset drive" command. But if SPI comm is out of sync (caused by interference), then power reset is the only option.
There seems to be an error in manual. The OUT1 is used as data output, not OUT2.
SPI error may be caused by out-of sync powering up of the controller and the drive. E.g. the controller is up and trying to send an SPI command while the drive is only starting up. Obviously, the drive can initialise its SPI subsystem right in the middle of SPI transmission from the controller. This would cause either timeout error or checksum error when the next attempt will be made when number of shifted bits reaches 32.
I, basically, want a signal that says that the drive is ready to receive SPI data.
To set SPI watchdog, use:
Code://0=disabled, other=number PID cycles to wait for serial command #define RUNTIME_INPUT_WATCHDOG 5300 setparam(RUNTIME_INPUT_WATCHDOG, timeout);