Posts made by mkelly

@fcwilt

@fcwilt said in 48v on V_Bed by replacing SMD components?:

@mkelly said in 48v on V_Bed by replacing SMD components?:

I have been using an SSR but it limits the operating frequency and feels unneeded. The SSR being used right now is this one from automation direct

The point of not using an SSR would be to achieve a higher frequency than 50-60Hz, which is what the data sheet lists as the operating frequency for them.

This would also be a way to save costs by not requiring a separate circuit to drive a 48v device, either by an SSR or the mosfet selection I'm proposing.

I do not understand your concerns.

For a bed heater the frequency range you listed is fine. Bed heaters rated for line voltage (110/220 VAC) are usually more powerful which is a good thing.

Since the SSR connects directly to the bed heater output on the Duet it is about as simple as it can be.

What do think you would improve by doing what you propose?

Thanks.

Frederick

Hi Fred. I never said I wanted to be driving a bed heater from the V_bed line, but rather I wanted to drive 48v at a higher frequency (ideally 1-2khz range). This is an exploration at the possibility.

I have been using an SSR but it limits the operating frequency and feels unneeded. The SSR being used right now is this one from automation direct

The point of not using an SSR would be to achieve a higher frequency than 50-60Hz, which is what the data sheet lists as the operating frequency for them.

This would also be a way to save costs by not requiring a separate circuit to drive a 48v device, either by an SSR or the mosfet selection I'm proposing.

I am exploring the possibility of driving 48V on the V_bed rail on a Duet 2 Ethernet. From what I see in the schematics the components that would need replacing are TR2, D5/6, and C91

For TR2 a 60V mosfet could be used instead, such as a IPD031N06L3 G

For D5 I'm struggling to determine what the allowable forward voltage is. The worst case I found was 30V for SOD-523F package, ie RB520S30. But it could also be 75V if it was a 1N4448WT

Looking at a close up of the SMD it appears to have an E2 marking, which makes me think it's a 75V version

I'm also thinking the LED is going to be affected, meaning replacing R65 with an 10k resistor.

For C91 I'm thinking this is easy enough to just replace with another 10uf capacitor (what appears to be a 1206 package) with a higher voltage such as this: CL31A106KBHNNNE

Does this all make sense? Am I missing something obvious?

Granted this is all easy to do on paper, and not something very easily done on an existing board. The first step is just figuring out the circuit, then worrying about how to actually do it.

You were correct, x1 changed to x10 now I'm measuring 5.3V.

For the arduino output has a positive width of 1.78ms(~560Hz)(@ the full 5.3v) with a repetition frequency of 50Hz. Total Pulse width is 20ms

Here's the test code, intended to cycle the servo with a 2s pause:

#include <Servo.h>

Servo myservo; // create servo object

int pos = 0; // variable to store the servo position

void setup() {
myservo.attach(8); // attaches the servo on pin 8 to the servo object
}

