The actuator in the video comes with a gear box also, essentially a low speed actuator, the one you have is a high speed linear, which IMO is wrong for your application should have been the former style!
Max.

 

Yes, that represents the pwm from the micro.

They are at the very bottom of the schematic post.

I think you can do it in code. But in any case the micro needs to be able to "see" the switch. does it do that now?

I think i'll use a baracade method for securing the switch from tampering, However I'm trying to guess how I could build this feature into the programming:
I'm guessing you are thinking of counting the switch throws and accumulating that number. I timer could deduct switch actions over time. Then program a 'shut down' after the limit has been reached, and "resume" when the selected cool down time is reached.
. . . or were you thinking of something simpler?

To answer your question, currently the micro does not see the switch, it is only in control of imputing PWM at the right time.
The wire going to the switch is a switch loop with 2- conductor 14awg wire with ground.
I'm sure something could be placed on the relay to feed back the switch throws to the micro- controller, however this would involve interfacing 120v AC (a second relay would seem to be the easiest solution, I'm not smart enough to figure out how to do this with discrete DC components

The actuator in the video comes with a gear box also, essentially a low speed actuator, the one you have is a high speed linear, which IMO is wrong for your application should have been the former style!
Max.

I'll admit, this is my first encounter with actuators and everything I ordered was and educated guess. (I already had to return the first set because they were the wrong stroke size)
However since they have already been ordered and installed, they do work for the application . .. , (well accept maybe for the rapid stop at the end lol)
If I had to do it all over again, maybe I'd go with a slower but stronger actuator instead of augmenting it with speed control.
Then again, I wouldn't have gotten the opportunity to talk with you nice folks about making these ones work

 

I think i'll use a baracade method for securing the switch from tampering, However I'm trying to guess how I could build this feature into the programming:
I'm guessing you are thinking of counting the switch throws and accumulating that number. I timer could deduct switch actions over time. Then program a 'shut down' after the limit has been reached, and "resume" when the selected cool down time is reached.
. . . or were you thinking of something simpler?

To answer your question, currently the micro does not see the switch, it is only in control of imputing PWM at the right time.
The wire going to the switch is a switch loop with 2- conductor 14awg wire with ground.
I'm sure something could be placed on the relay to feed back the switch throws to the micro- controller, however this would involve interfacing 120v AC (a second relay would seem to be the easiest solution, I'm not smart enough to figure out how to do this with discrete DC components


I'll admit, this is my first encounter with actuators and everything I ordered was and educated guess. (I already had to return the first set because they were the wrong stroke size)
However since they have already been ordered and installed, they do work for the application . .. , (well accept maybe for the rapid stop at the end lol)
If I had to do it all over again, maybe I'd go with a slower but stronger actuator instead of augmenting it with speed control.
Then again, I wouldn't have gotten the opportunity to talk with you nice folks about making these ones work

I'm just sensitive about the reversal thing. I blew a circuit up once doing that. Your probably good to go.
I didn't give you a link to the capacitor. Get one rated for 25 or 50 volts. You can find them at Mouser as well under aluminum electrolytic.
Don't be afraid to ask if there is something you don't understand during the build.
Let us know how it turns out!

 

Timing is never good. So, in hindsight a potentiometer actuator really gives you what you need. there's pulsed (reed and hall effect) as you say and fixed limit switches.

So, I think what you first might need is a way to detect when to change the speed? If you had the ability to see the entire "last leg", that could work.

Your actuator thing has been discussed under "chicken coop door" many times. For 12 v systems, two automotive relays are generally used and you can arrange the limits to be low current (the relay coil current). One coil becomes FWD and the other reverse with limits.

Jamco has this little kit: http://www.jameco.com/z/K8004-Velleman-DC-to-Pulse-Width-Modulator-Kit-Control-DC-Motors_120539.html which I have used. Picture two reference voltages selected by "last segment: or "Not last segment".

 

