Experience RUMBA32 installation (and upload problem)
I followed this manual: https://code.visualstudio.com/docs/?dv=win
on this Board: https://www.amazon.de/gp/product/B08GLDWBJF/
This is a logfile of what I have done. I really wrote down every step, to be sure to have them when in trouble.
About the steps:
1. as described in manual: no problem
2. as described in manual: no problem
3. as described in manual: no problem, but it is named PlatformIO IDE which every user should be able to select
4. as described in manual: C/C++ extension was already installed on my fresh installation; When you search for Clang-Format the forst result is a clang format adapter, the second one is called Clang-Format and seems to be the right one. Anyway that is only needed for developers, what I am definetly not.
5. Download Firmware here: https://github.com/repetier/Repetier-Firmware/tree/dev2 (I have copied it to c:\Daten\repetier-firmware
6. as described in manual: Open Folder
7. In platformio.in I changed
default_envs = due
to
default_envs = RUMBA32
( 7. In the blue toolbar I clicked the checkmark. It may take a while to install the toolchain and compile. In my case 3 minutes. It failed. )
8. In configuration.h I replaced line 43
#define MOTHERBOARD MOTHERBOARD_FELIX // 405
by
9. In the blue toolbar I clicked the checkmark. SUCCESS
10. connecting the RUMBA32 using USB hub with external power supply I clicked the arrow to the right in the blue tool bar, it FAILED.
11. using hardware monitor I was looking for the USB Comport. In my case it was 16. I checked it by disonnecting the RUMBA32. Com16 was removed. reconnecting RUMBA 32 it appeared again. So I changed in platformio.ini the line
; upload_port = COM1
to
upload_port = COM16
And pressed the upload button again. It takes a longer time, ERROR 74 No DFU capable USB device available. FAILED
12. Here: https://github.com/makerbase-mks/MKS-RUMBA32/commit/aba3aa49b1653495a665d865eac59e0401e824bd ; I found
Setting to DFU mode:
USB connect MKS RUMBA32, press and hold the "BOOT" button, then press the "RESET" light strip for more than 1S, release "RESET", and then release "BOOT".
--> The COM16 is gone and LED1 on RUMBA32 does not flash anymore
USB connect MKS RUMBA32, press and hold the "BOOT" button, then press the "RESET" light strip for more than 1S, release "RESET", and then release "BOOT".
--> The COM16 is gone and LED1 on RUMBA32 does not flash anymore
--> flashing does no work
--> RESTART: COM16 appears
--> Upload Failed
Tried connecting the board without adapter, but via USB3.0 It did not work.
13. Checked the warnings:
If I set upload_port = COM16:
Warning! Ignore unknown configuration option `upload_port` in section [platformio]
When I do not set it:
No DFU capable USB device available
*** [upload] Error 74
*** [upload] Error 74
Independent from whether I switched as described in 12 to DFU or not.
14. I think I need to check what the delivery status of that board is and what I do have to do for the very first installation.
Or if I am doing something stupid, let me know.
Comments
There is no need to press reset 15 seconds. Just press Boot pin then Reset and release reset first then release boot. Now pixel should flash and in windows hardware manager you should see a device with vid 0x0483 and pid 0xDF11 which is the stm chip in DFU mode.
Match product ID from file: df11
No DFU capable USB device available
*** [upload] Error 74
.
Maybe when you google "platformio windows No DFU capable USB device available" you find more answers. I'm using it under mac and linux with success. If you have Repetier-Server Pro you can also try with that uploading. It has also the dfu-util uploader but that is the same software as used by platformio. But if you have it installed on a pi you can use it from there.
By the way: V1.0.3e needed a mod, see https://github.com/Aus3D/RUMBA32/issues/34
As I found here: https://github.com/Aus3D/RUMBA32/releases there are enough reasons to directly change to a newer version instead of having trouble using the old one. Especially because of the filtering, which is needed because of the huge size of my printer with long cables. Using Rumba I added some filters by myself within the connectors.
Anyway I added the resistor. Win takes much longer to find the device as COM. When I switch to DFU it takes longer than before, but the the board is found as an unknown USB-device. Removing one side of the resistor it still takes some time to finde the device, but is is found as "STM Device in DFU Mode". Resoldering the resitor it was found as "STM Devide in DFU Mode".
Just for comparison the original version of the env, which differs in the flags and platform / platform_packages:
Using your env the following error appears:
46 | #error "USB VID or PID not specified"
| ^~~~~
In file included from C:\users\flori\.platformio\packages\framework-arduinoststm32\system\Middlewares\ST\STM32_USB_Device_Library\Core\Inc/usbd_core.h:30,
from C:\users\flori\.platformio\packages\framework-arduinoststm32\cores\arduino\stm32\usb\usbd_desc.c:21:
C:\users\flori\.platformio\packages\framework-arduinoststm32\cores\arduino\stm32\usb\usbd_desc.c:160:10: error: 'USBD_PID' undeclared here (not in a
function); did you mean 'USBD_VID'?
160 | LOBYTE(USBD_PID), /* idProduct */
| ^~~~~~~~
C:\users\flori\.platformio\packages\framework-arduinoststm32\system\Middlewares\ST\STM32_USB_Device_Library\Core\Inc/usbd_def.h:275:32: note: in definition of macro 'LOBYTE'
275 | #define LOBYTE(x) ((uint8_t)((x) & 0x00FFU))
Compiling .pio\build\RUMBA32\FrameworkArduino\wiring_analog.c.o
| ^
*** [.pio\build\RUMBA32\FrameworkArduino\stm32\usb\usbd_desc.c.o] Error 1
When the problem appears, the LED1 does not flash after the button combination and DFU mode is not entered.
The resistor should only help to enter the DFU mode safely.
I believe, the resistor will not influence the speed, when windows detects the DFU mode.
I tried it again (changing value, storing it, reloading it), than it worked. I cannot reproduce this problem, but it might be interesting for others.
Latest github version now works and requires ststm32 V8, but it is set as mandatory so platformio will automatically install and use it, so nothing to do here.
Every parameter, which is stored in EEPROM, can ONLY be changed by changing the EEPROM-Value. Changing the value in a configuration file has no effort.
Advantage: you have permanent parameters, which can be changed without a new compilation
Changed parameters in a file are not automatically transferred into the EEPROM.
https://raw.githubusercontent.com/Aus3D/RUMBA32/master/Resources/Manual/RUMBA32 V1.1 User Manual - REV A.pdf
I do not use SPI yet. I used the 16times microstepping.
I have set the jumpers according to DRV8825 in the manual page 18. I mounted the driver in the given orientation which I double checked. I even tried it with 180° rotation. The only thing I hear is that the motor is switched on (those noise of ac current in a magnet), but it does not move the extruder, when I have heated up to 180°C and try to extrude 10 mm. I have not connected any other motordrivers yet. The driver is connected to E0. Jam detection is disabled. Current setting is used from the old setup and is correct.
Any ideas?
Have you tried inverting enable signal? Some drivers need enable high some low to work. So it might also be that you heard disabling the motor.
Use M302 S1 to allow cold extrusion for testing empty extruders.
Correct, I use repetier-server. Sorry that I did not mention this (clear enough). I thought I did.
I would suggest that if you prefer this behaviour, that there should not be the message "stored" or "success".
Back to the extrusion-problem:
When I start extrusion, I hear the continous sound of the motor. The noise becomes stronger, when I increase the current by rotating the resitor on the driver. The noise goes off, when I switch of the motors.
In addition the fan of the power supply goes on when I try to extrude and off, when I switch of the motors. Therefore I conclude that current is flowing when I try to extrude, meaning the enable-pin is set correctly.
The M302 S1 was a good advide, thanks. That increases testing speed.
I use the E0 extruder on the board, but the firmware says E1.
I connected ans oscilloscope to the enable pin: it is changed by three V depending on the state.
I connected it to the step-pin: the value is constant 0V.
Although I have not yet connected the xyz-motors, i connected the oscilloscope to the x-Motor step-pin. There I do see the clear steps, when I press "home x" in the firmware.
Next description is using the full graphic display controller:
- Sending Home x shows again the step-signal on my oscilloscope.
- Changing connection Board/Oscilloscope to Extruder
- Trying to move extruder turning the knob and pressing: nothing happens. The value on the display is not changed. No warning appears neither on the display nor in the repetier-server console.
When current gets too high motors start making sounds as well I think. Since you measured with oszilloscope the step input signal as I understand the problem sounds more like missing step signals. I see 4 possible reasons:
1. Wrong pin number. Double checked the one in configuration and it is same as for marlin so guess that is ok.
2. Broken line/defect pin output on board. Try in second extruder socket and see if it works.
3. Some internal constrain prevents extruder motor from being moved but I only know the temperature constraint. You can try switching x motor to E0 socket since you know homing sends signals when x motor moves. That also shows if the step line is functional.
4. Steps per mm/acceleration/jerk in eeprom have an illegal value.
Regarding server - yes I also find the current situation not perfect with M999. Need a better solution to mark a printer as in error state so it more obvious.
max speed: 30mm/s
3./2.:
In configuration_io.h I found:
edit: that using the display-controller does not change the displayed value sounds like an software problem, not a broken wire, or am I wrong?
It is a compatible driver which obvously is not sensitive to that. I did that before, nothing happened. I will keep that in mind if the error is not gone after I "found" the step-signal.
STEPPER_SIMPLE(YMotor, IOX1Step, IOX1Dir, IOX1Enable, endstopNone, endstopNone)
I found the stepper-signal at the Y-Step-Pin when pressing Home X. There was no signal on X-Step-Pin when pressing Home X. --> seems to be the correct way to change the pins.
I found the stepper-signal at X-Step-Pin when extruding and no signal at E-Step-Pin when pressing Home X, after I have set "M302 S1"
Have added a warning for cold extrusion prevented.
Another problem:
When Homing Z with the following values in EEPROM:
there is a problem: repetier server does not read the new position. The z-value is assumed to be 0mm.
- I press HOME Z.
- Motor goes up till it hits endstop
- If I press "1mm down" it moves 1 mm down.
Another solution: When using the "x mm down" option before each of this operations the actual position should be read.
By the way: do you want me to go on like this in this thread or create new threads for each problem?
In server you have configured homing position which is assumed after G28. Problem is you have set it to 0 so server assumes 0 after homing so going home to 0 is correct. Enter 160 there and it would work.
We do not use M114 responses at the moment. The problem is that they are not reliable due to asynchronous command execution. When we have 5 commands queued for which one does it explain the coordinates? I know G28 sends the coordinates for some firmwares at least when finished. But how do I know it is a position and for which of the send commands it was valid. That is why we require the user to enters the correct homing position so we have a correct internal representation. The problem might be solved when we send explizit M114 with waits preventing new commands so we are sure. But tricky solutions tend to always have some unseen problems.
?
@RAyWB
I'm thinking of adding a awaiting position response flag. Until received it would block all following commands. That would ensure we know where it comes from and if set we assume it to be a position if it contains all coordinates (because temperature responses also have X: and Y: on some firmwares).