void loop() {

delay(2000);
// 120ms to travel 60 degrees
for (pos = 60; pos <= 120; pos += 5) { // travel 60 degrees
myservo.write(pos); // tell servo to go to position in variable 'pos'
delay(10); // waits 10ms for the servo to reach the position
}

Apologies, sorted out the issues with the measurement, now I'm getting a clean signal from the PWM. Here's a picture from the scope with only 500mV being measured on the square wave at 50Hz. I have isolated the wiring to such a degree that there is no chance of faulty wiring, if it was such a simple troubleshoot this wouldn't have taken so many steps to unravel.

This measurement is identical to the arduino controlled version. Which further increases the confusion why driving the servo off the Duet would have any impact on driving a digital servo.

Again here's the chart showing the operability of the servo using the exact same wiring:

I also found a servo catalog chart with something interesting. It specifies the Control circuit for the HS-645MG as "ANALOG" but the HS-7954SH specifies a "G2 DIGITAL" Control circuit. It is not clear if this is referring to the internal control circuit (likely) or something relating to the PWM (unlikely), but perhaps that means something to you.

The other options for the other digital servos in the chart are "G1 Digital", "G2.5 Digital", "HR Digital", "32bit Digital" and "EBL Digital"

At this point all I'd like to know is if anyone has successfully driven a digital servo off of the Duet? I'm thinking it's necessary to use an external circuit to drive the servo since it's taking so much effort to get the Duet to do it.

@dc42

There's too much noise on the scope to get a good reading, but I was just reporting the measurements from the control signal.

Again, the digital servo works fine on an Arduino, which also drives the Analog servo of similar form factor.

The wiring on the duet can drive the analog servo just fine, meaning there's no issues with the wiring from a conductivity standpoint.

The only variable I can't control right now is how the Duet is outputting the PWM signal to drive a digital servo, and I'm not able to confirm if anyone has been successful in driving a digital servo off of a duet.

The arduino is only supplying a measured peak-to-peak 500mV on the control wire when driving the digital servo, the duet is outputting a measured peak-to-peak 1.5V. Both the old analog servo and new digital one operate at 6V on the power, so that's where we're currently set to switch between either option, at least until we get the digital working.

What frequency is the PWM operated at?

Good call, Just tried doing 20 degrees to see, no difference. Looking at the servo datasheet I'm seeing

Operating Travel: 40±5°/ONE SIDE PULSE TRAVELING 400usec
Direction: CLOCK WISE/PULSE TRAVELING 1500 TO 1900 usec

To try and eliminate variables I've also been using an Arduino driving a servo from 0-60°, it did seem to be driving the servo 60 degrees. I recreated the wiring diagram using an external variable power supply and confirmed I am able to drive the digital servo successfully using the voltage regulator and a relay. I confirmed this was true with analogs as well.

Meaning I only had the PWM pin connected to the arduino, and the voltage being driven elsewhere. Grounds were tied together for reference on a breadboard.

Again, with an arduino the digital servo and analogs commanded the correct move position every time

However, when I took this identical wiring arrangement, and only changing the PWM pin going into the PWM on the Duex, I am ONLY able to drive analog servos. The digital one continues to not move.

The only thing I can think of is the PWM frequency between the two devices is different. I'll probably hook it up to an osciloscope to see if I can see the frequency, but at this point I'm pretty compelled of the origin of the issue, and would be willing to go so far as to ship you a digital servo if necessary.

Forgot to upload the config first time. I'm shutting off all the heaters on the Duex just to be safe:
0_1548440073786_config.g

Tested two different analog servos, a little 9g one and the HS-645MG listed in the OP. Both worked without issue.

Still can't get the digital one to trigger.

@dc42

Thanks. Right now we're just running the relay plugged into an always on so we don't have to have another variable

Hey Everyone,

I've been driving servos on my duet for a while now and recently needed more power so I'm trying to get This Digital Servo working. This analog one works just fine in the same setup, but when I plug in the digital it will only move once then buzz.

Since the digital servo draws higher voltage I am running a voltage regulator off of 24v. This regulated voltage is then hooked into an SSR and driven off the duet. The servo will draw 3A at stall, and these regulators are rated for only 3A, so it might be questionable power wise.

The Signal pin for the servo connects to PWM1.

As I mentioned, using this arrangement I don't have any issues driving the analog servo. But when I connect the digital servo in I don't get a response.

Q:

1. From what I understand about digital servos is they should be able to receive the same PWM signal? Is there any reason to believe a digital servo won't work?
2. Could it be that the ground from the voltage regulator is not explicitly grounded to the duet? I presume the grounds on the voltage regulators are the same reference. Edit: I tried joining the grounds, same situation

I can draw up a diagram of the wiring if that's helpful. I've also attached my config settings

Here's the code for my driving the servo>
M280 P3 S0 ; Servo to 0deg
G4 P300 ; Dwell 300
M280 P3 S50 ; Servo to 50deg
G4 P300 ; Dwell 250ms

The story gets weirder...

To verify the digital servo works at all I set up a script in arduino to drive the servo. Verified it with an analog and it worked.

Initially it didn't move the digital servo at all, but once I plugged the 5v output from the arduino into a breadboard, then plugged the digital servo power input to the breadboard as well it started working?! I wouldn't have expected the slight capacitive/resistive change of the bread board to cause any major issues, but after trying to get the servo working without the breadboard there was no success.

Anyways I'm a bit stumped. I'm going to get some capacitors (the 220uF you'd recommended elsewhere) to put in line on the servo power

I recently purchased a duet board and I'm a bit torn as to which printer to put it into. I'm curious what other people would do

Here's the potential donors

Bigbox Dual extruder Kickstarter edition

Pros:

• Would benefit from quieter drivers
• Good platform to make a tool changer / future capability
• Already has working dual extrusion capabilities

Cons:

• Currently prints without major issues
• Already runs Octopi
• Some mechanical improvements needed on the Z
• Extruder is bulky and due for an upgrade

Deltamaker

Pros:

• It's a delta running 8 bit and would benefit the most from 32 bit controller
• Deltas are fun
  Cons:
• Already has Octopi
• Printing shows "Resonance" issue with a benchy, could be a controller issue?
• No heated bed

Z morph 2.0S

Pros:

• Can run a variety of extruders and tools, making best use of the Duet board
• Not already open source, has a bad interface and they refused to offer upgrade possibilities
• If Duet adds closed loop would be best used on this printer

Cons:

• Not many good options for CAM path planning to replace the (underwhelming) native software with
• Some odd design choices in the older versions of the Z morph (2.0s and 2.0sx etc) . Needs machined component replacements
• Closed loop upgrades to the motors will be more critical for doing any light CNC cutting
• May already run 32 bit?

Replicator 2 Modified with Aluminum Braces

Pros:

• Mightyboard is having some issues after a stepper driver popped
• Stepper drivers are loud
• Robust and reliable mechanical platform
• Was being upgraded to a Titan Aero before the failure

Cons:

• Mightyboard may be fine when replacement drivers are installed
• Requires a new PSU or a way to use the old one
• It's a makerbot so it's a bit 'special'

Let me know which one you would pick. I have my favorite but I'm curious what others might select.

I’ll switch to using an external 5v supply to the duex to not overload the onboard and use an M42 instead of the fan

Thanks!

I'm using the buck based off advice from E3D. Running the "fan" fully open:

I did find a "smoking gun" as it were, where the servo wires were exposed through the insulation and were shorting out, The intermittent nature meant it wasn't fully apparent, but I think we can mark this as "Solved" under "wiring issue"

I used 6 for as long as I could, but it just failed. Switched to 5 and used that for a while but now it failed.

All of the lights for the heaters are always enabled now.

Edit: Ok I'm pretty sure the issue is the servo overheated and (i'm guessing) caused the internals to short out to the control pin.

Perfect, thanks for clarifying.

As someone else noted the MCP3204 looks to be the chip you're referring to.

And the code is here: https://github.com/dc42/RepRapFirmware/blob/6b835cb3c8e9aa10113ae750151d9f9065116cd4/src/Heating/Sensors/CurrentLoopTemperatureSensor.cpp#L23
I'll report any more findings as I implement.

Did more testing. Hooked up a smaller servo directly to the pwm outputs. It was able to toggle position as expected on the other positions, including 6. But 7 still does not send out the signal to control the servo.

Also tested with the larger servo with the buck converter, and was able to confirm it worked as expected on 6. I'll be moving the command to run on 6, but I'm really hoping to understand why 7 isn't working anymore. The LED's do illuminate for 3-6(E2-E5) but not 7 (E6)

Well the problem is it's not actually moving through the motion required. And this is definitely abnormal behavior. The jittering is something I've only experienced when our X5 failed.

The add-on buck converter could be an issue, but when I monitor the voltage while enabling the servo I see the voltage drop from 5.18 to 5.11V. This seems healthy enough to me. I'm trying to avoid hooking the servo directly to the 5v board output, because of the lack of timeout from the servo command and also because it pulls quite a bit of current and don't want to pop another onboard 5v converter.

What I find concerning is the 0.8V being output from PWM_5 even when no signal is called and the system has freshly rebooted. PWM_4 is outputting 0.3V as well. PWM 1-3 all show 0v on the signal pin. The 5v rail on the X5 is measuring 4.86v

This to me points that either the Duet is outputting something to heater6 and heater7 or the U9 mosfet driver is bugged. But there's no LED illumination from E5 or E6 heater, which I'd expect.

I swapped in an old (questionable working) X5 to see what it would do, but in this instance both the E5 and E6 lights illumated and the servo didn't respond either.

I've been using the Duet X5 to drive a servo. I've had a couple of issues in the past, but this latest board had been working without issue.

I am powering the servo off of a 24v to 5v buck converter that is enabled from a fan output. The server is being controlled off PWM_5 from the Duex5 board.

I had a weird event on Friday with our AC input that ended up blowing the AC power fuse. I am not clear what happened that caused the event, but after replacing the fuse the system recovered.

I went to test the servo on yesterday, and it doesn't respond as expected and "Jitters" at around the expected position. If I move the servo arm to an off position, it will go close to the expected position as normal, then jitters in place.

Some testing I've done so far:

24v output being measured from the PSU and being input into the Duet and X5
Verified buck converter is outputting 5v
Verified 5v pin on X5 board is outputting correct voltage

Tried measured the input signal to the servo, but I'm only seeing 0.8v on standby, and doesn't change (much) during a state change. I would need to hook it up to a scope to see what the output signal looks like. I'm also not seeing LEDs illuminate on heater 6 and 7 as I'd expect. I also tried a new servo as well.

This is leading me to believe that the culprit is probably the U9 chip 74HCT02.

Is there any additional testing I can do on the U9 chip to verify it's integrity? Some other measurements I could be taking?

I'm going to try switching the servo to run from PWM_3 since that is on U10, but this isn't the first time this has happened to us so I'm curious what we're doing wrong.

Here's the code I'm using to run the servo:
0_1539186435146_Servo_Code.txt

And my config:
0_1539186702888_config (5).g

Thanks,
Mike

I am looking to set up my Duet to monitor a non-contact temperature sensor that outputs 0-5v. There is a linear relationship between temperature and output.

As I understand it, Duet can only currently monitor thermsitors, thermocouples, and RTD style temperature sensors. I believe the RTD comes the closest, but cannot use variables to modify the output like thermistors can.

Thus I think my only option will be to modify the source code to add the conversion equation for my sensor. If this is correct, then any insight into where the ideal place to make this revision would be is appreciated. Otherwise I'll continue exploring the code and making sense of it.

Thanks!
Mike