[cassbonin]

Hi everybody. My project is to retrofit a old six axis robot that mechanically is great but electronic and software doesn't exist anymore. I already purchased a granite VSD-E and i want to use simplemotion to command the six axis synchronously and simultaneously. Low cost is important.
My first simple ideia is to connect the six usb cables in pc and develop a C program that reads a static text with the trajectory in lines (references for each axis) divided in 10 miliseconds. Later i will elaborate a more sophisticated robotic software

The C program will do the sequence:

While (~end_of_trajectory)

Read line to know the references
send reference 1 to axis 1 trough 1ª USB SPI
send reference 2 to axis 2 trough 2ª USB SPI
send reference 3 to axis 3 trough 3ª USB SPI
send reference 4 to axis 4 trough 4ª USB SPI
send reference 5 to axis 5 trough 5ª USB SPI
send reference 6 to axis 6 trough 6ª USB SPI
Wait 10 miliseconds
end

The precision 10 miliseconds timing will not be a problem in principle, later i can use a Real time operacional system.

I read something about USB7AX but i can wait for...maybe in future projects.

The question is:

a) simplemotion can handle on this?
b) Am i forgetting something?
c) Someone tried it before?
d) suggestions?

Thanks

[cassbonin]

Hi there.

I don't have my drivers yet but i made some tests. I have some FTDI chips and i made a simple program to drive six chips through simplemotion. The ideia was exposed before.
Of course the simplemotion generated a bad CRC error, but the idea can be tested.
The good news is that it can be done, all six axes received de commands but the time is a problem.
I realized that simplemotion writes and read the answear from drive. It took 15 miliseconds in average to execute smcommand 1000 times. See graph:
http://dl.dropbox.com/u/5363316/smcommand_seconds.jpg
If i have to send six commands for positioning and six for speed limit:
12*15ms=180ms in average for each point. That is too long for robot controlling.

I tried to put each smCommand in a thread but this generate bad communication errors. I don't know if it is a simplemotion limitation or ftdi limitation. The fact is that communications doesn't work paralleling.

Xerxes, is there a rawcommand that only write references and don't read the answear from drive?
Do you know what is the problem with the thread approach?

Thank you.

[Xerxes]

The problem is USB latency. There's no way eliminating it completely.

In my tests I have reached up to 400 raw drive commands/s on USB cable and that's when one drive is operated. The rate may reduce when multiple FTDI cables are doing this simultaneously. Anyway the bigger problem here will be the non-realtimeness (USB can't be realtime) which will make motion jerky even if high average update rate is achieved.

So, I think you need to rethink some other way to send position data to drives. I would recommend SmoothStepper like pulse generators. They make motion smooth over USB due to data buffering.

[cassbonin]

Thank you for your considerations.

But my hopes are still alive...
My real time requirements aren't soo hard that needed in machining. I need 1 meter per minute because my process is welding.

I read about a welding robot that works very well in 10Hz/100ms of position and speed limit actualization rate. Not only position was sent to drive but speed limit too each step, making a "first order hold" movement.
2 miliseconds of non-determinist time would not affect this system.

If everything goes wrong i have two possibilities:

-Use a realtime windows extension like Interval Zero | RTX Hard Real-Time Platform
-Adapt the simplemotion to a realtime linux

If everything goes wrong again i can use Emc2 or mach3 to generate steps. But flexibility will be a problem in this case.

Next week i'll test it all. I will post the results here.
Thanks

The problem is USB latency. There's no way eliminating it completely.

In my tests I have reached up to 400 raw drive commands/s on USB cable and that's when one drive is operated. The rate may reduce when multiple FTDI cables are doing this simultaneously. Anyway the bigger problem here will be the non-realtimeness (USB can't be realtime) which will make motion jerky even if high average update rate is achieved.

So, I think you need to rethink some other way to send position data to drives. I would recommend SmoothStepper like pulse generators. They make motion smooth over USB due to data buffering.

[samco]

I would seriously look at emc2. It can to kins and already has a serial kins module. (stack robot arm where each joint is connected to the previous joint)

