the disengage time is how long the motor reverses for at teh end of the move, so tweak this so that the gear carrier sits perfectly in the middle.
the stroke time is just a timeout, and if it hasn’t reached its position by this time it will cancel the move.
your pwm is set to 750 which i found to be the optimum and doesn’t have a high pitch noise, but 255 for the duty cycle is max power and means the motor is always on so you wont notice the hum. you could reduce this and make it slightly quieter. but when you reduce it you will need to adjust the stroke/disengage times, 200 would be a good starting point.
you will see the slave has a lot more advanced options, its got a calibration routine etc. I’m in the process of porting it over to the master but I’ve found some issues. im re-writing the whole motor control logic for better error handling and basically doing the “calibration” on every move. my aim is to verify every time the actuator moves if the disengage time was correct and warn the user if its not. might take me a week or so… work is getting busy again
ahh yes, i forgot i hadn’t added those features to the master yet.
look in the file SleepyLoraMaster/include/Device_settings.h
line 37
time_t disengage_time = 1000;
time_t stroke_time = 14000; // time for full stroke
these are the times to tweak.
Im almost done with the rewrite of the actuator code, that will be common to the master and slave. but it will take another few days at least to complete and test
still working on the update, its going to be a big change! I’ve made a new library that holds all the code for the “actuator”, and it will be common to both the master and slave, it handles all of the position reading and motor control functions. it also does all the saving/loading of parameters to nvs which really helps the main code readability. the calibration is simplified and it just does one move from 0 to 100 and back with a few stops along the way to check the engage and disengage times. I have reworked the dynamic pwm too, now it targets a finish time, rather than a target speed, this should make synchronizing blinds easier… they look best when they all close at exactly the same time.
the web server is very hard to maintain in its current form and needs a rework too, that’s where I’m at now… might as well do it all at once… I’m changing to templates and moving all web portal code to its own files… ill try and make it universal between the master and slave too… with just the minor difference of lora vs rs485. all the web update and actuator stuff is the same.
I’ve just discovered some things with the motor driver… i was using the eep pin for PWM, but that wasn’t correct! that puts the IC to sleep… so for those currently using the devices its probably best just to use PWM of 255 for now.
the new motor driver will fix that… but i have a million other bugs i have introduced…
edit: I’m running out of hair to pull out! what a mess i have created! we are getting closer though… the motor controller library seems to be working reasonably well, I’ve upgraded to a full PID controller, it needs some tuning but works reasonably well to hit the target close time. just need to test a few things like the PID control direction when the actuator is used on the right vs the left etc.
I think i can live with a 59ms variation on the target time!
I’m happy with the motor controller now… time to get back to the web server - im sick of having to reflash every 2mins to test PWM settings.
edit 2: back to testing edge cases on the motor controller… i was getting a panic and boot loop - i think it was caused by a ticker firing when the cpu was in the process of going to sleep, now i stop the tickers before going to sleep.
there was also another bug where the stall detection didnt work in the reverse use case where extended is closed. this led me down another rabbit hole of bugs! im refactoring the code so there is extend and retract for all logic (PID, stall detection, engage detection etc). just now getting back to the webserver… but i cant get it to work at all now
So web server is working again, and has some updates… I’m still in the process of testing but hope to release tomorrow.
the slider on the right is to move the blind, i found it easier when tuning the PID.
Decided to add more features before I release… now the master web portal shows a list of all the connected slaves, and has a button to rescan for them. Each detected slave then gets a open web portal button and a slider to make it move.
I’m thinking I’ll make all parameters adjustable via mqtt, but for now it will be a manual command, later I will add discovery messages for the key ones that may need adjusting. - edit - ill add this at a later date… to many changes in this update already! +2442 -617 lines!
edit: latest updates pushed to GitHub. let me know what you think! you should notice a considerable reduction in motor noise following the update. I’ve tweaked my PID settings - Kp 12, Ki 0.003, Kd 0.03 deadband 4 integral min-50 max 50 deriv min -25, max 25 deriv alpha 0.1 PWM alpha 0.1 a move time of 30 or 40 seconds is nice and quiet.
Sorry, I’m loaded with work, will be getting back into the build now. Thanks for the updates, looking forward to seeing them on the github, in the meantime I’ll get it all back together
I grabbed the latest software changes. That is a lot of parameters!
The only issue I’m running into is opening the shutters (fully retracted). It doesn’t quite open all the way. The position reports 0 then bounces to like 18. Telling it to open a second time fixes it. I need to look into all the advanced settings and see if I can adjust something
Could you hook up a USB and check what the logs say, I suspect it may be a bug with jam detection… the logic is confusing because of extend/retract open/closed and ahead/behind… I thought I had it fixed.
I can analyse the output and see what’s happening…
How much of the travel are you using with your clip design? Whats you closed and open raw values?
Can you also share your clip design, I have an idea… have the cam profile on the clip side and the boss on the actuator. The reason I changed to the cam on the actuator was because of the link bar, But if your gears are internal then it’s best to keep the force in line with the gears and reduce the load on the slide pins
I think the issue is because the raw goes to 0 , the slider doesn’t really work at the fully retracted position I found it jumps around quite a bit the last few mm of travel doesn’t seem to work…
Can you move the body down a tiny bit so the raw at open is about 20?
I’m actually really surprised how much extra travel is required when using the clip like yours, I have set my raw open at 1500 and raw closed at 3500, that gives me close to horizontal
I’ll have a look and see if I can easily change the cam to the clip and just have a pin on the actuator
Edit: reviewing the logs I can see the engagement detection is what’s pushing it the last bit. Basically it’s getting to 0 raw and completing the move. The reason it moves further with the second command is the engage detection isn’t triggered by the move it’s already so close to 0… basically just noise, and it runs until it times out, this is moving it from where 0 is on the potentiometer even further towards 0. The solution would be to move the body down a little bit to take it out of that region of the potentiometer, or modify the clip to not require so much range. I think with 3700 at the closed limit you should be ok to move it down maybe 5mm.
@stout01 can you give this clip a try. I’m thinking double sided tape should be enough to hold it in place, as long as the hook makes fairly good contact. just trying to keep the light out and not have anything between the shutters
if you find you need a bit more force, you can modify extrude 3 to be a bit wider to give you more sticking force, or add some extra sections to the extrude from sketch 2… if you unhide the sketch you will see what i mean, you can add a few extra mm or make it the same length as the other side.
