Page 1 of 1

encoder count does not change with Duty/PWM commands

Posted: Thu Aug 08, 2019 12:12 am
by tly
If I control a PWM signal (duty command) from either packet serial or the GUI, the encoder count for both M1 or M2 will not change. When a velocity or position command is issued, the encoder counts increment/decrements in the correct direction, so this is not a wiring issue and not a noise issue as scoping the lines are clean. I am running the latest firmware as well at 4.1.33 on a roboclawI 2x7A. I have another setup with the same controller running 4.1.27 without this potential issue. Looking at the other posts I identifed two others who may be having a similar issue, viewtopic.php?f=3&t=901 , viewtopic.php?f=3&t=882

Could I receive a copy of the 4.1.27 Motion Studio as I would like to rollback the 4.1.33 controller if possible.

Another issue with I found with 4.1.33 though I am not sure this is intentional behavior, is that the Read Status (90) register is latching when S4 or S5 is hit and set in Limit(Fwd) mode. For example, I power cycle the controller it reads 0x0, I manually hit the limit switch connected to S5 and hold, status shows 0x800000, I release the switch, status still shows 0x80000 when i expect it to be cleared. Identical behavior for S4 as well as it shows 0x400000. I was expecting the register to clear the warning when the switch is released but this does not seem to be the case?

Re: encoder count does not change with Duty/PWM commands

Posted: Thu Aug 08, 2019 10:10 am
by Basicmicro Support
1. Does the encoder stop counting when using Duty commands or does the encoder get reset and start counting from 0? Note that when switching from closed loop commands to open loop commands some encoder variables are reset but I'll need a little more description to confirm if that is the likely cause. These internal variables are reset when changing from closedloop to openloop to prevent problems with changing back to closedloop later. This was a fixed added recently so may not have been in the earier firmware you are referencing.

The first of the two posts you linked is something else entirely. His problem is setting a deadzone makes small movements (within the deadzone) equal to 0. That is how deadzone works. Are you setting a deadzone?

The second post you linked, the customer never got back to us so I have to assume his problem was noise related. Based on his description it sounds like he was getting false counts or losing counts which caused the zero point to "slide".

2. The limit functionality is correct and by design. When a limit is set it will not clear until the motor moves out of the limit switch. The motor must be sent a command to move out of the limit switch otherwise it will keep the limit signal latched even if the physical switch changes state. The reason the limit system works this way is that some limit switches are momentary.

Re: encoder count does not change with Duty/PWM commands

Posted: Thu Aug 08, 2019 11:14 am
by tly
The encoder stops counting only when using duty commands.

I will test switching between position commands and duty commands and report back the behavior.

The deadzone is set to 25. I am doing a min of 250 resolution steps so that wouldn't be an issue.

Re: encoder count does not change with Duty/PWM commands

Posted: Thu Aug 08, 2019 12:00 pm
by tly
Ok so tested. Switching between velocity & position commands back to duty commands and back. The encoder count just stops counting when a duty command is executing. The counter is will continue to count for both position and velocity from where it left off. The counter never resets to zero.

Re: encoder count does not change with Duty/PWM commands

Posted: Fri Aug 09, 2019 10:20 am
by Basicmicro Support
Just so everyone is on the same page, I have reproduced the problem. It is exclusively tied to the position deadzone setting. If you only set a deadzone and leave everything else at defaults you can reproduce the problem. If you dont use deadzone the problem doesnt happen.

I will look more closely at the firmware.

The temporary work around is to zero deadzone when you change from closed loop to open loop control. and then set it back to 25 when you are changing from openloop to closed loop control.