Experience RUMBA32 installation (and upload problem)



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
#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
to
upload_port = COM16
And pressed the upload button again. It takes a longer time, ERROR 74 No DFU capable USB device available. FAILED

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.



















Comments

  • 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.
  • edited September 2020
    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
    .





  • 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.
  • 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.
  • edited September 2020
    may be this helps :


    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

  • Also have an AUS3DE Rumba32, mine is Version 1.0.3e and uploading works.
    By the way: V1.0.3e needed a mod, see https://github.com/Aus3D/RUMBA32/issues/34
    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.

  • edited September 2020
    @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





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





  • 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.
  • @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.
  • edited September 2020
    @ karl_ranseier

    Are you aware of the so called EEPROM trap? You'll find it several times 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
    Disadvantage: the experience that you change a parameter in a file and nothing happens.
    Changed parameters in a file are not automatically transferred into the EEPROM.
  • Scottty said:
    @ karl_ranseier

    Are you aware of the so called EEPROM trap? You'll find it several times 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
    Disadvantage: the experience that you change a parameter in a file and nothing happens.
    Changed parameters in a file are not automatically transferred into the EEPROM.

    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.

  • edited September 2020
    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.
  • In this manual one can find the settings for the stepper drivers:
    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?

  • 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.
  • edited September 2020
    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.
  • edited September 2020
    as you wrote above:
    <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.>

    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"

  • 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.
  • edited September 2020
    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?


  • RAyWB said:
    as you wrote above:
    <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.>

    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"


    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.

  • edited September 2020
    Setting:
    STEPPER_SIMPLE(YMotor, IOX1Step, IOX1Dir, IOX1Enable, endstopNone, endstopNone)
    STEPPER_SIMPLE(XMotor, IOY1Step, IOY1Dir, IOY1Enable, endstopNone, endstopNone)
    STEPPER_SIMPLE(ZMotor, IOZ1Step, IOZ1Dir, IOZ1Enable, endstopNone, endstopNone)
    STEPPER_SIMPLE(E1MotorBase, IOE1Step, IOE1Dir, IOE1Enable, 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.

    Setting:
    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)

    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"

    Setting:
    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, IOE2Step, IOE2Dir, IOE2Enable, endstopNone, endstopNone) (note the 2 instead of 1)

    I found the stepper-signal at the E2 when pressing Home x and I found a stepper signal at X when pressing extrude, after I have set "M302 S1".

    Looks like E1 is damaged.

    By the way: If cold extrusion is prevented, there should be any message about that. In the repetier-server, on the display and in the console. I do not see any message in standard operation.








  • From the results I also think that something with E2 step pin is damaged on board. Maybe just a soldering or the pin on the ARM is defect.

    Have added a warning for cold extrusion prevented.
  • Thanks!

    Another problem:

    When Homing Z with the following values in EEPROM:
    Z axis endstop distance after homing: 0
    Z axis min position: 0
    Z axis max position: 160

    there is a problem: repetier server does not read the new position. The z-value is assumed to be 0mm.

    In my case this results in the following:
    Expected correct behaviour:
    - I press HOME Z.
    - Motor goes up till it hits endstop
    - It stays there (or it moeves, if I change Z axis endstop distance after homing to another value; it moves down by this value)
    Unexpected behaviour:
    - Using the position conrol the actual position is 0mm, but my printer is at 160 mm.
    - If I then press "1 mm down", it moves to 0 mm, so 160 mm in my case.
    What I would expect:
    - If I press "1mm down" it moves 1 mm down.

    In my opinion Repetier server should here behave different. After each homing it should read the position or at least assume the new position. If I read the position by M114 it gives the correct value of z 160 mm. But in difference to the repetier host the position in repetier server ist not changed.
    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?
  • New threads for new problems are better also for others to find.

    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.
  • @Repetier why not simply allow or not allow M114 for server by selecting ,
    for example as switch in servers manual control settings.
    from my point of view it would be a nice temporary solution , especially for cnc use
  • edited September 2020
    DELETED
  • edited September 2020
    Ok, I did not see that I have configured that position (I left it out).
    These values are all entered in the EEPROM settings, so why not read them from EEPROM instead of making the user entering it again? Maybe even wit a selection
    1. enter manually
    2. read once from EEPROM
    3. read after every start from EEPROM

    ?
  • We have an option for reading most from eeprom, but that works mainly with V1 firmware I guess. Have to check for V2 string which may differ here. There is also a reread button in configuration so for those wanting that it should then be easy. After every start can have unexpected results - after all users set values and maybe want them different for some reason. But will definitively check the autodetect from V2.

    @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).
  • Yes, I see that now. The typical way may be the following:
    - One installs repetier-server
    - One installs the formware
    - One plays around with his printer and changes many things, because doing everthing correct before having a reacting printer is nearly impossible (at least for selfmade printers).

    So for this an autoreload would makes sense.
Sign In or Register to comment.