I have been working with arduino’s for a while and have come to the conclusion I am not a programmer. I can build just about anything. I’ve been a master mechanic for over 10 years and love to help people. I have hundreds of parts in my garage and have spent countless hours on organizing my garage. So I had an idea to build shelves with bins. It worked for a while but every time I’m looking for one part I make a huge mess. This is usually trying to help someone else and then I have to go spend another day cleaning it again. So I have built a gantry arm that has an RC Car motor that moves an x axis and y axis and grab a bin and bring it back to a “home” location. Now I need to figure out a way to move it and store part locations. I know this project is going to take a long time. I have sat down and used the GLIDE to make a touchscreen interface that I think will work. All the buttons I need to move it save and search. I don’t know how to make them work yet but it looks like it will work to me if I can get the buttons to do what I think they should do.
Hardware I have so far. Brushless motor and speed controllers X 2 that require a PWM signal. One for x and one for y locations. Both have hall 3 hall effect sensors in them. I will only be using one though to count rotations. These rotation counts is what I will use track the position of my x and y axis.
What board do you think I should use to accomplish my task?
This sounds like a fun project. I guess you could use the pulse count module for counting rotations and any of the mainboards. A Cerberus might do it if it has enough pwm outputs. I haven’t checked though
Cerberus, has only 1 PWM counter, so it can’t be used to source different PWM frequencies.
@ Styler93gsx, So do you have the mechanics to fetch bins worked out, and all you need now is the control electronics? If so you’ve come to the right forum
Can you post a pic of your shop? We like seeing them.
You are wrong The firmware sets the correct timer so signals may or not be on the same frequency. At least this is how it was in our implementation before switching to Microsoft.
The PWM for Cerberus has a few different timers that it uses to provide PWM frequencies. If timer 1 is being used with 2 different channels, then the frequency cannot be different. If it happens to be from a different timer, say timer 2, then the frequency can be different. The Cerberus hardware does not allow for different frequencies on the same timer.
Here is an illustrated example:
Timer 1: 2000Hz
Channel 1: period 20%
Channel 2: period 40%
Timer 2: 1000Hz
Channel 1: period 50%
On the other hand, Atmel (Hydra and Raptor) has an independent hardware PWM driver which allows a single PWM timer to have different frequencies.
Channel 1: 2000Hz period 50%
Channel 2: 1000Hz period 20%
Looks like there are two timers used to service the 8 PWM channels on Cerberus (TIM1 and TIM4), or at least, that’s true for Oberon’s Mountaineer code.
It wouldn’t have to be this way, the STM32F4 has something like 16 timers, many of which can be used to generate PWM signals. Honestly, I’m too lazy to pull up the datasheet and do the work to figure out which output pins can be mapped to which timers exactly. It’s just a firmware limitation.
NETMF in general makes such poor use of the hardware provided it’s scandalous
@ Brett - You bring a valid point. To know this info however would give you the ability to control many different signals at different frequencies. The pins could be and should be mapped out to let a user know the different timers to allow for independent control of multiple simultaneous different frequencies. Currently, if you look in the platform_select.h file, you can see at a glance the different timers that are used.
We will try to add a complete map of all of the Cerbware PWM timers and channels as soon as time permits.
@ godefroi - If you follow the link above, you will see that, at least on Cerberus, timers 1, 2, 8, and 14 are being used. The other Cerb platforms could use more.
The firmware sets the correct timer so signals may or not be on the same frequency. At least this is how it was in our implementation before switching to Microsoft.