Timing is never good. So, in hindsight a potentiometer actuator really gives you what you need. there's pulsed (reed and hall effect) as you say and fixed limit switches.

So, I think what you first might need is a way to detect when to change the speed? If you had the ability to see the entire "last leg", that could work.

Your actuator thing has been discussed under "chicken coop door" many times. For 12 v systems, two automotive relays are generally used and you can arrange the limits to be low current (the relay coil current). One coil becomes FWD and the other reverse with limits.

Jamco has this little kit: http://www.jameco.com/z/K8004-Velleman-DC-to-Pulse-Width-Modulator-Kit-Control-DC-Motors_120539.html which I have used. Picture two reference voltages selected by "last segment: or "Not last segment".

Thank you for the link and the insight.
My PicAxe can generate a PWM signal with no extra hardware and I can tune it to react to the inputs with the program.
I already have the micro-controllers and the mosfet now, I just need the support circuitry.

 

Hello again
I've decided to re-visit this project and go at it from a different angle.
I'm using an Arduino with a purchased set of motor controllers, but I will need to write the arduino code to make it work.

The problem of the abrupt start and stop of the monitors needs to be fixed.
My Arduino project will use a PWM sequence that I will fine tune to provide a more gradual opening and closing.
(I would also like to add an infrared transmitter mounted to the TV sensors so that I can have them turn on/off as they open/close)
Here is an illustration of how the system currently works:

I have sourced the following items for this build:
1) 2x Arduino Uno's
2) H- Bridge motor driver https://www.amazon.com/gp/product/B01GHKO5O8/ref=oh_aui_detailpage_o06_s02?ie=UTF8&psc=1
3) Infrared Diode LED IR Emission and Receiver https://www.amazon.com/gp/product/B00EFOQEUM/ref=oh_aui_detailpage_o08_s00?ie=UTF8&psc=1
4) Limit switches at each end of the Actuators desired stroke.

Features to include:

1) Interrupt code, if the switch needs to be reversed when the actuator is in motion, there is a brief pause before heading back. (this is really bad for the actuators, but I must leave some safety option)
2) IR transmission to turn ON/OFF TVs
3) Recovery protocol if power is cut to the system
(if a fuse blows mid-path or while the TVs are open, there must be a way for the program to recover)

There challenge in #1 & #3 is that the only input is signals sent to the Arduino based on 2 positions of the switch.
I plan on using the dry contacts of the relays to send 2 signals to the Arduino:
"Open" and "Close".

Unfortunately these actuators do not include position feedback, so I will use limit switches at each end of the desired stroke to feedback to the Arduino.
I plan on using the opening of the limit switches as a signal to start the timing of my PWM function to properly time the stroke speed.
Here is the order of the Arduino program:

Open TVs

1) Relay signal "open"
2) IR signal "TV_ON"
3) Actuator Powered "Forward"
4) "full_Closed" Limit switch opens
5) PWM function
6) "full_Open" Limit reached
7) Actuator Power Stops


Close TVs

1) Relay signal "close"
2) IR signal "TV_OFF"
3) Actuator Powered "Reverse"
4) "full_Open" Limit switch opens
5) PWM function
6) "full_Closed" Limit reached
7) Actuator Power Stops

*Interrupt function = Pause before reversing circuit
*Safety recovery after power blackout

I'm used to programing on PicAxe microcontrollers.
I have ideas about how I would use the interrupts and multitasking to accomplish this type of program, on my old platform, but I'm still learning how to do this on Arduinos, so perhaps you could recommend better procedures than how I propose to accomplish these objectives.

Here is the motor controller I purchased for the job

There is no real documentation with this controller, it appears that a +5v to the "PWM" pin and a ground to the "DIR" pin will allow it to operate at full speed in a particular direction.
(The controllers are coming in the mail tonight and I will test them)

I am grateful for any insight you can offer that will point me in the right direction!
Thank you!
In advance.

 

