My bed is 400x400mm 850W Bang bang controlled DC Aluminum 8mm bed. It does expand initially but settles after target is reached and doesn't rise/lower when heater is turned off/on. Temperature fluctuates +/-0.2 Degrees. The heater is turned always on when temperature goes below target temperature, which I don't think is a good way to control temperature via SSR as it connects so rapidly. Is there a way to add hysteresis to bang bang controlled bed (for RRF3.2 / Duet 3)?

My bed heat expansion:
https://youtu.be/tOQ3MXlgEK0

@jay_s_uk
That would work. I just need to change z gcode commands multiaxis commands in gcode but i need to do similar changes anyways for other reasons. Jogging the "real" z height with one press of a button wouldn't be possible with panel due or dwc or can those buttons be changed to take into account other axes?

@fcwilt
That worked! thanks.

I use B5015E24B-BSR fan on my printer. It has high static pressure, which really made it better than few other I tried. Only problem with it is that its quite loud and big (50mm body/frame). I've also noticed that having fan duct go over fan's mouth rather than in it makes it much quieter.

I put voltage divider (10k and 4.7k resistors) between sensor and input on Duet and it seemed to fix the problem.

I solved the issue with first layers (brim) not aligning with body of the part. It was caused by lost steps when tools are switched and the other extruder went to its minimum axis location and hit the other extruder slightly. This only happens with first layer and not with higher layers.

I still have problems with setting offsets. If I calibrate the extruders with any calibration object to correct offsets, offsets on prints will eventually change to something else and a new calibrations is required. This happens relatively randomly and I got about 10 print jobs done with one calibration and after that even the calibration was hard as correcting the values did not give the results it should have.

@fusedeep

https://docs.duet3d.com/User_manual/Troubleshooting/WiFi_troubleshooting

From Duet documentation:
If you are completely unable to connect, you can remove the SD card and edit the config.g files so that the network setup commands are run at startup

@o_lampe

Using text editor or simple post processor seems good option though it adds some extra work if it has to be done everytime seperately. I think I can write a program that does that aswell.

Linearity of air flow likely won't be that important because I usually use the same fan values for the entire print (and all same material prints). One option for valve is just to have two elastic tubing and pinch each of them accordingly with servo to achieve desired flow. Many off the shelf ball valves tend to be quite stiff but they probably would work great too.

I think found the issue: printed parts (ABS) on X- and U-gantries were attached by M3 bolts were loose. The printed part had given in slightly. Weird thing is that it didn't seem to affect one extruder printing (no shifted layers during printing).

@dc42

Thanks. I still need to do some tuning, but I think I'm getting close. It is possible to see some inconsistencies in black parts of the frog (green glitter hides those inconsistencies). I had line width set
to low (0,38) on the frog, which probably causes the issue along with not quite right extrusion multipliers.

I'll probably post more detailed description on my machine on "my Duet controlled machine" -section when I got the time.

@o_lampe

BLDC motors referred by simpleFOC cost more than NEMA 23s or have less power. Can you refer a BLDC motor with sensor that is similarly priced as NEMA 23s and have torque of 2-3 Nm at 300 RPM?

But would slave motors rotate at different if there is no load on them?

I think I'm going to try stuff in following order:

