I have built a test stand for working with a Spark Max and a DC motor with encoder feedback.
I can run the motor in “Percent Mode” but when I try to run the motor in Position mode the control loop seems to be disconnected some where. The motor runs as if it were in Percent Mode. The output sets motor speed to fast and the position value increases (or decreases) and it goes sailing right past the set point without any change in the output. I can change kInverted and get the motor to run the opposite direction and it again sails past the setpoint as if it doesn’t exist.
I was able to run a Neo Motor in Position mode and get it to stop at the setpoint. I did some tuning and got it to work ok (unloaded).
But for whatever reason I cannot find the setting that gets the encoder feedback to connect with the control loop when running a brushed motor. It seems like a fairly straight forward operating condition but it just acts like the feedback is not connected to the control loop.
REV has been fairly helpful, but really slow with their responses. They sent a nice list of control parameters for the Spark Max, but I still cannot find the setting that causes the position feedback mode to work correctly with a DC brushed motor.
I think he’s running it through REV’s hardware client software so there wouldn’t be any code to share.
I wouldn’t be surprised if it’s a bug in that software tbh. In our experience if you look at the computer funny, it’ll just stop working until you like blink twice and then plug the usb-c in with your left hand or smthn.
Have you tried using the spark max client to see if that works?
Do you mean the predecessor to the REV Hardware Client?
I have the latest Hardware Client 1.5.3 and the latest firmware in the Spark Max
I have used hardware like this in industrial settings and usually the configuration software provides test modes like this. They also come with extensive documentation that shows how to use each feature.
The documentation for the REV hardware client only seems to hit the high points. I haven’t had any real trouble with the client disconnecting or anything like that, though I only have a single Spark max on USB connection. I can run percentage mode. Percentage and Position modes with a neo motor. The Position value in telemetry mode increases and decreases as expected with motor rotation.
Hitting run motor will cause the motor to run. When Positiion crosses Set Position, the control loop doesn’t do anything to change the motor speed. Its like the summer at the front of the control loop isn’t getting one of those inputs.
Also if I rotate the motor by hand with the telemetry graph running the feedback position will change as expected.
If the output changed at all as the feedback position passes the set point position I would think my kPIDF was messed up. I would expect to see all kinds of overshoot or undershoot, but I am getting nothing. Currently my KP and KI are set to small values, kF and kD are zero.
Its the no control response at all that bugs the crap out of me.
hage-043 is correct there is no code and I am using the Hardware Client to exercise the Spark Max.
It could be a bug in the hardware client, but I have had a few responses to requests to REV Support and they have not hinted that this feature should not work.
I’ve never used anything other than a neo with a spark max so take what I say with a grain of salt, but what shows up when you plot the position from the alternate encoder tab? Also how exactly is your encoder connected to the spark max?
When using anything other than the neos built in encoder you have to configure the feedback sensor in code so there might be a setting missing. I know that if you go to the motor configuration tab you can edit the feedback sensor so you could take a look at that.
My guess is that the position you’re plotting is not the number being used in the control loop. One thing you could try is setting your constants to zero and seeing if there’s any output. That would confirm whether a calculation is being done or if there’s just a bug in the software.
I have some of the same thoughts as you on the encoder input. Support@ rev has confirmed that the main encoder input (used by neos) is directly connected to the pins on the Data Port. When using a brushed motor and nothing is connected to the encoder port, the normal Phase A and Phase B inputs are used on the data port.
I have 1k pull up resistors on the data port AB inputs because the PLG motor encoders are O.C. outputs. I can see frequency generated on the AB inputs when the motor is running. (I don’t have access to an O-Scope right now)
Any way the encoder input I am currently using is the exact same one used by a Neo but the motor type is set to brushed. It would not surprise me that there is a bug that causes that encoder input to be ignored by the control loop even though telemetry shows the position changing.
I suppose I should disconnect my hard limit switches and switch to the alternate encoder input and see what happens. The alternate encoder is supposed to be used when using feedback from somewhere else in the gear train rather than the neo’s encoder.
Well, switching over to use the Alternate Encoder Input didn’t make a difference.
The output only goes to the kOutputMin or kOutputMax value and eventually the Alternate Position blows past the Set Point Position as if it didn’t exist.
Main problem Parameters were kPIDMinInput and kPIDMaxInput the default for these are only -1 and 1. These values are in the Closed Loop section of parameters, not in the encoder section. This resulted in the feedback never reaching a useful value even though telemetry said it was.
Rev Documentation description is: Min (and Max) input expected to be sent to the controller. This is in the units after any conversions using the position conversion factor for the selected PID feedback sensor.
I am assuming this means that the feedback value is limited to the range defined by these min and max values.
kIZone may also have been part of the problem at its default value of 0. It was allowing the Integral factor to get all wound up.
I also tweaked kOutputMax_0 and kOutputMin_0 though I think these were only a minor part of the trouble.
Still don’t know how to set the initial feedback position other than it is 0 at power up. Under software control you can run the device into a hard stop and set a known position. Can’t do that from the hardware client.
Is there a particular reason you need an I term in this controller? As soon as I saw the graph and you mentioned “very low values” for P and I, my thought process went to integral windup. Unfortunately, I’m not very active over the summer so I just saw this thread.
