I'm not completely satisfied with the values of tune msec. 35 or even 37. from time to time the servo mainly the CP one, and the tilt one as well, have surprising moves,even when the camera want to take a picture!! all this without any change in the script running, or in the placement of the transistor and so on...
so I wanted to redo the test S0 calibrate. I shorted again white and black, with a system already used, a sharp splinter forceps (on the 2 external metal pins of the connector), and a rubber band to hold it in place. it worked fine until now. the clip was probably moved a little and I was alerted by the smell of burnt plastic. I think I made a short circuit between the + and -, and metal parts of the battery holder were heated and made a hole in the plastic sheet on the table .... just in front of me, in a few seconds. a little more and I needed the help of the firefighters. ouch!
Well, I'll start this more correctly. any advice for a convenient and clever short on these tiny m
not sure, but I think, I win a new CP-SDM in the same time!!! I'll check a bit further but with a new battery set (holder and battery) no response from the servo. I ran again the check-list, but little hope. to be continued
edited: still working, quite strong this little thing.
Fried components is the sort of thing I feared when contemplating the calibration procedure. Not to mention the fact that I didn't want to unwrap the protective tape surrounding the one decent soldering job I've ever done.
On CAMremote, Linnar provided 2 pins which, when fitted with a jumper, put the device into a different mode. This seems much more foolproof. Maybe an additional connector can be provided with clickPAN-SDM which will already have the white and black wires shorted, to be used only during calibration?
unit pulse width 12 stops the jerking movement of my tilt servo, during my 360pt script test.
PS: during s0 calibrate, with tms 35, I didn't manage to get the standard (tilt) servo back to the exact initial position (s1). tms35 upw10 allows to get back as close as possible. tms35 upw12 seems to get it back home almost perfectly
360m servo + turn script + tps35 upw12 with tps35 upw12, when I run the turn script (tps command line off) with the 360servo, the servo moves twice for each value from 1 to 10. the rotation is increasing linearly but with 2 equal rotation unit moves for each value. I don't know why. in the script there is only one send data.. so? (and in the 360PT script 1.83 A570, same 360 servo, only one rotation at a time).
one possible reason for the double move of the pan servo is that in your script the 'n' parameter has been set to 2 not 1. I put in the ability to do multiple moves because a highly geared pan servo might not move enough on a single pulse, no matter how strong.
rem simple pan 360servo tester script for clickPAN-SDM - Dave Mitchell TURN @param p pan servo (1 or 2) @default p 1 @param d direction (1=CW, -1=CCW) @default d 1 @param s pulse strength (1-10) @default s 5
print "up/down to +/- pulse" print "left/right to set direction" rem ensure SDM is set up properly
use_af_led tune_unit_pulse 35
if d < 1 then d = -1 if d > 1 then d = 1
while 1 if s < 1 then s = 1 d = 0-d endif if s > 10 then s = 10 if d = 1 then print "Clockwise=", s if d = -1 then print "Anticlockwise=",s S = (s + 100) * d if p = 1 then send_data S, -128, 0 if p = 2 then send_data -128, S, 0 wait_click if is_key "up" then s = s + 1 if is_key "down" then s = s - 1 if is_key "left" then d = -1 if is_key "right" then d = 1 wend end
and I don't know where would be a command for 2 unit moves but I am an "newcomer" there too.
David said: does a tune_unit_pulse = 42 and a unit pulse width of 10 also work ?
I tried once and my 360servo had funny response to the different values, turning or rotating at diffrent speed and direction of rotation. The camera battery is getting low and I didn't want to add a new variable in this. so I will have a break for a few hours. to be continued.
Sorry Philippe. The turn, tilt and rotate scripts have a third parameter on the send_data. If you remove that (ie change "send_data S, -128, 0" to "send_data S, -128" I think the double move will disappear. I've removed the extra parameter from the versions on my website.
Finally, I think I found something (This has already been reported, somewhere)
It is a matter of time ... as usual!
After the rotation command, I added time to allow the servo to move before the order is crushed by the next one (if this makes sense).
rem and pan a bit tested OK print "Pan ", n, " pulses of ", s for i = 1 to n if p = 1 then send_data S, -128 sleep 1000 else send_data -128, S sleep 1000 endif
or may be like this not tested, might be OK rem and pan a bit print "Pan ", n, " pulses of ", s for i = 1 to n if p = 1 then send_data S, -128 else send_data -128, S endif sleep 1000
I've updated the script zip here and made changes to the scripting document too - adding provisional notes about tuning the G11 and S90 and information about the "oscillating pan" script I wrote for Michael Layefsky.
Unfortunately I can't attend KAPiNED, but Michael and James will be there and I hope that together they can sort out some of the remaining issues. And if others bring SDM-capable Canon cameras along James can verify the clickPan-SDM settings for more models.
Are you interested to add CHDK-PTP support to your SDM builds? Then you don't need to use extra external light sensor to send data out from camera but you can use USB port for bidirectional communication.
Comments
It is better if tune_unit_pulse is not used and the correct default value is automatically set for each camera in the code.
You made a HUGE job, definitly.
in fact, I have a lot to learn... and first I'll join the RTFM group as an active member.
Philippe
Go through the scripts and change the tune_unit_pulse values
or
remove the tune_unit_pulse.
The 35 value in Serial Comms menu should be retained after power-off.
Do all the scripts work ?
David
Need more time to be able to answer this question.
Will try step by step and tell what I found.
Have to go back to work, first. :(
Philippe
so I wanted to redo the test S0 calibrate.
I shorted again white and black, with a system already used, a sharp splinter forceps (on the 2 external metal pins of the connector), and a rubber band to hold it in place.
it worked fine until now.
the clip was probably moved a little and I was alerted by the smell of burnt plastic. I think I made a short circuit between the + and -, and metal parts of the battery holder were heated and made a hole in the plastic sheet on the table .... just in front of me, in a few seconds.
a little more and I needed the help of the firefighters. ouch!
Well, I'll start this more correctly.
any advice for a convenient and clever short on these tiny m
I'll check a bit further but with a new battery set (holder and battery) no response from the servo.
I ran again the check-list, but little hope.
to be continued
edited: still working, quite strong this little thing.
Phil78 alias CP-SDMinator
I have to say, this is not a very satisfactory procedure, better provision needs to be made for it on the connectors.
Most users will not need to do this test, but some will.
It would be a little unfair if that resulted in destroying the CP.
David
On CAMremote, Linnar provided 2 pins which, when fitted with a jumper, put the device into a different mode. This seems much more foolproof. Maybe an additional connector can be provided with clickPAN-SDM which will already have the white and black wires shorted, to be used only during calibration?
Unit Pulse Width: 35
Tune msec value: 12
I'm still working on getting the PAN servo to work properly, and will post my results if I get it to work.
In fact, I think (hope) you find these results
Unit Pulse Width :12
Tune msec value : 35
unit pulse width 12 stops the jerking movement of my tilt servo, during my 360pt script test.
PS: during s0 calibrate, with tms 35, I didn't manage to get the standard (tilt) servo back to the exact initial position (s1). tms35 upw10 allows to get back as close as possible. tms35 upw12 seems to get it back home almost perfectly
360m servo + turn script + tps35 upw12
with tps35 upw12, when I run the turn script (tps command line off) with the 360servo, the servo moves twice for each value from 1 to 10. the rotation is increasing linearly but with 2 equal rotation unit moves for each value. I don't know why. in the script there is only one send data.. so? (and in the 360PT script 1.83 A570, same 360 servo, only one rotation at a time).
one possible reason for the double move of the pan servo is that in your script the 'n' parameter has been set to 2 not 1. I put in the ability to do multiple moves because a highly geared pan servo might not move enough on a single pulse, no matter how strong.
here the script I use
I think I change only 1 line
rem simple pan 360servo tester script for clickPAN-SDM - Dave Mitchell TURN
@param p pan servo (1 or 2)
@default p 1
@param d direction (1=CW, -1=CCW)
@default d 1
@param s pulse strength (1-10)
@default s 5
print "up/down to +/- pulse"
print "left/right to set direction"
rem ensure SDM is set up properly
use_af_led
tune_unit_pulse 35
if d < 1 then d = -1
if d > 1 then d = 1
while 1
if s < 1 then
s = 1
d = 0-d
endif
if s > 10 then s = 10
if d = 1 then print "Clockwise=", s
if d = -1 then print "Anticlockwise=",s
S = (s + 100) * d
if p = 1 then send_data S, -128, 0
if p = 2 then send_data -128, S, 0
wait_click
if is_key "up" then s = s + 1
if is_key "down" then s = s - 1
if is_key "left" then d = -1
if is_key "right" then d = 1
wend
end
and I don't know where would be a command for 2 unit moves but I am an "newcomer" there too.
Philippe
does a tune_unit_pulse = 42 and a unit pulse width of 10 also work ?
with tms35 upw12
I made a lillte change in the turn script (see previous post)
original 2 rotation moves
if p = 1 then send_data S, -128, 0
if p = 2 then send_data -128, S, 0
new one 1 rotation at a time
f p = 1 then send_data S, -128
if p = 2 then send_data -128, S
perhaps a path to follow
Philippe
does a tune_unit_pulse = 42 and a unit pulse width of 10 also work ?
I tried once and my 360servo had funny response to the different values, turning or rotating at diffrent speed and direction of rotation.
The camera battery is getting low and I didn't want to add a new variable in this.
so I will have a break for a few hours.
to be continued.
NO problem !!
Dave, David, James,
does a tune_unit_pulse = 42 and a unit pulse width of 10 also work ?
tilt OK
pan still having trouble.
so far tms35 upw12 seems better for me.
Finally, I think I found something (This has already been reported, somewhere)
It is a matter of time ... as usual!
After the rotation command, I added time to allow the servo to move before the order is crushed by the next one (if this makes sense).
rem and pan a bit tested OK
print "Pan ", n, " pulses of ", s
for i = 1 to n
if p = 1 then
send_data S, -128
sleep 1000
else
send_data -128, S
sleep 1000
endif
or may be like this not tested, might be OK
rem and pan a bit
print "Pan ", n, " pulses of ", s
for i = 1 to n
if p = 1 then
send_data S, -128
else
send_data -128, S
endif
sleep 1000
In any case, it works. GREAT!!
slow servo = lent servo = servo lent = cerf-volant = kite
Dave
PS good pun (calembour?) too
Philippe
I just want to know, can we say that the clickPAN-SDM works on the G11, it is just that the scripts need 'tweaking' ?
David
I would say that.
I tried another script 360P without any problem
I found the "time solution" when I looked pr
Unfortunately I can't attend KAPiNED, but Michael and James will be there and I hope that together they can sort out some of the remaining issues. And if others bring SDM-capable Canon cameras along James can verify the clickPan-SDM settings for more models.
Told you so :)
Dave
All ready done. You are amazing!!
PS Unfortunately, I could not attend, me neither.
Are you interested to add CHDK-PTP support to your SDM builds? Then you don't need to use extra external light sensor to send data out from camera but you can use USB port for bidirectional communication.
http://chdk.setepontos.com/index.php/topic,4338.0.html
I have not pursued this further at present.
There is no way the inexpensive PIC chips that James uses could do the PTP communication.
Nevertheless, PTP is something I am keeping an eye on .. it is still highly experimental and not all cameras are supported.