Pulsar124 Wikia

Troubleshooting1

Sign in to edit

Compilation issues[]

Since I introduced the Telescope Focuser mode, the program size became larger, and there is a chance you will run out of program space when trying to compile the code. The possible fixes are:

  • Upgrade your Arduino IDE to the newest version (1.6.11 or better). Modern IDE generates a better optimized code. This can save you ~2kB in program space.
  • You can free up 166 bytes of program space and 56 bytes of RAM by commenting out the line #define BATTERY_BITMAPS in stacker.h
  • Make sure #define SHORT_ERRORS is uncommented - this will free up 172 bytes of program space and 140 bytes of RAM.
  • If everything else fails, you can sacrifice accuracy by hardwiring your BigEasyDriver to use 8 microsteps/step, updating the corresponding parameter N_MICROSTEPS. This will allow you to set COORD_TYPE to short in stacker.h, which will free up 1408 bytes of program space and 26 bytes of RAM. As a bonus you can now set your maximum rail speed to 5 mm/s (SPEED_LIMIT_MM_S and SPEED_LIMIT2_MM_S).

LCD issues[]

LCD screen is empty (blank)[]

Perhaps an issue with hardware SPI[]

Test this by uncommenting this line in stacker.h: 

#define SOFTWARE_SPI

If LCD is still blank after the change, the issue is not with hardware SPI.

If on the other hand it does fix the LCD issue, try to lower the SPI frequency by replacing this line in stacker.ino, 

 SPI.setClockDivider(SPI_CLOCK_DIV8);

with this one: 

 SPI.setClockDivider(SPI_CLOCK_DIV16);

If it doesn't help, just stick with the SOFTWARE_SPI option - LCD will be slower, but it shouldn't interfere with the rail operation.

Could be an issue with hardware (RC) reset[]

