strange delays when calling FlexMotion functions from a C program

[Meel]

I run a program on a Windows XP machine written in Visual C++ that uses the FlexMotion library to control a robot through an FW-7344 controller. The program runs in a loop continually loading new target positions to the controller and "blending" each new position into the ongoing motion. The loop also queries the position of each axis and the status of limit switches to get feedback. It was all working fine with each loop iteration taking about 40 msec, until suddenly it became extremely slow, taking 140 msec per iteration. The change happened after I killed some unrelated processes through the Task Manager (I killed a RealPlayer process realsched.exe and the Windows AutoUpdate client wuauclt.exe). The killing
of these processes seems completely unrelated to anything, but yet my robot control program became slow. The strangest thing is that it has remained slow after rebooting the computer and after trying a million things to get it back to normal. I simply cannot get the looptime back to 40 msec no matter what I do. I thought it was a Windows bug, so I installed Service Pack 2 for Windows XP, but it did not help either. I even tried re-installing the National Instruments drivers and software, but no use.

I did some timing of how long each line of code in my loop took. It appears that every other call to a FlexMotion function takes about 15 msec, while the other half of them take less than 0.5 msec. A single call to a flex_* function that takes 15 msec seems way too long. Note that this time is very consistent, i.e. it is not caused by the processor being busy with other processes since that would cause an erratic delay.

This is a complete disaster. My project has come to a grinding h
alt because a looptime of 140 msec is much too slow. Please help!!!

[Jochen]

I also don't have an explanation why your program has become so slow but maybe this issue has something to do with the IEEE-1394 (firewire) support on your PC. You wrote that this problem occurred already before installing SP2 but is there a chance that SP2 was installed automatically on your PC before you did it manually?
I have found several hints on the web that SP2 slows down firewire communication dramatically. On the other hand firewire is always very slow when used for bidirectional transmissions with only a few bytes being transferred (first byte latency is very high).

If you can't find a solution a pragmatic approach could be to switch from blending to contouring mode. In this case you download position arrays to the controller and it sequentially moves
your axes to these positions within a fixed time period (e. g. 10 ms from one position to the next). Please refer to the contouring examples.

Best regards,

Jochen Klier
National Instruments Germany

[Meel]

Thanks, Jochen, I think contouring may be the solution. But the problem with countouring seems to be that you need to know the trajectory in advance of making the movement. My problem is that the next position only becomes known at the last moment. Ideally I would start the blend for the next position at the very moment I find out what the next position will be. Of course in any real system there will be a delay anyway, but it seems with coutouring there will be more of a delay because I have to load a few positions in advance to make sure the buffer does not run empty. Another problem with countouring seems to be that each axis needs its own buffer (I cannot use a vector space) and therefore I need to make a separate flex_write_buffer call for each axis. So if I
was to use contouring while only loading 1 position at a time (to minimize delay), I would still be making the same number of calls to the controller as I am with the current program. So the overall delay would be the same because the overhead, like you said, is per call.

On the other hand, I might use buffering without using the built-in contouring. I could load the next position for all of the four axes at once into an on-board buffer and then have an on-board program take those positions and blend them. This way I don't have to make separate calls per axis and don't have to worry about the buffer running empty when I'm a little late writing a position. Since I have four axes, it would cut the number of calls to the controller by four but I would transfer more data with each call, thus reducing the firewire overhead. Do you think this might be a way to go?

Even if I get it working this way, it will always bother me why it suddenly started having a delay and why it seems irrev
ersible 🙂 By the way, I am sure SP2 was not installed before.

Thanks,
Meel

[Jochen]

It was one of my apprehensions that you need to calculate the next positions just in time and I have also thought of a solution similar to the approach you have described involving onboard programming. Maybe you will be successful with this approach but I can't guarantee that.

Do you have to stick with the FW-7344 (are you using a notebook or is there any special need for an external motion controller)?
Otherwise using a PCI-7344 (PCI plug-in board) would probably solve this issue as the communication speed is much faster due to low latencies. If this is in option please contact your local NI branch. They should be able to manage an unbureaucratic exchange.

Best regards,

Jochen

[Meel]

That's a good idea, although a possible problem is cable length. My UMI breakout board has to be about 10 meters from the host PC. Right now I have the firewire cable making the long hop. With a PCI card I would have to have the cable that goes from the controller to the UMI board be 10m long. Do you know if there is a length restriction on that cable? As far as I know, optical encoder signals can suffer from long cable length. I suppose I could put the PC close to the robot and have 10 meter monitor, keyboard and mouse cables.

I might try that onboard program thing first.

[Buechsenschuetz]

Most of the outputs of the 73x4 and/or UMI box are open-collector outputs of which the level is limited to +5V (with respect to DGND). For such signals there is no specified maximum cable length (probably since almost nobody uses them for long distance signal transmission). But the longer the cable is the more it is prone to noise and will 'round off' the edges of the signals transmitted due to cable capacitance.

For cables longer than, say, 3m (10 ft) I would recommend using external differential drivers and receivers on all lines, at least the STEP, DIR and INH lines as well as encoder feedback signals. The UMI box will accept differential signals as they are supplied by many encoders but I am not sure whether the receiv
er circutry of the UMI box meets exact RS422 specifications. When using differential signals it is recommended to use twisted pair cable which should be shielded (I think this is a must with cable length of 10m or so).