Experience RUMBA32 installation (and upload problem)

karl_ranseier

I followed this manual: https://code.visualstudio.com/docs/?dv=win</div><div>on this Board: https://www.amazon.de/gp/product/B08GLDWBJF/</div><div><br/></div><div><br/>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

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

#define MOTHERBOARD MOTHERBOARD_RUMBA32 //3000

briefly before I set NUM_EXTRUDER to 1

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

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

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

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.

Repetier

I have only the original RUMBA32 but sounds similar. To upload a firmware it must be in DFU mode. So first enter boot mode then the NEOPIXEL starts slowly blinking indicating boot mode. Only then hit the arrow button to compile and upload. Once you have firmware installed you can also send M9999 to enter boot mode.
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.

karl_ranseier

When I press RESET-BOOT and release RESET the LED1 flashes once, than nothing flashes.

As I said, the COM16 disappears. What I had not recognized is that "STM Device in DFU Mode" at USB-Controller appears. Still Visual Studio says:

Match vendor ID from file: 0483
Match product ID from file: df11
No DFU capable USB device available
*** [upload] Error 74

Is there any way to show in visual studio the recognized / connected devices?

On my Win7 system two things are found: RUMBA32_F446VE CDC in FS Mode (when LED1 is flashing and Board is in normal mode) and STM32 BOOTLOADER (when LED1 is not flashing and the Board is set by RESET-BOOT...). On my Win10 system I do only find "STM Device in DFU Mode".

In the details I find "Geräteinstanzpfad" (no idea how to translate it) : USB\VID_0483&PID_DF11\STM32FXSTM32
.

Repetier

Ok so switching to DFU mode is working. The uploader expects only one device in that mode and searches for a usb device with just that vid/pid. So main question is why it does not find it when windows shows the device. Does windows show it as known or unknown device?

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.

karl_ranseier

It is found as a known device. Thanks for that hint, I do have a pi laying around which I may try after using google more intensive.

RAyWB

may be this helps :

https://www.youtube.com/watch?v=AeaglOYphfc</div><div><br/></div><div>I remember i had similar problems on Win10 , but as it´s long ago I´m not shure what the solution was.

As zadig is still present on my computer i think this was the solution

BTW i use RUMBA32 from aus3d 1st version , no plagiate

Scottty

Also have an AUS3DE Rumba32, mine is Version 1.0.3e and uploading works.
By the way: V1.0.3e needed a mod, see <a rel="nofollow" target="_blank" title="Link: null">https://github.com/Aus3D/RUMBA32/issues/34</a></div><div>The error results in having no single flash. It works after the mod. Newer versions don't need this mod.

One single LED1 flash after pressing RESET-BOOT and release RESET is correct.

Then, watching the win10 device manager: "Com<x>" disappears and "STM32 BOOTLOADER" in group "Universal Serial Bus devices" will be shown.

If this is the case, R32 is in DFU mode and win10 has recognized this.

The rest should be VSCode confiuration.

Working with VSCOde and platformio:

1) In platformio.ini I have this Rumba32 environment:

[env:RUMBA32]

platform = ststm32

framework = arduino

board = RUMBA32_F446VE

build_flags = ${common.build_flags} -DSTM32F4xx -DARDUINO_RUMBA32_F446VE -DARDUINO_ARCH_STM32 "-DBOARD_NAME=\"RUMBA32_F446VE\"" -DSTM32F446xx -DUSBCON -DUSBD_VID=0x8000 "-DUSB_MANUFACTURER=\"Unknown\"" "-DUSB_PRODUCT=\"RUMBA32_F446VE\"" -DHAL_PCD_MODULE_ENABLED -DUSBD_USE_CDC -DDISABLE_GENERIC_SERIALUSB -DHAL_UART_MODULE_ENABLED -DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256 -Os

src_filter = ${common.default_src_filter} +<boards/STM32F4>

upload_protocol = dfu

Hope this helps a bit.

karl_ranseier

@RAyWB

I followed the video instrictions. The devide is now found as USB-device instead of controller and is named "STM32 BOOTLOADER". Upload worked!

BUT: Now I cannot find the device anymore. No LED is flashing. USB PWR Led is on, 5V and 3V LED, too. Display shows nothing. Disconnecting, connecting, resetting did not help.

UPDATE: Now it is found on COM17. I have no idea why it suddenly appears. Repetier-Server said it has found the rinter and wants me to configure it, which I will do now.

Before the hint of RAyWB I tried the hint of RAyWB I tried the ideas of Scotty:

@Scotty : My Version is V1.0D

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:

[env:RUMBA32]

platform = ststm32@8.0.0

framework = arduino

board = RUMBA32_F446VE

build_flags = ${common.build_flags} -DSTM32F4xx -DARDUINO_RUMBA32_F446VE -DARDUINO_ARCH_STM32 "-DBOARD_NAME=\"RUMBA32_F446VE\"" -DSTM32F446xx -DUSBCON -DUSBD_VID=0x8000 "-DUSB_MANUFACTURER=\"Unknown\"" "-DUSB_PRODUCT=\"RUMBA32_F446VE\"" -DHAL_PCD_MODULE_ENABLED -DUSBD_USE_CDC -DDISABLE_GENERIC_SERIALUSB -DUSBD_PID=0x5740 -DHAL_UART_MODULE_ENABLED -DSERIAL_RX_BUFFER_SIZE=256 -DSERIAL_TX_BUFFER_SIZE=256 -Os

src_filter = ${common.default_src_filter} +<boards/STM32F4>

upload_protocol = dfu

platform_packages =

