[Solved] Commands 65, 66, 67 seem hobbled.

[GeeklyGrey]

I am working on a simple movement command to move motor2 to a predetermined position from a home reset position. Configuration is all finished at this point and the motor was initially moved to 14462 qpps position using command 45 successfully.
I wanted to try out command 66 to see if positioning to a fixed position would be better so activated that from a button click to return the motor to it's required position at 11520 qpps.

So... Current position on encoder is 14462, position required is 11520.
Desired movement is therefore 14462 - 11520 = 2942 in negative direction, say -2942.
Nominated top speed is 2000, accel and decel both set at 3000.
Signed speed used for this command will be -2000 for reverse direction.

If I was using command 45 to do this task then the 3 long integers are accel, speed and distance.
That is: 3000, -2000, 2942. This command seems to work quite well.

Now, if using command 66 to do this task then the 4 long integers required are
Accel, speed, decel, final position.
That is: 3000, -2000, 3000, 11520 being the final absolute position required.

Command line components in hex code are:
Port,Command,Accel-4b, signSpeed-4b, decel-4b, position-4b, buffer-1b, CRC16-2b
80, 42, 00000BB8, FFFFF830 , 00000BB8, 00002D00 , 01 , C60E

Command line in hex values is therefore "804200000BB8FFFFF83000000BB800002D0001C60E"
This command line is entering Roboclaw ok and sending the acknowledge code of "FF".
But it does nothing except cause stat2 led to lightup along with stat1. Led's are not flickering probably
because the driving code is stopped at present to test values. The led's seem to indicate that one of the motors 'is active' but there is no movement from the motor. WHY?

I tried varying the command with a positive value for speed in case position can control direction.
80 42 00000BB8 000007D0 00000BB8 00002D00 01 F82A (spaces left for readability)
Did not accept this - so direction did not equate with position required.

Also tried with negative value for decel- with negative signed speed as it should have.
80 42 00000BB8 FFFFF830 FFFFF448 00002D00 01 EAB1 (spaces left for readability)
Seems to have accepted negative value for decel but still no movement. Still stat1 and stat2 leds.

I knew the speed should be ok but tried halving the speed in case there is insufficient distance to reach nominated speed-doubtful but try anyway.
80 42 00000BB8 FFFFFC18 00000BB8 00002D00 01 E40F
Command is accepted with "FF" as expected but still no movement, still got stat1 and stat2 leds.

In the controlling subroutine I can change the command from 66 to 45 and the command data is adjusted to the slightly different layout. Did this without doing anything to roboclaw in the way of resetting or clearing of commands. Just the command 45 with buffer set to over-ride as usual.
3000 -2000 2942
80 2D 00000BB8 FFFFF830 00000B7E 01 3DAF
Motor2 now moved anticlockwise a turn or two at the gearbox shaft as expected. It did kick a little on starting though and it does not usually do that.

Last time I tried these two commands (65/66) I was unable to get any movement and thought the problem was something I was doing so went to command 44/45 and that ended up working.

It seems to me that command 66 is hobbled in some way, think 65 is affected too.
Or am I still doing something wrong.

[Basicmicro Support]

Did you test that positon control is working correctly in IonMotion(eg using the Position Settings window)? Velocity commands(including the distance commands) do not require the Position PID values to be tuned properly or even setup, but the Position commands do require them to be setup. Please check the movement of the motors is working correctly in IonMotions Position Settings screen and get back to me.

Note you must set the Min and Max ranges for position commands to work. To use the Position autotuner you must also have the QPPS value set. Everything else will be set by the autotuner. Then make sure the motors move correctly when you move the position sliders in that window.

[GeeklyGrey]

This refers to version v4.1.14 firmware on RoboClaw and IONmotion version to match.
Have not managed to use v4.1.15 yet - refer separate thread.

I have the Position screen sussed out and I believe motors and controller are setup correctly.
Velocity settings PID are 0,0,0
Position PID settings I am playing with at present are 5000,0,15000.
QPPS = 2000, MaxPos = 5000, MinPos = 0
Accel = 8000, Decel = 8000, Speed = 2000
I can whip the slider from top to bottom or other way and get a nice regular graph using Motor Setpoint and Motor Position for both motors. Slide upward for clockwise at shaft, downward for acw. All looks fine on both motors
Motors also respond correctly to other commands like 44/45 including stopping so encoders are counting correctly. I could probably manage ok with only those movements if necessary but would like to try out 65/66.

I just cannot get 65/66 to work using the coded values submitted previously that I believe are worked out ok.
Can you evaluate those on a controller and motor, think they were for motor 2.

[Basicmicro Support]

Ill double check again but I tested position commands on both motor channels before uploading the new release and they worked. This means your problem is probably fixed but needs to get the firmware update working.

Note IonMotion uses those commands(the individual Position commands) to run the motors when in Position Settings. If that works but your code doesn't then it could be a problem in whatever library you are using.

But for now lets table this thread until you are on 4.1.15. I fixed the problem you were having updating.

[GeeklyGrey]

I am now running on v4.1.15 and have posted elsewhere on that - Thank you.
Every thing seems good and is signed off except commands 65/66 as already noted in this thread.

My system does not use a library as such.
All my commands are built by a parsing engine that can handle about half of the commands in the RoboClaw manual on the fly, and the others I do not need to use. The -ONLY- command I have any issues with at this time are command 65 and command 66. Probably 67 (dual motors) would be affected as well but I do not have a need to use it.
I was going to drop another big summary in here but on looking again at my posts I see that what is covered in my post starting "I am working on a simple movement command ....", Nov 16 -7:03pm is very much still valid. (Not sure whether time stamps show the same time there as here!).
I have looked at the hex values sent, what they convert to in decimal, the CRC has been verified using the good Prof's calculator. Checked everything against the manual. The wiring is right and commands 44/45 work fine with buffer set, all very similar. Everything looks right to me.

