Serial multi-PUB code in new cog? Help needed!
Botdocter
Posts: 271
I am using this serial script to communicate with roborealm. But this script is so busy that it messes up the rest of the code, and especially the timing.
I added the script to this post.
Now i want to run it in a seperate cog, but the code uses 2 pub's and i have trouble getting it to work.
i removed everything from the code except the serial script. i just need one cog to produce me the variables that the main code can use.
RRSerial - standalone.zip
*edit
The serial script is working. The newcog is opened at the beginning of the script before the main loop. It does NOT need to be called for again in the loop itself. That'll make the cog start over and over again.
My motor drive code works also in a newcog. Allthough it will drive forward, it doesn't drive reverse...
I added the script to this post.
Now i want to run it in a seperate cog, but the code uses 2 pub's and i have trouble getting it to work.
i removed everything from the code except the serial script. i just need one cog to produce me the variables that the main code can use.
RRSerial - standalone.zip
*edit
The serial script is working. The newcog is opened at the beginning of the script before the main loop. It does NOT need to be called for again in the loop itself. That'll make the cog start over and over again.
My motor drive code works also in a newcog. Allthough it will drive forward, it doesn't drive reverse...
Comments
Here's a simple example that I use all the time: I create a "reporter" cog that spits out program variables (must be global) by using a secondary Spin cog. This requires a serial object to be loaded. (this is a demo, it should get you going).
Start with cognew:
By keeping track of the cog # you can kill it later if desired. Now put your output cog in a non-stop loop:
pri report term.tx(CLS) term.str(string("Report")) repeat term.tx(HOME) term.tx(LF) term.tx(LF) term.dec(value1) term.tx(CLREOL) term.tx(CR) term.dec(value2) term.tx(CLREOL) term.tx(CR) waitcnt((clkfreq / 1000) * 50 + cnt)This is an easy way to monitor global variables without interfering with your main program cog.
The example you gave is for debugging. Mine is receiving and i'm quite bounded by this script. Any changes and it wil stop working properly. I need both parts of the script to run in one cog.
But since i can't get it to work....
The string beeinh send by roborealm goes as follows:
\\value1\\value2\\value3\\value4\\value......etc.
you have to provide more information
How often per minute or per second do you have to receive the string?
The solution to this problem highly depends on the datarate you have to process.
How many bytes contains the longest string? (buffer-overrun of the serial object)
ALL global variables that are inside one and the same *.SPIN-file can be accessed from 1-8 cogs.
If you want answers that really help solve this problem you have to provide a detailed description
of what you want to to.
If I'm allowed to comment on your working-style:
you seem to expect "put two components together like plugging a USB-stick into ANY USB-port and the thing will work."
thinking maybe I have to ask a short question like (where can I check the free capacity of the USB stick? somebody drops three lines as answer
"right click on drive choose properties" and you are done.
programming the propeller is quite easy but not that easy as using a USB-stick.
there is still a learning curve.
It would be very helpful if you attach your COMPLETE code with the archive function of the propeller-tool.
best regards
Stefan
At the moment it contains 8 values but will be more in future. (max 15 values) i believe every value uses 24 bytes. 8 bit per character.
i knew this.. The problem is that if/when i put the script in a newcog it stops working....
After a few projects with the propeller chip i am aware of the dificulty-ness of propeller spin.
i never meant to plug and play....!?! I have been working on this problem for weeks accually. I'm just not that skilled with spin language yet.
It has been in the first post, since posting....?
John Abshier
You have to put everything in function drive into an endless loop if you want it to continue.
werkcodeRR - Archive [Date 2011.01.26 Time 23.58].zip
the attachment of the first posting to sounded like you have attached the roborealm-script
(as you talked about scripts and not about code)
In this case I did MYSELF wrong what I have often written in postings. I just took a quick look at it,
which led me to wrong assumings. I wanted to save time and instead of accelerating - everything slowed
down.
OK switching back to carefully examining the details.
Now I looked into your recent code posted above, examining it carefully from top to bottom:
first thing is:
the stack variable used in the cognew-commands has to have a minimumsize of 9 longs.
This stacksize increases if the called method has parameters and/or global variables.
To be sure that the stacksize is big enough - and as long as you do not run out of RAM use
a size of 200 to be really sure the stack is big enough
doing a
means a new cog is started and runs the code
PUB GetSer repeat rxHeight := SerCog rxWidth := SerCog rxTurretR := SerCog rxTurretL := SerCog rxSteerR := SerCog rxSteerL := SerCog rxDriveR := SerCog rxDriveF := SerCog returnthen your method main has a repeat-looprepeat GetSer Drive WheelAngle 'Wheel Angle for steering Transmitter 'Transmit valuesthat calls GetSer too. This means two cogs constantly and repeatedly are executing codethat grabs bytes out of the receivebuffer of FullDuplexSerial. Doing that means all the bytes
are getting mixed up
There should be only ONE place and just ONE cog receiving the data
You wrote I believe every value has 24 bytes. You have to be 101% sure how many bytes each value has.
The FullDuplexSerial-object has a receivebuffer of 16 bytes. This means there is a danger that bytes get overwritten. Bytes get overwritten if reading out the buffer is slower than the bytes come in.
At a baudrate of 115200 this might be the case.
If you would not read out any bytes at all then if you send 17 bytes the first
byte in the buffer gets overwritten by the 17'th byte. If you send even more bytes more bytes get overwritten. So it might be nescessary to increase the receivebuffer of FullDuplexserial.
There extist variants of the serial driver where you can easy increase the receivebuffer.
If it is nescessary depends on
- how many bytes are sended
- how fast the already received bytes are read-out of the receivebuffer
If RoboRealm sends the bytes all the time repeatedly you need something to synchronise sending and
receiving. Usually this is done by a special bytevalue indicating start of transmission (STX) and a special bytevalue indicating end of transmission (ETX). Otherwise the values get mixed up. What should be rxHeight becomes rxSteerL or anything else
In my early programming days I was very eager to get a program running. I wanted to finish it as quickly as possible. So I did almost no testing. In the end this slowed me down a lot.
At a students job I was forced to do intensitive testing. And - as I was payed per hour (and not per codeline) I thought "OK! gives even more money!) and I made the experience that the program developed
much faster than by hurrying up.
Why that? I was forced to program in a certain working-style:
every method does only one thing
this is something ypu already do in your coding
second thing was: test every method intensivly if the method is finished. Start coding the next method only if all the testing of the current method is finished successfully.
This working-style assures that a bug is in the current method and not in another method coded before.
Intensivly testing means creating different extreme situations
At receiving serial data this could be
- receiving no data at all for some minutes - checking how does the method behave on that
- receiving data with wrong parameters (wrong baudrate etc.)
- receiving data in a wrong order
- receiving too less bytes
- receiving too much bytes
If all these testing has been done and your code can react senseful on all these situations
go on with using the received data.
You might think "eh come on! I know how to set the serial parameters and I know the order of the data!"
I promise you: if you don't care about these things - later on it will bite you. Weeks or even months later your robot starts to behave strange and you ask yourself what the hell is wrong???
To do intensivly testing on a method like "Drive" means:
first test of the hardware is done with hardcoded values. Why that?
With hardcoded values you can be 101% sure that if something behaves strange the reason
is the hardware and not the value.
If you write a receiving-method and do no testings and then write the drive-method and then start testing
it combined there are much more possabilities where the bug can be.
You will need much more time to find the bug. Now imagine a bigger code with 10 or 20 or even more methods all interacting with each other and now try to find the bug.
Anyway If you post code with a concrete question pointing the forum-members to the codelines you suspect them to cause the problem you will get help here.
My suggestion is to find out:
- how does the RoboRealm-Data look like EXACTLY
- what is the frequency the data is sended from RoboRealm
or if you can create some kind of handshaking meaning RoboRealm send a set of data ONCE
and then waits for an acknowledge of the propeller-code and only if the acknowledge-signal was
received sending the next dataset
best regards
Stefan
My other problem is the drive script. It does drive forward when "rxDriveF" is "1", but when "rxDriveR" is "1" it doesn't do anything....
Did i make a mistake in the code?
Yes. If you havent't yet set the option "show block group indicator" in the propellertool you should do it.
So what makes the difference if something showing is switched ON???
You will see that all the "SERVO.SetRamp(......) lines of code do NOT belong to the repeat-loop
Second indicator for that is that the COLOR of these lines is the same as for comments
and if you take a close look at the lines in columm 3 you wrote a comment-sign so all of these lines are commented out
and were not compiled.
By the way coding a loop like
is vrey bad programming style. Even for testing. You call a method for 500.000 times
where it is enough to call it ONCE. Sure you can create a wait-functionality with this.
I haven't tested this but maybe it even behaves strange if you tell the ramp-cog again and again and again to do ramping
You should call it ONCE and then do a waitcnt
best regards
Stefan
About the Servo.SetRamp; I have tried many different ways of driving my speed controllers and this happened to be the first one that worked.
I have updated it since then but the problem still exists. forward is ok but reverse is a no no....go
this is the latest setup for the "drive" cog:
PUB Drive Repeat IF rxDriveR == 1 SERVO.Set(MotorChA,1425) IF rxDriveF == 1 SERVO.Set(MotorChA,1370) IF rxDriveF == 0 and rxDriveR == 0 SERVO.Set(MotorChA,1400) 'Stop Motor channel Athe repeat-loop makes the propeller-chip stay forever in this repeat loop
here again you have a outer repeat-loop in your method main
but as soon as the code starts to execute the method drive once
the code will stay inside the repeat-loop of method drive.
You started a second cog to receive the data into the variables rxDriveR, rxDriveF etc.
what do you send for data?
to test where the bug comes from you have to keep everything constant except for one thing at a time.
Otherwise you will not know where the bug comes from
There are so many possabilities where the bug can be
- does the ESC react on the prop-IO-pin signal? (wire OK? etc.)
- does the receiving work like expected?
you can go on posting code snippets and wait for some hours until an asnwer will posted
and wasting a lot of days to reach a working system.
I recommend testing EVERY DAMMED DETAIL on yourself.
If would like to put more effort in analysing your problem I would
- install roboREALM running your script to analyse how is the data sended? What is the repeat frequency?
how much data is it? do I get FullDuplexSerial bufferoverruns because one RoboREALM-data-packet contains more than 16 bytes
etc. etc. etc.
But I won't do that because this is YOUR homework.
Of course you can go on in the same style as before. And maybe I was overlooking something and maybe somebody else will find this.
- lots of maybes. My advice make things SURE by testing EVERY DAMMED DETAIL.
best regards
Stefan
Or did i misunderstood?
The data that is beeing send by roborealm is
\\value1\\value2\\val..... Etc
Coming out of roborealm like this:
/0/1/0/0/0/1/0/0/0/1/0/0/0.....etc
The data beeing send for driving are 1 for true and 0 for false.
I test all the time like you said. Rule by rule. Allthough, if you don't know how to write something, you can test all you want.
I'm not lazy. All i do all day long is working on the code.(i don't have a job).
I'm just not that familiair with spin yet. Allthough you guys teach me a lot.
OK. I referred to the code that is inside the zipfile named
"werkcodeRR - Archive [Date 2011.01.26 Time 23.58].zip"
here is that PART of the code that is important for this
PUB Main | DutyCycle, temp,GetData' new stuff DutyCycle SERVO.Start SERVO.Ramp InitA serial.start(rxpin,txpin,%0000, 115200) '- rxpin,txpin,mode,Baud Cognew(GetSer,@SerStack) Cognew(Drive,@DriveStack) repeat GetSer Drive 'call of method drive in the repeat-loop of method main WheelAngle 'Wheel Angle for steering Transmitter 'Transmit values PUB Drive Repeat 'repeat-loop INSIDE of method drive ......If you use code that has changed more than a few spaces you have to provide the new code as a whole thing.
I guess you understood right - but still not everything right.
please post an examplestring that is an EXACT copy&paste of what a serial terminal-program
RECEIVES from RoboREALM (what you SEND is NOT enough !! It has to be the received characters)
OK I understand: datavalues delimiter character is "/"
but how MANY bytes are coming IN. This is a really important detail !!! (Bufferoverflow of FullDuplexSerial)
did you ever check that your receive-code if all values are set properly??
This is part of your homework:
testing and checking if your receive-code works properly.
if you send a "1" for rxWidth that the variable contains DECIMAL value "1" ?
I have very strong doubts that your receive-code works properly.
I could tell some ideas what is wrong. But I do NOT because then I would support your style
of asking for a detail only scatching the surface instead of learning in depth.
Somehow I'm sorry to say that but in my opinion it is nescessary to get you going on your OWN FEET
The next homework to do is
1.) stop trying to push your complete code forward by reading a few words trying to understand them and then experimenting for hours with different variants of code based on guessing or assuming
2.) improve your understanding of the program-flow by coding SMALL testcodes which includes debug-information that shows you in detail which codelines are executed.
or start working through the Propeller Education Kit Labs Fundamentals Version 1.1
which you find in the help-menu of the propeller-tool. BEGINNING with
page 17 chapter 2: Software, Documentation & Resources
(and NOT jumping fast forward to a higher chapter)
it's up to you to choose
A: going on the same way as you did until now. Then I estimate finishing your project in two years after 2000 questions and 20.000 try's and errors still without really knowing what you are coding.
B: learning SPIN from ground up for 2 or 3 weeks doing 200 exercises
and then going on with your project
step by step testing each part of the code
and finishing it within 2 or 3 months.
The minimum I recommend is to choose ONLY ONE of the following parts of your project
- receiving the RoboREALM-string
- driving forward / backward
- learning about program-flow in a parallel processing environment as the propeller is
and then coming back here with a CONCRETE question I tried this SMALL code
I think it should do A but it does B can somebody explain to me how I can add debug-code
to improve my understanding of SPIN.
I may sound rough somehow but I'm trying to help to get you on your own feet going.
Sometimes I came to the conclusion I have to be very clear to get somebody on that way.
so please post your decision what is your next step within the options mentioned above?
best regards
Stefan
I case you did not 'read' my former post, one more time....
The serial script is working allready!
As for the driving. It must be something simple i overlook.(you would know).
It is NOT the first time i drive servos or motors with the propeller!
These esc's are just weird to controll. I wrote the same code for my other robot and that was working fine...
Although i want to learn spin better than i do.i don't think it's up to you to force me in to it. I have difficulties with reading and that's slowing me down. But that doesn't stop me from reading for day's in the manual and the forum before i post any question.
Is it really so weird that i ask a question like this on the forum??
Anyway, i'm happy with your support, but if these answers keep coming with preaches, please don't answer my posts anymore! I don't force anyone....
So from what I know until now about your project is:
RoboRealm is sending a string like "/0/1/0/0/0/1/0/0/0/1/0/0/0/"
If you send this to the propeller the receivebuffer contains
byte0 "/"
byte1"0"
byte2"/"
byte3"1"
byte4"/"
Now you call your datareceive-method
PUB SerCog rxVal_1 := serial.rx 'Get next value from roborealm rxVal_2 := serial.rx rxVal_3 := serial.rx rxVal_4 := serial.rxafter that the variables contain the ASCII-codes
rxVal_1 contains "/"
rxVal_2 contains "0"
rxVal_3 contains "/"
rxVal_4 contains "1"
as DECIMAL values these are
rxVal_1 contains 47
rxVal_2 contains 48
rxVal_3 contains 47
rxVal_4 contains 49
now you do some bitshifting producing a 32bit value which is surely bigger than 1
rxVal := rxVal_1 | (rxVal_2<<8) | (rxVal_3<<16) | (rxVal_4<<24)
this big value is passed to the variables
rxDriveR := SerCog
rxDriveF := SerCog
and in method Drive you have a if-condition
IF rxDriveF == 1
how should this work?
I would be astonished very much if this works
There must be something different
a different string sended by roborealm or a difference in the code
This is one example that let's me come to the concusion that you have not yet understood how basic things like ASCII-code, bitshifting etc. work
But I guess I have to setup a test-environment myself and proof it through debug-output
If I should help you here more I need to now how the string looks like roborealm is sending
minimum is a screenshot of a serial terminalprogramm that shows the result of the method
PUB Transmitter serial.dec(rxHeight) serial.tx(13) serial.dec(rxWidth) serial.tx(13) serial.dec(rxTurretR) serial.tx(13) serial.dec(rxTurretL) serial.tx(13) serial.dec(rxSteerR) serial.tx(13) serial.dec(rxSteerL) serial.tx(13) serial.dec(rxDriveR) serial.tx(13) serial.dec(rxDriveF) serial.tx(13)but in a modified version like this
PUB Transmitter serial.str(string("rxHeight=")) serial.dec(rxHeight) serial.tx(13) serial.str(string("rxWidth=")) serial.dec(rxWidth) serial.tx(13) serial.str(string("rxTurretR=")) serial.dec(rxTurretR) serial.tx(13) serial.str(string("rxTurretL=")) serial.dec(rxTurretL) serial.tx(13) serial.str(string("rxSteerR=")) serial.dec(rxSteerR) serial.tx(13) serial.str(string("rxSteerL=")) serial.dec(rxSteerL) serial.tx(13) serial.str(string("rxDriveR=")) serial.dec(rxDriveR) serial.tx(13) serial.str(string("rxDriveF=")) serial.dec(rxDriveF) serial.tx(13)this will pull out the REALLY TRUTH about the values of each variable
but as long as the method main looks like this
PUB Main | DutyCycle, temp,GetData' new stuff DutyCycle SERVO.Start SERVO.Ramp InitA serial.start(rxpin,txpin,%0000, 115200) '- rxpin,txpin,mode,Baud Cognew(GetSer,@SerStack) Cognew(Drive,@DriveStack) repeat GetSer Drive WheelAngle 'Wheel Angle for steering Transmitter 'Transmit valuesand method Drive has a repeat-loop I predict that
the method transmitter NEVER gets executed!
as the program "hangs" inside of method drive because of the repeat-loop there
gonna test this myself later this evening
If you have done any modifications to the code please create a new archive and post it here that I can look into your most actual code
best regards
Stefan
Everything is recognized as it should.
I attached the updated achive where everything is set in 2 cogs.
i combined the drive and the wheelangle in one cog, and the serial receiver and transmitter in the other.
All the functions except the drive reverse work as should.
That should accually be:
byte0"1"
byte1"\"
byte2"0"
byte3"\"
byte4"0"
That makes a 3 digit value. That should be correct.
Also i'm pretty sure that the 2 backslashes are interpretted as <cr >
that is what makes the code synchronize with the serial string. Every <cr > makes it go to the next line and therefor to the next character.
the method "rx" of the FullDuplexSerial-Object does nothing else but reading a byte out of the receivebuffer. Completely regardless of the value of the byte.
So if you get good values out of the string that the propeller-chip is RECEIVING this string cannot be "1/0/0"
I assume the line
\240\0\0\0@\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0
is created by roborealm
each "/" is delimiter between the single bytes (where each 4byte "packages" create a 32bit value)
RoboRealm is NOT sending the character "/" to the propeller-chip.
As you get good values with your receive-routine roborealm send each value as a 32bit-value as 4 bytes. These bytevalues are NOT ASCII-coded
example that could be easy understand
the decimal value 513 represented as a 32bit binary value looks like this MSByte Byte2 Byte3 LSByte 87654321 87654321 87654321 87654321 00000000 00000000 00000010 00000001 = decimal 513 dec 512 dec 1 what I can conclude from your code PRI SerCog rxVal_1 := serial.rx 'Get next value from roborealm rxVal_2 := serial.rx rxVal_3 := serial.rx rxVal_4 := serial.rx rxVal := rxVal_1 | (rxVal_2<<8) | (rxVal_3<<16) | (rxVal_4<<24) is that roborealm sends it this way rxVal_1 rxVal_2 rxVal_3 rxVal_4 LSByte Byte3 Byte2 MSByte 87654321 87654321 87654321 87654321 00000001 00000010 00000000 00000000 32bit values are sended bytewise with lowest significant BYTE first rxVal_1, 2, 3, 4 contain each a 8bit value. This 8bit-values are bitshifted to the LEFT rxVal := rxVal_1 | (rxVal_2<<8) | (rxVal_3<<16) | (rxVal_4<<24) rxVal_1 is not bitshifted just "or'ed" rxVal_2 is bitshiftet 8 bits to the left (which means bitshift 1 byte to the left) rxVal_2 00000010 before bitshifting 87654321 87654321 00000000 00000010 after bitshifting 87654321 87654321 00000010 00000000 rxVal_3 is bitshifted 16 bits left (which means bitshift 2 bytes to the left) rxVal_4 is bitshifted 24 bits left (which means bitshift 3 bytes to the left)now back to your examplestring\240\0\0\0@\1\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\1\0\0\0\0\0\0\0
take a close look at what you wrote
there are 5 bytes
1 byte0
2 byte1
3 byte2
4 byte3
5 byte4
your receive-routine receive only 4 bytes.
\240\0\0\
rxVal_1 contains value 240 (less than 255 so all bit fit into the lowest siginficant byte)
rxVal_2 contains value 0
rxVal_3 contains value 0
rxVal_4 contains value 0
this results in value rxHeight=240<cr>
next packet @\1\0\0\
rxVal_1 contains value 64 (320 is bigger than 255 so not all bits fit into 1 byte)
rxVal_2 contains value 1 (through bitshifting value 1 8 bits to the left it becomes value 256
rxVal_3 contains value 0
rxVal_4 contains value 0
256 + 64 = 320
this results in value rxWidth=320<cr>
Now I want to look "from above"
You have a lot of misunderstandings about how it works in detail
and because I have seen this I had strong doubts that the receiving works properly
that's why I wanted you to check everything carefully
It has taken 12 postings and 4 days until I it is clear what roborealm is sending.
and it is something different than you wrote.
How was it finally cleared what roborealm is sending?
through DETAILED information provided by you.
HARD information based on the hardware and software-debug-output not based on assumings or conclusions.
Now what could be a way to go on solving the problem driving backwards?
my suggestion is to insert debug-code that indicates the if-condition
IF rxDriveR == 1 'Drive Backwards/Reverse SERVO.Set(MotorChA,1365)is true.This will clear up if something is wrong with the synchronisation or if there is something wrong
with the ESC
by the way I you sended me your new code
the stacksize of Initstack is still too small all three should be 200
if a stacksize is too small - memory dedicated to variables or code get overwritten and this can cause
the most strangest behaviour of the code you can think of.
how did I recognize that?
through DETAILED information provided by YOU.
If you wouldn't have sended your actual code I would have assumed that all stackvariables are already
on 200 longs. We might would have searched for WEEKS where is the bug without finding it!
I hope you can see now how much important HARD and DETAILED information is in software-developing is!! Especcially actual code.
So next step is correct stackvariable-size and do a quick test. It might be that it work already good.
if not follow my suggestion above
EDIT: InitStack is not used at all. So this cannot be the bug. Anyway what do I learn from that? It's ALWAYS good to look carefully at the things
and keep in mind if a code behaves strange - ask is the stacksize big enough?
best regards
Stefan
It is beeing called for....
but with only the output-result I can't analyse much.
I need to know WHERE in the code did you insert the debug-code and how the complete actual code looks like.
please upload a new archive with the actual code.
do you still have the method drive running in two cogs the "drive"-cog and the "main"-cog??
Running a method in two cogs that should only run in one cog is a infinite source for bugs and strange behaviour of the code.
Please write me a description of what your code should do. If I know that I can make suggestions on how to achive this.
As the debug-output of each variable is clearly named it is easy to see that you sended rxDriveF = 1
and then no variable with a one. If I remember right driving forward was already working and driving reverse not.
So the interesting case is to add debug-output "inside" of if-condition
and to see what is happening then
does the if-condition ever gets true?
if yes do you have a signal on the related output-pin?
If you don't have an oscilloscope you could test this
by using a standard servo instead of the ESC.
make a pretest with a small program that sends the same pulse-lengths (=position) as in your aesior-code
i.e.
SERVO.Set(MotorChA,1425)
SERVO.Set(MotorChA,1365)
mark somehow the positions of the servo.
then test it with your aesior-code to see if the servo drives to the same positions.
If yes you can conclude the bug is related to the ESC
So narrowing down goes into the direction of analysing on how does the ESC react on what.
If I remember the datasheet of your ESC right it has an auto-calibrate-function.
set remote-control to neutral position hold for some time until you hear a beep
set remote to position max forward hold some time until you hear a beep
set reote to position max reverse hold some time until you hear a beep
or anything similar I don't remember it right
did you test your code if it does this initialisation- and calibration-procedure properly?
Do you know in which cases (power-off, servo-signal loss etc.) the ESC needs a re-calibration?
Did you test this? Can you reproduce faults and successful calibration?
I have a lot more ideas what MIGHT be the problem. But I stop here because I'm already guessing through the fog
Please provide detailed information and actual code
best regards
Stefan
i couldn't be more clear than my code. It's just receive the variables from roborealm,react on those values(nuber of values may differ). for now drive forward and reverse(motors) left and right (servo).
from the propeller i need to send new made variables to the pc(sensors). through the same interface and concept.
the dump was from a piece before the rxDriveR = 1 to after the SUCCES (rxDriveR), so at the time that rxDrive is indeed "1" the SUCCES string is overwriting everything so it is unreadable.
The IF condition does get true (succes). there is also signal. i haven't tried a servo yet but since they work on other pins why wouldn't this? The steeringservo/wheelangle works fine too aswell as the turret. i will try to connect one though.
When i use the same pulse widths in a seperate file,(servo32v7RampDemo is used for testing), it works fine. forward brake and backwards/reverse. i will try with a servo though, it could be a timing issue....
It needs a low throttle upon start. this equals to 1400(1.4ms). this is the midpoint/0.
Everytime i start the code it beeps and never after that. so that must be the only time i have to calibrate. According to the manual it has to be redone after power off/on. with the microcontroller it accepts it every reset.
hope this will help..
thank you for uploading your latest code.
between the codeversion before you changed the pulsewidth values for forward/backward
code from werkcodeRR - Archive [Date 2011.01.28 Time 21.11]
PUB Drive Repeat IF rxDriveF == 1 'Drive Forward SERVO.Set(MotorChA,1425) IF rxDriveR == 1 'Drive Backwards/Reverse SERVO.Set(MotorChA,1365)code from werkcodeRR - Archive [Date 2011.01.29 Time 23.50]IF rxDriveR == 1 ' serial.str(string("SUCCESS")) Direction := 1425 'Drive Reverse IF rxDriveF == 1 Direction := 1365 'Drive ForwardI did a research about the datasheet of your ESCreferring to a posting from Graham Stabler who took the time to dig out a link to
xaic china
http://www.xaic.cn/english/zzcp/ElectronicSpeedController.htm
The only datasheet listet there that comes close your 50A ESC is the
20A,dual way, push switch,recoil, auto cut off
inside this datasheet you can find
the following setup-procedure
1) Switch the transmitter on.
2) Throttle down (min.throttle).
3) Connect the controller to RC equipment.
4) Switch on the controller.
5) 1xbeep.
6) Start.
This means before even switching on the ESC you have to have your propeller
sending a pulsewidth that means the LOWEST throttle
now switching on the ESC
the propellerchip has to keep on sending the LOWEST-throttle-signal
UNTIL the ESC CONFIRMS calibrating on the LOWEST-throttle-signalthrough a beep.
1) Switch the transmitter on. (switch on propeller)
2) Throttle down (min.throttle). (ESC is still OFF propeller starts sending lowest throttle-signal and is DISCONNECTED from ESC)
3) Connect the controller to RC equipment. (connect ESC to propeller)
4) Switch on the controller. (controller = ESC)
5) 1xbeep. (ESC confirms calibration through a beep)
6) Start.
And it MIGHT be that the ESC is picky about following this procedure EXACTLY
Somehow I doubt that for a two-way-controller you have to calibrate on throttle-low instead of throttle-neutral. But as the datasheet says it is worth a try
If the ESC simply divides the pulsewidth-range by two to get the neutral this might work
If this is the case the init procedure has to create the throttle-low-pulsewidth
In your code this is value 1365 instead of value 1400
My way of examining the ESC and learning how to control it would be
1.) reading the datasheet very carefully
2.) coding a small testprogram that follows the setup-procedure very exactly
(you took the standard servodemo-program and just adjusted the pulsewidth and don't cared about the rest. ESC reacted with driving forward/backward OK testing done go on with the next part)
I say at this moment testing ISN'T done. I would start varying the setup-procedure
when does it fail to find out what is really important.
3.) varying the setup-procedure
what happens if the controller stays connected to servo-signal still beeing switched of?
(no disconnecting of the servo-signal from the ESC as recommended in the setup-procedure)
what happens if if the controller stays connected to servo-signal then is switched on without already sending the throttle-low-signal?
What is the minimum-time the throttle-low-signal has to be send that the ESC can calibrate on it?
What is the range of the pulsewidth for which does the ESC beep as confirming calibration?
(this means testing is the ESC really dumb that it would even calibrate on a pulsewidth of 2 millisecs
which is already the maximum-value.
Does minimum-throtlle mean a short pulsewidth (range 1 millisecond to 1,5 milliseconds)?
or does minimum-throtlle mean a long pulsewidth (range 1,5 millisecond to 2 milliseconds)?
After all these testing your knowledge about this particular ESC is quite good.
Then I would take the testing code and implement it in the bigger aesior-code
I would NOT write it new.
This is a style of systematic examining one part of the hardware.
Estimate how long this systematic examining would take. I guess 3-8 hours.
Now compare it with the time you have spend on it and how many days has gone by until you posted your first question about the ESC
it was 22.01.2011 not 8 hours ago 8 days ago.
I can't resist to comment sarcastic on this: very effective.
best regards
Stefan
Done that when the link was posted.. also i received the original manual through email. It is unusable! both of them. initialization is done with a throttle neutral. No need for timing here. one pulse is enough it seems. Ofcourse the first thing i did is write a testprogram that exactly follows the manual (once i got it). Did NOT work! Only working setup is the one i used. at least for as far my knowledge goes....
I think it's quite normal that if i tested something, and it works, that i go on to the next step. What would you expect?? More testing just to be sure it is indeed working? i saw that the last time. If you know what i should be doing different here, please explain.....
It needs to be initialized before it is usable.. no movement No movement.. It calibrates best at 1400. And not below. Allthough higher pwm upto 1450 is accepted. at 1490 it keeps beeping. but that sounds like a fault.
That's exactly what i did in the first place. Then you said that that wasn't the way to drive my motor controllers. it was accually a very bad idea, you said
Yeah, so what exactly is your point now? i already did all the testing before we even got to talk.
The rest of the time you kept me busy asking questions about a serial script (wich is working fine),wich i hope are nescesairy to help me fix my problem and not to make your point..........
I gave up. I came to the conclusion that your way of working on projects and my way of working are too different to proceed at an acceptable speed.
There are some details in your postings that formed a picture of you in my mind that doesn't seem to fit at all.
It would take a lot effort to clear these personally things up. This would retard the success in the project itself even more.
And I estimate it would be very unsecure if it would work better after trying to clear it up.
I'm sorry that I have wasted a part of your time. Seems that I'm unable to write in an understandable way.
This happens here for the first time in my life. Please start a new thread to make it easier for others to chime in.
Stefan
I believe i tried very hard to answer all your questions, and kept having the idea that you where posting just to make a point.
It isn't very weird if you use sarcasm in almost every post, you'll loose credibility.
A lot of time was lost because you misinterpreted the serial script.
And you asked me to explain a code that is a bit over my head.
If you are really through, fine. If you think you have the answer to my problem. Don't hesitate to share.....
Might you or anyone else be interested in how the serial plugin from roborealm works, here is the link:
http://www.roborealm.com/help/Serial.php
After that I will think about coming back to help. I wish "climbing" up the learning curve in SPIN, in hardware and whatever is needed
to go on with your project.
Stefan