My FPGA driver board is on the fritz so I'm trying to run my dobot on a RAMPS 1.4 board instead. Previously the FPGA version was working great with 1.3.0, it was moving all was well. To get RAMPS set up I've:
1) Set the microstepping by placing all three jumpers under EACH driver 2) Soldered in the 4.7k ohm driver to hold movement 3) Replaced the off-brand arduino mega I was running with a genuine one 4) Flashed firmware with both the *.sh and using avrdude and the *.hex
Now, my problem is that when I run the example-sdk.py (that works fine with the old FPGA board) it realizes it has a RAMPS board, realizes there are no accelerometers attached and then freezes after printing out everything about Slice #1. No movement, no further action.
I installed the repetier firmware (for a RepRap) and testing code runs all three motors just fine on the same hardware so I doubt it's a driver or board problem.
I've run on a rasp pi and a virtualized ubuntu install to the same effect. Is there something I'm missing or have others seen this as well?
To build and flash RAMPS firmware in *nix (Linux or RPi) you only need to run upload-ramps-version.sh Make sure you have set AVR_DIR and SERIAL_PORT in that script according to where Arduino is installed in your system and serial device Arduino is seen in your system as.
You can opt to flash the pre-built released firmware (*.hex) with avrdude by hand if you like, but you should only do that then, without running any other scripts. So it's either scripts (only one of them, for the corresponding board - fpga or ramps), or avrdude.
You can even build and flash RAMPS firmware with upload-ramps-version.cmd in Windows. If your host OS is Windows you don't need a Linux VM just to work with or build open-dobot.
Yup no problem, for flashing the firmware I've been using the *.sh on both Raspian and Ubuntu (haven't tried from Windows). Other the complaining about an invalid baud rate at the beginning of the script it flashes just fine and then read backs fine, then reports that all three fuses are ok. I only used the *.hex as a last resort to see if that baud rate error was really the problem.
I will go copy the error code it reads back about baud rate, but since it can communicate about the accelerometers and get the board type I assume it was just a warning...
('Initializing with steps:', 0L, 0L, -7999L) ('Reading back what was set:', (0, 0, 0, 0))
Can you try replacing the entire "if" block starting on line 109 in DobotSDK.py with the following lines:
rearAngle = 0 frontAngle = -piHalf
This should skip the step when it tries to initialize accelerometers and immediately get the steps. The point is to make it read back the same as it sets. Not being able to do that means comms problem. This might be because firmware is still trying to initialize accelerometers as was just requested.