FANDOM


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.)

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).

Ad blocker interference detected!


Wikia is a free-to-use site that makes money from advertising. We have a modified experience for viewers using ad blockers

Wikia is not accessible if you’ve made further modifications. Remove the custom ad blocker rule(s) and the page will load as expected.