Not listing as a USB device?

[Pukington]

Hey all. I've had this board a few days and am trying to work out the kinks.

I've found the fact the 5v rail on the board is a pos so my bltouch has slammed the buildplate more than once when homing, but another issue I'm having is the fact it doesn't show up as a usb device to send firmware to it.

The printer connects, I get a comm port and can send commands to it from pronterface, but no usb device to send firmware. I guess it's not a be-all/end-all type but it's rather annoying as that's what its suppose to do. I've tried updating the drivers but my win10 system insists its got the best already installed and if i do update, still no dice.

Any ideas?

[chaoticchoas]

It depends on what version of marlin you are trying to use. If you are using the latest version of marlin 2.0.x you will need to go to platformio.io file and where you see "default_envs = STM32F103R_bigtree" and edit that so that it's "default_envs = STM32F103R_bigtree_USB". If you are using BTT fork of marlin then I'm not %100 sure but you can try editing the build_flags to so that it includeds "-DUSE_USB_COMPOSITE"

[Pukington]

@chaoticchoas Thanks for the reply. I feel a bit stupid as saw the _usb variant but hadn't occurted to me to try it. I tried many times to get the current Marlin bugfix to work but failed, when it finally compiled without errors the printer would have issues. When I auto-homed, it would send x and y axis into the wrong direction to the end of the gantries and keep trying. I'd rather have vanilla marlin as this repo is a few months old, do you have it configured and working? If so I'd love a look to see where i've gone wrong.

I succcesfully managed to setup the BTT fork with my BLTouch, and once I added a capacitor between GND and VCC its working very well.

[chaoticchoas]

If your axis are moving in the wrong direction I would go into configuration.h and search for INVERT_X_DIR and change what ever axis is moving in the wrong direction. I will upload my files so that you can what I edited.

[chaoticchoas]

This fork should be pretty much what I have for marlin. The 3 file you want to look at are platformio.io, Configuration.h and Configuration_adv.h since that all I edited. I was also having trouble with my bl touch(3d touch since it is a clone) but I think I fixed it by just enabling BLTOUCH_FORCE_SW_MODE. I disabled BLTOUCH_SET_5V_MODE but I'm not too sure if that did anything or not.

[ghost]

@Pukington Where on the board did you add the capacitor, and which size?

[Pukington]

@thubot I just soldered a 100nF ceramic capacitor between vcc and gnd pins on the three wire BLTouch lead. Try enabling BLTOUCH_FORCE_SW_MODE in configuration_adv.h first, quite a few people have said that works without having to use a capacitor at all. I've just enabled it and will upload the fw when my next print has finished.

Here's where I added the capacitor if you choose to do it though.

[Pukington]

@chaoticchoas Thanks mate, I've just gotten back into this and it's now working on Vanilla 2.0 bugfix, question for you though. Did you use the Z-Stop pins for the BLTouch or did you use the Probe pins? I was just reading the BLTouch thread in the git of the E3Mini issues and someone changed the pins in pins_BIGTREE_SKR_E3_DIP.h so they could use both the Z-Endstop as a backup and the Probe pins. Yours are the same as mine so wondering which you plug your Touch into?

[chaoticchoas]

@Pukington I used the z endstop pins since it was easier for me to do it that way at the time. Bigtreetech support did mention this

#define SERVO0_PIN PA1 , PA1 Define the control port (with PWM output port, different output ports, different names)

which I am assuming is to get the probe pins to work.

[ghost]

Can someone here do me a favor and take a look at their board to see if the FAN0 LED lights up on their board while probing, or if that's just me?

I noticed this while debugging my 3DTouch/BLTouch clone which completely misses the trigger point very often:

The green LED on my board next to the FAN0 connector lights up whenever a servo command is being sent to the probe. I assumed it was either a hardware design problem (interference between PCB traces) or a manufacturing problem, but:

• when I comment out #define FAN_PIN in pins_BIGTREE_SKR_E3_DIP.h, the LED doesn't light up and the probe works perfectly, even at high probing speeds

• when I uncomment #define FAN_SOFT_PWM in Configuration.h, the LED doesn't light up and the probe works perfectly, even at high probing speeds

That makes me think that this might be a Marlin bug (I use the latest bugfix-2.0.x), maybe because the hardware PWM for the fan and the servo system are trying to use the same timer. If it's not just me, I'll file a bug report for Marlin.