Quick comment:

Add another switch in each direction to sense when to slow down. Then effectively ramp down with time and settle to a slow workable speed.
You know that when your at a limit you can accelerate. Usually an "S" accel/deceleration curve is used.

 

Hello again
I've decided to re-visit this project and go at it from a different angle.
I'm using an Arduino with a purchased set of motor controllers, but I will need to write the arduino code to make it work.

The problem of the abrupt start and stop of the monitors needs to be fixed.
My Arduino project will use a PWM sequence that I will fine tune to provide a more gradual opening and closing.
(I would also like to add an infrared transmitter mounted to the TV sensors so that I can have them turn on/off as they open/close)
Here is an illustration of how the system currently works:

I have sourced the following items for this build:
1) 2x Arduino Uno's
2) H- Bridge motor driver https://www.amazon.com/gp/product/B01GHKO5O8/ref=oh_aui_detailpage_o06_s02?ie=UTF8&psc=1
3) Infrared Diode LED IR Emission and Receiver https://www.amazon.com/gp/product/B00EFOQEUM/ref=oh_aui_detailpage_o08_s00?ie=UTF8&psc=1
4) Limit switches at each end of the Actuators desired stroke.

Features to include:

1) Interrupt code, if the switch needs to be reversed when the actuator is in motion, there is a brief pause before heading back. (this is really bad for the actuators, but I must leave some safety option)
2) IR transmission to turn ON/OFF TVs
3) Recovery protocol if power is cut to the system
(if a fuse blows mid-path or while the TVs are open, there must be a way for the program to recover)

There challenge in #1 & #3 is that the only input is signals sent to the Arduino based on 2 positions of the switch.
I plan on using the dry contacts of the relays to send 2 signals to the Arduino:
"Open" and "Close".

Unfortunately these actuators do not include position feedback, so I will use limit switches at each end of the desired stroke to feedback to the Arduino.
I plan on using the opening of the limit switches as a signal to start the timing of my PWM function to properly time the stroke speed.
Here is the order of the Arduino program:

Open TVs

1) Relay signal "open"
2) IR signal "TV_ON"
3) Actuator Powered "Forward"
4) "full_Closed" Limit switch opens
5) PWM function
6) "full_Open" Limit reached
7) Actuator Power Stops


Close TVs

1) Relay signal "close"
2) IR signal "TV_OFF"
3) Actuator Powered "Reverse"
4) "full_Open" Limit switch opens
5) PWM function
6) "full_Closed" Limit reached
7) Actuator Power Stops

*Interrupt function = Pause before reversing circuit
*Safety recovery after power blackout

I'm used to programing on PicAxe microcontrollers.
I have ideas about how I would use the interrupts and multitasking to accomplish this type of program, on my old platform, but I'm still learning how to do this on Arduinos, so perhaps you could recommend better procedures than how I propose to accomplish these objectives.

Here is the motor controller I purchased for the job

There is no real documentation with this controller, it appears that a +5v to the "PWM" pin and a ground to the "DIR" pin will allow it to operate at full speed in a particular direction.
(The controllers are coming in the mail tonight and I will test them)

I am grateful for any insight you can offer that will point me in the right direction!
Thank you!
In advance.

Only thing you need to do, is write some code for the arduino so that PWM is increased gradually, so as to create an acceleration curve that will eliminate the "abruptness" that you've mentioned. You also need to invert that process once a limit switch is reached.

 

Only thing you need to do, is write some code for the arduino so that PWM is increased gradually, so as to create an acceleration curve that will eliminate the "abruptness" that you've mentioned. You also need to invert that process once a limit switch is reached.

Thank you Calvin?
We are on the same thought process!
I was thinking the same thing about the PWM execution.
Some of the particular problems I'm having with the code layout is that I don't know (for example) if or how I can trigger the interrupts during the motion of the actuators OR should I include a polling function during the motion that constantly checks for this signal?
When I program in PicAxe I simply use the multitasking to poll my inputs, I'm not sure that I can do the same with the Arduino.

