05-19-2017 04:35 AM
Is this correct?
05-19-2017 04:48 AM
This is where I am.
05-19-2017 05:31 AM
I went home to test the motor with the latest .VI and here is the link to the result.
The results are the same and further investigation is needed.
Here is the video link: https://youtu.be/irhrKMQJdzw
Hope you find this interesting.
Regards,
Mike
05-19-2017 06:04 AM
I am looking into "Using a State Machine (Event Driven) Architecture
But it looks complicated: http://www.ni.com/white-paper/2926/en/
05-19-2017 06:31 AM
Here is more info that might help to solve this problem.
Normally this type of motor is controlled with its own MCode Terminal.
Schneider have their own software (that said, they also created the .VI's):
The Terminal ooks like this:
The commands there made the motor move very smoothly in several curves. Blue is forward and Red backward. The Motor ramps up and down very smoothly.
I think the commands in the code are the same as the commands in the .VI below.
The VI. was made by
I feel that something is mising from the current .VI that is shown in the MCode.
Hope someone outthere undersands this stuff ;o).
05-19-2017 06:40 AM
One observation is the "H"
This is my thoughts on the problem.
That H (HOLDS) the second input/number while the motor finishes the first. Without that, the second number (and the following) jump in and send the motor to the new number.
I feel, and it looks like this is happening. As all the numbers load, the motor moves to them, "BIG BUT" But I think the numbers pour in faster than the motor moves, thus creating the fragmented moves. The last (Go to Zero) works because nothing else gets loaded.
Here is the video again: https://www.youtube.com/watch?v=irhrKMQJdzw&feature=youtu.be
05-19-2017 06:46 AM
I'm trying to get this to work in LabView:
05-19-2017 12:16 PM
It has been recommended that I look into the Slew command of the motor. I did experiments and got very smooth results. I am currently working on a VI that allows the motor to match the Slew to the .CSV file.
If anyone has ever done this please help.
05-19-2017 12:38 PM
I asked some "big picture" questions before but didn't fully understand your answer.
1. How many motors will you eventually be controlling?
2. Will you need them coordinated to move in sync with one another?
3. What about camera control? Do you also need to sync frame grabs with specific waypoints within your trajectory?
A brief scan of the motor doc suggests that only trapezoidal velocity profiles are supported. You won't be able to fully match the arbitrary trajectories generated in your modeling software.
It seems kinda unlikely that you'll be able to track a desired trajectory very closely using "immediate mode" to communicate with the controller, whether you're doing positional moves or slewing at a fixed speed. Just warning you so you can set your expectations realistically.
There's a programmed motion mode available that may help some, but you'll still be stuck with trapezoidal motion segments.
-Kevin P
05-19-2017 12:38 PM
You could try doubling the wait time inside your FOR loop as it may be an update/lag issue between the vi-->Controller-->Stepper. See what your results look like. If they are worse, you might even have to speed things up. Perform a few experiments - Design of Experiments (DOE) to determine. Your communication Baud rate is set at 9600.