Advanced Search

Hi tommylight!

We have tested the spinndle idea but the error happens regardless of if its on or off. We use and unshielded cable, let me test that out.

Most probably interference on the SPI wiring, so the first thing would be to make those wires very short, like 10cm short, or use shielded cable.
I would also not bother with the power supply as Octopus has pretty good regulators.
If the machine has a spindle, notice if the error occurs when the spindle is turned on.

we turn on the machine, and all normal

## Entering IDLE state

we open linux cnc and enable the machine

## Entering RUNNING state

x ammount of time passes and this happens

## Entering RESET state
Resetting rxBuffer

disable and we then get this printout

## Entering IDLE state

after that we can enable the machine but the time it takes for it to enter the reset state is much much shorter, like milliseconds

Hello again Scotta!

We've continued testing on the octopus board, we have gotten movement but it seems that the SPI communication with the board seems to keep dying. We got the serial output:

Creating a std module

Remora PRU - Programmable Realtime Unit 

 Mbed-OS6 

 Remora-spi Driver 

## Entering SETUP state
1. Reading json configuration file
Mounting the filesystem... OK
Opening "/fs/config.txt"... OK
Json config file lenght = 1996
Closing "/fs/config.txt"... 
2. Setting up DMA and threads
Initialising SPI1 slave
Initialising DMA for SPI

3. Parsing json configuration file
Config deserialisation - Deserialization succeeded

4. Config threads
Creating thread 40000
Creating thread 1000
Creating thread 57600

5. Loading modules

Servo thread object
Reset pin
Make Reset Pin at pin PC_15

Creating a std module
Creating Pin @
  port = GPIOC
  pin = 15

Servo thread object
eStop
Make eStop at pin PG_12

Creating a std module
Creating Pin @
  port = GPIOG
  pin = 12

Servo thread object
Spindle
Make PWM at pin PB_0

Creating a std module
Creating variable frequency Hardware PWM at pin PB_0
Creating Pin @
  port = GPIOB
  pin = 0

Base thread object
X - Joint 0 step generator

Creating a std module
Creating Pin @
  port = GPIOG
  pin = 2
Creating Pin @
  port = GPIOF
  pin = 9
Creating Pin @
  port = GPIOF
  pin = 10

Base thread object
Y1 - Joint 1 step generator

Creating a std module
Creating Pin @
  port = GPIOF
  pin = 1
Creating Pin @
  port = GPIOC
  pin = 13
Creating Pin @
  port = GPIOF
  pin = 0

Base thread object
Y2 - Joint 1 step generator

Creating a std module
Creating Pin @
  port = GPIOD
  pin = 4
Creating Pin @
  port = GPIOE
  pin = 2
Creating Pin @
  port = GPIOE
  pin = 3

Base thread object
Z - Joint 2 step generator

Creating a std module
Creating Pin @
  port = GPIOE
  pin = 0
Creating Pin @
  port = GPIOE
  pin = 6
Creating Pin @
  port = GPIOA
  pin = 14

Servo thread object
X min
Make Digital Input at pin PG_6

Creating a std module
  Setting pin as No Pull
Creating Pin @
  port = GPIOG
  pin = 6

Servo thread object
Y min
Make Digital Input at pin PG_9

Creating a std module
  Setting pin as No Pull
Creating Pin @
  port = GPIOG
  pin = 9

Servo thread object
Z min
Make Digital Input at pin PG_10

Creating a std module
  Setting pin as No Pull
Creating Pin @
  port = GPIOG
  pin = 10

Servo thread object
Probe
Make Digital Input at pin PG_11

Creating a std module
  Setting pin as No Pull
Creating Pin @
  port = GPIOG
  pin = 11

## Entering START state

Starting the BASE thread
Registering interrupt for interrupt number = 24
    power on Timer 9

Starting the SERVO thread
Registering interrupt for interrupt number = 25
    power on Timer 10

## Entering IDLE state

## Entering RUNNING state

## Entering RESET state
   Resetting rxBuffer

## Entering IDLE state


This last bit is where we are running into a wall, we are not sure what is causing this.
 

Consistent position errors after a long program could indicate a step timing
or polarity issue. Too low direction setup or hold times could cause a lost step
at reversals. Wrong step polarity can also cause this issue as stepping on the
trailing edge of the step pulse (rather then the expected leading edge) will
decrease the expected hold time.

It might be worth either inverting the step polarity or increasing the setup/hold times,
at least to see if it changes anything.

Some of the cheaper fixed bearing blocks are sold with non angular contact bearings, this is something to check.
Until you perform a backlash test, and yes this can manifest as repeatable, you can not rule out a mechanical issue.

Thanks Rod. I'll look into upgrading to 2.10.

Good to hear. I'd suggest slowing down the SPI comms like in the discussion above.

hal
loadrt remora-spi SPI_num=0 CS_num=0 SPI_freq=2000000

ini
#SERVO_PERIOD = 1000000
SERVO_PERIOD = 5000000

Did the subroutine execute?

You could run

halcmd show signal s-index-zero-for-ATC

From the command line to check

No, the actual index pin is not typically used by LinuxCNC

What interface card are you using for the encoder interface?

Is the encoder single ended or differential?

Is  the interface card jumpered to match the encoder type?

Another way to check the low level hardware is to set the index input to
single ended mode, and then watch hm2_7i80.0.encoder.00.input-index
in halshow as you ground the index input on the interface card.
hm2_7i80.0.encoder.00.input-index  should change state when you ground
the +index input pin

(with the encoder unplugged of course)

 

FF0,FF1,FF2 are feed forward terms

FF0 adds a proportion of the PID command to the PID output
FF1 adds a proportion of the PID commands first derivative to the PID output
FF2 adds a proportion of the PID commands second derivative to the PID output

For a simple example imagine a spindle control PID loop
This would have a PID loop with velocity command and velocity output.
Setting FF0 to 1 means that at a say commanded RPM of 3000,  means
that the PID output would be 3000 without any correction from the PID error
term. You can think of the FF terms as a way of centering the operating
point of the PID loop around the current state (rather than having
feedback have to do all the heavy lifting)

 

No, it does not.
I scrolled through the HAl and could not find the hm2_7i80.0.encoder.00.input-index pin linked anywhere. So I assume Linuxcnc does not get this signal- can this be the reason?

If you set x-index-enable high manually, does it get cleared if you jog the axis? 
(enough for one full turn of the encoder)

Beware, this may trigger a following error

Works for me. I use the same potentiometer for jog and feed rate (changes are immediate during jogging and running commands):

I can set it high in HAL-show by pressing the SET button on the right side, but not by homing/tripping the switch.
Also with 1ms division I can not see the index rush by...