I'm trying to figure out how the architecture of my program will be.
The PWM part I'll have to experiment with after install, but I've pretty much got that idea set for now.

 

The PWM speeding up works when leaving a limit. It doesn't work when approaching one UNLESS you know your approaching one. Hence the extra switches.

Remember that interrupt service routines are just that. Service the interrupt as quickly as possible and get out of there. Semephores are used for interprocess type of communication.

If you can't disable interrupts when your servicing one, you at least disable them in the semaphore routine.

Inuse=0

If inuse>1 then inuse=inuse-1; No control. Exit.
if inuse=1 then inuse=inuse+1
If inuse=1 then you gain control. Exit.

So, it's like get an interrupt and disable the interrupts and set a variable and return from the interrupt. In your actuator routine, your "polling" the variable that you set in the interrupt routine.

There are some GPIO I2C chips that can cause only one interrupt when any of the ports do something.

 

Thank you K.I.S.S. sorry I missed your first post

The PWM speeding up works when leaving a limit. It doesn't work when approaching one UNLESS you know your approaching one. Hence the extra switches.

You are correct, perhaps I should have been more clear about the purpose of the limits
Since I don't have the feedback version of the actuator I intend to use the limits to tell the program when it has left one end of travel, and arrived at the other.
I could put more limits in between as you suggest, but I would like to keep the hardware as simple as possible if I can manage it.
Let me better explain what I was thinking:
My hope is that with the acceleration curve that Calvin spoke of, by the time the actuator reaches the limit, it will barely be moving at all so that it can just make the limit to end that cycle of code.
(this is a trial & error process but the positions of the limits are movable to make this work hopefully)

Remember that interrupt service routines are just that. Service the interrupt as quickly as possible and get out of there. Semephores are used for interprocess type of communication.

If you can't disable interrupts when your servicing one, you at least disable them in the semaphore routine.

Inuse=0

If inuse>1 then inuse=inuse-1; No control. Exit.
if inuse=1 then inuse=inuse+1
If inuse=1 then you gain control. Exit.

So, it's like get an interrupt and disable the interrupts and set a variable and return from the interrupt. In your actuator routine, your "polling" the variable that you set in the interrupt routine.

There are some GPIO I2C chips that can cause only one interrupt when any of the ports do something.

I think that the example you gave is the direction I should use instead of interrupts.
I'm not familiar with how Semephores work on Arduino, but I am looking into it now.

I simply need to include the 'polling" that you spoke of in the code while the PWM process is running.
Once the opposite input is seen (there are only 2 possible direct inputs from the switch) then the program routes to the opposite side (or and equivalent) after it has done a 1 second delay)

I'm going to research how to do the 'polling" code while the PWM signal is running.
I'll post the results I find along with some sample code.

I'm making progress, thanks for your help!

 

In some real, say linear stepper motor based motion control, you might have a HARD Limit A, an ORIGIN sensor, (CLOSE) and another HARD LIMIT B. So, the thing powers up and wants to find the origin, so it hit's the hard limit A and slowly steps to ORG and then resets it's counter.

Not expecting you to do that.

 

In some real, say linear stepper motor based motion control, you might have a HARD Limit A, an ORIGIN sensor, (CLOSE) and another HARD LIMIT B. So, the thing powers up and wants to find the origin, so it hit's the hard limit A and slowly steps to ORG and then resets it's counter.

Not expecting you to do that.

If I understand correctly, I will have to experiment with these values to find the timing that works.
That is exactly what I have to do anyway with the method mentioned above. And the starting point is when the motion opens the limit. I can use timing after that.

 

The PWM command in the Arduino runs in the background once you issue the command. That is you issue a command for 50% duty cycle. Then go onto something else while the Arduino continues to perform PWM at 50% duty cycle.

