I actually want cognew to complete first

lardom

I'm completing an object that runs two steppers differentially which requires two cogs. Other operations can be executed by a single cog. I wanted to test a few robot commands such as "Rotate Left, Rotate Right, Accelerate, Arc Left and Decelerate...repeat 3"
The only way I've been able to get the test to run properly is to write waitcnt(clkfreq * 6 + cnt) which is the time it takes for the two-cog operation to execute. I was thinking I must be missing something.

PUB test | a, b

    repeat 3     
      workin.Spin_Left                'eight bit pattern    
      workin.Start_B(a, b)            'two cognew commands
      waitcnt(clkfreq * 6 + cnt)      'wait for methods to finish

Mike Green

COGNEW / COGINIT just initializes the cog including setting up the transfer of the code into the cog's memory. The instruction finishes as soon as that's done, but the cog will not begin executing code for about 100us as you've noticed (with an 80MHz system clock). That's the way it works. If you need to wait until the cogs start up or otherwise synchronize the cogs, you have to have the cogs set a variable to some specific value (usually a non-zero), initialize that variable to some other value (usually a zero) before issuing the COGNEW, and test for that specific value before continuing in the original cog that issues the COGNEWs.

In your case, I'd modify .Start_B something like this:

PUB Start_B( a, b) | waitFlag
waitFlag := false
ok := COGNEW(@codeAddress, @waitFlag) + 1
if ok
   repeat until waitFlag
' ... more code
DAT
codeAddress  wrlong  flagValue, par  ' signal that code has started
' ... actual code
flagValue   long   1

jazzed

A shared VAR or DAT mailbox variable would be readable by the starter object and cleared before the cog is started. The mailbox variable would be checked by the starter for non-zero. The cog program sets the variable once it starts and the starter can continue after seeing non-zero. No locks are required as long as the cog program uses only write and the starter uses only read after cog start.

lardom

@jazzed,

Quote by jazzed
The cog program sets the variable once it starts and the starter can continue after seeing non-zero. No locks are required as long as the cog program uses only write and the starter uses only read after cog start.

When I want the robot to move in an 'Arc', the coils of the two motors will be pulsed at different rates so I have to use two cogs. Every 'arc' command will require two cogs. The other commands need only a single cog. The issue for me is, I guess, waiting for a result variable from the cog program before the starter program moves to the next command. I'm now wondering if this is a special case. Perhaps a 'mailbox' variable would apply here.

StefanL38

Hi Larry,

there is a variant of the bresenham-algorithm for circles (or eliptic curves) that is able to create circle-moving with just one cog.

Aattached some documentation of the math.

Maybe the step/dir-gen-code from Mat-At-Work is useful to: it offers synchronised cogs
http://forums.parallax.com/showthread.php/142705-Step-Dir-signal-generator-for-CNC?

best regards
Stefan

Phil Pilgrim (PhiPi)

As an alternative to a shared variable, have the main cog set a lock and the new cog clear the lock as soon as it starts up. The main cog can then poll the lock until it's available again.

-Phil

jazzed

lardom wrote: »

@jazzed,
When I want the robot to move in an 'Arc', the coils of the two motors will be pulsed at different rates so I have to use two cogs. Every 'arc' command will require two cogs. The other commands need only a single cog. The issue for me is, I guess, waiting for a result variable from the cog program before the starter program moves to the next command. I'm now wondering if this is a special case. Perhaps a 'mailbox' variable would apply here.

Rather than starting and stopping cogs, just use variable(s) for command processing or other data interaction. I use mailboxes for everything requiring event changes or other communications. Waiting for cogs to start is wasteful in my book.

lardom

@StefanL38, thanks for the link. I learned the Bresenham algorithm from you and Tracy Allen and I made use of that knowledge in a previous project. I don't forget stuff like that. Thanks. I believe what I'm now working on can be useful for some users who are interested in robotics. If I can create something of value for the OBEX it's the best way I can think of to say thanks to all who have contributed to my developement.

lardom

Phil Pilgrim (PhiPi) wrote: »

As an alternative to a shared variable, have the main cog set a lock and the new cog clear the lock as soon as it starts up. The main cog can then poll the lock until it's available again.

-Phil

That might be what I'm looking for. I've never used a lock.

jazzed wrote: »

Rather than starting and stopping cogs, just use variable(s) for command processing or other data interaction. I use mailboxes for everything requiring event changes or other communications. Waiting for cogs to start is wasteful in my book.

I agree that starting cogs is wasteful and I wish I could find a single object/method call for the 'differential' operation.

Mark_T

StefanL38 wrote: »

Hi Larry,

there is a variant of the bresenham-algorithm for circles (or eliptic curves) that is able to create circle-moving with just one cog.

Aattached some documentation of the math.

Maybe the step/dir-gen-code from Mat-At-Work is useful to: it offers synchronised cogs
http://forums.parallax.com/showthread.php/142705-Step-Dir-signal-generator-for-CNC?

best regards
Stefan

It should be pointed out that that paper is AFAICT just wrong about helical paths - the Bressenham's circle algorithm is not constant angular velocity (not at all) so it can't be naively
tacked on to a Z-axis movement to give a true helix.