Help Please: PICAXE and Robot Boat

Robin Lovelock

Senior Member
Hi Folks. I'm new to the PICAXE stuff, and hope
that someone can save me some time on getting
RS232 input to work on a AXE024 servo controller.

Many Thanks in advance for any help and advice.
Thanks also to my friend Roy who recently
introduced me to PICAXE and got me started.

I'm hoping to make an RS232 servo controller,
to replace a Pololu SCCII, based on the AXE024.
This is part of a robot boat project described on
www.gpss.co.uk/autop.htm
You may enjoy the "Snoopy Sails!" video :)

The robot boat is navigated by an iPAQ Pocket PC
with RS232 for GPS input and output to the servo controller.
For the past year we've used a standard Pololu SSCII
servo controller, plus a small card from friend Klaus
in Germany, because of the simple protocol we use on RS232.
We wish to do everything on one PICAXE card,
even if this restricts the number of servos to 2 or 3.

Please remember that I'm a newbie to PICAXE stuff,
and cannot afford to spend a lot of time on this
particular part of what is for me a hobby project.
I'm an old man of 62 who cut his teeth on computers
in the 1960s: details on www.gpss.co.uk/history.htm
So please be gentle with me :)

I'm having problems with RS232 input: details below.

Can the AXE024 handle RS232 input AND control three servos ?

The RS232 input is a very simple protocol:
a three byte servo command: 127=sync, 0,1 or 2 for servo number,
0 to 126 servo position (translated by my SC1 program on the AXE024).

I've tried quite a few other things already,
including putting the RS232 input onto a servo pin,
but what I have is now is using 08M pin 4 (signal 3).

My PC COM1 port has a test program, AUTOP,
already proven for testing the Pololu Servo Controller.
Clicking on a button sends the three required bytes out
via RS232 into the PICAXE AXE024 servo controller with 08M.

The RS232 is wired into pin 4 (signal 3) on the AXE024
(have tried with and without 10k pullup resistor)
and three servos are plugged in to the servo positions.

My SC1.BAS (code below) application runs OK, using SERVO to
do the correct test pattern of wagging all three servos twice,
before waiting on a byte from serial input with
SERIN 3,N4800_8,b1

It does as it should, waiting, until I send the 3 bytes from PC.
It SHOULD waggle just one servo and then wait.
There is a twitch on one servo, and then the program restarts.
Presumably due to an error condition.
Same symptoms both with and without the 10k pull up resistor.

I thought the error condition might be due to the next two bytes
coming in before the SERIN were issed, but this latest version of
SC1 program just does the SERINs. i.e. not waiting on sync byte.
No delays yet added between the three bytes from the AUTOP on PC.

Extra notes: wires from 9 way D on PC COM1: pin 5 = 0V, pin 3 signal.
Not using SERVOPOS due to unreliabity. Can return to this later.
But SERVO seems to work reliably enough while I work on this RS232 input.
Document for AXE024 servo controller: http://www.rev-ed.co.uk/docs/axe024.pdf
Document for programming: http://www.rev-ed.co.uk/docs/picaxe_manual2.pdf

Robin
www.gpss.co.uk/autop.htm


'SC1.BAS servo controller for robot boat
'input is RS232 group of 3 bytes:
'127=sync, 0,1 or 2=servo number, 0 to 126 servo position

verytop:
b5=100 'limits of servo travel
b6=191 '100 to 191 gives 360 degrees

'first a simple test pattern
'wag servos 1,2,4, twice.
SERVO 1,b5 'initiate 3 servos
SERVO 2,b5
SERVO 4,b5
PAUSE 3000 'pause 3 secs
for b7=1 to 2
SERVO 1, b6 'drive servo 1
PAUSE 1000 'pause 1 secs
SERVO 2, b6 'drive servo 2
PAUSE 1000 'pause 1 secs
SERVO 4, b6 'drive servo 4
PAUSE 1000 'pause 3 secs
SERVO 1, b5 'all back
SERVO 2, b5
SERVO 4, b5
PAUSE 3000 'pause 3 secs
next b7

'then wait for bytes on serial port to control servos
sync: SERIN 3,N4800_8,b1 'read byte from RS232 input on 3
'IF b1<>127 then goto sync 'wait for the sync byte of 127

SERIN 3, N4800_8,b2 'read servo number 0 to 2.
SERIN 3, N4800_8,b3 'read servo position 0 to 126

'this for test only - wag just servo 1
SERVO 1,b6 'drive servo to upper limit
PAUSE 3000 'pause 3 secs
SERVO 1,b5 'drive servo to lower limit
PAUSE 3000 'pause 3 secs
SERVO 1,b6 'drive servo to position based on 3rd byte
PAUSE 3000 'pause 3 secs
GOTO sync

'(logic here will be different if and when RS232 is working)
 

hippy

Technical Support
Staff member
Welcome to the PICAXE forum.

The AXE024 is an 08M board with connectors for three servos with Leg 4 ( Input Pin 3, not used ). You can connect serial input to leg 4 - use a 22K in series and a diode pull-up between Leg 4 ( cathode, pointy-end ) and +V ( anode ). Use SERIN to read the incoming serial.

However ... the 08M will stop controlling servos while waiting for SERIN so you need to use a protocol which allows it to work. Prefixing messages with a pulse ( send $00 ) allows Pin 3 to be monitored by polling and jumping to a routine which will read the subsequent serial data. Other similar schemes using interrupts can be used.
 
Last edited:

hippy

Technical Support
Staff member
Code:
#Picaxe 08M
Do
  If pin3 = 1 Then
    Serin 3, N2400, ( $0A ), b1, b2, b4
    Servo 1, b1
    Servo 2, b2
    Servo 4, b4
  End If
Loop
You'd send a packet of $00 $FF $0A $aa $bb $cc

Code:
#Picaxe 08M
Do
  If pin3 = 1 Then
    Serin 3, N2400, ( $0A ), b0, b1
    Select Case b0
      Case 1 : Servo 1, b1
      case 2 : Servo 2, b1
      case 3 : Servo 4, b1
    End Select
  End If
Loop
You'd send a packet of $00 $FF $0A $0n $ss ( n=1,2,3 )
 
Last edited:

Robin Lovelock

Senior Member
Many Thanks for such a quick reply Hippy.

So I guess the answer to my question:
"Can the AXE024 handle RS232 input AND control three servos ?"
is Yes ? Is this based on others using the AXE024 ?