Hence, you can issue the PWM command and then poll your inputs.

As far as interrupts, Arduino code can only enable them on a few pins. There may not be enough for you.

 

A reminder is that some H-bridge chips may have Brake, coast, fwd and reverse as available options. Brake prevents overruns. Usually Direction and !Enable are used. !Enable is PWMed to change the speed. !Enable or NOT ENABLE is used, because TTL floats high. Therefore, you can disconnect the control and nothing moves.

The same deal occurs with processor outputs. The ports are inputs at power up, so you don't want anything to happen until the port is configured, so a ULN2003 does this.

 

Here http://www.nxp.com/documents/data_sheet/PCAL6408A.pdf is an I2C I/O expander that might help.

 

I've received my Motor Controllers and I ran into a problem.
Other buyers have reported this driver gets extremely hot.
Before I write my Arduino program, I tested the driver circuit with the included example test circuit.

When connected to "Motor2" (as per the diagram) the circuit works, however when you supply +5Votls to the "Dir2" pin Mosfet "Q1" (shown by the red arrow) gets SUPER HOT. However, when you put "DIR2" pin low the circuit works and all of the components are cool to the touch.

I tried the same circuit on "Motor1" and this time +5Volts was fine, however -5Volts on "Dir1" pin caused Mosfet "Q7" to overheat.
I've tired to limit the current to the direction pin by putting a 10K resistor in series, this makes no difference.

I've noticed that when the 12volt motor line voltage is switched "OFF" there is no overheating on the mosfets. This leads me to guess that the design of this board is causing some misoperation with the Gate and Drain of the Mosfets, and the effect is mirrored on each motor path.
Unfortunately I'm not smart enough to come up with the specific location of the fault.
This board has been sold many times and has positive feedback, so I'm not sure how others are using it without this problem . . . (could that be an hint as to a work around?)

Another thought I had was that perhaps somehow the diodes built into the limit switches of the Linear actuator could only cause the problem with these actuators and not regular motors. I don't have any other motors I could test it with, but I kind of doubt this is the problem.

You can tell by the traces how the "H" bridge is arranged, but if you wish I can also include a picture of the under side of the board.
I'm sure this would be a simple problem to solve for someone familiar with advanced "H" bridge design. Any insight would be greatly appreciated.
Is there a way I can work around this problem?
I purchased other motor drivers, but these were much more expensive and higher current rated, it's a shame that they are the ones to cause an issue.

 

I've received my Motor Controllers and I ran into a problem.
Other buyers have reported this driver gets extremely hot.
Before I write my Arduino program, I tested the driver circuit with the included example test circuit.

When connected to "Motor2" (as per the diagram) the circuit works, however when you supply +5Votls to the "Dir2" pin Mosfet "Q1" (shown by the red arrow) gets SUPER HOT. However, when you put "DIR2" pin low the circuit works and all of the components are cool to the touch.

I tried the same circuit on "Motor1" and this time +5Volts was fine, however -5Volts on "Dir1" pin caused Mosfet "Q7" to overheat.
I've tired to limit the current to the direction pin by putting a 10K resistor in series, this makes no difference.

I've noticed that when the 12volt motor line voltage is switched "OFF" there is no overheating on the mosfets. This leads me to guess that the design of this board is causing some misoperation with the Gate and Drain of the Mosfets, and the effect is mirrored on each motor path.
Unfortunately I'm not smart enough to come up with the specific location of the fault.
This board has been sold many times and has positive feedback, so I'm not sure how others are using it without this problem . . . (could that be an hint as to a work around?)

Another thought I had was that perhaps somehow the diodes built into the limit switches of the Linear actuator could only cause the problem with these actuators and not regular motors. I don't have any other motors I could test it with, but I kind of doubt this is the problem.