What is left for me to do?

It would be good if you were able to set a motor2 encoder at say, 14462 and issue the command string supplied and see what happens - it will either work or not. Outside of the included info above I use QPPS= 2000
If it does work - why does it not work for me? Is there something wrong with my command structure above or my understanding of 'position'?, does the manual match the built system - hope so!
If it does not work - you would be wanting to find out why.

Bug finding is mostly dividing the problem and testing the parts. Can you assist?

[Basicmicro Support]

Ok. Now that you are on 4.1.15...

1. The position commands do not take signed speed arguments(absolute speed only, direction is determined by the relative position change. Im just noting this for confirmation, since you say you did try a positive speed as well.

2. I moved my M2 motor to 14462 using IonMotion. Then closed IonMotion and using RealTerm sent your hex data(the one with the positive speed value) to the Roboclaw. It moves to the new position(though slowly since my motors are alot faster). I then opened IonMotion and read the current position for Motor 2. It was 11520.

So I thought maybe it was the PID settings so I set mine to match yours exactly adn repeated the test. Motor moved to 11526 which is about the best I could expect with incorrect tuning for this motor, but it did make the move.

Now, I've got another update(its for some changes when using RC/Analog controls with encoders) so I am technically not using the same release you are. I will be uploading this release shortly so you can try that one.

[GeeklyGrey]

Thank you for doing that test.
It seems that my code is producing useful command data since it worked for you.
And it is helpful to note that commands 65, 66 and 67 in the current manual have the heading
"65 - Buffered Drive M1 with signed Speed, Accel, Deccel and Position" etc indicating signed speed.
Probably an adjustment needed there.

Question: is the deccel value intended to be signed or unsigned.
edit-I see that IONmotion does not accept a negative so my assumption that an unsigned value is used is probably right

I seem to be overlapping with you in real time at present and I can test these things quickly, have probably done them many times anyway!
I do not have the update just yet.

I have just done a test to ensure my PC is running IONmotion ok and the position screen works fine.
So the PC is capable of the command.
The RoboClaw is capable of following the code as output by IONmotion.
My code is capable of correct output as you have confirmed, seems to confirm that manual matches IONmotion.

And that seems to leave not much left.
Perhaps a firmware reset or something is needed.

[GeeklyGrey]

Lots more homework then I found that it will work provided I do not set the buffer flag. Hmmm
First time I got around to removing the buffer flag because I wanted to use the buffering facility.

Thinking. Is this coded out now?

But then the example you tested for me had the flag set and that worked for you, not for me.

At least I can do some things with it this way and do more testing.

[GeeklyGrey]

Well that lasted all of a few seconds and I may have been mistaken as to command. In all I have done a great deal of analysis and head scratching and still these commands will not work for me.

I now believe that the issue has to lie somewhere in RoboClaw.
There may be a speed or timeout issue which is at its worst with these selected commands.

I say that because if you compare the bytes sent for command 66 with command 43, with all values set to 2000, then the command outputs are identical with exception of the command number itself and the CRC16 values, and of course the resulting motions. The command 43 does its job and the motors run while command 66 will not turn the motors for me. This applies to both 65 and 66. I have coded a command structure for dual motors command 67 and that will not work for me either. I hear a 'scrittttch,scrittttch' noise from the motor, an attempt to do something but nothing does happen.

It is apparent that the command is being accepted from the 'FF' feedback and the little noises.
The command length and content is accepted by comparison with command 43 which works and the command line tested by you for me seemed to work on your fast machine. That also rules out the thought that the command structure in use is at variance with the published manual.

The speed of my PC will not be similar to your machine BUT -ALL- the other commands work properly without any of the issues I am having with these three positioning commands.

The only single answer to this that I can visualise is speed of delivery within the roboclaw is running foul of a timeout trap in the case of these three commands. And then there is IONmotion which seems to be operating these same commands without issue on the same computer. How can there be such a difference in result.

The answer to that is ' there has to be another factor acting as a trip line'.
When IONmotion is doing all this it works fine because the conditions are set by itself to a 'known' level.
When I am doing it some 'pull-cord' is not being pulled even though all other commands work fine on the same machine immediately before and after without doing anything to RoboClaw.
After the last upgrade I found the S$/S5 values had changed to Home(auto) instead of Home(user), and I wonder if some setting is inadvertently affecting what is happening. It needs to be something like this to have the clear-cut lack of action I am seeing.

Any thoughts? I am about all thunk out on this one.

[Basicmicro Support]

I plugged in your exact data and it did work. Using the currently available version. This would lead me to beleive the problem is something out side of the raw data. Could be how its being sent? Follow along with what I did:

1. I used RealTerm specifically to elliminate the method of sending the data.
2. I then sent the exact data you said you were sending(IE the unsigned speed value, not the negative speed value).
3. I used the exact PID settings you said you were using.

Im I missing something? The only thing I didnt do was use the home signal(s) at all(my s4 and s5 are disabled). Try running the same test with homing disabled and let me know what happens.

Also note that it doesnt matter how fast you sent the bytes for the commands if it was accepted(eg the 0xFF indicates that) then it received the command and no timeout happened or could have happened. The ocmmand doesnt execute until the whole command is received. If you are sending the command while the home sensor is triggered it could potentially be some kind of debounce issue. Another test assuming the first test works, would be to move the device out of the home sensor before running the test but leaving the sensors enabled to see if that fails or not.

Lastly, any chance you can call in so I can work with you on this. I have a new release I want to put up that adds some better control input filtering for Analog/RC controls but if there is a bug in a specificc usage case of commands 65/66/67 I want to fix it before making this new release.