First I had better make sure I've made the required hardware changes.
You say "leg 3". Is that the same pin as I describe in my first posting ?
I think that was hardware pin 4 (signal 3 for SERIN).

Is what you describe anywhere in the PDF documentation ?
I thought I had followed this correctly, with a pull down 10k resistor
between the pin and oV. You describe something very different
with a diode and resistor. I don't want to blow anything up :)

Robin
www.gpss.co.uk/autop.htm
 

hippy

Technical Support
Staff member
So I guess the answer to my question:
"Can the AXE024 handle RS232 input AND control three servos ?"
is Yes ? Is this based on others using the AXE024 ?
The answer is, "yes". Based on others using serial to control servos though I do not know if any have used AXE024 with serial. There is a lot of discussion on servo control which will be found via the forum's Search.

You say "leg 3". Is that the same pin as I describe in my first posting ? I think that was hardware pin 4 (signal 3 for SERIN).
That was my mistake/typo; Leg 4 is Input Pin 3 ( I'll correct my original post ). We have a de-facto standard to use "Leg" to describe the physical pins of the chip and "Pin" to describe the signals used by the software to avoid confusion.

Is what you describe anywhere in the PDF documentation ?
I thought I had followed this correctly, with a pull down 10k resistor
between the pin and oV. You describe something very different
with a diode and resistor. I don't want to blow anything up :)
Serial interfacing is described in PICAXE Manual 3 - Electrical Interfacing.

The 22K is used to limit the current for a +/-12V RS232 signal. That may be / need to be reduced / removed depending on what your serial voltage levels are. The 10K pull-down is placed at the end of the 22K furthest from the PICAXE but isn't a necessity if the system is permanently connected to the serial data line. It does no harm to add it even if that is the case. The diode is a necessity for the 08M if serial voltages are above +V voltage for the PICAXE.
 
Last edited:

hippy

Technical Support
Staff member
Very interesting site.

they will need to wire the output of the computer's RS232 serial port to an SSCII servo controller, via a protocol convertor such as that seen here from Klaus. This is a "hardware workaround" to the Microsoft OS not allowing more than 7 data bits to be sent to the SSCII
If using a PICAXE you should be able to do away with the Klaus converter and have the PICAXE handling the iPAQ protocol directly. You can also have more than three servos if you need them, either using multiple AXE024 or building your own PCB/vero-board and using a larger PICAXE.
 

Robin Lovelock

Senior Member
Many Thanks again Hippy.
I'm making some progress - thanks to you :)

Adding a 22k resistor in series with the serial
signal from my PC COM1 port was important.
Now I do not get a program restart due to
what I guess was an error condition caused
by the PC RS232 levels being higher than the 5v supply.

So now my test program could wait on the sync
byte, still using SERIN. Then use the SERVO command.
Now, clicking on my PC test program,
to cause the 3 bytes to be sent out,
correctly causes just the one servo to twitch
- but not move to the required position.

So now I'm thinking your words about SERIN
stopping SERVO to work means I should use
your solution such as
If pin3 = 1 Then
Serin 3, N2400, ( $0A ), b1
etc

However, I need to use N4800 because
the PC (or rather the iPAQ on my robot boat)
will be reading GPS data that must be at 4800.

So I thought I could just try
Serin 3, N4800, ( $0A ), b1

- but this was quickly rejected by the program editor software.

I looked at Manual3 on interfacing,
and followed your suggestion on your 22k resistor in series.
I removed the 10k resistor.
I saw no mention of a diode in the manual,
so have not added one.
It looks as if this 22k has solved the hardware problem.

From your earlier posting it seems you do not know
of anyone using the AXE024 with servos AND serial input.
This is obviously the neat solution - if it works. I got a couple
of AXE024 in addition to several AXE021 experimental boards
which were my original choice.
Then I saw the AXE024 and it includes that
neat set of servo pins - avoiding extra work :)

Any suggestions on what I might try next ?
Seems as if we might be close.
Just need to work around SERIN mucking up SERVO.

Robin
www.gpss.co.uk/autop.htm
 

hippy

Technical Support
Staff member
The diode on Leg 4 / Pin 3 of the PICAXE-08M is essential when serial is over +V. That's actually described in PICAXE Manual 2 under the SERIN command.

You can use N4800_8 to get 4800 baud but also have to add "SETFREQ M8" at the start of your program. That will likely mess up servo operation as the servo timing loop halves.

The PICAXE SERIN has to match whatever protocol you are feeding into it while for the Pin 3 polling to work you need the protocol to provide for that. Alternatively you can use another PICAXE to do the conversion from iPAQ to the AXE024, or use a different PICAXE member to handle the serial and drive the servos.

There are two approaches to take with what you currently have; make the iPAQ work with the PICAXE or make the PICAXE work with the iPAQ, and in this case the specific AXE024. Both have their constraints within which you have to work with. Getting the iPAQ to send what the PICAXE would like ( using 2400 baud, slight change to what is sent ) would seem the easiest approach though I don't know the iPAQ capabilities. Once you have that setup working you can then move on

The ideal start would be to write a test program for the iPAQ ( or the PC AUTOP program ) to send out serial data, the PICAXE to read that and report to the PC what it is receiving, then the protocol and serial can be tweaked for reliable operation if needs be, then servos added.
 
Last edited:

Robin Lovelock

Senior Member
Thanks yet again Hippy. Now I think the picaxe restrictions and
"undocumented features" are being brought to the surface :)

This is why your feedback on this Forum is so valuable.
It looks as if the AXE024 servo controller may not be
suitable for this job. It may not have been used in
this RS232-controlled servo control with success.

But with your help I am happy to see if we can program around it.

Thanks the info on adding the diode: this is now added.
I can see that it was mentioned in the documentation text.

First the spec: it is to receive the 3 bytes at 4800 baud.
I'd rather not start changing the iPAQ system to program
around limitations of the PICAXE.

I can confirm that use of SETFREQ M8 in order
to try and get SERIN to work, does in fact screw up SERVO.

I've tried quite a few variations on your code, but with no good result.
e.g. SERIN, N4800_8, (127), b2, b3
- thought this might look for the sync byte of 127 followed by two bytes.

Some of the symptoms I'm getting make me think that there could
be other restrictions in the picaxe system - such as missing bytes
that appear too quickly. AUTOP on the PC sends out the 3 bytes
withoiut delays between them - limited only by the 4800 baud.
Of course, there are usually big delays of several seconds between
each 3 byte group that represents a particular servo command.

I greatly appreciate your quick responses and knowledge
of what the picaxe systems may and may not be capable of doing.

