--- On Sat, 5/6/10, Tom Kerekes <tk@...> wrote:

From: Tom Kerekes <tk@...>
Subject: Re: [DynoMotion] Max. Following Error Handler
To: DynoMotion@yahoogroups.com
Date: Saturday, 5 June, 2010, 11:32 PM

 

Hi Azeddien,

 

There is no provision for this but you should be able to do it with a "watchdog" type of User C program that runs constantly and watches if anything bad happens and applies the brakes.  Something like:

 

#include "KMotionDef. h"

main()
{
    for (;;)  //loop forever
    {
          WaitNextTimeSlice( );

          if (ch0->Enable)
              SetBit(152);
          else
              ClearBit(152) ;
     }
}

 

TK

Group: DynoMotion	Message: 411	From: Tom Kerekes	Date: 6/5/2010
Subject: Re: Max. Following Error Handler

Hi Azeddien,   There are 100 global 32 bit variables called persist.UserData[100].   (They are called persist because they are in an area that gets flashed if you flash user programs).   You can communicate between threads using these variables.  If you need more, declare an array or structure in one thread and pass the address of the object to the other thread through a UserData variable.   Regards TK     Group: DynoMotion Message: 413 From: Azd Md Date: 6/5/2010 Subject: Re: Max. Following Error Handler What do u mean by flashing a user program? regards --- On Sun, 6/6/10, Tom Kerekes <tk@...> wrote: From: Tom Kerekes <tk@...> Subject: Re: [DynoMotion] Max. Following Error Handler To: DynoMotion@yahoogroups.com Date: Sunday, 6 June, 2010, 1:15 PM   Hi Azeddien,   There are 100 global 32 bit variables called persist.UserData[ 100].   (They are called persist because they are in an area that gets flashed if you flash user programs).   You can communicate between threads using these variables.  If you need more, declare an array or structure in one thread and pass the address of the object to the other thread through a UserData variable.   Regards TK     Group: DynoMotion Message: 414 From: Tom Kerekes Date: 6/5/2010 Subject: Re: Max. Following Error Handler There is a button on the Config/Flash Screen called "User Memory".  It saves all the configuration variables, User programs, and persist variables to flash memory.  This allows KFlop to run in "stand alone mode" (No PC connection).  Where it can run a User program immediately on power up.  But if you are using a PC to control things, it isn't necessary or recommended to use this.  It's simpler to just download from the PC when your program initializes.  That way the board remains in the default state and you don't get confused with what configuration or source was flased into a particular board.   TK