Hard estop during segment motion

38 views
Skip to first unread message

Pierre Giusti

unread,
Jun 3, 2020, 8:28:55 AM6/3/20
to beagleg-dev
Hello everyone,

According to this commit : https://github.com/hzeller/beagleg/commit/9e947d2bb40480101f655c1b959f74ef375b6210 (Add support to the PRU code to check the EStop input before each step..), I thought that for all kind of command (G28, G0, G1, G2 ...) motion would be aborted (without any delay)  if hard estop is triggered. It is not working for me with motion commands like G0, G1, G2 ...
However it is working during homing cycle : if I send a G28 command and then trigger estop then motion is aborted immediatly.
I'm not really confortable with PRU programming and I am not sure to understand well the implementation of CheckForEStop function in hardware configuration file pru-io-routines.hp so I try two compilations, one with pru-io-routines.hp based on CRAMPS implementation, and another based on VGEN5 where I change pin mapping according to my hardware.
In the first case hard estop works fine with homing but nothing happens with other motion commands, estop is not detected. Furthermore when beagleg is idle and estop triggered I can see estop log in console.
In the second case nothing happens anymore with any command (no motion), eventhough I can still see estop log in console.
Any help will be appreciated..!
Pierre

Hartley Sweeten

unread,
Jun 3, 2020, 11:15:14 AM6/3/20
to Pierre Giusti, beagleg-dev

Pierre,

 

Did you also modify the pru-io-routines.hp CheckForEStop function based on you hardware configuration?

 

That routine currently needs to be hard coded based on the input you have your Estop connected to. The VGEN5 board has the Estop connected to IN_7_GPIO (GPIO_0_BASE | 27).

 

You will either need to modify the VGEN5 function or add a similar implementation to the CRAMPS function.

 

Hartley

--
You received this message because you are subscribed to the Google Groups "beagleg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/6db1d618-cf6a-4278-805e-5bd65bc82498%40googlegroups.com.

Pierre Giusti

unread,
Jun 3, 2020, 11:48:32 AM6/3/20
to beagleg-dev
Hartley,
Thank for your answer

 

Did you also modify the pru-io-routines.hp CheckForEStop function based on you hardware configuration?

 

That routine currently needs to be hard coded based on the input you have your Estop connected to. The VGEN5 board has the Estop connected to IN_7_GPIO (GPIO_0_BASE | 27).

 
Yes I did, I have copied the vgen5 pru-io-routine.hp and I changed the input IN_7_GPIO to IN_4_GPIO according to my hardware... 

 

You will either need to modify the VGEN5 function or add a similar implementation to the CRAMPS function.


What do you mean by modifying the function, is there anything else than changing input definition ? 

Pierre


 

Hartley

 

From: beagl...@googlegroups.com <beagl...@googlegroups.com> On Behalf Of Pierre Giusti
Sent: Wednesday, June 03, 2020 5:29 AM
To: beagleg-dev <beagl...@googlegroups.com>
Subject: Hard estop during segment motion

 

Hello everyone,

 

According to this commit : https://github.com/hzeller/beagleg/commit/9e947d2bb40480101f655c1b959f74ef375b6210 (Add support to the PRU code to check the EStop input before each step..), I thought that for all kind of command (G28, G0, G1, G2 ...) motion would be aborted (without any delay)  if hard estop is triggered. It is not working for me with motion commands like G0, G1, G2 ...

However it is working during homing cycle : if I send a G28 command and then trigger estop then motion is aborted immediatly.

I'm not really confortable with PRU programming and I am not sure to understand well the implementation of CheckForEStop function in hardware configuration file pru-io-routines.hp so I try two compilations, one with pru-io-routines.hp based on CRAMPS implementation, and another based on VGEN5 where I change pin mapping according to my hardware.

In the first case hard estop works fine with homing but nothing happens with other motion commands, estop is not detected. Furthermore when beagleg is idle and estop triggered I can see estop log in console.

In the second case nothing happens anymore with any command (no motion), eventhough I can still see estop log in console.

Any help will be appreciated..!

Pierre

 

--
You received this message because you are subscribed to the Google Groups "beagleg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev+unsubscribe@googlegroups.com.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev+unsubscribe@googlegroups.com.

Hartley Sweeten

unread,
Jun 3, 2020, 12:02:51 PM6/3/20
to Pierre Giusti, beagleg-dev

Pierre,

 

Not sure what the issue is.

 

Please send a diff of your change.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.


Le mercredi 3 juin 2020 17:15:14 UTC+2, Hartley Sweeten a écrit :

Pierre,

 

Did you also modify the pru-io-routines.hp CheckForEStop function based on you hardware configuration?

 