Robin
www.gpss.co.uk/autop.htm


>>>>>>>>>>


The diode on Leg 4 / Pin 3 of the PICAXE-08M is essential when serial is over +V. That's actually described in PICAXE Manual 2 under the SERIN command.

You can use N4800_8 to get 4800 baud but also have to add "SETFREQ M8" at the start of your program. That will likely mess up servo operation as the servo timing loop halves.

The PICAXE SERIN has to match whatever protocol you are feeding into it while for the Pin 3 polling to work you need the protocol to provide for that. Alternatively you can use another PICAXE to do the conversion from iPAQ to the AXE024, or use a different PICAXE member to handle the serial and drive the servos.

There are two approaches to take with what you currently have; make the iPAQ work with the PICAXE or make the PICAXE work with the iPAQ, and in this case the specific AXE024. Both have their constraints within which you have to work with. Getting the iPAQ to send what the PICAXE would like ( using 2400 baud, slight change to what is sent ) would seem the easiest approach though I don't know the iPAQ capabilities. Once you have that setup working you can then move on

The ideal start would be to write a test program for the iPAQ ( or the PC AUTOP program ) to send out serial data, the PICAXE to read that and report to the PC what it is receiving, then the protocol and serial can be tweaked for reliable operation if needs be, then servos added.
 

hippy

Technical Support
Staff member
If we're working with the protocol the iPAQ / AUTOP puts out, that's "127 nn ss" and the PICAXE should catch them at 4800 baud, if it can determine there's a data transmission occuring when it polls Pin 3. I'd have thought there's a good chance it would poll something high, then wait and read the next data. You may lose some data but it should work.

You can try the following to see if anything is getting received by the PICAXE ...

Code:
#Picaxe 08M
#Terminal 9600
SetFreq M8
Do
  If pin3 = 1 Then
    SerTxd( "pin3=1", CR, LF )  
  End If 
Loop
Then try ...

Code:
#Picaxe 08M
#Terminal 9600
SetFreq M8
Do
  If pin3 = 1 Then
    SerIn 3, N4800_8, (127), b0, b1
    SerTxd( "b0=", #b0, " b1=", #b1, CR, LF )  
  End If 
Loop
 

Robin Lovelock

Senior Member
Many Thanks again Hippy.
This example is very useful
- enables me to see how to output using the terminal for a trace.

To answer your questions:
the first block of code results in scrolling opf "pin3=1"
So it looks as if pin3 is always 1
This is without my entering any data.

The second example does nothing
- but maybe that to be expected,
since it's looking for the 127 and I need to
leave the cable plugged into my PC COM1
- so can't use AUTOP to output the 127, etc

BUT, I changed the line to
SerIn 3, N4800_8, ("A"), b0, b1
So I thought I might usethe terminal that appears
to enter the characters, starting with A.
I used the area at the bottom, tapping afterwards on the button.
But nothing happens, even if I just type lots of AAAAA

Maybe I should have added some H's
as in AAAAAAHHHHH !
:)

I can see I need that USB version of the cable.
Then I could use terminal AND my COM1 tests.

Many Thanks again
Robin
www.gpss.co.uk/autop.htm


>>>>>>>>>
If we're working with the protocol the iPAQ / AUTOP puts out, that's "127 nn ss" and the PICAXE should catch them at 4800 baud, if it can determine there's a data transmission occuring when it polls Pin 3. I'd have thought there's a good chance it would poll something high, then wait and read the next data. You may lose some data but it should work.

You can try the following to see if anything is getting received by the PICAXE ...

Code:
#Picaxe 08M
#Terminal 9600
SetFreq M8
Do
  If pin3 = 1 Then
    SerTxd( "pin3=1", CR, LF )  
  End If 
Loop
Then try ...

