Looping move absolute position method - Thorlabs MLJ050 Motorized Lab Jack - Activex

[sidlower96]

I want to be able to specify an absolute position for the motor to go to and the number of steps to take, i.e. move a total of 20 mm in 2 steps, so the motor should move 10 mm, wait some amount of time, and move the last 10 mm. The user would specify the distance to move and the steps to take and then press a 'go' button. 

I am utilizing Thorlabs APT software (with LabVIEW 2016) with activeX methods: SetMoveAbsPos which sends a command to the MoveAbs method. However, I can't get the SetMoveAbsPos command to loop with the number of steps. With the attached VI, the behavior I am getting is that the position input from the user is updated every time the VI loops. For example, if the user inputs a position of 20 mm and do it in 2 steps (cycles), it will go to 10 mm, then moves to 5 mm, and then to 2.5 mm, etc. I have tried different positions (inside vs outside the for loop) for the SetMoveAbsPos command and I have tried to initialize the position control outside the loop but I don't get the results I want: either the motor moves to position/steps and doesn't loop or I get erratic behavior. 

Is there anyway to somehow loop the SetMoveAbsPos method for the number of steps I want without it updating the user input position value?

[lagelian]

Hi sidlower96, my assumption is because you're using a local variable for position, which allows you to write to and read from a control. Every time you divide the position by the number of cycles, LabVIEW takes the result and updates that as the new position, which would explain why you're seeing the position decrease by a factor of two with each iteration. 

Angela L. 

National Instruments

[sidlower96]

Hi Angela,

That makes sense. Is there another way to allow user input without the actual input being manipulated? I've tried just initializing the position input outside the for loop then using a local variable of the position inside the for loop in hopes that it would reference the original input position in the next iteration. Unfortunately this didn't work. 

[lagelian]

I would keep the position as a control so the user can still input target position, but my question is why are you writing the output from the IChanID to the position local variable? Can you have that as a separate indicator? 

[sidlower96]

The position local variable is wired to the fAbsPos part of SetMoveAbsPos command. I replaced it with a separate indicator and now the for loop does not loop at all. Removing the indicator gives the same problem. The motor moves to position/steps and does not loop. 

[lagelian]

Can you elaborate on the behavior when you move the step calculation outside the for loop? This isn't the most relevant, but if you were working in SoftMotion, you would do an initial calculation of how far the motor moves/"step" based on final position and number of "steps" (10 mm, if we're using your example), and then execute x number of straight line moves in a for loop (where x=2, according to the example). Is this what you are trying to implement in your application? 

[sidlower96]

So if the SetAbsMovePos method, the position control and/or the cycles control are placed outside the for loop, the motor will move to the position position/cycles (so if position = 20 and cycles = 2 the motor will move to 10 mm). But it won't loop a second time to move the last 10 mm. I think this is because it keeps sending the command to move to the position 10 mm instead of just moving a distance of 10 mm. So if the motor is already at that position from the first iteration of the loop, it won't move in the next iteration. This is distinct from the other behavior of when everything is inside the for loop and the motor continuously moves to position/cycles (20/2 = 10 then in the next iteration 10/2 = 5, etc.) I am not sure how to remedy either behavior but your description of SoftMotion seems to be what I'm after. 

[lagelian]

Based on what you said, have you tried implementing an algorithm that adds the calculated number of steps to the current position so it'll actually reach that position every iteration? 

[sidlower96]

Not quite. But after more trial and error I ended up finding another method, this time implementing relative movement instead of absolute (meaning it will move a certain distance instead of to an absolute position), which fixed all of the problems.