EMC Documentation Wiki: Kinematics
KINS

it does all the forward and inverse calculations going from machine space to part space. (then you could use normall xyzabc gcode to run it)


Here is a video of a welding robot someone made using emc.
Welding robot with EMC2.wmv - YouTube

sam

[Xerxes]

I would still skip the USB on this to avoid possible dead end and re-doing it from start. USB won't become realtime even when realtime OS is being used. Actually app might hang on realtime OS because OS expects the app to be able to run at deterministic speed. No software can push USB to respond any faster.

[tnimble]

I would still skip the USB on this to avoid possible dead end and re-doing it from start. USB won't become realtime even when realtime OS is being used. Actually app might hang on realtime OS because OS expects the app to be able to run at deterministic speed. No software can push USB to respond any faster.

I second that. I've seen USB devices sending data, that is never recevied at all as soon as a realtime procees/thread is present. IMHO USB is only suited in CNC as a medium to sent (preprocessed) gcode to a trajectory controller.

Probably the most troubleless, inexpensive and simple to setup way would be to get one of the Mesa FPGA cards, a breakoutboard or optiisolator card for it. Install EMC2 start pncconf, select your FPGA card, select the SV12 or SVST8_4 firware configure 6 PWM generators, 0 STEP generators. Hook up the VSD-E's to the PWM+DIR and encoder inputs. Tune the torque loop in the VSD-E, put it in torque mode. Start EMC and tune the position loop. Hookup error outputs from the drives, e-stops etc to the GP IO pins and configure them, write some hal components, pyvcp, etc.

[cassbonin]

I would still skip the USB on this to avoid possible dead end and re-doing it from start. USB won't become realtime even when realtime OS is being used. Actually app might hang on realtime OS because OS expects the app to be able to run at deterministic speed. No software can push USB to respond any faster.

Xerxes, what about adapt the simplemotion to use parallel LPT instead USB to generate SPI commands?
My idea is to send six spi commands paralleling through one or two LPT interfaces to reduce realtime problem. Aparently rutex uses this approach with SPI DLL. see R2040 - Rutex, USA

I read in simplemotion lib code that the function smSPIword must be changed, so my question:
Do you have a code for smSPIword function for LPT or something like this
to share?
Thanks in advance

Ps. I receive the drives and started the tests. I would like to say that the product is very very good, well finished, best resources, congratulations.

[cassbonin]

Xerxes, would it be a problem if you share de diagram of vsdepi board?
cassbonin gmail

It will save me a lot of time...no problem if you can´t. Thank you

[Xerxes]

Xerxes, would it be a problem if you share de diagram of vsdepi board?
cassbonin gmail

It will save me a lot of time...no problem if you can´t. Thank you

Sure, its available at:
http://www.students.tut.fi/~kontkant...schematics.pdf

And yes, you can generate SPI data from parallel port and this can be used to avoid USB latencies. You can do it with parapin library and by modifying part of SimpleMotion code. As attachment you can find simple SPI command example that use parapin.

[cassbonin]

Sure, its available at:
http://www.students.tut.fi/~kontkant...schematics.pdf

And yes, you can generate SPI data from parallel port and this can be used to avoid USB latencies. You can do it with parapin library and by modifying part of SimpleMotion code. As attachment you can find simple SPI command example that use parapin.

Works fine here! thanks. In your example the return parameter is set to CAPTURE_RAW_POS, this is an undocumented feature that seems very nice. Looking at vsd_cmd.h there is a list of possible parameters but no ideia how to use...

I am using SPI and would be great to use the vsd inputs/outputs for general purpose, in other words, using SPI command to set an output or to read an analog value. If is it possible, vsd can be the definitive motion and control solution.

Is there a SPI command to use:

-HSIN1 and HSIN2 as digital input for general use?
-AIN1 and AIN2 as analog inputs?
-OUT2 as digital output for general use?

Thanks.

[cassbonin]