Code:
#Picaxe 08M
#Terminal 9600
SetFreq M8
Do
  If pin3 = 1 Then
    SerIn 3, N4800_8, (127), b0, b1
    SerTxd( "b0=", #b0, " b1=", #b1, CR, LF )  
  End If 
Loop
 

hippy

Technical Support
Staff member
Pin3 is likely to always read as 1 when not connected to anything. A 10K pull down on the 22K furthest away from the PICAXE should fix that, or leave it permanently connected to the serial.

If you're controlling this by hand through a terminal emulator, try this ...

Code:
#Picaxe 08M
#Terminal 9600
Do
  Serin 3, N4800_8, b0
  SerTxd( b0 )
Loop
That should echo back everything you type to the PICAXE back to the Programming Editor terminal.
 

Robin Lovelock

Senior Member
Thanks Hippy. It has occured to me that there might be
a work-around to the restrictions, if we can switch between
SetFreq M8 and SetFreq M4 while the program is running.

i.e. SetFreq M8 before use of SERIN to read the
3 bytes at 4800, including waiting for the sync.

Then SetFreq M4 (perhaps after a short PAUSE)
before use of SERVO to move the servo.
No harm in a PAUSE 3000 to give time for
the servo to travel to it's new position.

Then back to the earlier sync: code and SetFreq M8.

Might this work ?
Is it possible that SetFreq controls the Pin1 signal
used for download and not the Pin3 I'm using ?
If so, maybe I should switch to using Pin 1 ?

Could you remind me of the code ?
Sorry to appear so dumb.
Maybe I'll have a clearer head in the morning :)

Robin
www.gpss.co.uk/autop.htm



If we're working with the protocol the iPAQ / AUTOP puts out, that's "127 nn ss" and the PICAXE should catch them at 4800 baud, if it can determine there's a data transmission occuring when it polls Pin 3. I'd have thought there's a good chance it would poll something high, then wait and read the next data. You may lose some data but it should work.

You can try the following to see if anything is getting received by the PICAXE ...

Code:
#Picaxe 08M
#Terminal 9600
SetFreq M8
Do
  If pin3 = 1 Then
    SerTxd( "pin3=1", CR, LF )  
  End If 
Loop
Then try ...

Code:
#Picaxe 08M
#Terminal 9600
SetFreq M8
Do
  If pin3 = 1 Then
    SerIn 3, N4800_8, (127), b0, b1
    SerTxd( "b0=", #b0, " b1=", #b1, CR, LF )  
  End If 
Loop
 

BeanieBots

Moderator
If you intend to use m8, you MUST dissable the servo just before hand or will go berserk.
Another option might be to stick with m8 and use pulsout instead of servo.
You would need to generate your own 20mS frame rate but the 20mS is not critical and can be doen within the software loop using pauses.
It should be possible to keep the correct frame rate even when doing the serial part by making appropriate compensations.
 

Robin Lovelock

Senior Member
Good Tuesday Morning Beanibot and Hippy.

Many Thanks Beanibot: how might I "disable the servos" ?

My latest test program follows, to investigate effect
of switching with SETFREQ. When it switches to 8MHz
and waits for 15 seconds, at least one servo creeps.
I get same symptoms using SERVOPOS or just SERVO.

I would obviously like them to remain where they were
while handling the serial input. If I could "disable" the
servo control process, maybe the servos would remain
where they were. They are highly geared, so I am not
too concerned with mechanical forces moving them.

You and Hippy may want to read this in conjunction
with my last posting yesterday.

Robin
0850 Tues 4 Aug 09 in UK

verytop:
b5=100 'limits of servo travel
b6=191 '100 to 191 gives 360 degrees

SETFREQ M4 'standard 4MHz

'first a simple test pattern
'wag servos 1,2,4, once.
SERVO 1,b5 'initiate 3 servos
SERVO 2,b5
SERVO 4,b5
PAUSE 3000 'pause 3 secs

SERVOPOS 1, b6 'drive servo 1
PAUSE 1000 'pause 1 secs
SERVOPOS 2, b6 'drive servo 2
PAUSE 1000 'pause 1 secs
SERVOPOS 4, b6 'drive servo 4
PAUSE 1000 'pause 3 secs
SERVOPOS 1, b5 'all back
SERVOPOS 2, b5
SERVOPOS 4, b5
PAUSE 3000 'pause 3 secs

SETFREQ M8 '8Mz for SERIN spoils SERVO

for b1=1 to 15 '15 sec delay
PAUSE 2000
next b1
goto verytop

If you intend to use m8, you MUST dissable the servo just before hand or will go berserk.
Another option might be to stick with m8 and use pulsout instead of servo.
You would need to generate your own 20mS frame rate but the 20mS is not critical and can be doen within the software loop using pauses.
It should be possible to keep the correct frame rate even when doing the serial part by making appropriate compensations.
 

hippy

Technical Support
Staff member
Is it possible that SetFreq controls the Pin1 signal
used for download and not the Pin3 I'm using ?
If so, maybe I should switch to using Pin 1 ?
SETFREQ will affect everything. Leg 4 / Pin 3 is ideal for use in this configuration, and particularly for the AXE024; it's an otherwise unused input, available for use on the AXE024, allows Pin 0 to be kept for diagnostic reporting and debugging (SERTXD) and Pins 1, 2 and 4 to be used as servo control.

I would stick with using Pin 3 as there's nothing to be gained from moving to another pin.

You're right, changing to 8MHz for serial then dropping back to 4MHz for the servo control loop should work. The first thing though is to get serial comms working reliably; see the code in post #12. So the process is -

1) Get comms working at 8MHz from a terminal emulator
2) Get comms from AUTOP working at 8MHz
3) Get comms from AUTOP working in a 4MHz loop 8MHz for serial
4) Get comms from iPAQ working at 8MHz
5) Get comms from iPAQ working in a 4MHz loop 8MHz for serial
6) Add actual servo control

Taking it a step at a time will make it easier and quicker to see what does work and does not work and will hopefully show where the AUTOP/iPAQ code may need to change to make the protocol work with the AXE024 / PICAXE.
 

BeanieBots

Moderator
As hippy states, one thing at a time. Get the comms working first.

IMHO, pulsout will possibly be the best solution if you require 8Mhz for the comms. How that's implemented will depend on the details of the comms solution so that needs to come first.

Simply using a 'low pin' command will dissable the servo.
Issue a new 'servo' command to get it going again.
 

Robin Lovelock

Senior Member
Thanks Hippy (and Beaniebots now). I think our typing this morning's posting overlapped :)

Yes, that sounds good, and a logical test sequence.

But first I need to confirm that it is possible to disable the servos
while the program spends most of it's time waiting on the sereial input.
If the "servos going crazy" cannot be solved, that lengthy test
progression of serial comms would be wasted effort.

If neither of you know how the servos can easily be
disabled, then I would consider trying Beanibots idea
of useing pulse - but one step at a time.

Thanks again.
Robin 0915 Tues.
www.gpss.co.uk/autop.htm


SETFREQ will affect everything. Leg 4 / Pin 3 is ideal for use in this configuration, and particularly for the AXE024; it's an otherwise unused input, available for use on the AXE024, allows Pin 0 to be kept for diagnostic reporting and debugging (SERTXD) and Pins 1, 2 and 4 to be used as servo control.

I would stick with using Pin 3 as there's nothing to be gained from moving to another pin.

You're right, changing to 8MHz for serial then dropping back to 4MHz for the servo control loop should work. The first thing though is to get serial comms working reliably; see the code in post #12. So the process is -

1) Get comms working at 8MHz from a terminal emulator
2) Get comms from AUTOP working at 8MHz
3) Get comms from AUTOP working in a 4MHz loop 8MHz for serial
4) Get comms from iPAQ working at 8MHz
5) Get comms from iPAQ working in a 4MHz loop 8MHz for serial
6) Add actual servo control

Taking it a step at a time will make it easier and quicker to see what does work and does not work and will hopefully show where the AUTOP/iPAQ code may need to change to make the protocol work with the AXE024 / PICAXE.
 

Robin Lovelock

Senior Member
Apologies Beanibots - I should have read your posting that came in as I typed this earlier one.

What pin numbers should I use to disable the three servos ?
pin 3 is obviously reserved for the serial input.

Robin
0924


Thanks Hippy (and Beaniebots now). I think our typing this morning's posting overlapped :)

Yes, that sounds good, and a logical test sequence.

But first I need to confirm that it is possible to disable the servos
while the program spends most of it's time waiting on the sereial input.
If the "servos going crazy" cannot be solved, that lengthy test
progression of serial comms would be wasted effort.

If neither of you know how the servos can easily be
disabled, then I would consider trying Beanibots idea
of useing pulse - but one step at a time.

Thanks again.
Robin 0915 Tues.
www.gpss.co.uk/autop.htm
 

BeanieBots

Moderator
Use the same pin assignments as your servos!

servo 1,150 'will keep a servo on pin 1 at neutral position.
low 1 'will dissable it. (it goes limp)
'go do your comms here.
servo 1,150 'will re-enable it.
 

hippy

Technical Support
Staff member
To disable a servo simply issue a LOW on its pin - a SERVO 2,xxx would be disabled by a LOW 2.

