Dynomotion

Group: DynoMotion Message: 9662 From: Russ Larson Date: 6/18/2014
Subject: MPGSmoothHardwareEnc.c

Tom,

 

Question, we have been working on the C file MPGSmoothHardwareEnc.c and it does not appear to be a complete application.  Perhaps we missed something but unlike the C program MPGSmooth.c , there does not appear to be any defines in the program that identify the two phases of the MPG coming from the hand held pendant.  Are we missing something as it does nothing when you combine and download into KFLOP?

 

 

Russ Larson

 

 

 

 

#define QA 26   // define to which IO bits the AB signals are connected

#define QB 27  

 

 

 

 

 

 

 

#include "KMotionDef.h"

 

// Example Init program that includes "smooth" MPG motion example

// which makes use of the exponential motion command.

 

#define MPG_INPUT_AXIS 6

 

 

 

 

 

 

 

On 6/17/2014 12:55 AM, Tom Kerekes tk@... [DynoMotion] wrote:

 

Group: DynoMotion Message: 9663 From: Tom Kerekes Date: 6/18/2014
Subject: Re: MPGSmoothHardwareEnc.c
Hi Russ,

The original MPGSmooth.c example was written to monitor and count the MPG A B phases in software.  Because KFLOP User programs get a guaranteed chance to execute every 180us they are able to track quadrature transitions as long as they don't occur faster than about 5KHz.  Most low resolution MPGs don't go that high.  Actually a trick was used to get up to about 50KHz by assuming velocity can't change that rapidly and predicting how many transitions would have been missed.  The advantage to handling the MPG in pure software is that no hardware encoder resources are used, no KFLOP Axis Channel Input is required to support the hardware encoder, and any input pins can be used.

The MPGSmoothHardwareEnc.c example is written to use a Hardware Encoder Input.  This allows input speeds up to 1MHz with out any assumptions on limited acceleration.   However the MPG must be wired up to a hardware encoder input an a KFLOP Axis Channel Must be configured as Input Mode Encoder with the corresponding Encoder Input Channel.  The example assume your configuration settings do this.   The MPG_INPUT_AXIS must be defined to be the Axis channel assigned to this role.

HTH

Regards

TK 



From: "'Russ Larson' rdlarson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Cc: 'Mark Vogel' <mlvogel@...>
Sent: Wednesday, June 18, 2014 3:52 PM
Subject: [DynoMotion] MPGSmoothHardwareEnc.c

 
Tom,
 
Question, we have been working on the C file MPGSmoothHardwareEnc.c and it does not appear to be a complete application.  Perhaps we missed something but unlike the C program MPGSmooth.c , there does not appear to be any defines in the program that identify the two phases of the MPG coming from the hand held pendant.  Are we missing something as it does nothing when you combine and download into KFLOP?
 
 
Russ Larson
 
 
 
 
#define QA 26   // define to which IO bits the AB signals are connected
#define QB 27  
 
 
 
 
 
 
 
#include "KMotionDef.h"
 
// Example Init program that includes "smooth" MPG motion example
// which makes use of the exponential motion command.
 
#define MPG_INPUT_AXIS 6
 
 
 
 
 
 
 
On 6/17/2014 12:55 AM, Tom Kerekes tk@... [DynoMotion] wrote:
 


Group: DynoMotion Message: 9664 From: Russ Larson Date: 6/19/2014
Subject: Re: MPGSmoothHardwareEnc.c

Thanks Tom,

 

That explain a lot, will try that tonight.  It is connected to standard encoder inputs.

 

Russ

 

 

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Wednesday, June 18, 2014 9:17 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] MPGSmoothHardwareEnc.c

 

 

Hi Russ,

The original MPGSmooth.c example was written to monitor and count the MPG A B phases in software.  Because KFLOP User programs get a guaranteed chance to execute every 180us they are able to track quadrature transitions as long as they don't occur faster than about 5KHz.  Most low resolution MPGs don't go that high.  Actually a trick was used to get up to about 50KHz by assuming velocity can't change that rapidly and predicting how many transitions would have been missed.  The advantage to handling the MPG in pure software is that no hardware encoder resources are used, no KFLOP Axis Channel Input is required to support the hardware encoder, and any input pins can be used.

The MPGSmoothHardwareEnc.c example is written to use a Hardware Encoder Input.  This allows input speeds up to 1MHz with out any assumptions on limited acceleration.   However the MPG must be wired up to a hardware encoder input an a KFLOP Axis Channel Must be configured as Input Mode Encoder with the corresponding Encoder Input Channel.  The example assume your configuration settings do this.   The MPG_INPUT_AXIS must be defined to be the Axis channel assigned to this role.