1. Simple signal converter between external cheap driver and signal source. For testing only.
2. Arduino or Duet (these for sure have better features). For testing only.
3. Custom driver boards (this would only be in final version and it's a bit early to think about that).

Getting to the actual testing phase probably takes a lot of time.

@Maestro said in Analog current -> duet -> stepper motor speed:

I think he was thinking that the output from the frequency transducer could be used to directly drive the pulse/step input for an external driver.

That is what I meant. So is this kind of setup possible:

The setup above would be for one time testing the motion. Some other control solution (and components) would probably be much better alternatives. I just need something that works with existing software (which I cannot change) used by rest of the machine.

Frequency limits might be problem, though I think it should be smooth enough for simple test. Jerk and acceleration control would be done by software of the input mA signal.

@dc42 said in Analog current -> duet -> stepper motor speed:

It occurs to me that this may meet your requirement for continuous motion at a selectable speed.

The rollers are constantly moving, but they change rotation directions periodically and do high movement speeds occasionally. Having constant torque is not needed as long the movement stays relatively smooth and requested speeds are followed.

########################################################

I think this could be suitable converter that can directly control an external stepper driver speed: MINI MCR-SL-UI-F.

@T3P3Tony

In the first version RPM of one motor is measured from its shaft and it is used to control all of the motors. The measurement shouldn't be required and it should work just fine without it if motors are chosen correctly and no step losses occur even at max loads. All of the loads in my application are predictable.

I've been trying to google suitable converters. Would any converter do if it outputs pulse at desired frequencies? Does the pulse shape matter?

What I mean by custom drivers is that using something like Duet as final solution to drive the rollers is overkill, but I need 5-8 drivers in a single package (PCB board?) and many of the existing solutions I've found so far seem very expensive or they lack sufficient power. Would it make sense to design custom PCB with 5-8 drivers with 4-5 Amps (perhaps even with signal converter integrated) that has input of 4-20mA for speed and digital input for direction? So no encoder in this type of setup and the production volume would be potentially hundreds yearly.

Current system:
Inputs to stepper drivers/converters:

• 4-20mA speed signal
• digital signal of rotation direction (I don't know yet what voltage)

Output information from motor shaft

• Encoder (I don't know anything about the sensor spefically, but it should not matter if there are plans to get rid of it anyways eventually)

@o_lampe

BLDC motors have low torque at low speeds. In my application stepper motors (vs. for example servos and BLDC motors) have high enough torque at about 0-300 RPM to be used without gearboxes. SimpleFOC seems interesting and I will look into it. Plug and play options would be preferable for the converter. The converter may need to be able to adjust its output to determine speeds (something like this: 4mA -> 0 RPM, 16 mA -> 300 RPM).

@T3P3Tony
@Maestro

Thanks for the responses.

The application is to run 10 rollers that move sheets of materials. In the application driving the rollers do not need to be in real time. Each motor rotates two rollers via timing belt. The accuracy does not need to be as high as in CNC applications (but it still needs to be quite good), but the system needs to be repeatable, smooth and the sheet materials have to maintain predictable position when oscillating several times. The materials and the rollers are heavy and this could be a problem for the drivers when decelerating (duet drivers or external drivers). The roller drive is just for testing proof of concept and probably more refined solution would be used in the end.

I intend to use Nema 23/24 with up to 4A current. Drivers that can do that are a bit hard to find. Duet can run predetermined G-code precisely and has high current drivers. I think it may be possible that simple signal conversion to step direction and pulse may not be accurate enough or has some other issues. Use of the 4-20mA signal would be however convenient as it is compatible with existing software/automation systems. For those reasons I think Duet could be good for my use case as I can test the setup either with external 4-20mA signal + converter + Duet or Duet in standalone mode.

I also found that there are integrated drivers that can be mounted directly onto the motors and they could one solution. If I can prove the concept, could custom driver boards (possibly with signal converters) be a good cost effective solution?

Is it possible to use 4-20mA signal to control speeds of stepper motors connected to Duet 6HC (and expansion boards)? The direction would be determined by digital input. All connected motors would spin at the same rate or if possible at predetermined ratios to one another.

This thread might be redundant if there is already another, although I couldn't find one.

@droftarts

I get:

HTTP is enabled on port 80
FTP is disabled
TELNET is disabled

Is it possible that the servo is broken?
Can incorrect wiring to right pins cause damage to Duet or the servos?
The servos that I have can rotate by hand more than they can by when they are controlled electronically. Do they have to be in certain starting position to work?

M122

M122
=== Diagnostics ===
RepRapFirmware for Duet 3 MB6HC version 3.4.5 (2022-11-30 19:35:23) running on Duet 3 MB6HC v1.01 (standalone mode)
Board ID: 08DJM-956BA-NA3TJ-6J9D2-3S06T-9V8GT
Used output buffers: 3 of 40 (14 max)
=== RTOS ===
Static ram: 152760
Dynamic ram: 98776 of which 400 recycled
Never used RAM 98736, free system stack 206 words
Tasks: NETWORK(ready,35.1%,252) ETHERNET(notifyWait,0.2%,561) ACCEL(notifyWait,0.0%,348) HEAT(notifyWait,0.0%,322) Move(notifyWait,0.0%,351) CanReceiv(notifyWait,0.0%,944) CanSender(notifyWait,0.0%,336) CanClock(delaying,0.0%,333) TMC(notifyWait,7.8%,91) MAIN(running,56.6%,925) IDLE(ready,0.2%,30), total 100.0%
Owned mutexes:
=== Platform ===
Last reset 00:00:55 ago, cause: power up
Last software reset at 2023-01-02 16:44, reason: User, GCodes spinning, available RAM 98736, slot 1
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x00400000 BFAR 0x00000000 SP 0x00000000 Task MAIN Freestk 0 n/a
Error status: 0x00
Aux0 errors 0,0,0
Step timer max interval 127
MCU temperature: min 28.9, current 39.7, max 39.9
Supply voltage: min 24.3, current 24.4, max 24.4, under voltage events: 0, over voltage events: 0, power good: yes
12V rail voltage: min 12.1, current 12.1, max 12.2, under voltage events: 0
Heap OK, handles allocated/used 0/0, heap memory allocated/used/recyclable 0/0/0, gc cycles 0
Events: 0 queued, 0 completed
Driver 0: standstill, SG min 0, mspos 8, reads 46633, writes 14 timeouts 0
Driver 1: standstill, SG min 0, mspos 8, reads 46633, writes 14 timeouts 0
Driver 2: standstill, SG min 0, mspos 8, reads 46634, writes 14 timeouts 0
Driver 3: standstill, SG min 0, mspos 8, reads 46634, writes 14 timeouts 0
Driver 4: standstill, SG min 0, mspos 8, reads 46634, writes 14 timeouts 0
Driver 5: standstill, SG min 0, mspos 8, reads 46634, writes 14 timeouts 0
Date/time: 2023-01-03 11:35:39
Slowest loop: 4.43ms; fastest: 0.05ms
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 25.0MBytes/sec
SD card longest read time 2.4ms, write time 0.0ms, max retries 0
=== Move ===
DMs created 125, segments created 0, maxWait 0ms, bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== AuxDDARing ===
Scheduled moves 0, completed 0, hiccups 0, stepErrors 0, LaErrors 0, Underruns [0, 0, 0], CDDA state -1
=== Heat ===
Bed heaters 0 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 -1, chamber heaters -1 -1 -1 -1, ordering errs 0
=== GCodes ===
Segments left: 0
Movement lock held by null
HTTP is idle in state(s) 0
Telnet is idle in state(s) 0
File is idle in state(s) 0
USB is idle in state(s) 0
Aux is idle in state(s) 0
Trigger is idle in state(s) 0
Queue is idle in state(s) 0
LCD is idle in state(s) 0
SBC is idle in state(s) 0
Daemon is idle in state(s) 0
Aux2 is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty
=== CAN ===
Messages queued 500, received 0, lost 0, boc 0
Longest wait 0ms for reply type 0, peak Tx sync delay 0, free buffers 50 (min 50), ts 279/0/0
Tx timeouts 0,0,278,0,0,220 last cancelled message type 30 dest 127
=== Network ===
Slowest loop: 4.33ms; fastest: 0.03ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
= Ethernet =
State: active
Error counts: 0 0 0 1 0 0
Socket states: 5 2 2 2 2 0 0 0
=== Multicast handler ===
Responder is inactive, messages received 0, responses 0

@achrn said in Hobbyservo controlled part cooling fan (compressor+valve):

I agree with that colour scheme and wiring layout. As previously, I would expect the DC-DC converter to have the 0V in and 0V out connected together internally (if you have a multimeter you could check there's no voltage across them, but I doubt this is the problem).

Tested the difference in voltage and it was 0V.

• try some different S values in M280 (as @droftarts suggests)
• I see the fan is now commented out of the config file, but is anything still physically connected on OUT9? (I don't think it will matter actually, but worth a try disconnecting it if it is?)
• try connecting the orange wire to io7.out and changing the config line to M950 S1 C"io7.out" and M280 P1 S<whatever> (this is just in case something is up with your out9 on the board, from config it doesn't look like you're using io7 yet)

Switching S value didn't work (that were on the product page of the servo), but I might keep trying other values anyways. Nothing is connected to out9 (fan) pin. I changed to io7.out in config and rewired the servo and it behaves the same as before.

Btw how do you differentiate between fan pin out9 and 5V PWM pin out9 in config?
The green arrow points to the pin I've been using as out9.

@droftarts said in Hobbyservo controlled part cooling fan (compressor+valve):

@Visionary try

M98 P”/sys/config.g”

This didn't work either, got the same error.

Almost all servos accept a pulse width range of at least 1us to 2us, which corresponds to an S parameter range of 44.2 to 141.2 degrees. So for many servos, values in the range 44.2 to 141.2 or alternatively 1000 to 2000 will cover the full operating range of the servo.

I didn't realize to check allowed servo angles. I thought they all started at 0 Degrees.
I checked the correct allowed pulse widths for both servos.
I changed to using microseconds in the command, but that didn't work and I got the same result.