Disabling will only be necessary during the serial comms and we are minimising that by using the Pin 3 polling. Most of the time the PICAXE will not be in SERIN so the servos will run as desired, the 20ms frame rate will be maintained. I'm not even sure the servos will need to be disabled during the short SERIN period, but we are not at a stage where we even have to worry about that.

Hence the step-by-step approach of proving serial comms works then getting it to work in a loop which will later be used for servo control which can be broken out of to do serial comms whan necessary.

Another approach may be to stay in serial most of the time, when serial is received, update the servo positions, wait for a while to ensure servos are set right, disable the servos, and go back to SERIN waiting. I'm not sure that will work though for things like rudder or sail control in the middle of the ocean where there will probably be a lot of force applied to a not actively driven servo. I'm not a servo expert though.

There are numerous possibilities which can be debated and some may be better than others in particular scenarios but we've got to start somewhere. Get something working, and then improve on that, try alternatives, later.
 

Robin Lovelock

Senior Member
Thanks Hippy and Beaniebots. I feel a bit silly because
shortly after my last posting I saw that the required LOW
pin numbers were, of course, LOW 1: LOW 2: LOW 4

I put this into the test program and sure enough,
it solves the problem of the servos drifting.
So I'm now into the serial input handling again.

From what you say here Hippy, that's encouraging
- we might end up with a solution where the servos
are not "limp". Although, right now, this is not a problem
with the servo being used - it's high gearing makes it
far from limp.

I've started trying some variations on the code you supplied,
and need to do some more - as best I can with the cables
that I've got here right now.

e.g.
LOW 1 'disable servos before 8MHz
LOW 2
LOW 4
SETFREQ M8 '8Mz for SERIN spoils SERVO

sync:
If pin3 = 1 Then
SerIn 3, N4800_8, ( 127 ), b2, b3
else
goto sync
End If

and, since the 127 can probably only be sent
by my AUTOP on the PC, for testing with
the Terminal Console (set at 4800) I tried

SerIn 3, N4800_8, ( "A" ), b2, b3

Hoping that would use A as a sync byte.
So I might type something like ABC then click the send button.

But I need to look back at your other examples
and see what extra tests I can do to get the serial input working.

Right now I'm thinking KISS (Keep It Simple Stupid)
e.g. just try and read the serial data without
being too worried about how long the process takes.

e.g.
sync:
SerIn 3, N4800_8, b1
if b1<>127 then goto sync
SerIn 3, N4800_8, b2
SerIn 3, N4800_8, b3

Not yet tried.
Now to grab a late breakfast.
I'll look for any ideas before more SERIN attempts.

Many Thanks again.
Robin
1020
www.gpss.co.uk/autop.htm





To disable a servo simply issue a LOW on its pin - a SERVO 2,xxx would be disabled by a LOW 2.

Disabling will only be necessary during the serial comms and we are minimising that by using the Pin 3 polling. Most of the time the PICAXE will not be in SERIN so the servos will run as desired, the 20ms frame rate will be maintained. I'm not even sure the servos will need to be disabled during the short SERIN period, but we are not at a stage where we even have to worry about that.

Hence the step-by-step approach of proving serial comms works then getting it to work in a loop which will later be used for servo control which can be broken out of to do serial comms whan necessary.

Another approach may be to stay in serial most of the time, when serial is received, update the servo positions, wait for a while to ensure servos are set right, disable the servos, and go back to SERIN waiting. I'm not sure that will work though for things like rudder or sail control in the middle of the ocean where there will probably be a lot of force applied to a not actively driven servo. I'm not a servo expert though.

There are numerous possibilities which can be debated and some may be better than others in particular scenarios but we've got to start somewhere. Get something working, and then improve on that, try alternatives, later.
 

hippy

Technical Support
Staff member
Right now I'm thinking KISS (Keep It Simple Stupid)
e.g. just try and read the serial data without
being too worried about how long the process takes.

e.g.
sync:
SerIn 3, N4800_8, b1
if b1<>127 then goto sync
SerIn 3, N4800_8, b2
SerIn 3, N4800_8, b3
No, that's unlikely to work. In the time it takes to execute the test on b1 and start subsequent SERIN's the data coming in will have gone by or will be read halfway through and you'll either see the program lock-up or receive corrupted data.

It may work when sending data at a slow rate from a terminal emulator, but not for AUTOP/iPAQ sending data bytes back-to-back with no delays between bytes.

"Serin 3, N4800_8, (127), b2, b3" is what you need to use.
 

f2cf1g

Member
Hi all. I'm new to this forum but I have some involvement in the robot boat as well as my own weather station project. I have had design issues with the latter, using serial communications as a method of linking two PICAXEs together, but I don't have the underlying problem of keeping servo updates going in the background so it's not as challenging for me. Anyway, it strikes me that the ultimate solution to the serial input problem would be for the PICAXE to support interrupt driven input from USARTs on the PICs which support them e.g. the PIC on the 28X2. Has anyone any idea if Rev Ed plan to provide this support? I would solve a whole lot of problems and open up their market for multiprocessor systems considerably I would have though.
Roy
 

hippy

Technical Support
Staff member
Welcome to the PICAXE forum, f2cf1g. I am sure your input will be gratefully appreciated.

The X1 and X2 PICAXE's do indeed have 'interrupt driven input from the UART', what we call 'background receive' - Have a look at the HSERSETUP command.

These PICAXE's are also able to operate as I2C Slave Devices which can simplify communications in some applications.
 

MartinM57

Moderator
...which highlights that it is often more effective to use the higher-end PICAXEs (which are only a few GBP more expensive) to achieve some tasks than spending hours trying to squeeze clever functionality from the lower end devices.

The fun is often in the journey, but if you actually want to achieve the end goal and value your time at more than about £0.50 per hour, I'd go to the higher-end devices every time...
 

Robin Lovelock

Senior Member
Success at last ! :)
Thanks for your patience guys - particularly Hippy.

After several hours doing other things today,
then coming back to this - and seeing a dry joint
on my RS232 input - which may not have helped,
I have now got something working which is
close to "fit for purpose". Latest program below.

After waggling the servos as a test at the start,
it waits on the 3 byte RS232 servo command,
currently supplied by AUTOP driving the PC COM1 port,
then does what the command asks:
drive servo N to position P.

This may already be usable, after confirming it works on the iPAQ,
but first I will see if I can exploit Hippy's neat idea of using
a test on PIN3 so that it is only briefly switched to 8MHz
allowing the SERVO commands to hold the servos in position
(not relying on that high gearing for that).

