Connection fails with Octoprint

[McPrince96]

HI,

i've set up my new Rumba32 board and installed it in my printer. I've got Octoprint and Octoscreen installed on a raspberry pi which links to the board througn a usb cable.

My previous board was a rumba+ and connected just fine but this board won't connect to Octoprint. I tried it in the default mode and DFU mode but neither one of them work.

[capibara1]

You will not get any support from Aus3D. I was able to compile Marlin-bugfix-2.0.0 in Nov 2019 just fine. Now can't even compile at all following the exact instructions on the website.
No response from Aus3D for months.

[chrissbarr]

Hi @McPrince96,

Are you able to talk to the RUMBA32 board from a computer over the USB connection (i.e. using any printer host software - Pronterface, Simplify3D, etc?).

I would suggest you need to work out if the firmware on the board is running correctly and communicating over USB - so that you can figure out if it's an Octoprint setting or an issue with the firmware on the board.

DFU mode is only for firmware upload and the firmware will not be running on the board when in that mode - so that won't be a help.

@capibara1 - sorry to hear your experience has not been great. I (Aus3D) haven't been selling these boards for almost a year now while I am working on the next revision. MKS and others have started shipping their own version in recent months and I have been flooded with emails requesting assistance with these boards. I am trying to answer these emails but can only spend an hour or so on them per day, which is often not enough. MKS have modified their version from my design so I have to do extra work to answer those questions. Some emails have slipped through the cracks - feel free to shoot through another email (or open an issue here) and I will try and respond as best I can.

To try and offer some guidance on compilation - I have found that recent versions of Marlin that require the STM32 HAL experience compilation errors in the Arduino IDE on Windows, and that using PlatformIO is the only option that is working for me. If you can provide specific details on the problem you're facing I can offer more guidance.

[McPrince96]

@chrissbarr

i just tried it with Repetier Host and it connects to the printer (button top left is blue) but i get a timeout error.

@capibara1

Try Marlin Auto build in Visual studio code. Worked for me. It did stop working last week but i uninstalled Marlin Auto Build and reinstalled it and it works fine now.

https://marlinfw.org/docs/basics/auto_build_marlin.html

[chrissbarr]

Hi @McPrince96,

Hmm, I'm not seeing any response from the printer firmware in the log there - it looks like Repetier Host opens the serial port, but receives no reply. Are you sure that firmware has been compiled and uploaded to the board? One way to check - Marlin should blink the orange status LED about 4 times per second after it has started running.

If Marlin is running, perhaps it is set to use the wrong serial interface - check Marlin's Configuration.h, and make sure that the serial port is set to -1, which is the USB interface:

#define SERIAL_PORT -1

[McPrince96]

@chrissbarr

That did it! It works now. Thank you for the support!

[McPrince96]

@chrissbarr

Not related question:
I forgot to change the jumpers on my fan 12V select and accidently sent 24V to my 12V fans. Now i don't have any output on the fan pins and the led only lights up a little. (+-50% of the other leds)
Do i have to replace the mosfets?

[chrissbarr]

@McPrince96,

Glad to hear the serial comms are working!

Hmm, not sure on the MOSFET question. I would not expect them to be damaged, but it is hard to say - it depends on the failure mode of the fan to some extent.

If the 24V damaged the fan in such a way that it formed a short circuit, it could have overloaded the MOSFET. In this case, the main fuse should blow to protect the board - but it is hard to guarantee that would happen before damage occurs to the individual MOSFET.

I know some manufacturers have been changing the fuse ratings or types (or omitting them). Most are also using different MOSFETs to the ones I selected, with different characteristics that may behave differently in circumstances like this. So, the behaviour will depend a bit on the specific board you have.

Can you still get the LED to turn on or off if you try and control the fan in Repetier Host? If the LED is stuck on, then it is likely that there is some damage. Depending on how many fans/heaters you need, you can likely remap the fan to use one of the other outputs (let me know if you want info on this).

[McPrince96]

@chrissbarr

The led turns on and off but at a brightness of 50% or even less compared to other leds on the board.
I changed the jumpers to 12V and coneected a new (12v) fan but it does nothing. My multimeter doesn't detect any voltage.

To be honest i got a board from banggood but it has AUS3d written on it. It is however a white board. Sorry i didn't buy one from you but last time (my previous board, rumba+) came from you) i payed almost the same order amount in taxes. Knowing i'm an expert in destroying boards this was just too expensive.

[chrissbarr]

Hi @McPrince96,

No need to apologise! To be fair, I haven't had the RUMBA32 boards in stock for a long time now so even if you had wanted to grab an official one you'd have been in the same spot. Definitely hear what you're saying about taxes - sorry to hear they were so high.