Starting from h1.2 reset of the LCD is done via hardware - an RC delay circuit (R10=47 k, C2=0.1 uF). My LCD works with a wide range of RC parameters (R10=30k ... 650k with C2=0.1uF), but perhaps your LCD is very different and requires totally different reset delay. Experiment with smaller and larger values for R10, and perhaps C2. Warning: C2 should not be an electrolyte capacitor (they won't work in this RC delay circuit)!

If for some reason the RC delay circuit doesn't work for you, and if you don't plan to use the rail with batteries, you can use the battery sensing Arduino pin (A0) to drive the RST pin of the LCD screen - instead of the RC delay circuit. You'll have to do the following changes:

  • Remove the RC circuit (R10, C2), and the voltage divider (R3, R4, C1).
  • Connect the RST pin of the LCD via 10k resistor to the pin A0 of Arduino.
  • In stacker.h, change "#define PIN_BATTERY A0" to
#define PIN_LCD_RST A0
  • Also in stacker.h, comment out the following line:
// const short PIN_LCD_RST = 100;
  • In status.ino (battery_status() function), replace this line
float V = (float)analogRead(PIN_BATTERY) * VOLTAGE_SCALER;

with the following one: 

const float V = SPEED_VOLTAGE + 0.01;
  • Uncomment the line 203 in pcd8544.cpp:
pinMode(reset, OUTPUT);
  • Uncomment the lines 224-226 in pcd8544.cpp:
digitalWrite(reset, LOW);
delay(1);
digitalWrite(reset, HIGH);

You can see the text, but LCD screen is too dark or too light[]

Starting from s0.12 I increased the LCD contrast. If the contrast is too high (you only see a black square) or too low, you can adjust it by modifying the current value, 0x47 (a hexidecimal number; larger value means higher contrast), on line 234 in pcd8544.cpp: 

command(PCD8544_VOP | 0x47);


Rail issues[]

After a software upgrade, weird things happen[]

For example, rail doesn't stop after hitting one of the limiters, or some parameters have crazy values.

The solution: do a factory rest (press "#*" keys combo). Sometimes two in a row factory resets are required.

Motor skips some steps[]

This is manifested by fairly loud clicking noise when the rail is moving. It happens when the motor doesn't have enough of torque to move the camera.

First, make sure the tiny pot on your EasyDriver is set to the maximum current your motor + AC adapter can handle; see Question 3 at the bottom of this page: http://www.schmalzhaus.com/BigEasyDriver/ . The best way is to set TP1 voltage to the value I*0.88, where I is the current limit per coil you want to set with the pot. In my case, my 12V 1.5A AC adapter coped until I set V_TP1 to ~1.23V (corresponds to 1.4A per coil), at higher values the controller behaved erratically (turned itself on and off). The TP1 voltage should be measured with the motor unit disconnected from the controller.

If that doesn't solve the issue - perhaps the rail has some mechanical issues (it takes too much effort to turn the focusing knob), or the alignment of the motor shaft with the focusing knob is not great.

Finally, the batteries you are using might be not very good, or need to be recharged. Test if using an AC power solves the issue.

If all else fails, you can mitigate this problem by reducing the SPEED_LIMIT_MM_S parameter in stacker.h. You can also try to hardwire the BigEasyDriver motor driver to use larger microsteps (by default it is using the smallest microsteps - 16 per step); make sure you update the N_MICROSTEPS parameter in stacker.h accordingly. (You will lose positional accuracy with this mod.)

Limiting switches behave erratically[]

Some people reported erratic behaviour of the limiting switches (e.g. fake switch triggering, at some random locations on the rail). This was traced down to the EM interference between the motor wires and signal (switchers) wires in the cable connecting the controller to the rail. Potential solutions for this:

  • Try another cable. Some of my cables had this issue, while others didn't.
  • Try wrapping an end of the cable around a ferrite core.
  • Try placing a 0.1uF capacitor between pin 8 and ground on the Arduino.

Camera issues[]

In continuous stacking, camera doesn't take any shots[]

Perhaps you need to set AF_SYNC to 1 in stacker.h

Another possibility - if you enabled the Mirror lock feature in your camera. If so, you should disable it when using continuous stacking mode. You can only enable it when using non-continuous stacking ("#0" function). In the latter case, make sure the mirror lock parameter is on (*C function).

In continuous stacking, camera ignores the first shot[]

In stacker.h, if AF_SYNC=0 (default), try to increase CONT_STACKING_DELAY value.

Some shots are not taken[]

Perhaps increasing one or more of the following parameters in stacker.h can help: SHUTTER_TIME_US, SHUTTER_ON_DELAY, SHUTTER_OFF_DELAY.

Or could be because your camera doesn't support the current FPS parameter - try to reduce it until the problem goes away.

In software s1.00 and older, some shots might be skipped when using very small mm/frame parameter (<20 um). Upgrade to s1.10 or newer, where this issue was fixed.

Keypad issues[]

One column of keys doesn't work[]

Specifically, if column 2 doesn't work, this might be due to the conflict on the pin 12 used to read that column. Apparently, pin 12 is used internally by the hardware SPI (which in my design is used to control the LCD display). The solution is to use another pin in place of pin 12 (and modify the config file accordingly) - e.g. one could sacrifice the battery status functionality, and use the pin A0 in place of pin 12 to read the keypad: 

// Before:
// byte rowPins[rows] = {4, 7, 12, 6}; //connect to the row pinouts of the keypad
// Now:
byte rowPins[rows] = {4, 7, A0, 6}; //connect to the row pinouts of the keypad

(You'll also need to comment out the line with PIN_BATTERY in status.ino.)

Alternatively, switching to software SPI (by uncommenting the "#define SOFTWARE_SPI" line in stacker.h) should help, though this will result in slower display refresh.

So far I am aware of only one case when this was an issue; it wasn't an issue for many others (including myself).

Community content is available under CC-BY-SA unless otherwise noted.