Sorry Hippy, but you may well save me some time
by a little more feedback here.

You can see what I'm using further below, but should my
new code look more like this ? ....

'wait for 3 bytes from RS232,sync, servo N, position P
sync:
IF pin3=1 then
LOW 1 : LOW 2: LOW 4 'disable servos before 8MHz
SETFREQ M8 '8Mz so can use SERIN
SerIn 3, N4800_8, (127), b2,b3
SETFREQ M4 '4Mz so can use SERVO
END IF

'drive servo N to position P in 3rd byte
if b2=0 then 'servo number 0
SERVO 1,b3
endif

etc,etc

Many Thanks again from a happy bunny :)
Robin
1745 Tuesday
www.gpss.co.uk/autop.htm


'SC1.BAS servo controller for robot boat
'input is RS232 group of 3 bytes:
'127=sync, 0,1 or 2=servo number, 0 to 126 servo position

#Picaxe 08M

verytop:
b5=100 'limits of servo travel
b6=191 '100 to 191 gives 360 degrees

SETFREQ M4 'standard 4MHz

'first a simple test pattern
'wag servos 1,2,4, once.
SERVO 1,b5 'initiate 3 servos
SERVO 2,b5
SERVO 4,b5
PAUSE 3000 'pause 3 secs

SERVOPOS 1, b6 'drive servo 1
PAUSE 1000 'pause 1 secs
SERVOPOS 2, b6 'drive servo 2
PAUSE 1000 'pause 1 secs
SERVOPOS 4, b6 'drive servo 4
PAUSE 1000 'pause 3 secs
SERVOPOS 1, b5 'all back
SERVOPOS 2, b5
SERVOPOS 4, b5
PAUSE 3000 'pause 3 secs

LOW 1 'disable servos before 8MHz
LOW 2
LOW 4
SETFREQ M8 '8Mz so can use SERIN

'wait for 3 bytes from RS232,sync, servo N, position P
sync:
SerIn 3, N4800_8, (127), b2,b3

SETFREQ M4 '4Mz so can use SERVO

'drive servo N to position P in 3rd byte
if b2=0 then 'servo number 0
SERVO 1,b3
endif
if b2=1 then 'servo number 1
SERVO 2,b3
endif
if b2=2 then 'servo number 2
SERVO 4,b3
endif

PAUSE 3000 'pause 3 secs to give servo time to travel

LOW 1 'disable servos before 8MHz which upsets them
LOW 2
LOW 4
SETFREQ M8 '8Mz for SERIN spoils SERVO

goto sync 'back to serial input






No, that's unlikely to work. In the time it takes to execute the test on b1 and start subsequent SERIN's the data coming in will have gone by or will be read halfway through and you'll either see the program lock-up or receive corrupted data.

It may work when sending data at a slow rate from a terminal emulator, but not for AUTOP/iPAQ sending data bytes back-to-back with no delays between bytes.

"Serin 3, N4800_8, (127), b2, b3" is what you need to use.
 

hippy

Technical Support
Staff member
IF pin3=1 then
LOW 1 : LOW 2: LOW 4 'disable servos before 8MHz
SETFREQ M8 '8Mz so can use SERIN
SerIn 3, N4800_8, (127), b2,b3
SETFREQ M4 '4Mz so can use SERVO
END IF
Yes, that's what you are after - but you will need to issue a SERVO command to position it.

The only thing is ... that one of the data packet bytes is going to activate entering the code by making pin 3 high, but then you have to wait for the next packet of data to be sent before it is read.

This where tweaking the AUTOP/iPAQ protocol to send $00 before the 127 will help as that will make pin 3 high and then you can then read the rest of that packet immediately. It might also require a bit of tweaking to get that to work.
 

Robin Lovelock

Senior Member
Thanks Hippy. Stopping work today soon, but since my posting
I did get a chance to try the AXE024 with the iPAQ and connected
into the boat system, complete with GPS and eunning with the
AutoPilot software. A quick test (stepping from -180 to +180
degrees in steps of 15 degrees seemed to work perfectly.
i.e. no missed commands and did what was spoken.
Some minor arithmatic on servo position needs
to be done so that the servo position is scaled identically.

Then I can start trying your PIN3 idea.
I'd rather get a solution that is exactly compatible
with the working system we've used in the past year.
I'll obviously look at tweaking the iPAQ protocol if forced to,
but only after a few days of 24/7 reliability tests.

Yes, that code in the last posting was just
that to be modified in related to reading the three bytes.
The rest of the logic including SERVO and SERVOPOS
could remain almost exactly the same.

I'll look for any tips from you tomorrow
before what I hope will be completion of the job.

Many Thanks
Robin
1845 Tuesday
www.gpss.co.uk/autop.htm



Yes, that's what you are after - but you will need to issue a SERVO command to position it.

The only thing is ... that one of the data packet bytes is going to activate entering the code by making pin 3 high, but then you have to wait for the next packet of data to be sent before it is read.

This where tweaking the AUTOP/iPAQ protocol to send $00 before the 127 will help as that will make pin 3 high and then you can then read the rest of that packet immediately. It might also require a bit of tweaking to get that to work.
 

f2cf1g

Member
Welcome to the PICAXE forum, f2cf1g. I am sure your input will be gratefully appreciated.

The X1 and X2 PICAXE's do indeed have 'interrupt driven input from the UART', what we call 'background receive' - Have a look at the HSERSETUP command.

These PICAXE's are also able to operate as I2C Slave Devices which can simplify communications in some applications.
Thanks for pointing that out Hippy, I see that close study of the latest versions of the manuals is key! I did have a look at i2c but didn't see an interrupt capability. Having had another look, the manuals seem to indicate that output can be interrupt driven but there is no mention of interrupt in input although the PIC data sheet seems to suggest that both are available on chip. Is there a restriction or am I mis-reading (again!)

Roy
 

hippy

Technical Support
Staff member
The manuals describe the commands in terms of functionality rather than internal mechanisms used so don't always use the same terminology as elsewhere. IMO, PICAXE users either don't know and don't care how the commands work internally and would not want or would get overwhelmed by detailed technical explanations, or have a level of knowledge that lets then read between the lines and recognise which internal mechanisms are used.

"HI2CSETUP I2CSLAVE" is what enables background receive of I2C and that is interrupt driven internally. SETINTFLAGS and HINTSETUP are also related commands which tie hardware interrupt driven events to PICAXE software interrupts and cause the "interrupt:" routine to execute.
 

Robin Lovelock

Senior Member
Good Morning Gentlemen, including Hippy.
I am hoping I will receive your good help again soon.

As you know, yesterday, with your help, I got
to the significant stage of my AXE024 servo controller
being able to read from the iPAQ RS232 with SERIN
and control the three servos with SERVO and SERVOPOS.
The work-around the restrictions was to switch 4Mhz/8MHz.

This morning, starting what I thought would be a trivial change,
I hit what looks suspiciously like another restriction - in arithmatic.
Sorry if I've still not got to grips with the documentation.

Here is the short bit of code, added early in my
program to investigate the problem:


'test on simple arithmatic to scale servo position
'input is 0 to 126 output to servo needs 100 to 191
'i.e. something like b3 = 100 + 91 * b3 / 126
'but probably needs to use simple integer arithmatic ?
for b3 =0 to 126 step 63
w1=b3
'w1 = 100 + 91 * w1 / 126
w1 = 91 * w1
w1 = w1 / 126
w1 = w1 + 100
b3=w1
SERVOPOS 1, b3 'move servo
PAUSE 3000
next b3
SERVOPOS 1, 100 'move servo back
PAUSE 3000

If the loop includes no real calculation then it works
e.g.
w1=b3
b3=w1

However, if any arithmetic statements are included
such as those commented out, the program appears to freeze.
e.g.
w1 = 100 + 91 * w1 / 126
or
w1 = 91 * w1
w1 = w1 / 126
w1 = w1 + 100

I've tried various things including use of LET
but that has no effect, and the manual indicates that
it's optional.

I do remember having to do integer arithmatic in the very
early days of computers, in the 1960s, on early machines
like the Lyons 2-11 or Ferranti Pegasus - which went into
production in 1949, after it was pioneered by the likes
of Alan turing at Bletchley Park working on Enigma
(that was the German code breaking project - not
Enigma Variations - some bit of music I think)
Anyway, by the 1960s, these old machines, now
found in the Science Museum, had high level language compilers.
Pegasus had only "RAM" of 55 words of 39 bits i.e. about 270 bytes
and a HUGE drum store, which I think gave a few KB of "hard disk".
So, comparing Pegasus with my iPAQ, or even the PICAXE boards,
it was a very small and slow computer indeed.
But despite that, it was quicker to program :)

