I purchased these at All Electronics in Van Nuys, Ca. The Lamda is old but works great. The other is out of production. Maybe a similar item would help.
EDIT... After hooking up the WXY pins to a scope, noticed some activity in the scope and touching the motor shaft there is a short burst forward and then backward (15 seconds apart, which was the MTR_HOLD_AT_SPEED_IN_SEC setting). Created a repeating loop & set MTR_HOLD_AT_SPEED_IN_SEC to different values, but results of the short forward/backward bursts are the same. Video of the HDMI screen: https://youtu.be/70F3EqzD09I
END-EDIT
Not getting motor response when trying to use the driver with: Parallax BLDC, 24V motor, SKU 750-90020... I do get response from the hall sensors, but the motor does not turn using the demo_single_motor.spin2 source (latest from P2-BLDC-Motor-Control-main ZIP download).
I noticed that PWR_24p0V is stated as "NOT SUPPORTED", but actually does appear to be supported in the isp_bldc_motor.spin2 sources.
isp_bldc_motor_userconfig.spin2 states:
' ADDING SUPPORT as we go...
' WARNING: NOT SUPPORTED YET: (if you use a NOT SUPPORTED value, motor won't go...)
' NO SUPPORT FOR PWR_6p0V
' NO SUPPORT FOR PWR_7p4V
' NO SUPPORT FOR PWR_24p0V
BUT, isp_bldc_motor.spin2 code appears to support PWR_24p0V:
if user.MOTOR_TYPE == MOTR_DOCO_4KRPM
CASE userVoltage
' NOTE 6.0V is not legal for this motor
PWR_7p4V:
PWR_11p1V:
PWR_12p0V:
PWR_14p8V:
PWR_18p5V:
PWR_22p2V:
PWR_24p0V:
' NOTE 25.9V is not legal for this motor
OTHER:
legalVoltage := INVALID_VOLTAGE
This config reports hall sensor activity, but the motor does not spin:
MOTOR_TYPE = MOTR_DOCO_4KRPM
ONLY_MOTOR_BASE = PINS_P16_P31
DRIVE_VOLTAGE = PWR_24p0V
WHEEL_DIA_IN_INCH = 0.0 ' no wheel attached (floating point constant)
Do I need to use this config?:
MOTOR_TYPE = MOTR_DOCO_4KRPM
ONLY_MOTOR_BASE = PINS_P16_P31
DRIVE_VOLTAGE = PWR_12p0V <== use 12V versus 24 ???
WHEEL_DIA_IN_INCH = 0.0 ' no wheel attached (floating point constant)
@"Stephen Moraco" said:
@dgately there is the beginning of support for 24v but it’s not complete. Stay below 24v for now…. Always more to be implemented. 😋
Well, thats good But, even using the config set to DRIVE_VOLTAGE = PWR_12p0V, I get only a short pulse of movement. About an 8th turn forward, then backward the same amount. I get the same pulse no matter what value of MTR_HOLD_AT_SPEED_IN_SEC...
The forward pulse (I think, but could have been a backwards) looks like this for the WVU outputs to the motor:
After sending the pulse, it waits for the correct amount of time with the following code, but the pulse is "long gone!".
wheel.stopAfterTime(MTR_HOLD_AT_SPEED_IN_SEC, wheel.DTU_SEC) ' set to hold at speed for MTR_HOLD_AT_SPEED_IN_SEC Sec
waitUntilMotorDone()
Note:
Yellow probe == yellow (W)
Blue probe == blue (V)
Purple probe == green (U)
Setting up the driver for debugging, the console returns the following (note: I have added some DEBUG statements so I would know where in the code we are at any one time. And, voltage, current and watts are displayed, while waiting for the motor to finish...)...
The motor is obviously faulting, but does this debug data give a clue as to why? Is the "MOTR_DOCO_4KRPM" config applicable to the Parallax BLDC motor in the recent Mystery Box? At 12V?
@VonSzarvas said:
Sorry for not reading all the details above, but is your power source able to supply the required amps at 12V. Ie. Your not hitting a current limit.
You might want a 2 or 3amp @12v capable power source.
@VonSzarvas said:
The other critical factor is the deadtime software setting. I think the rev A 64010 needed about 250ms, and the rev B about 50ms.
I guess the driver auto-configures the deadtime, but figured it's worth mentioning as that and the power source can cause what you are seeing.
I'm using an Edge (P2-EC) and Mini Breakout (64019)... Should that be closer to the A 64010 rev B and require 50ms or totally different? Note: DEBUG stated: "init values dead_gap = 70", during test runs.
@knivd said:
Maybe a stupid question for which I apologise, but can this object with BLDC motors be used for precise static positioning like steppers?
Hmm, good question? Here's my thinking...
Things that help:
(1) The driver API supports feedback in turns of hall tics and can stop the motor after N tics.
(2) The driver supports active braking - can use power to keep the motor in a stopped position
Things that might hinder:
But... the distance between hall tics varies by motor type. (e.g., the 6.5" is 4° while the DocoEng motor is 15°) so the step size will be in terms of these rotational distances.
Also, your power choice (how fast you attempt to move between steps) would affect the behavior.
So, in the end, this would need to be experimented with to see what type of precise control we do have. Does this help?
Lastly, our motor API is purposefully rich to support many different areas of investigation and use.
Code archive attached (from PropellerTool). This is the same archive as was attached to the QuickByte demo page, but I figured it would be good to be certain we are both using the same code.
If you have things set-up the same way (with 12V source) and run the "demo_single_motor.spin2" code, does that work for you ?
If yes, at line 86-ish you can increase the motor speed limit from 5 to 50 or more, and see if things are still good.
Did you already check for signals out of the motor drive terminal blocks? And signals at the hall headers?
@VonSzarvas said:
Code archive attached (from PropellerTool). This is the same archive as was attached to the QuickByte demo page, but I figured it would be good to be certain we are both using the same code.
I tried your code and the motor is now spinning (yay!) The code I had used came from the propeller code on GitHub.
If you have things set-up the same way (with 12V source) and run the "demo_single_motor.spin2" code, does that work for you ?
Yes, my setup is like yours and now the motor is spinning (there is an issue that may be a hint of the problems). See below):
If yes, at line 86-ish you can increase the motor speed limit from 5 to 50 or more, and see if things are still good.
Yes, that speeds up the motor, but it seems to hang, waiting for the motor to finish past the time set by MTR_HOLD_AT_SPEED_IN_SEC (I set it from 5 to 15 seconds for testing). Let me test that some more as I'm trying to run the motor at different speeds within a loop.
Did you already check for signals out of the motor drive terminal blocks? And signals at the hall headers?
Yes, When I was testing the original code from GitHub, I put the signals onto my scope and could see the short burst of pulses, but they would not last as long as MTR_HOLD_AT_SPEED_IN_SEC. But, with your code version, the motor keeps spinning. Now, just have to figure out why waitUntilMotorDone() is not returning.
So, the issue that may hold a clue is displayed here (this is your version of the code but notice the HDMI display):
Notice that the HDMI display is rather wonky... The only difference that I find is in 'your' p2textdrv.spin2 file, compared to the one from GitHub (FileMerge says):
The code with Mac CR line endings versus Windows CRLF line endings is compiling differently? That's the only difference that I can see. I ran FileMerge on other project files and did not find actual code differences, just the line-endings. Not sure how this caused a problem with the motor driver... When I compile your motor driver and demo code, the motor works, but the HDMI display is broken. I replaced p2textdrv.spin2 with the GitHub code and the HDMI display is correct. Perplexing, for sure!
BTW: I am also using macOS! If I edit and save any files with typical Mac editors (subEthaEdit, TextEdit, etc.) they will also get macOS line-endings. However, I have not edited the files from the ZIP!
Really? I thought only Classic Mac OS used Mac line endings, and that they switched to Unix endings when OSX came out, and I used to use Mac before I switched to Linux. Huh.
@Electrodude said:
Really? I thought only Classic Mac OS used Mac line endings, and that they switched to Unix endings when OSX came out, and I used to use Mac before I switched to Linux. Huh.
You are correct! Testing this, modern macOS-created text-only files use just a line-feed (0a), as does Linux/Unix. Not sure how the files above have (0d) at line ends.
I'm going to check the repo today to see what's going on. When I find those files I'll correct them in the repo. I'll report back here what the conclusion is.
Ok, nothing was found! When I pull a fresh copy of the repo and check all .spin2 files they have the correct line endings for my OS (macOS, LF line terminators) I also unpacked the latest release .zip and .tar.gz files and they are all LF-only terminated as well. So I don't have a clue why some people are getting CR-only vs CRLF or LF-only line terminators. Does anyone else have any ideas?
I was wrong. My check tool was broken, is working now.
Let's try this again. The BLDC repo is fine, LF-only (mine) and CRLF (not mine) files however, the release .zips have mostly CR-only files and I have no idea how this happened. I'm working on fixing the .zip files.
Final State of Things
Ok, in the end, I was able to download the .zip archives, repair the files containing CR-only line endings, rebuilt the .zip files and replaced the .zip files in the release with the new .zip files. All should be good now. Please let me know if that's not the case.
I'll be watching for this issue in releases from now on.
@"Stephen Moraco" said: Final State of Things
Ok, in the end, I was able to download the .zip archives, repair the files containing CR-only line endings, rebuilt the .zip files and replaced the .zip files in the release with the new .zip files. All should be good now. Please let me know if that's not the case.
When I try to compile demo_single_motor.spin2 in flexprop on macOS as well as on WIN 11, I get the following errors:
"./flexprop/bin/flexspin" -2 -l --tabs=2 -D_BAUD=230400 -O1 --charset=utf8 -I "./flexprop//include" -I "./flexprop/include/spin" -I "./flexprop/include/libsimpletext" -I "./Downloads/spcog_v1_0/tunes" -I "./Documents/P2ESCode/p2library" -I "./Documents/PropSpinCode/SpinObjects" -I "./flexprop/include/filesys/fatfs" -I "./Documents/P2ESCode/P2Custom" "./Downloads/demo-archive-set/demo_single_motor.spin2"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.18-beta-v5.9.16-69-gbd2c222b Compiled on: Oct 13 2022
./Downloads/demo-archive-set/demo_single_motor.spin2:35: error: unknown identifier ONLY_MOTOR_BASE in class isp_bldc_motor_userconfig
./Downloads/demo-archive-set/demo_single_motor.spin2:35: error: unknown identifier ONLY_MOTOR_BASE in class isp_bldc_motor_userconfig
demo_single_motor.spin2
|-isp_bldc_motor_userconfig.spin2
|-isp_hdmi_debug.spin2
|-|-p2textdrv.spin2
|-|-|-p2videodrv.spin2
|-isp_bldc_motor.spin2
|-|-isp_bldc_motor_userconfig.spin2
|-|-isp_dist_utils.spin2
child process exited abnormally
Finished at Thu Oct 13 18:34:13 2022
So, I ran FileMerge on that copy of isp_bldc_motor_userconfig.spin2, which has Unix/Liux line-ending (CR) and a copy that had WIN-style (CRLF) line-ending (which I named: "isp_bldc_motor_userconfigMINE.spin2"). That's the only difference! The copy with WIN-style (CRLF) compiles without issue (on macOS & WIN11):
"./flexprop/bin/flexspin" -2 -l --tabs=2 -D_BAUD=230400 -O1 --charset=utf8 -I "./flexprop//include" -I "./flexprop/include/spin" -I "./flexprop/include/libsimpletext" -I "./Downloads/spcog_v1_0/tunes" -I "./Documents/P2ESCode/p2library" -I "./Documents/PropSpinCode/SpinObjects" -I "./flexprop/include/filesys/fatfs" -I "./Documents/P2ESCode/P2Custom" "./Downloads/demo-archive-set/demo_single_motor.spin2"
Propeller Spin/PASM Compiler 'FlexSpin' (c) 2011-2022 Total Spectrum Software Inc.
Version 5.9.18-beta-v5.9.16-69-gbd2c222b Compiled on: Oct 13 2022
demo_single_motor.spin2
|-isp_bldc_motor_userconfigMINE.spin2
|-isp_hdmi_debug.spin2
|-|-p2textdrv.spin2
|-|-|-p2videodrv.spin2
|-isp_bldc_motor.spin2
|-|-isp_bldc_motor_userconfig.spin2
|-|-isp_dist_utils.spin2
ieee32.c
demo_single_motor.p2asm
Done.
Program size is 140020 bytes
Finished at Thu Oct 13 18:43:05 2022
@"Stephen Moraco" said:
So, in the end, this would need to be experimented with to see what type of precise control we do have. Does this help?
Lastly, our motor API is purposefully rich to support many different areas of investigation and use.
-Stephen
Seems promising. I am in options for motor control, but mostly for precise positioning and not so much for continuous rotation. Hall sensors are inherently inaccurate; they create a field, which can be detected from two sides. Optical sensors are much better in that regard, although they are also not ideal.
@"Stephen Moraco" said:
@dgately there is the beginning of support for 24v but it’s not complete. Stay below 24v for now…. Always more to be implemented. 😋
Well, thats good But, even using the config set to DRIVE_VOLTAGE = PWR_12p0V, I get only a short pulse of movement. About an 8th turn forward, then backward the same amount. I get the same pulse no matter what value of MTR_HOLD_AT_SPEED_IN_SEC...
The forward pulse (I think, but could have been a backwards) looks like this for the WVU outputs to the motor:
After sending the pulse, it waits for the correct amount of time with the following code, but the pulse is "long gone!".
wheel.stopAfterTime(MTR_HOLD_AT_SPEED_IN_SEC, wheel.DTU_SEC) ' set to hold at speed for MTR_HOLD_AT_SPEED_IN_SEC Sec
waitUntilMotorDone()
Note:
Yellow probe == yellow (W)
Blue probe == blue (V)
Purple probe == green (U)
That is the same issue I have with see attachment. I varied the volts from 5 to 24 and get the 1/4 turn then stops.
@"Stephen Moraco" said:
@pilot0315 I can guarantee that the driver will not work with that motor until adjustments are made to built-in tables and power limits. There will be a number of experiments to determine what needs to be added.
Comments
@CJMJ
The variable is an old LAMBDA model lr-602a-fm: https://www.recycledgoods.com/lambda-dc-power-regulator-lr-602a-fm/ I got both from All Electronics in Van Nuys, Ca when I lived there it is variable up to 15 volts and 15 amps.
The 24 output: https://www.alliedelec.com/product/mean-well/sp-240-24/70069596/
All Electronics:
https://www.allelectronics.com/
Ask for Fabien or Mike. Tell them Martin Montague sent you. I have worked with them for 10 years. Really great folks. Everything is wholesale.
Martin.
@CJMJ
24 volts: https://www.alliedelec.com/product/mean-well/sp-240-24/70069596/
variable to 20 vdc: https://www.ebay.com/itm/254542594417
I purchased these at All Electronics in Van Nuys, Ca. The Lamda is old but works great. The other is out of production. Maybe a similar item would help.
Maybe a stupid question for which I apologise, but can this object with BLDC motors be used for precise static positioning like steppers?
Stephen,
EDIT... After hooking up the WXY pins to a scope, noticed some activity in the scope and touching the motor shaft there is a short burst forward and then backward (15 seconds apart, which was the MTR_HOLD_AT_SPEED_IN_SEC setting). Created a repeating loop & set MTR_HOLD_AT_SPEED_IN_SEC to different values, but results of the short forward/backward bursts are the same. Video of the HDMI screen: https://youtu.be/70F3EqzD09I
END-EDIT
Not getting motor response when trying to use the driver with: Parallax BLDC, 24V motor, SKU 750-90020... I do get response from the hall sensors, but the motor does not turn using the demo_single_motor.spin2 source (latest from P2-BLDC-Motor-Control-main ZIP download).
I noticed that PWR_24p0V is stated as "NOT SUPPORTED", but actually does appear to be supported in the isp_bldc_motor.spin2 sources.
isp_bldc_motor_userconfig.spin2 states:
BUT, isp_bldc_motor.spin2 code appears to support PWR_24p0V:
if user.MOTOR_TYPE == MOTR_DOCO_4KRPM CASE userVoltage ' NOTE 6.0V is not legal for this motor PWR_7p4V: PWR_11p1V: PWR_12p0V: PWR_14p8V: PWR_18p5V: PWR_22p2V: PWR_24p0V: ' NOTE 25.9V is not legal for this motor OTHER: legalVoltage := INVALID_VOLTAGEThis config reports hall sensor activity, but the motor does not spin:
MOTOR_TYPE = MOTR_DOCO_4KRPM ONLY_MOTOR_BASE = PINS_P16_P31 DRIVE_VOLTAGE = PWR_24p0V WHEEL_DIA_IN_INCH = 0.0 ' no wheel attached (floating point constant)Do I need to use this config?:
MOTOR_TYPE = MOTR_DOCO_4KRPM ONLY_MOTOR_BASE = PINS_P16_P31 DRIVE_VOLTAGE = PWR_12p0V <== use 12V versus 24 ??? WHEEL_DIA_IN_INCH = 0.0 ' no wheel attached (floating point constant)Still trying different configs...
dgately
@dgately there is the beginning of support for 24v but it’s not complete. Stay below 24v for now…. Always more to be implemented. 😋
Well, thats good
But, even using the config set to DRIVE_VOLTAGE = PWR_12p0V, I get only a short pulse of movement. About an 8th turn forward, then backward the same amount. I get the same pulse no matter what value of MTR_HOLD_AT_SPEED_IN_SEC...
The forward pulse (I think, but could have been a backwards) looks like this for the WVU outputs to the motor:
After sending the pulse, it waits for the correct amount of time with the following code, but the pulse is "long gone!".
Note:
Yellow probe == yellow (W)
Blue probe == blue (V)
Purple probe == green (U)
Setting up the driver for debugging, the console returns the following (note: I have added some DEBUG statements so I would know where in the code we are at any one time. And, voltage, current and watts are displayed, while waiting for the motor to finish...)...
The motor is obviously faulting, but does this debug data give a clue as to why? Is the "MOTR_DOCO_4KRPM" config applicable to the Parallax BLDC motor in the recent Mystery Box? At 12V?
Sorry for not reading all the details above, but is your power source able to supply the required amps at 12V. Ie. Your not hitting a current limit.
You might want a 2 or 3amp @12v capable power source.
The other critical factor is the deadtime software setting. I think the rev A 64010 needed about 250ms, and the rev B about 50ms.
I guess the driver auto-configures the deadtime, but figured it's worth mentioning as that and the power source can cause what you are seeing.
My power supply was set to 5 amps…
I'm using an Edge (P2-EC) and Mini Breakout (64019)... Should that be closer to the A 64010 rev B and require 50ms or totally different? Note: DEBUG stated: "init values dead_gap = 70", during test runs.
That deadtime is only relevant to the mosfets on the motor driver. Try bumping that 70ms to 150 or 250. Sadly those are just faded re-collections....
If it would help I could go run the code with the same motor tomorrow and compare notes.
That would be great!
Consider it done!
Hmm, good question? Here's my thinking...
Things that help:
(1) The driver API supports feedback in turns of hall tics and can stop the motor after N tics.
(2) The driver supports active braking - can use power to keep the motor in a stopped position
Things that might hinder:
But... the distance between hall tics varies by motor type. (e.g., the 6.5" is 4° while the DocoEng motor is 15°) so the step size will be in terms of these rotational distances.
Also, your power choice (how fast you attempt to move between steps) would affect the behavior.
So, in the end, this would need to be experimented with to see what type of precise control we do have. Does this help?
Lastly, our motor API is purposefully rich to support many different areas of investigation and use.
-Stephen
Hi @dgately !
Little video of my setup here:
https://drive.google.com/file/d/1hakKCSTq7dIXYdTmfSwb2LhSer8xMWr8
Code archive attached (from PropellerTool). This is the same archive as was attached to the QuickByte demo page, but I figured it would be good to be certain we are both using the same code.
If you have things set-up the same way (with 12V source) and run the "demo_single_motor.spin2" code, does that work for you ?
If yes, at line 86-ish you can increase the motor speed limit from 5 to 50 or more, and see if things are still good.
Did you already check for signals out of the motor drive terminal blocks? And signals at the hall headers?
I tried your code and the motor is now spinning (yay!) The code I had used came from the propeller code on GitHub.
Yes, my setup is like yours and now the motor is spinning (there is an issue that may be a hint of the problems). See below):
Yes, that speeds up the motor, but it seems to hang, waiting for the motor to finish past the time set by MTR_HOLD_AT_SPEED_IN_SEC (I set it from 5 to 15 seconds for testing). Let me test that some more as I'm trying to run the motor at different speeds within a loop.
Yes, When I was testing the original code from GitHub, I put the signals onto my scope and could see the short burst of pulses, but they would not last as long as MTR_HOLD_AT_SPEED_IN_SEC. But, with your code version, the motor keeps spinning. Now, just have to figure out why waitUntilMotorDone() is not returning.
So, the issue that may hold a clue is displayed here (this is your version of the code but notice the HDMI display):
Notice that the HDMI display is rather wonky... The only difference that I find is in 'your' p2textdrv.spin2 file, compared to the one from GitHub (FileMerge says):
The code with Mac CR line endings versus Windows CRLF line endings is compiling differently? That's the only difference that I can see. I ran FileMerge on other project files and did not find actual code differences, just the line-endings. Not sure how this caused a problem with the motor driver... When I compile your motor driver and demo code, the motor works, but the HDMI display is broken. I replaced p2textdrv.spin2 with the GitHub code and the HDMI display is correct. Perplexing, for sure!
How did you manage to get a file with Classic Mac line endings?
Well, several of the files in VonSzarvas' ZIP file have Mac line-endings (CR)...
BTW: I am also using macOS! If I edit and save any files with typical Mac editors (subEthaEdit, TextEdit, etc.) they will also get macOS line-endings. However, I have not edited the files from the ZIP!
Really? I thought only Classic Mac OS used Mac line endings, and that they switched to Unix endings when OSX came out, and I used to use Mac before I switched to Linux. Huh.
You are correct! Testing this, modern macOS-created text-only files use just a line-feed (0a), as does Linux/Unix. Not sure how the files above have (0d) at line ends.
Happily, flexprop will actually replace all the x0d's with x0a's if you edit and re-save the files in its editor!
Those files came via a GitHub code zip download; possible that process mangled them somehow.
I'm running Win11 and PropellerTool.
All in thread -FYI
I'm going to check the repo today to see what's going on. When I find those files I'll correct them in the repo. I'll report back here what the conclusion is.
Hi all,
Ok, nothing was found! When I pull a fresh copy of the repo and check all .spin2 files they have the correct line endings for my OS (macOS, LF line terminators)
I also unpacked the latest release .zip and .tar.gz files and they are all LF-only terminated as well.
So I don't have a clue why some people are getting CR-only vs CRLF or LF-only line terminators. Does anyone else have any ideas?
I was wrong. My check tool was broken, is working now.
Let's try this again. The BLDC repo is fine, LF-only (mine) and CRLF (not mine) files however, the release .zips have mostly CR-only files and I have no idea how this happened. I'm working on fixing the .zip files.
Final State of Things
Ok, in the end, I was able to download the .zip archives, repair the files containing CR-only line endings, rebuilt the .zip files and replaced the .zip files in the release with the new .zip files. All should be good now. Please let me know if that's not the case.
I'll be watching for this issue in releases from now on.
Could you check the ZIP file from post #47?
I downloaded the demo-archive-set.zip, version 3.0.0 from: https://github.com/ironsheep/P2-BLDC-Motor-Control/releases
When I try to compile demo_single_motor.spin2 in flexprop on macOS as well as on WIN 11, I get the following errors:
So, I ran FileMerge on that copy of isp_bldc_motor_userconfig.spin2, which has Unix/Liux line-ending (CR) and a copy that had WIN-style (CRLF) line-ending (which I named: "isp_bldc_motor_userconfigMINE.spin2"). That's the only difference! The copy with WIN-style (CRLF) compiles without issue (on macOS & WIN11):
FileMerge says:
Seems promising. I am in options for motor control, but mostly for precise positioning and not so much for continuous rotation. Hall sensors are inherently inaccurate; they create a field, which can be detected from two sides. Optical sensors are much better in that regard, although they are also not ideal.
That is the same issue I have with see attachment. I varied the volts from 5 to 24 and get the 1/4 turn then stops.
@"Stephen Moraco"
I wandered over to that page yesterday. Makes sense to me. I will probably have questions. Was a good tutorial. Clear and concise.
Thank you.
Martin
Dennis, yes the .zip file in #47 has the bad line endings too.