Yes, before you say it, I know there are a lot of topics asking if the spark max can follow a Talon SRX. This is not one of those topics. The subject may not be clear enough, but reading through here I ran across the concept of using the complex built-in libraries of the TalonSRX, but having all the motors be NEOs instead of a heavier motor like a CIM and driven by SPARK maxes following the Talon. I recognize a few situations where this would be impractical:
The complex motion-profiling, etc. features of the talon are not necessary (probably any motor that does not need to be precisely controlled)
Using a Talon and brushed motor is just as useful (lighter, faster, cheaper) as a SPARK MAX and a brushless motor (because you likely already have Talons, in which case the use of the MAX would be to use a brushless motor)
Youāre out of PDP slots. (remember, every motor controller needs one of the 16 slots, even if it doesnāt have a motor attached)
However, for a team whose programmers know lots about using the control features of the Talons, but whose mechanical design team wants to go brushless, for the physical advantages of NEOs over CIMs, this might seem like a good compromise.
The main problem would be if it turns out to not work at all, which is why I have been asked to research it. So I turn to this community:
Has anybody else experimented with slaving SPARK MAXES to a Talon without a motor attached, and if so, how was your experience with it?
I canāt help but think that this is a pretty inefficient way of achieving whatever it is youāre trying to do. Without a motor attached, an SRX is basically a coprocessor that you have to treat like a motor controller with respect to wiring, PDP slots, etc. Why not write your own high-speed thread on the RIO to do that processing? You could potentially even use a separate coprocessor, such as a Raspberry Pi, to run all of your motors. Heck, since the SRX runs a dsPIC, you could probably figure out how to load the CTRE firmware onto your own dsPIC board, creating a ābrain-in-a-jar Talonā that you wouldnāt have to count as a motor controller.
At Detroit CTRE was showing off a new BLDC motor and controller that they hope to have legal for the upcoming season. They said the new motor controller will have the same programming features as the Talon SRX currently has. No official word on these new products yet, but if they do come to fruition that should all but solve your problem.
If this is not an option, I want to question this statement:
If the Talon isnāt controlling a motor, you can consider it part of a custom circuit. So you can power all of the sensor Talons from either a single PDP branch circuit or a VRM circuit.
Electrically, a small load (1k resistor maybe?) is less potentially harmful to the controller.
If it is a standard H-Bridge using MOSFETs, a high-impedance load (open circuit) can allow for harmful (to the circuit) voltage spikes. Oh, there are ways to mitigate these things, but why risk it for a few milliwatts?
Interesting. Yours definitely seems to be the correct interpretation of the definition of a custom circuit.
A CUSTOM CIRCUIT is any electrical COMPONENT of the ROBOT other than motors, pneumatic solenoids, roboRIO, PDP, PCM, VRM, RSL, 120A breaker, motor controllers, relay modules (per R36-B), wireless bridge, electrical solenoid actuators, or batteries.
(emphasis mine)
That being said, Iāve definitely seen custom circuits with VRMs and Spike relays inside. And per R40 COTS battery packs can be included in custom circuits to power computing devices. So I donāt really know.
Back in 2017, when I needed a relay inside a custom circuit, I intentionally didnāt use a Spike for this reason. It would be nice to get some clarification on whether motor controllers and relays only count as such when being used to control actuators.
Following a Talon with the SPARK MAX is currently not officially supported. You can read about details in the release notes under āKnown Issuesā here. That discussion also includes details for a roboRIO side code workaround.
Anyone who is familiar with the common control features of the Talons shouldnāt have any issues using similar functions on the SPARK MAX. We have some good examples and API documentation that can help as well.
CTREās CAN communication protocol is documented online (and can be reverse engineered using CAN reading programs) so I donāt know that this is necessarily the issue.
Edit: Apparently I was misremembering and this hasnāt been done yet. See below
This is exactly what we did. We were able to successfully use velocity control and motion magic with a NEO that had a spark max follow a talon not connected to any motor. It worked flawlessly and very accurately and we didnāt use Spark Maxās built in following code. We did however use this for our Arm, but we think it could have very well worked with our drivetrain for motion profiling. If you want more info about how we did it:
Reason behind doing this:
The NEO was the only motor that would fit in our design, so programming team was tasked to get it working like a cim and talon. Neoās motion magic equivalent was a horrible experience for us, so we ditched it.
As Kunal said, we did the exact thing you are describing as the NEO was quite literallythe only motor that would fit to power our arm. The method we used to follow the SRX I posted a while back here: REV SPARK MAX & NEO APIs & Info
The reason we did this was because at the time we were not very confident in the Spark MAX software and because we did not want to put any more workload on to our (admittedly weak) programming team than they already had.
Are you sure? The āoldā Talon CAN protocols (that I used here, and that can be found in code on the CTRE github) is no longer in use. Recent Pheonix releases use different, obfuscated packet formats that I havenāt yet succeeded in reverse engineering.
The documentation I remember seeing must have been for the old protocols. Iām pretty sure I remember seeing someone on here had reverse engineered the new protocols, but Iām on mobile so I canāt go searching for it right now. I think in Detroit the Dilligent people were showing off one of their products that reads the CAN bus messages and they were explaining how the CTRE motor controller protocols work, but I could be mistaken on that.
Would you mind providing a link to documentation listing the specific message ids and contents of each message for CTREās protocol? I may be wrong, but I have never seen such a document.
I thought I remembered someone reverse engineering the new protocols but I canāt seem to find it. Iām starting to think I was just misremembering the documentation and reverse engineering of the old protocols, thinking they were for the new ones.
Iād heard about this, but it was āmaybe if enough people lobby the GDC they will clarify this.ā I agree with CarlosGJ, Iām pretty sure a motor controller is a motor controller, regardless of whether itās actually controlling a motor.
So Iām getting mixed messages here. For some teams it seems to work fine, others say itās totally not supported to follow a Talon with a MAX. Did some teams just do some hackery to get it to work?