Hope the above has amused if not educated you.
Looking forward to hearing how I can do some simple arithmatic
so those servo positions are properly scaled.

Maybe I need to switch the processor from 4MHz down to 1KHz ? :)

Robin
1145 Wed
www.gpss.co.uk/autop.htm
 

hippy

Technical Support
Staff member
The problem in this case is b3 is part of w1, so when you do your calculation and setting w1 you are altering the value b3 required for the FOR-NEXT loop ...

w0 => b1:b0
w1 => b3:b2
w2 => b5:b4
w3 => b7:b6
w4 => b9:b8
w5 => b11:b10
w6 => b13:b12

... And more so, doing that explicitly with your 'b3=w1' :)

When doing maths it's often best to write a short test program to prove the calculations and run that on a real chip or through the Programming Editor Siimulator.

Note that internally the PICAXE uses 16-bit maths so because the result is less than 256 the result can be stored in a byte and there's no overflow which can occur during internal, intermediate calculations. All maths is positive integer only and strictly left to right as you've spotted.

#Picaxe 08M
#Terminal 4800

For b0 = 0 To 126
b1 = b0 * 91 / 126 + 100
SerTxd( #b0, " gives ", #b1, CR, LF )
Pause 500
Next
 

Robin Lovelock

Senior Member
Many Thanks Hippy - what I dumbo I am
- changing a for loop variable - oldest mistake in the book :)
Thanks also for making me realize that the Word and Byte
variables are in fact the same memory locations - I missed that one.

Anyway, my program now has the required arithmatic in it
and it appears to work exactly as it should.
So later today I will be trying that neat idea of yours
to test the PIN and reduce time that servos are not held.

Many Thanks
Robin
1230 Wed
www.gpss.co.uk/autop.htm

p.s. you will find an old photo of me dressed as a hippy
at the top of www.gpss.co.uk/problems.htm :)



The problem in this case is b3 is part of w1, so when you do your calculation and setting w1 you are altering the value b3 required for the FOR-NEXT loop ...

w0 => b1:b0
w1 => b3:b2
w2 => b5:b4
w3 => b7:b6
w4 => b9:b8
w5 => b11:b10
w6 => b13:b12

... And more so, doing that explicitly with your 'b3=w1' :)

When doing maths it's often best to write a short test program to prove the calculations and run that on a real chip or through the Programming Editor Siimulator.

Note that internally the PICAXE uses 16-bit maths so because the result is less than 256 the result can be stored in a byte and there's no overflow which can occur during internal, intermediate calculations. All maths is positive integer only and strictly left to right as you've spotted.

#Picaxe 08M
#Terminal 4800

For b0 = 0 To 126
b1 = b0 * 91 / 126 + 100
SerTxd( #b0, " gives ", #b1, CR, LF )
Pause 500
Next
 

Robin Lovelock

Senior Member
Hello again Hippy. Glad you liked the piccy :)
On the basis of "if yer don't ask yer don't get" I'm after more advice.

Below you will find two very similar copies of my SC1.BAS program
(by the way, I guess there is an option so you see program
text pasted in here as it should be, with indented block structure.
If not, please forgive the poor layout, not in the original)

The start of both programs are identical,
waggling the servos and testing that arithmetic.
The changes are in the main loop starting at lael sync:

The second program seems to work just fine
and reliably, but servos are not held.
I have to rely on that high gearing mentioned earlier.

The first program is what I am working on now.
No doubt you will see major flaws in my understanding
of what you have suggested in use of IF PIN3.

It seems to work (a little unreliably) but it DOES
hold the servos in place. I saw that I need to
"remember" their three positions so all three are
restarted after processing the received RS232 command.

Also I sometimes get a regular twitch - but not always.

I'm guessing it may relate to the need for the output
protocol to be slightly "tweaked" as you suggested.

I have already modified AUTOP.EXE on the PC and
GPSSPPC.EXE on the iPAQ to preceed the three bytes
(sync=127, servo number, servo position 0-126)
by an extra blank byte - decimal zero.
It is not difficult for this to be more bytes or different value.

I thought I might save myself time experimenting by running
this past you first. You will probably see several mistakes.

Many Thanks
Robin
1400 Wed
www.gpss.co.uk/autop.htm