You can tell by the traces how the "H" bridge is arranged, but if you wish I can also include a picture of the under side of the board.
I'm sure this would be a simple problem to solve for someone familiar with advanced "H" bridge design. Any insight would be greatly appreciated.
Is there a way I can work around this problem?
I purchased other motor drivers, but these were much more expensive and higher current rated, it's a shame that they are the ones to cause an issue.

It is possible that the mosfets gates are being triggered out of sync. You should scope both gates simultaneously to find out.

 

It is possible that the mosfets gates are being triggered out of sync. You should scope both gates simultaneously to find out.

That is in interesting observation Brian.
You would think that with no PWM input that this could not be a problem though, right?
(however since it's reported that it takes a partial PWM, 252 aduino setting, perhaps this could be the issue)
Can you give me any tips on how to scope the individual mosfets inside the circuit? Do I need to solder some leads on to pull it off?

I contacted the seller this was my message:
Hello,
For your Motor controller I set up your test circuit. Other buys reported "Motor controller gets extremely hot", they are right. I found one source of the problem.
I used an Arduino for the 5Volts and a 12V supply to control a motor in a 5 Amp max Linear Actuator.
I used 3Amp fuses, so the power was never too much for the driver.
The Dir2 pin controls the direction. The circuit works in both directions with the test circuit, however, when Dir2 (or Dir1) is set "high" with 5 volts then "Q1" Mosfet gets SUPER HOT (I can smell it!)
I have tried putting a 10K resistor on the +5 volts to limit current, but the same results.
Next I tried using the "Motor 1" side.
This time when "Dir1" = LOW then Q7 Mosfet gets SUPER HOT.
Please tell me, Is there a way to correct the Motor Driver by adding components, or is there no way to fix this bad design?

His reply:
"Add a heat sink"

Lol, NO!!
I told him 4 reasons why strapping a heat sink will not make this problem go away and requested a schematic.
Here it is:

I'm not sure how useful this schematic is in troubleshooting, because this only shows 1 channel, so I'm sure a lot of other things are missing.
Also, why doesn't this say: " +36 volts" since that is what the board is advertised as?
Anyone smarter than me see any smoking guns from this though?
Or is this how the board 'should' have been designed?
Did this guy just throw me a generic diagram?

 

That is in interesting observation Brian.
You would think that with no PWM input that this could not be a problem though, right?
(however since it's reported that it takes a partial PWM, 252 aduino setting, perhaps this could be the issue)
Can you give me any tips on how to scope the individual mosfets inside the circuit? Do I need to solder some leads on to pull it off?

I contacted the seller this was my message:
Hello,
For your Motor controller I set up your test circuit. Other buys reported "Motor controller gets extremely hot", they are right. I found one source of the problem.
I used an Arduino for the 5Volts and a 12V supply to control a motor in a 5 Amp max Linear Actuator.
I used 3Amp fuses, so the power was never too much for the driver.
The Dir2 pin controls the direction. The circuit works in both directions with the test circuit, however, when Dir2 (or Dir1) is set "high" with 5 volts then "Q1" Mosfet gets SUPER HOT (I can smell it!)
I have tried putting a 10K resistor on the +5 volts to limit current, but the same results.
Next I tried using the "Motor 1" side.
This time when "Dir1" = LOW then Q7 Mosfet gets SUPER HOT.
Please tell me, Is there a way to correct the Motor Driver by adding components, or is there no way to fix this bad design?

His reply:
"Add a heat sink"

Lol, NO!!
I told him 4 reasons why strapping a heat sink will not make this problem go away and requested a schematic.
Here it is:

I'm not sure how useful this schematic is in troubleshooting, because this only shows 1 channel, so I'm sure a lot of other things are missing.
Also, why doesn't this say: " +36 volts" since that is what the board is advertised as?
Anyone smarter than me see any smoking guns from this though?
Or is this how the board 'should' have been designed?
Did this guy just throw me a generic diagram?

Question, do you own, or have access to, an oscilloscope?