I have
this motor controller that I picked up for about 12 euros. It seems to be up to the task of controlling a wiper motor that I also picked up cheaply.
My current set up looks like this. I ultimately want to 3D print some pullies to steer my wheel from the cockpit as an initial, easy to access (and disengage) working concept.
https://imgur.com/a/3qxIzkg
Right now I face the difficulty of trying to get the "vanilla" motor.ino sketch that sean has provided to work. But trying to read it at times feels like trying to decipher ancient Egyptian hieroglyphics (with all due respect).
How best to approach massaging this code into something that I can use in my setup? Whilst not castrating myself of some useful features and fault detections.
Kind regards.
Hey billynomates, welcome to the forum.
In this thread
https://forum.openmarine.net/showthread....70#pid9170 there's a motor.ino with IBT-2 specific adaptations. The motor.ino code has since then been updated, but the version given here might still work for you. Otherwise, you could get an old version of motor.ino from github and diff against that, so you can isolate those specific adaptations, and then apply them to a current motor.ino.
uncomenting #define VNH2SP30
is supposed to work on ibt-2 though I have never attempted to do this.
as for the code being trying to decipher, well it's not even 1500 lines, how bad could it be?
anyway, I can't use the fork mentioned above because it introduced floating point as well as disregard for timing considerations which may work on ibt-2 (with higher sampling noise) but those changes were bad for hbridge mode, so there is no way to merge them.
(2021-04-12, 08:26 PM)seandepagnier Wrote: [ -> ]as for the code being trying to decipher, well it's not even 1500 lines, how bad could it be?
Is that a sincere question? If I said I was a software engineer by profession (albeit a junior), and I've spent several hours hacking away to try and understand the code and get it to work, with little to show for it. Would that be indicative of the code being convoluted? or me being incompetent? or perhaps a combination of both?
It's difficult to give this kind of feedback because it is open source, and it clearly works for some people, and it does come across as me being ungrateful and a bit of a whiner. But I really dig what's going on here, and my intentions are to give some constructive feedback. I found it very difficult to understand the code. Perhaps that's by design, or simply due to a bunch of other technical factors that aren't obvious to me.
Usually, if the code is hard to follow, that can be remedied by documentation. But that's also lacking as far as I can find.
I'm prepared to dig deep and go into the trenches of despair that usually accompanies learning under-the-hood software things, but it seems that there is room for clarification either in code or documentation, that is simply not quite there yet.
There is some documentation on motor.ino in the making ;-) You might check out this youtube I made which will be the basis of it.
https://youtu.be/kpq53e9755s
I just ordered an IBT-2 just out of curiosity. This post
http://www.hessmer.org/blog/2013/12/28/i...h-arduino/ suggests that LPWM and RPWM are enough to drive the engine. I suggest you try hooking RPWM and LPWM to D9 and D10, leaving the VNH2SP30 define untouched for now, wiring the R_EN and L_EN to Vcc.
(2021-04-12, 10:51 PM)billynomates Wrote: [ -> ]Is that a sincere question? If I said I was a software engineer by profession (albeit a junior), and I've spent several hours hacking away to try and understand the code and get it to work
Don't expect to understand it fully after just a few hours. There are some tricky things going on in motor.ino. The documentation could improve, but I'm not going to sacrifice functionality or make the code significantly longer just to make the code more readable. Making this easier to understand for someone (most people) may make it difficult for me, but more importantly, I don't have much reason to make this particular part of the project modifiable by most, otherwise I'm afraid of the bad results from people mindlessly tweaking things and not realizing the side effects (which there are many due to the interrupt driven nature)
Much safer to tweak python you actually get understandable errors. I have a bit of code in avr-gcc for example, and so I've been using this processor for a while. With gcc you can read the source for days and still not understand a lot.
Sorry for your frustration, but the IBT-2 is not really that good of a part. Based on specs my regular motor controller design dissipates a lot less heat therefore is much more efficient, and I rate it only to 7 amps (so it stays cool and efficient) This IBT2 somehow rated to 43 amps, well, I would like to see it do this for any significant time. Maybe with a fan?
Even at 20 amps continuous it is in question if it can manage or not. The autopilot is generally intermittent, so it may be able to "work" for most hydraulic pumps at least most sea conditions, but the heat generated in the ibt2 could become significant in rougher seas.
So for these reasons as well making the sketch easier to understand would only encourage this part and likely just cause more problems or poor performance. Really this part is "ok" for tiller pilots (just a bit less efficient), but I think a lot of people are going by the 43 amp rating which is the point at which it catches fire. I don't want to limit anyone, and you have the same code but how long it will take you is not really my consideration as I have spent years on this. What do you think?
If someone can get it working with a simple #define for IBT2 without damaging motor.ino in other ways I would be glad to merge it.
I am currently testing an IBT-2 with the latest motor.ino available on github repository with almost no code modifications. It works fine (after the usual dismantling of the radiator to ensure electrical isolation and apply thermal conductive paste before reassembling).
As Sean exposed, uncommenting #define VNH2SP30 is enough. Here are some notes taken:
* IBT2 is supported but may require some adjustments for current image accuracy
* Motor current is given by formula Il=Is*Kilis with Kilis=[3000,14000] centered on 8500.
* This is a quite wide range and require calibration thanks to a potentiometer to avoid code modification
* The current signal is at PWM frequency and may require a low pass filter (to be tested)
IBT2 <-> arduino
1. RPWM D2
2. LPWM D3
3. R_EN D9
4. L_EN D9
5. R_IS R_IS & L_IS are connected together and linked to GND by 200ohm+1k potentiometer
6. L_IS A low pass RC filter based on 1uF and 1K resistor may be needed
7. VCC 5V
8. GND GND
The sole modification required is the computation of the current image to match the output given by the IS resistor to GND.
if(pwm_style == 2) // VNH2SP30
return v * 9 / 34 / 16;
The last line need to be updated.
I have chosen to keep the PWM frequency low to enable low velocities and limit BTS7960 dissipation.
Independently of the value of Kilis, I still have to check the accuracy of the current image vs PWM cycle (ie, at various velocities). This is on the list as well as a PWM on the Clutch to limit the power drawn by solenoids such as the ones of hydraulic pilots (the solenoid need to be energized full rate just a few seconds and then a PWM cycle between 50-70% is enough).
All in all and should Sean agree, I can propose some (very minor) mods to the code to support explicitly the IBT-2 based on #define options and Clutch PWM. It would be nice to have a hold-on and pwm as parameters through the various interfaces such as pypilot, web and opencpn but I have not looked at these codes yet.
Regards,
Xavier.
(2021-04-13, 07:17 PM)damien Wrote: [ -> ]I am currently testing an IBT-2 with the latest motor.ino available on github repository with almost no code modifications. It works fine (after the usual dismantling of the radiator to ensure electrical isolation and apply thermal conductive paste before reassembling).
As Sean exposed, uncommenting #define VNH2SP30 is enough. Here are some notes taken:
* IBT2 is supported but may require some adjustments for current image accuracy
* Motor current is given by formula Il=Is*Kilis with Kilis=[3000,14000] centered on 8500.
* This is a quite wide range and require calibration thanks to a potentiometer to avoid code modification
* The current signal is at PWM frequency and may require a low pass filter (to be tested)
IBT2 <-> arduino
1. RPWM D2
2. LPWM D3
3. R_EN D9
4. L_EN D9
5. R_IS R_IS & L_IS are connected together and linked to GND by 200ohm+1k potentiometer
6. L_IS A low pass RC filter based on 1uF and 1K resistor may be needed
7. VCC 5V
8. GND GND
The sole modification required is the computation of the current image to match the output given by the IS resistor to GND.
if(pwm_style == 2) // VNH2SP30
return v * 9 / 34 / 16;
The last line need to be updated.
I have chosen to keep the PWM frequency low to enable low velocities and limit BTS7960 dissipation.
Independently of the value of Kilis, I still have to check the accuracy of the current image vs PWM cycle (ie, at various velocities). This is on the list as well as a PWM on the Clutch to limit the power drawn by solenoids such as the ones of hydraulic pilots (the solenoid need to be energized full rate just a few seconds and then a PWM cycle between 50-70% is enough).
All in all and should Sean agree, I can propose some (very minor) mods to the code to support explicitly the IBT-2 based on #define options and Clutch PWM. It would be nice to have a hold-on and pwm as parameters through the various interfaces such as pypilot, web and opencpn but I have not looked at these codes yet.
Regards,
Xavier.
Hi Xavier, hi Sean
I would be on likeing the option of pwm on the clutch afer 100% engageing setting a lower % to just hold it, for further energy saving while sailing.
Save sailing
Andreas
I bought an IBT-2 as well just to do some experimenting and possibly some mythbusting, but referring to
earlier findings of captkernel and sean's remark before I must agree: this can be a dodgy product. In my case, pcb connections between the 74HC244 and the H-bridges seems to have failed. Myself, I'm not averse to heating up my soldering iron, but based on this one sample, it's hardly a part I would recommend.
So billynomates, if you're still around, you might very well have run into a similar problem. Pulling up R_EN and L_EN, then pulling up RPWM while pulling LPWM down should bring some movement in the motor, provided you supplied 5V to VCC and something more to B+. If it does not, you can join the club that received a DOA.
I must say, this is very frustrating. I guess many of us, including myself, try to find the cheapest products on the web, but I've just decided to only buy from professional suppliers from now on (like conrad in .nl and reichelt in .de) and refrain from sourcing parts from those online providers that have cheap pricing in their sales pitch.