Unfortunately pretty much all of the clone boards have the Aus3D branding on them - I've had more than a few people telling me in recent months that they've bought these from me, much to my confusion. MKS seems to be the exception, they have changed their board more than anyone else and have added their branding too. There's nothing wrong with anyone else making these, and I'm excited to see so many out there - just each manufacturer makes changes to components, and because they don't release a Bill of Materials I can't tell what parts they're using or what their ratings are. It makes troubleshooting issues like this tricky!

White board from Banggood - is it one of these?

If you remove the jumper to select 12/24V, does the LED still turn on and off? If you don't mind using that multimeter a bit more, I can suggest a few points to test.

[McPrince96]

This is my board

The led:

[chrissbarr]

Cool, thanks for the photos! Definitely makes it easier to see what we're talking about, cheers.

I can't see any obvious damage to the MOSFET in either image, but that doesn't say much - sometimes the damage is visible, but not always.

I'd suggest running through a few checks using your multimeter, if you'd like.

Here's an image showing the pins of the MOSFET in the same orientation as your board:

There's a handy guide here that covers a few steps to test a MOSFET. These are N-Channel (NMOS) devices that we're dealing with here. I'd suggest doing the diode test and checking the resistance between Drain and Source. All of these should be done with the power switched off, no power from USB or 24V supply etc.

Are there any of the other HE0/HE1/HE2/F0/F1 outputs that you're not using? If so, let me know which and I can check the firmware change to swap the fan to that pin if you want.

[McPrince96]

I did last 2 methods. I do measure a resistance of 100k instead of 10k between gate and source.

For the last method i don't measure a continuity between drain and source. The MM stays on "1" and doesn't beep. I guess that's good, right?

I don't know how to do the first method with my MM.

[McPrince96]

On the working mosfets i measure 1300Ohms between Drain (red) and Source (black).
I don't get this on the fan mosfets.

I do however measure around 500Ohms when measuring between Drain (black) and Source (red) on both.

[chrissbarr]

Hmm. Those results would seem to suggest that the MOSFET is okay. The different resistances could be explained by the manufacturer using different parts for the heaters vs. fan MOSFETs.

It might be easier to change the fan channel in the firmware and see if the second fan MOSFET behaves the same way as the first, or if it works as expected. You could accomplish this by editing the pins file:

Marlin/src/pins/stm32f4/pins_RUMBA32_common.h

And swapping the FAN and FAN1 pin definitions, from:

#define FAN_PIN   PC9
#define FAN1_PIN  PA8

To:

#define FAN_PIN   PA8
#define FAN1_PIN  PC9

I've just seen this issue in the Marlin repo: MarlinFirmware/Marlin#17519

It looks like there may be a timer conflict in the STM32 core (or Marlin's use of the timers) that clashes with the timer used for PWM on this pin. It would be worth checking if you disable PWM or use the FAN_SOFT_PWM feature as described in that issue, do things start working correctly?

[McPrince96]

I have 2 fans and both fan channels act the same so if one is broken they're both broken. Isn't changing the 2 useless in that case?

[McPrince96]

Edit: Nevermind. I forgot to put the 12V select pin back in. It works now.

I've enabled soft pwm and now the led looks a little bit brighter but not as much as the others. The fan still doesn't spin.

I also have two errors but i don't think they are related.

1. "Err: EEPROm Version"
2. TMC connection error

[chrissbarr]

Hi @McPrince96

Ah, I missed that both fans were not working - sorry, looking back now I see you said that. I thought only one fan had been plugged in at first. You are right, no point in swapping the pins then.

So it sounds like things are working with the soft PWM option now? That's great if so. I'll have to dig into why the default PWM isn't working on these pins and see if the timers can be reallocated in Marlin.

The EEPROM version error shouldn't be anything to worry about - probably just means that no EEPROM settings were found in memory. Saving the EEPROM values (M500) for the first time should clear that. Because EEPROM is emulated in flash, I believe the values will be overwritten and you'll have to do this again if you upload new firmware to the board.

The TMC connection issue sounds like it comes from the SPI defect in RUMBA32 models v1.0E and earlier. This seems to have persisted into all clone boards. If you haven't seen this yet, here are the instructions I put together on fixing this:

Another way of going is if you make a jumper cap that can span the right pin spacing. There's an example in #12 of someone doing this.

[McPrince96]

@chrissbarr

If i do this mod and it turns out it wasn't necessary, will there be a chance of damage?

Edit: took a leap of faith and it was a success. They indeed cloned the defect too. Tried it with only the X axis but now it shows up as OK after a M122 while the others give an All High error. Gonna mod the other ones tomorrow.

Thank you very much for your support! I appreciate it very much.

[chrissbarr]

Hi @McPrince96, just wanted to say I'm glad this mod worked and hope all is up and running now!

I'm going to mark this issue as closed now, but if there's anything else you can either leave another comment and we can reopen it, or if there's something entirely different you're welcome to open another issue.