HTH

Regards

TK 

 


From: "'Russ Larson' rdlarson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Cc: 'Mark Vogel' <mlvogel@...>
Sent: Wednesday, June 18, 2014 3:52 PM
Subject: [DynoMotion] MPGSmoothHardwareEnc.c

 

 

Tom,

 

Question, we have been working on the C file MPGSmoothHardwareEnc.c and it does not appear to be a complete application.  Perhaps we missed something but unlike the C program MPGSmooth.c , there does not appear to be any defines in the program that identify the two phases of the MPG coming from the hand held pendant.  Are we missing something as it does nothing when you combine and download into KFLOP?

 

 

Russ Larson

 

 

 

 

#define QA 26   // define to which IO bits the AB signals are connected

#define QB 27  

 

 

 

 

 

 

 

#include "KMotionDef.h"

 

// Example Init program that includes "smooth" MPG motion example

// which makes use of the exponential motion command.

 

#define MPG_INPUT_AXIS 6

 

 

 

 

 

 

 

On 6/17/2014 12:55 AM, Tom Kerekes tk@... [DynoMotion] wrote:

 

 

Group: DynoMotion Message: 9665 From: Tom Kerekes Date: 6/19/2014
Subject: Re: MPGSmoothHardwareEnc.c
Hi Russ,

After your Axes are configured verify that "Position" on the KMotion Axis Screen changes properly when you rotate the MPG.

Regards
TK

Group: DynoMotion Message: 9666 From: Russ Larson Date: 6/19/2014
Subject: Re: MPGSmoothHardwareEnc.c

Thanks Tom,

 

Will get this tested tonight.

 

Russ

 

 

 

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Thursday, June 19, 2014 12:03 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] MPGSmoothHardwareEnc.c

 

 

Hi Russ,

 

After your Axes are configured verify that "Position" on the KMotion Axis Screen changes properly when you rotate the MPG.

 

Regards

TK

 


From: "'Russ Larson' rdlarson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Sent: Thursday, June 19, 2014 5:17 AM
Subject: RE: [DynoMotion] MPGSmoothHardwareEnc.c

 

 

Thanks Tom,

 

That explain a lot, will try that tonight.  It is connected to standard encoder inputs.

 

Russ

 

 

 

From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com]
Sent: Wednesday, June 18, 2014 9:17 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] MPGSmoothHardwareEnc.c

 

 

Hi Russ,

The original MPGSmooth.c example was written to monitor and count the MPG A B phases in software.  Because KFLOP User programs get a guaranteed chance to execute every 180us they are able to track quadrature transitions as long as they don't occur faster than about 5KHz.  Most low resolution MPGs don't go that high.  Actually a trick was used to get up to about 50KHz by assuming velocity can't change that rapidly and predicting how many transitions would have been missed.  The advantage to handling the MPG in pure software is that no hardware encoder resources are used, no KFLOP Axis Channel Input is required to support the hardware encoder, and any input pins can be used.

The MPGSmoothHardwareEnc.c example is written to use a Hardware Encoder Input.  This allows input speeds up to 1MHz with out any assumptions on limited acceleration.   However the MPG must be wired up to a hardware encoder input an a KFLOP Axis Channel Must be configured as Input Mode Encoder with the corresponding Encoder Input Channel.  The example assume your configuration settings do this.   The MPG_INPUT_AXIS must be defined to be the Axis channel assigned to this role.

HTH

Regards

TK 

 


From: "'Russ Larson' rdlarson@... [DynoMotion]" <DynoMotion@yahoogroups.com>
To: DynoMotion@yahoogroups.com
Cc: 'Mark Vogel' <mlvogel@...>
Sent: Wednesday, June 18, 2014 3:52 PM
Subject: [DynoMotion] MPGSmoothHardwareEnc.c

 

 

Tom,

 

Question, we have been working on the C file MPGSmoothHardwareEnc.c and it does not appear to be a complete application.  Perhaps we missed something but unlike the C program MPGSmooth.c , there does not appear to be any defines in the program that identify the two phases of the MPG coming from the hand held pendant.  Are we missing something as it does nothing when you combine and download into KFLOP?

 

 

Russ Larson

 

 

 

 

#define QA 26   // define to which IO bits the AB signals are connected

#define QB 27  

 

 

 

 

 

 

 

#include "KMotionDef.h"

 

// Example Init program that includes "smooth" MPG motion example

// which makes use of the exponential motion command.

 

#define MPG_INPUT_AXIS 6

 

 

 

 

 

 

 

On 6/17/2014 12:55 AM, Tom Kerekes tk@... [DynoMotion] wrote: