Posts made by Eric

Hello Ian,

These work thanks! It's maybe a good idea to update the documentation.

With regard,

Eric

Hello Duet team,

I cannot find the stop 10 and 11 pins in the pin names dictionary for the duet WIFI
https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview#Section_Pin_names

They are in the stepper channel 10 and 11
https://duet3d.dozuki.com/Wiki/Duet_Wiring_Diagrams

What are the names for these? "stop 10" and "stop 11"? Thanks in advance!

With regards,

Eric Wieland

Hello Tony, Thanks for your reponse. Any idea how the firmware would react to very high values like displaying pressure in pascal (1bar is 100000 pascal) or Kpascal. If i use absolute pressures the values that i need should be in the range of 50 to 150 kpascal. I assume that this should be fine for the firmware?

Thanks for the fast responses. So with A flyback diode the mosfet should survive?

Hello All,

I recently burned the mosfet of the bed heater while using it to power a bigger DC motor with PWM (1.5 A current at 12v).

We will probably replace the mosfet or use other outputs but it would be nice to protect these ones properly.

What would be aquadate protection for the mosfets when driving coils like motors or solinoids? Would a Diode do the trick?

It is clear that protection is needed for PWM out put is is also needed for simple on and off outputs (like solinoids)?

Thanks in advance for the answers!

Hello Duet team and Co users,

I am currently building a fuildhandiling robot with a duet Wifi and a DUEX5.

There are serveral cases here where it would be nice to controll air flow and air pressure with the duet.

It should be possible to use the M308 with Y parameter Y"linear-analog" to define any kind of sensor that has a 0 to 5v output.

But is it also possible to couple an PWM output controll loop to this?

For example using a simple on/off controll to keep a pressure in a certain range.
Or using PWM on an air pump to maintain a certain flow measured form a gas flow sensor.

Is this possible? And how do i set it up?

Thanks in advance for your responses!

It looks like one of the possible fixes is a 10uf capacitor to tone down the noise as i can easily implement that i will try that.

Thanks for the help to everyone

Yes I can be happy that the CPU still works after this... Tony and Co make a very robust board

The switches are normally open. But as these are used to detect the
presence of a tool and they are activated a lot of the time.

Strangely if i use the E5_Stop and E6_stop connectors there is no problem. And i am planning to use the other two connectors with setups that will not have any electromagnetic interference as they will be used as buttons on the controller (confirm/continue and pause button).

I am confident that the CPU is still working. As webcontroll is working normally.

But i did measure 4.96 volt on both the endstop 3.3v pin and the probe 3.3v pin. I could not find the Vref pin.

stupid me... i just found the problem... There was an used crimp terminal lodged in the solder pins of the expansion connector.... So much for keeping a clean work place

I narrowed down the other issue (connectivity to web controll lost) to the E2_STOP and E3_STOP pins. If there are end stops connected to these and the small steppers are powered the connectivity to the duet is lost. This is either damage form the short or an an cross talk issue between the steppers lines and the end-stop lines.

Could i reduce the noise on these by adding small (ceramic) capacitors over the end-stop lines? With a low capacitance this should have a minimal effect on the homing accuracy.

@droftarts

The 3.3v rail measures 4.9v so there is indeed a short between the 5 and 3.3v rails.

Apart form external equipment what damage does this do to the board? And would this damage also extend to the DEUX5?

Should i write of the board and expect weird issues if i use it? Or is their a likely cult-print and an component replacement that can be done to fix these issues?

@Phaedrux

Good info i see i missed a very important point there. I am planning to drive the DUEX5 at a different Vin (12v instead of 24v) that the DUET. Currently the setup is not jet in the the final controller and i indeed made the mistake to not connect the grounds of the duet and the DUEX together with a separate wire. I have only tested driving a single pump en a few endstops with the duex 5 so far but it could be that the damage is done.

The measured Vin at the terminals of the duex is 23.8v

@Ian,

Thank for the info. I will check the reference voltage on the board on Monday as i am working from home today.

As for the other issue do you know anything that could cause web control to become unresponsive from driving a stepper? But still lets planned G Code be executed?

These issues started popping op after a badly crimped connection on the X axis caused the stepper driver to report that only 1 phase was driven. Strangly the error happens when i drive one of the other 3 axis. As i said before i have some small 15mm steppers connected to these:

Hello All,

I have been having some weird issues with a duet wifi that i am currently configuring for a machine that i build (a fluid handling robot for operation in a laminar down flow cabinet). I have already ordered a new duet but i want to fix potential issues as to no fry another duet.

First the MCU is reporting strange readouts in voltage and temperature:

The voltage should be 24v and the temperature is obviously false. Earlier before i disabled all heaters i did also see reported temperatures of 2000°C which is also bull as i do not have temperature sensors connected.

In the second more important issue: the DUET web control is becoming unresponsive if i move certain axis. I have 3 mini axis driven by M3 lead screws 15mm 16 step steppers that pull 0,5A. If i move one of these web control disconnects but the WIFI signal stays up. This is very weird as i have several days of testing without this issue. Furthermore its just web control that crashes if i run the home all command all axis home without issues even though small problematic axis home before the x and y axis. The problem is not in G code execution and the axis seem to be wired fine otherwise the homing commands would not work.

Some back ground on the design which may point to some issues:

The system once finished will use a separate controller which is connected using a 64 pin ribbon cable which connects into a breakout board which splits in the different connections on the duet. There is another breakout board on the X carriage that connects the different motors and end stops. As this introduces extra connectors and points of failure i triple checked all connections and they are fine. However this makes the cable length very long (~2m).

To get enough power to the X and Y motors they are all double wired and a 24v power supply is used. The smaller steppers use only one lead each.

The connected hardware:
X axis 2.5A stepper (set for 1500ma)
Y axis double 2.5A stepper connected in series (set for 1500ma)
3 mini linear actuators of which two move with different tools in the Z axis and one will be configured as a mini syringe pump

On the DUEX 5 at 12v
5 peristaltic pumps driven by stepper motors which are (not yet connected)
3 additional endstops for the small axes to check if tools are present.
1 electromagnet driven by an H bridge controlled by three fan pins (not yet connected)
3 solenoid valves that i want to drive with fan/led outlets these pull 0.66A at 12v
3 1.5A air pumps that i want to drive with heater outlets Is it possible to run motors this powerfull on the heater outlets? Or is the EM noise to much?

Thanks in advance for the helpfull responses!

With regards,

Eric Wieland

Diagnostics if it helps...
M122
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 3.1.1 running on Duet WiFi 1.02 or later + DueX5
Board ID: 08DGM-9T6BU-FG3SJ-6J9DD-3SN6P-TVYRG
Used output buffers: 3 of 24 (15 max)
=== RTOS ===
Static ram: 27980
Dynamic ram: 93836 of which 56 recycled
Exception stack ram used: 264
Never used ram: 8936
Tasks: NETWORK(ready,460) HEAT(blocked,1456) DUEX(suspended,160) MAIN(running,1880) IDLE(ready,80)
Owned mutexes:
=== Platform ===
Last reset 00:01:40 ago, cause: power up
Last software reset at 2020-08-27 15:01, reason: User, spinning module GCodes, available RAM 8728 bytes (slot 3)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task MAIN
Error status: 0
MCU temperature: min -71.4, current -64.4, max 235.8
Supply voltage: min 15.4, current 15.6, max 15.8, under voltage events: 0, over voltage events: 0, power good: yes
Driver 0: standstill, SG min/max not available
Driver 1: standstill, SG min/max not available
Driver 2: standstill, SG min/max not available
Driver 3: standstill, SG min/max not available
Driver 4: standstill, SG min/max not available
Driver 5: standstill, SG min/max not available
Driver 6: standstill, SG min/max not available
Driver 7: standstill, SG min/max not available
Driver 8: standstill, SG min/max not available
Driver 9: standstill, SG min/max not available
Date/time: 2020-08-27 15:30:01
Cache data hit count 173840482
Slowest loop: 7.99ms; fastest: 0.12ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0, resets 0
=== Storage ===
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest read time 4.0ms, write time 0.0ms, max retries 0
=== Move ===
Hiccups: 0(0), FreeDm: 169, MinFreeDm: 169, MaxWait: 0ms
Bed compensation in use: none, comp offset 0.000
=== MainDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== AuxDDARing ===
Scheduled moves: 0, completed moves: 0, StepErrors: 0, LaErrors: 0, Underruns: 0, 0 CDDA state: -1
=== Heat ===
Bed heaters = -1 -1 -1 -1, chamberHeaters = -1 -1 -1 -1
=== 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
Daemon is idle in state(s) 0
Autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 15.75ms; fastest: 0.00ms
Responder states: HTTP(2) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0), 0 sessions
HTTP sessions: 1 of 8

• WiFi -
  Network state is active
  WiFi module is providing access point
  Failed messages: pending 0, notready 0, noresp 0
  WiFi firmware version 1.23
  WiFi MAC address 62:01:94:2e:1b:47
  WiFi Vcc 4.36, reset reason Unknown
  WiFi flash size 4194304, free heap 23264
  WiFi IP address 192.168.1.11
  Connected clients 1
  Socket states: 0 0 0 0 0 0 0 0
  === DueX ===
  Read count 3, 1.79 reads/min

This does not work see my earlier post where i wrote:

I currently try to set the following maximum and minimum speeds according to: https://duet3d.dozuki.com/Wiki/Gcode#Section_M203_Set_maximum_feedrate
M203 X600.00 Y600.00 Z600.00 U600.00 V600.00 I0.01
but the machine keeps the default 30 mm/min

I have firmware 2.03

Yea i already though about going to steps per micro or nano meter I would however prefer to stay with mm.

So if i switch to laser mode the M203 command might use the I parameter? i can try that.

I specify the feed rate with the G1 command however i cannot go lower than F30 as it is below the firmware minimum speed.

I currently want to use the M203 command to lower this minimum speed.
I use M203 X600.00 Y600.00 Z600.00 U600.00 V600.00 I0,01 to set max and minimum speeds.

However the I parameter is not working as the minimum speed stays at 30 mm/min instead of going to 0,01mm/min.

And i have an additional question. Is it possible to turn of the Pythagorean path length calculation for the speed? If i now move the x and y axis 10mm simultaneously the firmware precieves this as a move of ~14mm.
so a move G1 X10 Y10 F10 takes 1,4 minutes instead of 1 minute.

For this project it would be great if that could be turned of. This is already the case for the u and the v axis.

Here is the complete axis configuration i am using:
; Axis and motor configuration
M569 P0 S0 ; physical drive 0 goes backwards
M569 P1 S0 ; physical drive 1 goes backwards
M569 P2 S0 ; physical drive 2 goes backwards
M569 P3 S0 ; physical drive 3 goes backwards
M569 P4 S0 ; physical drive 4 goes backwards
M584 X0 Y1 Z2 U3 V4 ; set drive mapping
M350 X256 Y256 Z256 U256 V256 I0 ; configure microstepping without interpolation
M92 X40960.00 Y40960.00 Z40960.00 U40960.00 V40960.00; set steps per mm
M566 X60.00 Y60.00 Z60.00 U60.00 V60.00 ; set maximum instantaneous speed changes (mm/min)
M203 X600.00 Y600.00 Z600.00 U600.00 V600.00 I0,01 ; set maximum speeds (mm/min)
M201 X900.00 Y900.00 Z900.00 U900.00 V900.00 ; set accelerations (mm/s^2)
M906 X700 Y700 Z700 U700 V700 I30 ; set motor currents (mA) and motor idle factor in per cent
M84 S1 ; Set idle timeout
M564 S0 H0 ; Allow movement without homing and outside the axis range
G91 ; Set to relative positioning

;

Hello All,

I now have a DUET Wifi connected to 4 syringe pumps. However i am running into a snag. I need much lower minimum speeds.

I currently try to set the following maximum and minimum speeds according to: https://duet3d.dozuki.com/Wiki/Gcode#Section_M203_Set_maximum_feedrate
M203 X600.00 Y600.00 Z600.00 U600.00 V600.00 I0.01
but the machine keeps the default 30 mm/min

I could increase the steps per mm 10 fold to make it steps per centimeter but i would like a more flexible solution.

Thanks in advance for your help.

With regards,

Eric Wieland

Thanks that sounds good and it should work.

Thank you that is already very helpful. Do you know if it is possible to define more heater loops like the heated bed?