framework-arduinoststm32@4.10900.200819

Using your env the following error appears:

C:\users\flori.platformio\packages\framework-arduinoststm32\cores\arduino\stm32\usb\usbd_desc.c:46:4: error: #error "USB VID or PID not specified"
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

Scottty

Regarding ""USB VID or PID not specified"":

For using version ststm32 V8 repetier need to perform some modifications first.

In the meantime, I went back to version 6.1.1 and this compiler error did not happen.

Regarding version 1.0D and the resistor: at my board (V1.0E) entering the DFU mode worked for a while and then suddenly stopped. Electronical: one input is floating.
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.

My win 10 device manager shows "STM32 Bootloader" when in DFU mode.

I also followed https://github.com/Aus3D/RUMBA32/wiki/Entering-USB-DFU-Mode

karl_ranseier

Now I am getting some results. The full graphic display from my Rumba works, the one delivered with the Rumba32 not. That may be a setting, but I prefer the full graphics display anyway.

I connected heated bed and thermistor as the first test. Because of my DIN A3 size heated bed is slow. Standard setting for "bed1 decouple test period" is 30000ms. I increased it to 60000ms. Still after 30 seconds the heater stopped. I tried this 3 times by changing the value to others (61000ms and so on). It did not help.

I reloaded the EEPROM-site by pressing F5 in Firefox. The loaded value was 30000ms. Obviously the value was not stored. In addition I noted, that "Bed1 I min part" was now decimal data instead of integer, as I realised by 2.00 instead of 2 (I add here some text to make clear, that the point does not belong to the digit 2).

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.

Repetier

@Scottty
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.

Scottty

@ karl_ranseier

 
 
 <div>
 <span>
 <br/></span></div><div><span>Are you aware of the so called EEPROM trap? You'll find it several times here.<br/>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.<br/>Advantage: you have permanent parameters, which can be changed without a new compilation</span></div><div><span>Disadvantage: the experience that you change a parameter in a file and nothing happens.<br/>Changed parameters in a file are not automatically transferred into the EEPROM.<br/> </span>
 </div>

karl_ranseier

Scottty said:

@ karl_ranseier

 
 
 <div>
 <span>
 <br/></span></div><div><span>Are you aware of the so called EEPROM trap? You'll find it several times here.<br/>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.<br/>Advantage: you have permanent parameters, which can be changed without a new compilation</span></div><div><span>Disadvantage: the experience that you change a parameter in a file and nothing happens.<br/>Changed parameters in a file are not automatically transferred into the EEPROM.<br/> </span>
 </div></div>

Dear Scotty,

yes, I am, but it is always good to be reminded on that. At the moment I set up ecerything from the beginning and will do many changes in the firmware. Maybe at one point I will wonder why some changes have no effect ;-).

What I explained above happened using the config-page, so working on the eeprom values.

karl_ranseier

I reproduced the error with the EEPROM: If there was an error, like decoupling of temperature, one cannot write the EEPROM. This makes in my opinion no sense, because there might be errors, which might arise from wrong EEPROM settings. It should either be mentioned that the EEPROM cannot be saved before you entered M999, or better it should be saved even if an error stopped the operation.

karl_ranseier

In this manual one can find the settings for the stepper drivers:
https://raw.githubusercontent.com/Aus3D/RUMBA32/master/Resources/Manual/RUMBA32%20V1.1%20User%20Manual%20-%20REV%20A.pdf<br/><br/>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?

Repetier

I see you are changing EEPROM with something like Repetier-Server. Once firmware is in failure mode and requires M999 it ignores all commands it receives except M999 so it is correct that setting eeprom will not work. In fact I expect also M205 to get the values to fail here - except if it was already loaded before the error.

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.

karl_ranseier

About EEPROM:
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.

RAyWB

as you wrote above:

i guess you fried the Driver. DRV8825 die immediate when mounting in wrong direction.

fried myself around 10 pieces the last two years while "ich probier kurz"

Repetier

In configuration extruders like all C++ arrays start with 0. On eeprom we use names starting with 1 which is more natural to normal users and also matches much better to extruder numbering you see in most host softwares. So that is intentional.

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.

karl_ranseier

4.:

Steps per mm: 495.000

Yank: 5.00 mm/s
max speed: 30mm/s

acceleration: 300 mm/s²

advance: 10steps/mm

3./2.:
In configuration_io.h I found:

STEPPER_SIMPLE(XMotor, IOX1Step, IOX1Dir, IOX1Enable, endstopNone, endstopNone)

STEPPER_SIMPLE(YMotor, IOY1Step, IOY1Dir, IOY1Enable, endstopNone, endstopNone)

STEPPER_SIMPLE(ZMotor, IOZ1Step, IOZ1Dir, IOZ1Enable, endstopNone, endstopNone)

STEPPER_SIMPLE(E1MotorBase, IOE1Step, IOE1Dir, IOE1Enable, endstopNone, endstopNone)

Is it correct to change them to

STEPPER_SIMPLE(E1MotorBase, IOX1Step, IOX1Dir, IOX1Enable, endstopNone, endstopNone)

STEPPER_SIMPLE(YMotor, IOY1Step, IOY1Dir, IOY1Enable, endstopNone, endstopNone)

STEPPER_SIMPLE(ZMotor, IOZ1Step, IOZ1Dir, IOZ1Enable, endstopNone, endstopNone)

STEPPER_SIMPLE(XMotor, IOE1Step, IOE1Dir, IOE1Enable, endstopNone, endstopNone)

just to switch E0(board numbering) and x-movement?

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?