16LikesThe Homebuilt Dynamometer (Dyno)Thread!!!
04-21-2024, 06:27 PM
#151
In a couple more weeks I should have some time available to look into this as well. I have a bunch of different dev boards that can be tried. I can use the MiniPro flywheel and base for the hardware. I'll look at downloading Simple Dyno and messing around with that. But what would be really cool is if someone could help make a more up to date app for Windows. I will say, that isn't me, lol.
04-21-2024, 07:39 PM
#152
Ok, tried a couple things tonight.
1. Tried sending the serial data as a bunch of Serial.Print lines. Unfortunately, there must be something in the SimpleDyno software that doesn't work with this. Couldn't get the software to read or record any data.
2. I did an array with the Minima (as mentioned in my previous post). Here are some plots. Very nice curve but you can see in the zoomed plot that my disk isn't very symmetrical.
1. Tried sending the serial data as a bunch of Serial.Print lines. Unfortunately, there must be something in the SimpleDyno software that doesn't work with this. Couldn't get the software to read or record any data.
2. I did an array with the Minima (as mentioned in my previous post). Here are some plots. Very nice curve but you can see in the zoomed plot that my disk isn't very symmetrical.
04-22-2024, 12:47 PM
#153
Ok, short update. I fixed the new way of sending the serial data. I was missing a value and the SD software didn't know what to do. With that working and the new "delay" setup, I can get data every 15msec. If I go any faster, the SD software falls behind in some weird way. I am currently printing a bigger peg wheel for the RPM measurement. I am hoping this will yield better results due to the symmetry issue. If my 3d printer is off by some number of mm, then that same number of mm on a bigger wheel should still be better. On the other hand, having the holes on a larger radius means they are passing the sensor with a higher angular velocity. This may cancel out the whole advantage but I am too lazy to do the math.
04-22-2024, 06:15 PM
#154
Ok, short update. I fixed the new way of sending the serial data. I was missing a value and the SD software didn't know what to do. With that working and the new "delay" setup, I can get data every 15msec. If I go any faster, the SD software falls behind in some weird way. I am currently printing a bigger peg wheel for the RPM measurement. I am hoping this will yield better results due to the symmetry issue. If my 3d printer is off by some number of mm, then that same number of mm on a bigger wheel should still be better. On the other hand, having the holes on a larger radius means they are passing the sensor with a higher angular velocity. This may cancel out the whole advantage but I am too lazy to do the math.
04-22-2024, 06:30 PM
#155
Ok, short update. I fixed the new way of sending the serial data. I was missing a value and the SD software didn't know what to do. With that working and the new "delay" setup, I can get data every 15msec. If I go any faster, the SD software falls behind in some weird way. I am currently printing a bigger peg wheel for the RPM measurement. I am hoping this will yield better results due to the symmetry issue. If my 3d printer is off by some number of mm, then that same number of mm on a bigger wheel should still be better. On the other hand, having the holes on a larger radius means they are passing the sensor with a higher angular velocity. This may cancel out the whole advantage but I am too lazy to do the math.
Do you have any gear reduction at all in the setup? 15ms is about 4000 RPM without any gear reduction, so not very good. I thought you were saving all the data to an array then do a serial dump after the run.
04-23-2024, 08:16 AM
#156
Currently 4. I have experimented with 1, 2 and 4 pickups. The main problem with my pickup is that PLA doesn't block IR light so I have to cover the disk with electrical tape. I then cut out the holes in the disk with an X-acto knife and the edges aren't as clean as the 3d printed part.
Yes, sorry. Wrong velocity. The big wheel didn't really work any better anyway. No gear reduction but the data points are timed revolutions not a polling. Every 15msec, it records the next 1/4 revolution time and equates that to RPM. I have been playing around with 2 different ideas. The first being the improvement of the Simple Dyno sketch. The second is dumping the whole run to an array using the Minima (doesn't work with SD yet or my Win7 shop computer. Had to bring a Win10 computer down to the shop).
Your angular velocity will be the same no matter where you are on the disc. Linear velocity will change, but that will not matter.
Do you have any gear reduction at all in the setup? 15ms is about 4000 RPM without any gear reduction, so not very good. I thought you were saving all the data to an array then do a serial dump after the run.
Do you have any gear reduction at all in the setup? 15ms is about 4000 RPM without any gear reduction, so not very good. I thought you were saving all the data to an array then do a serial dump after the run.
04-23-2024, 02:57 PM
#157
Currently 4. I have experimented with 1, 2 and 4 pickups. The main problem with my pickup is that PLA doesn't block IR light so I have to cover the disk with electrical tape. I then cut out the holes in the disk with an X-acto knife and the edges aren't as clean as the 3d printed part.
Yes, sorry. Wrong velocity. The big wheel didn't really work any better anyway. No gear reduction but the data points are timed revolutions not a polling. Every 15msec, it records the next 1/4 revolution time and equates that to RPM. I have been playing around with 2 different ideas. The first being the improvement of the Simple Dyno sketch. The second is dumping the whole run to an array using the Minima (doesn't work with SD yet or my Win7 shop computer. Had to bring a Win10 computer down to the shop).
Yes, sorry. Wrong velocity. The big wheel didn't really work any better anyway. No gear reduction but the data points are timed revolutions not a polling. Every 15msec, it records the next 1/4 revolution time and equates that to RPM. I have been playing around with 2 different ideas. The first being the improvement of the Simple Dyno sketch. The second is dumping the whole run to an array using the Minima (doesn't work with SD yet or my Win7 shop computer. Had to bring a Win10 computer down to the shop).
Would you care to share your timing for the 15ms intervals and how you go about collecting the times? I'm curious if you are using only timers or if you are using any delays.
04-24-2024, 05:52 PM
#159
How big is your encoder wheel? I can print one in PETG, or even PA6-GF. Haven't had a chance to print with the PA6 yet, but it is supposed to be dimensionally stable.
Would you care to share your timing for the 15ms intervals and how you go about collecting the times? I'm curious if you are using only timers or if you are using any delays.
Would you care to share your timing for the 15ms intervals and how you go about collecting the times? I'm curious if you are using only timers or if you are using any delays.
It is the code that I shared above and modified with the suggestions that were posted. Maybe I don't understand how it works? I created a Github repository for sharing
https://github.com/Kufman/Dyno/blob/...New-Delay_Nano
And the one without a string for the serial
https://github.com/Kufman/Dyno/blob/...lay_New-Serial
Array code for Minima
https://github.com/Kufman/Dyno/blob/...t_Array_Minima
Last edited by kufman; 04-24-2024 at 06:07 PM.
04-24-2024, 06:00 PM
#160
I did this as a test early on but I want to test brushed motors as well so I changed the design. I thought it would be easier for my to manufacture an optical wheel. That was before I realized that PLA doesn't work. I also have concerns that a hall probe may have speed related, variable delay problems
04-25-2024, 07:42 AM
#161
The original wheel is 36mm in diameter. The larger test was 96mm. The windows in the wheel are 5mmx5mm. PETG is also transparent to IR. I haven't heard of PA6-GF till your post. Looks interesting from a strength aspect but sounds nasty to print with.
It is the code that I shared above and modified with the suggestions that were posted. Maybe I don't understand how it works? I created a Github repository for sharing
https://github.com/Kufman/Dyno/blob/...New-Delay_Nano
And the one without a string for the serial
https://github.com/Kufman/Dyno/blob/...lay_New-Serial
Array code for Minima
https://github.com/Kufman/Dyno/blob/...t_Array_Minima
It is the code that I shared above and modified with the suggestions that were posted. Maybe I don't understand how it works? I created a Github repository for sharing
https://github.com/Kufman/Dyno/blob/...New-Delay_Nano
And the one without a string for the serial
https://github.com/Kufman/Dyno/blob/...lay_New-Serial
Array code for Minima
https://github.com/Kufman/Dyno/blob/...t_Array_Minima
If you are telling it the update time then this:
if((currentTime - lastUpdateTime) > UPDATE_INTERVAL)
should change to:
if((currentTime - lastUpdateTime) >= UPDATE_INTERVAL)
The first statement will make the update time greater than the interval while the second statement will keep it at the update interval.
So the code has an ISR that is constantly running checking for the falling edge of the rpm sensor. Then the code that is running in the main loop checks for the update time and then serial prints all the variables it it currently knows. It goes through 6 analog sensors, I assume this is in case you want to use them all, but I would comment out all the sensors not being used and change the number of ports to read to the number of analog sensors you have. Then store the other non needed sensors as 0s in a string in flash (use FlashStringHelper). This will save time and not have to analog read the sensors you are not using as each analog read take approximately 110µs. I would also write a function for the analog reads instead of reading them while serial printing and then just serial print the results.
After that, I would test a sensor on the motor by connecting off of one into pin 2 of your Uno. But these sensors work reliably for low turn BLDC motors with high rpm (50,000+).
And... I just looked at the array code. Which is completely different, lol. So question I have now; what does the Simple Dyno software actually expect for data? I don't think you need all these data points for current and voltage. Your array size is 1550, and I think you said you can get 4 seconds, so if you average it, 400 sample/seconds. I understand the longer the run goes the more samples there will be because the RPM goes up, but just for numbers sake let's make it easy. So the idea is to split up the analog read from the rpm sensor (and please take those out of the ISR) and treat the timing of these (rpm and other sensors) independently. I would put the analog sensors on a timer to start with and go from there. After looking through this there are quite a few different things I want to try.
As to the IR transparency, are you using black filament? Some on the interwebs claim the black PLA can be used. I'm not seeing a lot of results for PETG and IR transparency. I also have some black PLA-CF I can test with. Not sure if the small amount of carbon filament in it would make a difference, but I will print a test wheel and test it with a ir tachometer.
04-25-2024, 02:14 PM
#162
Do you tell the program the update time or does it take it from the timestamps of the readings?
If you are telling it the update time then this:
Good question, I am not 100% sure what the SD software is looking for.
if((currentTime - lastUpdateTime) > UPDATE_INTERVAL)
should change to:
if((currentTime - lastUpdateTime) >= UPDATE_INTERVAL)
The first statement will make the update time greater than the interval while the second statement will keep it at the update interval.
So the code has an ISR that is constantly running checking for the falling edge of the rpm sensor. Then the code that is running in the main loop checks for the update time and then serial prints all the variables it it currently knows. It goes through 6 analog sensors, I assume this is in case you want to use them all, but I would comment out all the sensors not being used and change the number of ports to read to the number of analog sensors you have. Then store the other non needed sensors as 0s in a string in flash (use FlashStringHelper). This will save time and not have to analog read the sensors you are not using as each analog read take approximately 110µs. I would also write a function for the analog reads instead of reading them while serial printing and then just serial print the results.
I will have to think about that.
After that, I would test a sensor on the motor by connecting off of one into pin 2 of your Uno. But these sensors work reliably for low turn BLDC motors with high rpm (50,000+).
They work fairly well but you are subject to the sensor balance causing the same problem as my wonky wheel. If I was only using a single sensor pickup per revolution, either system works fine. I have spoken to Tekin in the past about the hall sensors and they don't really like them but that is the way the industry went. Tekin and Castle both said that the sensors can give bad timing data during periods of high torque (Lots of magnetic field from the stator). The magnetic field can actually shift in the rotor which is why using sensorless, back EMF gives the best timing information. I also test brushed motors so it wasn't a good option for me.
And... I just looked at the array code. Which is completely different, lol. So question I have now; what does the Simple Dyno software actually expect for data? I don't think you need all these data points for current and voltage. Your array size is 1550, and I think you said you can get 4 seconds, so if you average it, 400 sample/seconds. I understand the longer the run goes the more samples there will be because the RPM goes up, but just for numbers sake let's make it easy. So the idea is to split up the analog read from the rpm sensor (and please take those out of the ISR) and treat the timing of these (rpm and other sensors) independently. I would put the analog sensors on a timer to start with and go from there. After looking through this there are quite a few different things I want to try.
So far, I have been black box testing what the SD software is looking for. I know it wants all the values for each data point. I also know that is is looking at the RPM in real time to determine when data taking should begin and when it should end. It is a settable parameter in the software.
As to the IR transparency, are you using black filament? Some on the interwebs claim the black PLA can be used. I'm not seeing a lot of results for PETG and IR transparency. I also have some black PLA-CF I can test with. Not sure if the small amount of carbon filament in it would make a difference, but I will print a test wheel and test it with a ir tachometer.
Yes, black and dark blue PLA with 100% infill and up to 5mm thick. I also know that painted lexan doesn't work (tried a scrap piece of a painted body). My cousin does vinyl cutting so want to try that route as well since electrical tape works very well.
If you are telling it the update time then this:
Good question, I am not 100% sure what the SD software is looking for.
if((currentTime - lastUpdateTime) > UPDATE_INTERVAL)
should change to:
if((currentTime - lastUpdateTime) >= UPDATE_INTERVAL)
The first statement will make the update time greater than the interval while the second statement will keep it at the update interval.
So the code has an ISR that is constantly running checking for the falling edge of the rpm sensor. Then the code that is running in the main loop checks for the update time and then serial prints all the variables it it currently knows. It goes through 6 analog sensors, I assume this is in case you want to use them all, but I would comment out all the sensors not being used and change the number of ports to read to the number of analog sensors you have. Then store the other non needed sensors as 0s in a string in flash (use FlashStringHelper). This will save time and not have to analog read the sensors you are not using as each analog read take approximately 110µs. I would also write a function for the analog reads instead of reading them while serial printing and then just serial print the results.
I will have to think about that.
After that, I would test a sensor on the motor by connecting off of one into pin 2 of your Uno. But these sensors work reliably for low turn BLDC motors with high rpm (50,000+).
They work fairly well but you are subject to the sensor balance causing the same problem as my wonky wheel. If I was only using a single sensor pickup per revolution, either system works fine. I have spoken to Tekin in the past about the hall sensors and they don't really like them but that is the way the industry went. Tekin and Castle both said that the sensors can give bad timing data during periods of high torque (Lots of magnetic field from the stator). The magnetic field can actually shift in the rotor which is why using sensorless, back EMF gives the best timing information. I also test brushed motors so it wasn't a good option for me.
And... I just looked at the array code. Which is completely different, lol. So question I have now; what does the Simple Dyno software actually expect for data? I don't think you need all these data points for current and voltage. Your array size is 1550, and I think you said you can get 4 seconds, so if you average it, 400 sample/seconds. I understand the longer the run goes the more samples there will be because the RPM goes up, but just for numbers sake let's make it easy. So the idea is to split up the analog read from the rpm sensor (and please take those out of the ISR) and treat the timing of these (rpm and other sensors) independently. I would put the analog sensors on a timer to start with and go from there. After looking through this there are quite a few different things I want to try.
So far, I have been black box testing what the SD software is looking for. I know it wants all the values for each data point. I also know that is is looking at the RPM in real time to determine when data taking should begin and when it should end. It is a settable parameter in the software.
As to the IR transparency, are you using black filament? Some on the interwebs claim the black PLA can be used. I'm not seeing a lot of results for PETG and IR transparency. I also have some black PLA-CF I can test with. Not sure if the small amount of carbon filament in it would make a difference, but I will print a test wheel and test it with a ir tachometer.
Yes, black and dark blue PLA with 100% infill and up to 5mm thick. I also know that painted lexan doesn't work (tried a scrap piece of a painted body). My cousin does vinyl cutting so want to try that route as well since electrical tape works very well.
04-25-2024, 03:57 PM
#164
https://www.tinkercad.com/things/1zf...dyno-rpm-wheel
05-06-2024, 06:38 PM
#165
Any progress on this?
EDIT: And do you have the Simple Dyno software? I checked the github link, but there is not a packaged zip file that I can find.
EDIT: And sometimes you just got to click a few more times to find it...
EDIT: And do you have the Simple Dyno software? I checked the github link, but there is not a packaged zip file that I can find.
EDIT: And sometimes you just got to click a few more times to find it...
Last edited by trilerian; 05-06-2024 at 06:52 PM.