I got problems to set HSIN1 as a disable in and clear fault signal. It just doesn't work. I point Opto-in 1 in gdtool as a disable in, see attachment. Any suggestions?

[Xerxes]

The HSIN1 and HSIN2 does not work when Force SPI mode is being used as input. You may assign disable/clearfaults input to analog input which works also in SPI mode.

It is possible to read analog input values via SPI, however if you plan to send continuous stream of position commands to drive, then it may be bad idea to mix other commands in stream (because motion may jerk).

BTW, you can replace CAPTURE_RAW_POS with other CAPTURE_ variables from vsd_cmd.h to read other values such as motor current.

[cassbonin]

The HSIN1 and HSIN2 does not work when Force SPI mode is being used as input. You may assign disable/clearfaults input to analog input which works also in SPI mode.

It is possible to read analog input values via SPI, however if you plan to send continuous stream of position commands to drive, then it may be bad idea to mix other commands in stream (because motion may jerk).

BTW, you can replace CAPTURE_RAW_POS with other CAPTURE_ variables from vsd_cmd.h to read other values such as motor current.

Jerk motion won't be a problem, since i'm using timers to send the commands, also my plant have a relative low dynamic characteristic. But thanks for the hint.

Looking at vsd_drive_bits.h i found these options for return value:
CAPTURE_TORQUE_TARGET, CAPTURE_TORQUE_ACTUAL, CAPTURE_VELOCITY_TARGET, CAPTURE_VELOCITY_ACTUAL, CAPTURE_POSITION_TARGET, CAPTURE_POSITION_ACTUAL,CAPTURE_FOLLOW_ERROR, CAPTURE_OUTPUT_VOLTAGE, CAPTURE_BUS_VOLTAGE, CAPTURE_STATUSBITS, CAPTURE_FAULTBITS, CAPTURE_P_OUT, CAPTURE_I_OUT, CAPTURE_D_OUT, CAPTURE_FF_OUT

But none of these options points to the analog value of AIN1 and AIN2.

I am thinking in use the CFG_STAT_USER_BIT_SOURCE to the "right" value and read the status bits to know the digital value. I don't know what is the "right" value yet.
Anyway, it will not read the analog value but the digital value.


Finnaly, all this CAPTURE_ options works for reading, and i need a spi command to set or clear the OUT12 (pin 11) output.
Xerxes, is it possible? how can it be done?

Best regards.

[Xerxes]

These will read analog input values:

cmd(CMD_MISC,200)
cmd(CMD_MISC,201)
ain1=cmd(CMD_NOP,0)
ain2=cmd(CMD_NOP,0)

Values are read with NOP because 2 command delay in return values from SPI.

There's no way to set digital output values over SPI. Please note that it takes at least 250Hz position command rate to get smooth motion. Total command rate must be much higher to be able to inject other commands between position commands.

[PCW_MESA]

I second that. I've seen USB devices sending data, that is never recevied at all as soon as a realtime procees/thread is present. IMHO USB is only suited in CNC as a medium to sent (preprocessed) gcode to a trajectory controller.

Probably the most troubleless, inexpensive and simple to setup way would be to get one of the Mesa FPGA cards, a breakoutboard or optiisolator card for it. Install EMC2 start pncconf, select your FPGA card, select the SV12 or SVST8_4 firware configure 6 PWM generators, 0 STEP generators. Hook up the VSD-E's to the PWM+DIR and encoder inputs. Tune the torque loop in the VSD-E, put it in torque mode. Start EMC and tune the position loop. Hookup error outputs from the drives, e-stops etc to the GP IO pins and configure them, write some hal components, pyvcp, etc.

Actually SPI is supported in HostMot2 in EMC V2.5. The driver uses the BSPI firmware (BufferedSPI) so requires no waiting for XMIT of multiple channels of data. It requires a HAL COMP to deal with SPI data munging but a single 5I25 card ($89) could support 8 SPI channels with up to 16 MHz data rate (all signals separate) or 14 SPI channels on one connector if DI/DO/CLK were common (and separate /CS's)