That routine currently needs to be hard coded based on the input you have your Estop connected to. The VGEN5 board has the Estop connected to IN_7_GPIO (GPIO_0_BASE | 27).

 

You will either need to modify the VGEN5 function or add a similar implementation to the CRAMPS function.

 

Hartley

 

From: beagl...@googlegroups.com <beagl...@googlegroups.com> On Behalf Of Pierre Giusti
Sent: Wednesday, June 03, 2020 5:29 AM
To: beagleg-dev <beagl...@googlegroups.com>
Subject: Hard estop during segment motion

 

Hello everyone,

 

According to this commit : https://github.com/hzeller/beagleg/commit/9e947d2bb40480101f655c1b959f74ef375b6210 (Add support to the PRU code to check the EStop input before each step..), I thought that for all kind of command (G28, G0, G1, G2 ...) motion would be aborted (without any delay)  if hard estop is triggered. It is not working for me with motion commands like G0, G1, G2 ...

However it is working during homing cycle : if I send a G28 command and then trigger estop then motion is aborted immediatly.

I'm not really confortable with PRU programming and I am not sure to understand well the implementation of CheckForEStop function in hardware configuration file pru-io-routines.hp so I try two compilations, one with pru-io-routines.hp based on CRAMPS implementation, and another based on VGEN5 where I change pin mapping according to my hardware.

In the first case hard estop works fine with homing but nothing happens with other motion commands, estop is not detected. Furthermore when beagleg is idle and estop triggered I can see estop log in console.

In the second case nothing happens anymore with any command (no motion), eventhough I can still see estop log in console.

Any help will be appreciated..!

Pierre

 

--
You received this message because you are subscribed to the Google Groups "beagleg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "beagleg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/337c3209-6c91-4d93-8e6d-7a1c9f6b4a55%40googlegroups.com.

Pierre Giusti

unread,
Jun 3, 2020, 12:17:20 PM6/3/20
to beagleg-dev
Here is a diff between vgen5 original pru-io-routine.hp and mine :

                
18c18                                  
<       MOV r4, (IN_7_GPIO & 0xfffff000)
---                                    
>       MOV r4, (IN_4_GPIO & 0xfffff000)
22c22                                  
<       MOV r5, (IN_7_GPIO & 0x1f)     
---                                    
>       MOV r5, (IN_4_GPIO & 0x1f)     

Hartley Sweeten

unread,
Jun 3, 2020, 1:18:53 PM6/3/20
to Pierre Giusti, beagleg-dev

Pierre,

 

Can you send your beagle-pin-mapping.h file?

 

Also, what is the active polarity of you Estop input. On VGEN5 it’s active level is HIGH (it’s a N/C switch to GND).

 

Hartley

 

From: beagl...@googlegroups.com <beagl...@googlegroups.com> On Behalf Of Pierre Giusti
Sent: Wednesday, June 03, 2020 9:17 AM
To: beagleg-dev <beagl...@googlegroups.com>
Subject: Re: Hard estop during segment motion

 

Here is a diff between vgen5 original pru-io-routine.hp and mine :

--

You received this message because you are subscribed to the Google Groups "beagleg-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.

Pierre Giusti

unread,
Jun 3, 2020, 3:06:36 PM6/3/20
to beagleg-dev
Hartley,

Here is my beagle-pin-mapping.h :

// Motors

#define MOTOR_1_STEP_GPIO  PIN_P9_31  // X_STEP
#define MOTOR_2_STEP_GPIO  PIN_P9_29  // Y_STEP
#define MOTOR_3_STEP_GPIO  PIN_P9_28  // Z_STEP

#define MOTOR_1_DIR_GPIO   PIN_P9_27  // X_DIR
#define MOTOR_2_DIR_GPIO   PIN_P9_41  // Y_DIR
#define MOTOR_3_DIR_GPIO   PIN_P9_25  // Z_DIR

// Inputs (Available 1-9)

#define IN_1_GPIO          PIN_P8_7   // IN0 - X home (min)
#define IN_2_GPIO          PIN_P8_8   // IN1 - Y home (max)
#define IN_3_GPIO          PIN_P8_9   // IN2 - Z home (max)
#define IN_4_GPIO          PIN_P8_17  // IN3 - ESTOP

// Outputs (Available 1-16)

#define AUX_1_GPIO         PIN_P8_18  // SPINDLE



My Estop is active LOW...
By the way estop definition in my .config file is :

switch_4 = active:low e-stop

Do you think I should change QBBC to QBBS in debounce loop in pru-io-routine.hp ?

Pierre.


Le mercredi 3 juin 2020 19:18:53 UTC+2, Hartley Sweeten a écrit :

Pierre,

 

Can you send your beagle-pin-mapping.h file?

 

