After a couple of very long days I'm not sure what I was thinking asking that question.
How do you suggest we proceed with the duet 3 prototype?
After a couple of very long days I'm not sure what I was thinking asking that question.
How do you suggest we proceed with the duet 3 prototype?
Wow sounds nice.
You mentioned 10 heater and fan outputs on the main board, is that 10 heater and 10 fan or 10 total for heaters and fans?
That falls in line with our schedule. Do you have a list of supported items for the main board and available prototype slave boards? Depending on what is currently supported in prototype we may have to adjust our prototype to fit and that should be learned sooner rather than later if possible.
Also is there any current weaknesses in functionality compared to the Deut 2 functionality.
Yes I was just reading your previous post thinking we have an endstop for each stepper. We could on some of steppers use stall detection but I'm not sure we could take that to production.
I don't think a few weeks would hurt to wait, currently we have a stack of raspberry pi's/odroids etc handling a few steppers/end stops manually controlled with buttons for testing.
When do you expect the duet 3 goes into full production? Or more important when do you expect it to be available to go into a production device?
Hello dc42,
Thanks for the response.
The prototype build is underway and once complete assuming we can work out all the hurdles we will start manufacturing it in a few different models. We have been working on the prototype for a number of months and feel we can get it to operational in 30-60 days.
Firmware updates are something we can normally handle the concern is not ability it is duration to take everything apart, learn it well to be able to modify it properly without messing up other modules. The possibility of course is with some direction and information of the area that is "safe" to modify without messing up other modules. Electronics talent is a bit weak not non existent just weak. We planned to leverage duet hardware since it was already developed and has the best possibility to handle our needs. You got my interest on a second duex 5, this would get phase 1 completed with what sounds like less effort.
I have been reading what I could find on the duet 3, sounds like it is a ways out yet with testing can bus and its different versions to get effective control speeds in the communications. Part of my thoughts was on how the duet 3 code was written to handle movement of data to slave boards and was a possibility that part of the needs were there already with a different interface that would need to be changed.
Since we are building a prototype and proof of concept I'm not thinking there is any remotely convincing case other than is other people looking for similar needs to drive the case.
An option I did not mention is to turn all duet/duex into slaves and drive them with gcode only via a custom middle man. A concept like octoprint but build to deal with command parsing to different slaves. That is fairly easy I think but does require more expense since another processor board is needed with a couple of ethernet ports to isolate the slaves.
I have not seen any data on how to connect the "extra" 2 stepper external drivers. Although 4 external drivers likely cost as much or more than another duet that has 5 drivers on it.
in our prototype/proof of concept 15 each with its own home switch, this would have 6 heaters. 3 steppers are X/Y
in our full build it would be 28 steppers with homing and 18 heaters. 3-7 steppers are x/y, 14-16 heaters
Hello,
We are working on a prototype that has a need for a lot of stepper motors / heaters and end stops. I'm sure there are many with that need. We have been looking into the source code to see what could be possible and may have found a way but it could be a large can of worms for us to add due to not being intimately involved in the code.
The thought of course is use one duet2 as master (with or without a duex) and multiple duet2 as slaves. The duet2 slaves would simply receive gcode commands from the master on non timing critical functions. For example Z home or any Z move since Z moves are always (??) command and wait for completion and not timing critical like X/Y/feeders.
There are a fair number of not as critical functions like heaters, fans etc that would be under full control at the slave board and not really require high speed monitoring by the master since the slave has it under control.
On items like the Z axis completely moving to a slave since I think it is non timing critical a series of verification commands would ensure movement and error handling like get position, cmd move, wait for complete, as position, verify it moved then continue tools for next layer. Z hop could send Z move during retract and not wait until after retract due to the communication delay to not hugely effect time.
The commands could be handled over ethernet by the slaves via http cgi scripts, or telnet, http has a bit easier report handling but of course a bit more overhead.
The master duet could handle all the configuration with device configuration adding slave address/user/password and would simply if there is addressing pass through the command to the slave when called.
Of course anything on ethernet can be a mess with external forces that could be overcome with a smart switch and placing the master and slaves on a vlan, even a passthrough or proxy host could be added for outside access.
Has this been tried?
Nice, your a savior
It was the old hightmap, I removed it and X/Y axis is running normal. I also moved the G29 S1 to the homeall.g and homez.g .
Thanks very much everyone for your awesome assistance.
I don't think I could express my appreciation enough for all the help. Thank you for the suggestions.
I am running a 20mm cube test and thought I would let it complete, its inside the 75 x 75 coords so it prints. When I ran the test and aborted it earlier I seen another problem with some issue of the feeder was having trouble pushing filament, I found a burr in the new hot end I installed (heat break).
I will do that test shortly, the heightmap is actually there and it is from the removed inductive probe so it is very wrong.
Further testing I ran a test print of a 20mm cube placed in the corner so all parts of the cube are inside the 75mm X/Y current unknown reason limits. It printed fine. X/Y print size was 20mm, I aborted the print after about 15 layers.
Yes the z probe is working.
There are no blockages, moving the axis with the power off is smooth for X/Y, Z is tougher to try with 2 steppers and lead screws.
I change to 16 micro stepping as you suggested. No change in distance X/Y can move before it stops accepting move commands. I also cut all M92 values in half for the micro stepping change.
I did the calibration likely the hard way.
X/Y/Z was calibrated by measuring 100mm move with a ruler and E was measured through the filament movement.
Thank you for all the info, wow helpful.
The 3dTouch is a clone, unfortunately money is very tight and I had to settle for the risk of trouble over the real thing. The inductive probe that came with the FLSun repeat accuracy I measured at .9mm which of course was horrible. The 3dTouch I tested at .15mm repeat. Not sure if that is horrible also but it is of course less horrible. I eyeballed the geometry needed to print a bracket and I was off a little 0.85mm over is fairly close for eyeballing I think. I will once the printer is printing again make a new bracket.
The M98 was a leftover of trying the probe configured as P5. Initially the probe would not deploy so I tried a few things. All it was needing is an I1 added to the end of the M280 commands. I did try both ways with and without.
0,0 was a tough piece of information to find on the internet on its location but yes standing in front of the printer 0,0 is on the left side closest to me. I did have X backwards when I assembled the printer (ok its my first time lol), found it odd when I printed items from thingiverse were wrong and mirrored then the bulb turned on and I figured it out.
Endstops for X/Y are at 0/0.
I built up the nerve after watching countless youtube videos to jump into the game of 3d printing, apparently I was in need of banging my head on the wall more than usual. lol We all need aggravation, I think that is the definition of a hobby.
The probe did seem to work find, I was able to do a repeat test of about 30 probes on the same point to get a feel for its accuracy with the G30 S-1 command and then raise Z +5 between. I was also able to HomeAll. It all stopped when I was troubleshooting the double tap and switched to the M558 P5, the old way.
After implementing the changes you suggested nothing seems to have changed with the axis issue.
To give an explanation of what happens further to earlier when I was in a bit of a rush.
I press the HomeAll button,
Z moves up, X & Y move to their 0 position and then away slightly and slowly back, z moves back down. Once X/Y is complete the Z raises and it stops with no movement of X or Y. Selecting any movement function does nothing.
If I home X and Y I can move the nozzle to +75 (earlier I said 80 in error). As long as I stay in 0-75 I can move any direction of X/Y. If I move to 76 all movement functions are ignored. Z does nothing but report a not homed. Something possibly important to note is after homing the X/Y and moving the X/Y manually, after it stops moving the Machine status shows all the position changes, just the nozzle doesn't move. i.e if I click X+100, X will move to 75 and stop and the display shows 100, if I click again X+100 the head does nothing and the machine status shows X200.
There is 1 other tidbit of information I found conflicting in the web installation information that could lead to the problem, don't know. In the information on the duet forum and its links to other pages explaining the install of the bltouch it talked about the old bltouch being +5v on its signal and that a 240 Ohm resistor is needed, someone chimed in on the latest version of the duet board being protected and did not need the 240 ohm resistor, I did try it both ways. Not sure if that could have blown something and thus messed up the steppers. Doesn't make a lot of logical sense though since they happily move inside the 0-75.
Now to add more fun to the problem, further testing.
I changed a homeall.g line from:
G1 X135 Z161 F6000
to:
G1 X35 Y35 F6000 ; probe position inside of the X0:75/Y0:75
With the resistor installed the head crashed into the bed, probe seemed to operate properly
With the resistor removed the home worked properly.
But still limited to the 0-75 X/Y problem. Z now travels properly with no limit, I ran it up to Z+350 and back to +5 and no problem. If I move X to 75 Z is dead as all axis.
Weird, lol
Thanks for a response
Note that if I manually move the X and Y axis to their max, the home moves them back to their 0 position.
config.g
; Configuration file for Duet WiFi (firmware version 1.21)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool v2 on Mon Feb 04 2019 02:18:18 GMT-0700 (Mountain Standard Time)
; General preferences
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
; Network
M550 P"FLSun" ; Set machine name
M552 P0.0.0.0 S1 ; Enable network and acquire dynamic address via DHCP
M586 P0 S1 ; Enable HTTP
M586 P1 S1 ; Enable FTP
M586 P2 S1 ; Enable Telnet
; Drives
M569 P0 S1 ; Drive 0 goes forwards X
M569 P1 S0 ; Drive 1 goes forwards Y
M569 P2 S1 ; Drive 2 goes forwards Z
M569 P3 S0 ; Drive 3 goes forwards Extruder
M350 X32 Y32 Z32 E32 I0 ; Configure microstepping without interpolation
M92 X200.00 Y200.00 Z800.00 E174.00 ; Set steps per mm
M566 X900.00 Y900.00 Z12.00 E120.00 ; Set maximum instantaneous speed changes (mm/min)
M203 X6000.00 Y6000.00 Z180.00 E1200.00 ; Set maximum speeds (mm/min)
M201 X500.00 Y500.00 Z20.00 E250.00 ; Set accelerations (mm/s^2)
M906 X800.00 Y800.00 Z800.00 E800.00 I50 ; Set motor currents (mA) and motor idle factor in per cent
M84 S0 ; Disable motor idle current reduction
; Axis Limits
M208 X0 Y0 Z0 S1 ; Set axis minima
M208 X300 Y300 Z420 S0 ; Set axis maxima
; Endstops
M574 X1 Y1 S1 ; Set active high endstops
; Z-Probe
M574 Z1 S2 ; Set endstops controlled by probe
M307 H7 A-1 C-1 D-1
M558 P9 H5 F120 T6000 ; Set Z probe type to bltouch and the dive height + speeds
G31 P500 X44 Y-4 Z2.80 ; Set Z probe trigger value, offset and trigger height
M557 X50:250 Y50:250 S25 ; Define mesh grid
G29 S1 ; LOAD EXISTING MESHMAP
; Heaters
M305 P0 T100000 B4138 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 115C
M305 P1 T100000 B4138 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S280 ; Set temperature limit for heater 1 to 275C
; Fans
M106 P0 S0.3 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
M106 P1 S1 I0 F500 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned on
; Tools
M563 P0 D0 H1 ; Define tool 0
G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C
; Automatic saving after power loss is not enabled
; Custom settings are not configured
M404 N1.75 D0.4 ;SET FILAMENT SIZE AND NOZZLE SIZE
; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool v2 on Mon Feb 04 2019 02:18:18 GMT-0700 (Mountain Standard Time)
M144 S0 ; Bed on Standby
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
M98 Pdeployprobe.g ; deploy mechanical Z probe
G1 S1 X-305 Y-305 F1800 ; move quickly to X and Y axis endstops and stop there (first pass)
G1 X5 Y5 F6000 ; go back a few mm
G1 S1 X-305 Y-305 F360 ; move slowly to X and Y axis endstops once more (second pass)
G90 ; absolute positioning
G1 X135 Y161 F6000 ; go to first bed probe point and home Z
G30 ; home Z by probing the bed
M144 S1 ;Take bed off standby
; Uncomment the following lines to lift Z after probing
;G91 ; relative positioning
;G1 S2 Z5 F100 ; lift Z relative to current position
;G90 ; absolute positioning
M98 Pretractprobe.g ; retract mechanical Z probe
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool v2 on Mon Feb 04 2019 02:18:18 GMT-0700 (Mountain Standard Time)
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G1 S1 X-305 F1800 ; move quickly to X axis endstop and stop there (first pass)
G1 X5 F6000 ; go back a few mm
G1 S1 X-305 F360 ; move slowly to X axis endstop once more (second pass)
G1 Z-5 F6000 S2 ; lower Z again
G90 ; absolute positioning
; homey.g
; called to home the Y axis
;
; generated by RepRapFirmware Configuration Tool v2 on Mon Feb 04 2019 02:18:19 GMT-0700 (Mountain Standard Time)
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G1 S1 Y-305 F1800 ; move quickly to Y axis endstop and stop there (first pass)
G1 Y5 F6000 ; go back a few mm
G1 S1 Y-305 F360 ; move slowly to Y axis endstop once more (second pass)
G1 Z-5 F6000 S2 ; lower Z again
G90 ; absolute positioning
; homez.g
; called to home the Z axis
;
; generated by RepRapFirmware Configuration Tool v2 on Mon Feb 04 2019 02:18:19 GMT-0700 (Mountain Standard Time)
M144 S0 ;PUT BED ON STANDBY FOR ACCURACY OF ZPROBE
G91 ; relative positioning
G1 Z5 F6000 S2 ; lift Z relative to current position
G90 ; absolute positioning
G1 X135 Y161 F6000 ; go to first probe point
;G1 X35 Y61 F6000 ; go to first probe point
G30 ; home Z by probing the bed
M144 S1 ;PUT BED ACTIVE
; Uncomment the following lines to lift Z after probing
;G91 ; relative positioning
;G1 S2 Z5 F100 ; lift Z relative to current position
;G90 ; absolute positioning
M122 report
=== Diagnostics ===
RepRapFirmware for Duet 2 WiFi/Ethernet version 2.02(RTOS) running on Duet Ethernet 1.02 or later
Board ID: 08DGM-9T6BU-FG3S4-6JKD4-3SD6K-KURBF
Used output buffers: 3 of 20 (14 max)
=== RTOS ===
Static ram: 25524
Dynamic ram: 98176 of which 0 recycled
Exception stack ram used: 328
Never used ram: 7044
Tasks: NETWORK(ready,544) HEAT(blocked,1232) MAIN(running,3788) IDLE(ready,200)
Owned mutexes:
=== Platform ===
Last reset 00:11:59 ago, cause: power up
Last software reset at 2019-02-13 14:18, reason: User, spinning module GCodes, available RAM 7028 bytes (slot 2)
Software reset code 0x0003 HFSR 0x00000000 CFSR 0x00000000 ICSR 0x0441f000 BFAR 0xe000ed38 SP 0xffffffff Task 0x4e49414d
Error status: 0
Free file entries: 10
SD card 0 detected, interface speed: 20.0MBytes/sec
SD card longest block write time: 0.0ms, max retries 0
MCU temperature: min 23.3, current 27.5, max 29.0
Supply voltage: min 12.3, current 12.3, max 12.4, 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
Date/time: 2019-02-13 15:51:19
Cache data hit count 1807026636
Slowest loop: 1.68ms; fastest: 0.07ms
I2C nak errors 0, send timeouts 0, receive timeouts 0, finishTimeouts 0
=== Move ===
Hiccups: 0, StepErrors: 0, LaErrors: 0, FreeDm: 240, MinFreeDm: 240, MaxWait: 0ms, Underruns: 0, 0
Scheduled moves: 0, completed moves: 0
Bed compensation in use: mesh
Bed probe heights: 0.000 0.000 0.000 0.000 0.000
=== Heat ===
Bed heaters = 0 -1 -1 -1, chamberHeaters = -1 -1
=== GCodes ===
Segments left: 0
Stack records: 1 allocated, 0 in use
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
serial is idle in state(s) 0
aux is idle in state(s) 0
daemon is idle in state(s) 0
queue is idle in state(s) 0
autopause is idle in state(s) 0
Code queue is empty.
=== Network ===
Slowest loop: 5.72ms; fastest: 0.02ms
Responder states: HTTP(0) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) Telnet(0)
HTTP sessions: 1 of 8
Interface state 5, link 100Mbps full duplex
deployprobe.g
M280 P7 S10 I1
retractprobe.g
M280 P7 S90 I1
Hello,
I have a FLSun I3 printer and slowly working towards making it work better. Bed leveling was my current project.
About 1 week ago I installed a Duet v1.04 Ethernet board, all was working fine with the Inductive bed sensor. I installed a 3d Touch sensor and all the axis worked while I was testing.
When I attempted a bed mesh scan the touch sensor would lets call it a double tap, it would drop and detect the bed then as the Z axis was raising the pin would deploy and fault canceling the mesh leveling scan.
The 3D Touch is setup as per documentation on the Duet connected as per the instructional link on Heater7. The sensor macros all work fine for functionality.
Once this error occurred a couple of times I selected Home All and the axis failure started.
The build area is 300 x 300 x 420, X axis now after individual home moves to +80 and stops, positioning reports it moved but there is no physical movement and it seems all gcodes after the attempted move stop. Y does the exact same. Z is not functional since the home requests a move to the center of the bed and it fails moving there.
Diagnostic report commanding moves 0-80 on these axis show fine, if attempt to move outside of that it reports Scheduled moves 18, completed moves 17. Turning off software limits has no change.
I did not want to go crazy dumping config info yet, I have reverted back to the config that ran prior to the 3d touch being installed but same problem.
Any thoughts?
Thanks for any help