>>>>>>>
Yes, I'd spotted that ( on a different page ). You'll never know how close that is ! But an appropriate reference to cap off 10,000 posts :)

Time for a celebratory cup of tea and a biscuit.
added by Ron after posting above>>>>>>>>>>>

THIS PROGRAM ALMOST WORKING, WITH SERVOS HELD AT THEIR POSITION
BUT SEEMS UNRELIABLE AND CAN GET REGULAR TWITCH

'SC1.BAS servo controller for robot boat
'input is RS232 group of 3 bytes:
'127=sync, 0,1 or 2=servo number, 0 to 126 servo position

#Picaxe 08M

verytop:
b5=100 'limits of servo travel
b6=191 '100 to 191 gives 360 degrees

SETFREQ M4 'standard 4MHz

'first a simple test pattern
'wag servos 1,2,4, once.
SERVO 1,b5 'initiate 3 servos
SERVO 2,b5
SERVO 4,b5
PAUSE 3000 'pause 3 secs

SERVOPOS 1, b6 'drive servo 1
PAUSE 1000 'pause 1 secs
SERVOPOS 2, b6 'drive servo 2
PAUSE 1000 'pause 1 secs
SERVOPOS 4, b6 'drive servo 4
PAUSE 1000 'pause 3 secs
SERVOPOS 1, b5 'all back
SERVOPOS 2, b5
SERVOPOS 4, b5
PAUSE 3000 'pause 3 secs

'test on simple arithmatic to scale servo position
for b0 =0 to 126 step 63
w5 = 91 * b0 / 126 + 100
SERVOPOS 1, w5 'move servo
PAUSE 3000
next b0
SERVOPOS 1, 100 'move servo back
PAUSE 3000

b4=64: b5=64: b6=64 'remember servo positions


'wait for 3 bytes from RS232,sync, servo N, position P
sync:
IF PIN3 = 1 THEN

LOW 1: LOW 2: LOW 4 'disable servos before 8MHz
SETFREQ M8 '8Mz so can use SERIN
SerIn 3, N4800_8, (127), b2,b3

SETFREQ M4 '4Mz so can use SERVO

'covert b3 value 0..64..126 to 100..191
w5 = 91 * b3 / 126 + 100: b3 = W5

if b2=0 then 'servo number 0
b4=b3
endif
if b2=1 then 'servo number 1
b5=b3
endif
if b2=2 then 'servo number 2
b6=b3
endif

SERVO 1,b4 'set all three servos to their positions
SERVO 2,b5
SERVO 4,b6

PAUSE 3000 'pause 3 secs to give servo time to travel
SETFREQ M4 'back to standard 4MHz
END IF

goto sync 'back to serial input





THIS PROGRAM WORKS BUT SERVOS ALLOWED TO BE FREE

'SC1.BAS servo controller for robot boat
'input is RS232 group of 3 bytes:
'127=sync, 0,1 or 2=servo number, 0 to 126 servo position

#Picaxe 08M

verytop:
b5=100 'limits of servo travel
b6=191 '100 to 191 gives 360 degrees

SETFREQ M4 'standard 4MHz

'first a simple test pattern
'wag servos 1,2,4, once.
SERVO 1,b5 'initiate 3 servos
SERVO 2,b5
SERVO 4,b5
PAUSE 3000 'pause 3 secs

SERVOPOS 1, b6 'drive servo 1
PAUSE 1000 'pause 1 secs
SERVOPOS 2, b6 'drive servo 2
PAUSE 1000 'pause 1 secs
SERVOPOS 4, b6 'drive servo 4
PAUSE 1000 'pause 3 secs
SERVOPOS 1, b5 'all back
SERVOPOS 2, b5
SERVOPOS 4, b5
PAUSE 3000 'pause 3 secs

'test on simple arithmatic to scale servo position
for b0 =0 to 126 step 63
w5 = 91 * b0 / 126 + 100
SERVOPOS 1, w5 'move servo
PAUSE 3000
next b0
SERVOPOS 1, 100 'move servo back
PAUSE 3000


LOW 1 'disable servos before 8MHz
LOW 2
LOW 4
SETFREQ M8 '8Mz so can use SERIN

'wait for 3 bytes from RS232,sync, servo N, position P
sync:
SerIn 3, N4800_8, (127), b2,b3

SETFREQ M4 '4Mz so can use SERVO

'covert b3 value 0..64..126 to 100..191
w5 = 91 * b3 / 126 + 100
b3 = W5

'drive servo N to position P in 3rd byte
if b2=0 then 'servo number 0
SERVO 1,b3
endif
if b2=1 then 'servo number 1
SERVO 2,b3
endif
if b2=2 then 'servo number 2
SERVO 4,b3
endif

PAUSE 3000 'pause 3 secs to give servo time to travel

LOW 1 'disable servos before 8MHz which upsets them
LOW 2
LOW 4
SETFREQ M8 '8Mz for SERIN spoils SERVO

goto sync 'back to serial input
 

MartinM57

Moderator
(by the way, I guess there is an option so you see program
text pasted in here as it should be, with indented block structure.
Yes, in the Advanced reply box use the # button to wrap code tags around the code.

You also don't have to press Return after every line in your posts - it makes them very long and more difficult to read.

I thought I might save myself time experimenting by running this past you first.
The forum welcomes people who do some experimenting themselves rather than jumping straight back asking questions in long and complex emails :)
 

hippy

Technical Support
Staff member
You can use [code]...[/code] tags which will keep your code formatted correctly.

You need to keep the right frequency at the right time, so I would recommend trying this. I used b0, b1, b2 as the previous servo positions as easy to remeber.

Code:
b0 = 150 : Servo 1, b0
b1 = 150 : Servo 2, b1
b2 = 150 : Servo 4, b2

Sync:
  If pin3 = 1 Then
    Low 1 : Low 2 : Low 4
    SetFreq M8
    SerIn 3, N4800_8, (127), b12, b13
    b13 = b13 * 91 / 126 + 100
    Select Case b12
      Case 0 : b0 = b13
      Case 1 : b1 = b13
      Case 2 : b2 = b13
    End Select
    SetFreq M4
    Servo 1, b0 ' *
    Servo 2, b1 ' *
    Servo 4, b2 ' *
    Pause 3000
  End If
  Goto Sync
You may be able to change all the SERVO commands marked * to SERVOPOS and the first as SERVO and next two as SERVOPOS would be the next best thing if it works. I haven't used servos enough nor have any to test to see if that will work in practice.
 
Last edited:
Top