Also, what is the active polarity of you Estop input. On VGEN5 it’s active level is HIGH (it’s a N/C switch to GND).

 

Hartley

 

From: beagl...@googlegroups.com <beagl...@googlegroups.com> On Behalf Of Pierre Giusti
Sent: Wednesday, June 03, 2020 9:17 AM
To: beagleg-dev <beagl...@googlegroups.com>
Subject: Re: Hard estop during segment motion

 

Here is a diff between vgen5 original pru-io-routine.hp and mine :

 

                
18c18                                  
<       MOV r4, (IN_7_GPIO & 0xfffff000)
---                                    
>       MOV r4, (IN_4_GPIO & 0xfffff000)
22c22                                  
<       MOV r5, (IN_7_GPIO & 0x1f)     
---                                    
>       MOV r5, (IN_4_GPIO & 0x1f)     

--
You received this message because you are subscribed to the Google Groups "beagleg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev+unsubscribe@googlegroups.com.

Hartley Sweeten

unread,
Jun 3, 2020, 4:38:19 PM6/3/20
to Pierre Giusti, beagleg-dev

Pierre,

 

The active low Estop is probably the problem. The PRU code doesn’t know about the switch_4 active state.

 

The estop detect in the PRU is kind of a hack for now. The PRU code needs to be hard-coded to correctly handle the input and state.

 

So, yes, changing the QBBC and a QBBS will probably fix your issue.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.

--

You received this message because you are subscribed to the Google Groups "beagleg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleg-dev/66985816-3378-4f78-80b6-dcba0d072084%40googlegroups.com.

Pierre Giusti

unread,
Jun 4, 2020, 3:05:35 AM6/4/20
to beagleg-dev
Hi Hartley,
I have tryed it quickly this morning, and it seems to be working !
Thanks a lot for you help!
Pierre

Here is my complete pru-io-routines.hp  with step by step comments on PRU code, maybe it will help someone :

;;; -*- asm -*-
;;; Specific PRU routines.

;; Just use the generic ones.
#include "../../src/pru-generic-io-routines.hp"

// HARDCODED function to check the E-Stop input
// IN_7_GPIO (GPIO_0_BASE | 27) is the dedicated E-Stop input
//
// NOTE: two reads are done for a minimal debouce
//
// Available registers:
// r0 = used to return the E-Stop status (0=ok, 1=E-Stop active)
// r4 = Start adress of the GPIO registers : here 0x44e07000 (GPIO_0_BASE)
// r5 = Adress of the EStop input bit in register :  27(d)
// r6 = GPIO_DATAIN register adress

CheckForEStop:

   
/* Definitio of gpio read register and estop input bit adresses */

   
// Get the start adress of the gpio registers
   
// IN_4_GPIO = GPIO_0_BASE | 27(d) = 0x44e07000 | 27(d) = 0x44e0701b

    MOV r4
, (IN_4_GPIO & 0xfffff000)

   
// r4 = 0x44e07000

   
// If r4.w2 == 0 then no estop pin is defined so jump to estok_ok
    QBEQ estop_ok
, r4.w2, GPIO_NOT_MAPPED

   
// Define in r5 GPIO_DATAIN (gpio reading) register adress
    MOV r5
, GPIO_DATAIN
   
// r5 = 0x138

   
// Define in r4 the complete adress of gpio0 reading register (r4 + r5)
    ADD r4
, r4, r5
   
// r4 = 0x44e07000 + 0x138 = 0x44e07138

   
// Define in r5 the estop input bit adress  

    MOV r5
, (IN_4_GPIO & 0x1f)

   
// r5 = 0x44e0701b & 0x1f = 0x1b (27d)

debounce
:

   
/* Reading of the input (double check if estop_active) */

   
// Copy 4 bytes (starting from 0) from r4 to r6
    LBBO r6
, r4, 0, 4
   
// r6 = 0x44e07138
   
   
// Jump to estop_ok if bit at adress r5 in register at adress r6 is set.
   
// !! Warning !! Here we have an input with active state low so estop is not active
   
// when bit is set. If an active high input is used then change QBBS to QBBC
    QBBS estop_ok
, r6, r5

   
// If previous debounce loop has set r0 = 1 then jump to estop_active
   
// and exit debounce loop
    QBEQ estop_active
, r0, 1
   
   
// If both previous jump failed, first edge of estop input has been detected so
   
// set r0 = 1
    MOV r0
, 1

   
// Loop on debounce
    JMP debounce

estop_ok
:
   
// If estop input is not active make sure that r0 = 0
    MOV r0
, 0

estop_active
:
   
// End of function
    RET



To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev+unsubscribe@googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "beagleg-dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email to beagleg-dev+unsubscribe@googlegroups.com.

Reply all
Reply to author
Forward
0 new messages