I have two simpleFOC boards that I make to work together stacked on an Arduino UNO. I have hardware configured (soldering pads) as suggested on the site, as for PWM and Encoder pins, as in the following:
Signal
Pwm A
Pwm B
Pwm C
Enable
Encoder A
Encoder B
Encoder I
Board #1
10
5
6
8
12
2
4
Board #2
9
3
11
7
A5
A4
13
Then I have two motors, iPOWER GM4108, each equipped with an AS5048A magnetic encoder. The encoders are wired according to the SPI connection as in the following:
ENC → Arduino UNO
GND → GND
Csn → A0 or A1
CLK → SCK (13)
MOSI → +5V
MISO → MISO (12).
The encoders both work well with the “magnetic_sensors_spi_example.ino”.
Using the code in the example “full_control_serial.ino”, board #1 works well while board#2 doesn’t. It is not a problem with the motor or encoder. By moving the motor-encoder to the board #1, they work well.
The board #2, using other code, can drive the motor correctly, for example, in an application using both motors with two 8192 PCR encoders.
@Valentine
Thank you for the prompt reply.
Pins 12 and 13 work like a bus. It answer upon the called id. The econders works well with a code making no use of the SimpleFOC library, both connected and both answering at the same time. Moreover the board #2 doesn’t work with the “full_control_serial.ino” which involve only one board: in that case the mentioned conflict doesn’t occur. While the board #1 does work.
Cheers, Francesco
I’m afraid this will not be possible using the standard magnetic sensor spi class.
We did not take in consideration the case where you’d daisy chain the two SPI sensors therefore it only works for one sensor at the time.
What you can do however is use the generic sensor and just timplement the getAngle function to return a value between 0 and 2pi. It is more or less what you’ve done already.
@Antun_Skuric
Hi, thanks for the reply.
I wanted to try the setup (two daisy-chained sensors) to see if it works with the FOC libraries. It works perfectly! My problem is another. That is, I have two shield cards hardware programmed according to the instructions on the SimpleFOC site. The shield #1 works perfectly (motor with the AS5048) while the #2 doesn’t.
If I consider just one motor/encoder, when connected to the #1 board, it works; when connected to board #2 doesn’t. For board #1 and #2 I mean two simpleFOC 2.0.4 with the hardware bridges according to what described in my first post above. When I use the board #1 with the example “angle_control” the motor makes the initialization, little movement forward then backward, then starts at constant velocity. So, good behavior.
Whit board #2, same motor/encoder and same code, since from the initialization there is something wrong… a strange hi frequency vibration… then no movements with the vibration… and when is time of constant velocity, always vibration. The motor hold the position vibrating.
I still think it’s the daisy chaining that’s causing the issue.
For example when you’re requesting the angle reading from the sensor you’re writing the MOSI pin, which is connected to the pin 11 of the arduino UNO. Even though you did not connect it physically, I still think that the SPI communication library uses it.
Maybe there are people with a bit more knowledge to explain this more in detail. In my opinion the function SPI.transfer16 will be the one causing the issues. And the best way to get arround it to implement a GenericSensor you already have all the code.
Hey, its cool someone is trying to use the daisy chaining mode.
In theory, I think it should be compatible with SimpleFOC, but I think you’ll have to write a special driver for it. MagneticSensorSPI, and also the AS5048A specific driver class in our drivers repository are intended for use with a single sensor.
When using a single sensor, you can work without the MOSI pin, just connect the MOSI on the sensor side to logic 1. On the MCU side, whether the MOSI pin can be used or not will depend a bit on the MCU, and maybe also how the Arduino framework is coded. If the framework re-intializes the SPI peripheral pins when you call the SPI methods then that will be a problem. But if it only sets up the pins during the SPI.begin(), then you should be able to set the pin to normal output mode after initialising SPI, and use it for other purposes.
When using a daisy chain, its not clear whether you can leave out the MOSI pin… looking at the datasheet it looks like you have to send SW_RESET as well as READ_ANGLE commands, and that would imply you need the MOSI line. But the reset isn’t described anywhere else, so this may also just be another READ_ANGLE to refresh the data? I guess you have to try it out.
When reading from the sensor in the “4-wire” daisy chain, you have to do multiple reads of 16 bits, once for each sensor, while keeping the nCS line low.
Note that you’ll have to wrap all this in a way that then provides the data via 2 instances of the Sensor class, so that you have one instance to link to each motor…
