@phaedrux said in Which emulation to use with PE Slic3r:
@captain_sq said in Which emulation to use with PE Slic3r:
Does the M555 command affect anything at all in this scenario?
No. It's often misunderstood.
Thanks for clarifying that. /T
@phaedrux said in Which emulation to use with PE Slic3r:
@captain_sq said in Which emulation to use with PE Slic3r:
Does the M555 command affect anything at all in this scenario?
No. It's often misunderstood.
Thanks for clarifying that. /T
@phaedrux said in Which emulation to use with PE Slic3r:
@captain_sq said in Which emulation to use with PE Slic3r:
M555 P2 ; Set firmware compatibility to look like Marlin
This is used for USB response acknowledgement format and nothing more.
The slicer should be set to reprapfirmware gcode flavor.
Interesting. I use the Duet over WiFi as mentioned. Does the M555 command affect anything at all in this scenario?
I use the 2.3.3 Prusa slic3r together with a Duet Wifi (2.05.1). If I choose the FW emulation "Marlin" both in PE Slic3r and in the Duet config.g I get strange behaviour; motors moving extremely slow. The only working combination of these settings - were it behaves like expected - seems to be RepRapFirmware in PE Slic3r and Merlin in the Duet config. Like this :
M555 P2 ; Set firmware compatibility to look like Marlin
Is there an explanation for this?
Best regards /Thom
Thanks guys, I think I can manage this using this information.
I finally decided to make the leap from RRF 2.05.1 to 3. I have been searching the forum for some comprehensive instructions for this but I have come to understand that there is no "one-size fits all" for this procedure. Could someone well versed in the do's and don'ts for this take a look at my config.g file and point out the changes needed to be made? Which 3.x version shall I pick to make the transition as smooth as possible?
Thanks in advance.
The printer in question is a heavily modified TronXY X5S core XY. The hardware is a older Duet WiFi board using an Escher IR Z-level sensor. Config.s as follows:
; Configuration file for Duet WiFi (firmware version 1.17 to 1.19)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool on Thu Dec 14 2017 23:00:02 GMT+0100 (Västeuropa, normaltid)
; General preferences
M111 S0 ; Debugging off
G21 ; Work in millimetres
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves
M555 P2 ; Set firmware compatibility to look like Marlin
; Mode and axis travel
M667 S1 ; Select CoreXY mode
M208 X0:325 Y-10:325 Z-0.6:380 ; Set axis minima/maxima
; Endstops, Z-probe and bed mesh grid
M574 X1 Y1 S0 ; Set active low endstop switches on X and Y
M574 Z1 S2 ; Set active high Z-probe as endstop Z
M591 D0 P2 C3 S1 ; Filament sensor enable Extruder 0 - E0 endst. input, normal low OK
M558 P1 H3.5 A2 R0.5 S0.02 F140 T4000 ; Set Z probe type to IR sensor, dive height, recov time, tolerance, dive speed, and # of probings/point
G31 P500 X0 Y15 Z2.23 S25 C0.0012 ; Set Z probe trigger value, X/Y offset, trigger height, TH @temp and Tcoeff-ZSensor
; M307 H3 A-1 C-1 D-1 ; Decomission H3 and use it as a GPIO with Z-probe servo control
; M280 P3 S2050 I1 ; Make sure Z-probe is up and out of the way -move up
; G4 P500
; M280 P3 S2000 I1 ; Make sure Z-probe is up and out of the way -go back a little to avoid servo buzz
M557 X0:285 Y6:291 P13:13 ; Define mesh grid
; Drives
M569 P0 S0 ; Drive 0 goes backwards (X)
M569 P1 S0 ; Drive 1 goes backwards (Y)
M569 P2 S1 ; Drive 2 goes forwards (Z1)
M569 P3 S0 ; Drive 3 goes backwards (E0)
M569 P4 S1 ; Drive 4 goes forwards (Z2)
M584 X0 Y1 Z2:4 E3 ; Two Z motors connected to driver outputs 2 and 4
M671 X396:-111 Y162:162 S5 ; leadscrews at mid left, and mid right
M350 X32 Y32 Z32 I1 ; Configure 32 microstepping with interpolation on XYZ
M350 E8 ; Configure 8 microstepping on Extruder
M92 X160 Y160 Z800 E167 ; Set steps per mm
M566 X600 Y600 Z70 E100 ; Max instantaneous speed change (mm/min)
M203 X18000 Y18000 Z700 E6000 ; Set maximum speeds (mm/min)
M201 X2500 Y2500 Z130 E450 ; Set accelerations (mm/s^2)
M906 X1000 Y1000 Z650 E550 I30 ; Set motor currents (mA) and motor idle factor in per cent
M84 S30 ; Set idle timeout
; Heaters
; M304 H0 P649.2 I2.550 D1569.0 ; Use PID on bed heater using these process parameters
; M301 H1 P11.6 I0.124 D41.4 ; Use PID on hotend using these process parameters
M305 P0 T100000 B3950 C0 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S120 ; Set temperature limit for heater 0 to 120C
M305 P1 T100000 B3950 C0 L-70 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S270 ; Set temperature limit for heater 1 to 270C
; 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
; Network
M550 PX5S ; Set machine name
;M587 S"SSID" P"passwd" ; Configure access point. You can delete this line once connected
M552 S1 ; Enable network
M586 P0 S1 ; Enable HTTP
M586 P1 S1 ; Enable FTP
M586 P2 S0 ; Disable Telnet
; Fans
M106 P0 S0 I0 F500 H-1 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned off
;M106 P1 S1 I0 F500 H-1 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned off
;M106 P2 S1 I0 F500 H-1 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned off
; Read in bed compensation, override etc.
M501 ; Read in EEPROM Parameters
G29 S1 ; Read in the bed compensation table
; Go make some final adjustments
M98 P"0:/macros/fineadjust.g"
M911 S12.8 R13.8 P"M913 X0 Y0 G91 M83 G1 Z3 E-5 F1000" ; Configure power loss restoration
T0 ; Select default tool
The small fineadjusting macro at the end of the config is to make quick changes to run parameters without rebooting the board. Currently, it looks like this:
; Extra Configuration file for minor adjustments
; without the need to reboot.
; executed by config.g on start-up
;
; Motor params
M92 X160 Y160 Z800 E167 ; Set steps per mm
M566 X200 Y200 Z100 E600 ; Set maximum instantaneous speed changes (mm/min)
; M203 X9000 Y9000 Z700 E6000 ; Set maximum speeds (mm/min)
M201 X2000 Y2000 Z150 E2000 ; Set accelerations (mm/s^2)
M906 X1000 Y1000 Z650 E800 I30 ; Set motor currents (mA) and motor idle factor in per cent
M99 ; Jump back to caller
; end
Found it. It was the dive height (H2.5) in M558, config.sys
M558 P1 H2.5 A2 R0.5 S0.02 F140 T8000 ; Set Z probe type to IR sensor, dive height........
This wasn't big enough. Strange however, previously, in 2.03 this was not a problem, even as the trigger height is 2.77 mm. Increased the value to 3.5 mm and now it works as it should.
@Phaedrux said in Z-Homing in 2.02 vs 2.05:
It's the S2 commands you're using. Normally they are to allow movement of an axis that hasn't been homed, such as to raise the Z axis for clearance, but you're using it for X and Y movements even after they have been homed once. On a corexy the S2 means move an individual motor.
Also, in newer firmwares, the G1 S parameter has been set aside for laser control (because all the laser software generates S values for laser power) so for homing moves you need to use H now.
See: https://duet3d.dozuki.com/Wiki/Gcode#Section_G0_G1_Move
See the example homeall.g for CoreXY here: https://duet3d.dozuki.com/Wiki/ConfiguringRepRapFirmwareCoreXYPrinter#Section_homeall_g_file
G91 ; relative mode G1 S1 X-240 Y-240 F3000 ; coarse home X or Y G1 S1 X-240 ; coarse home X G1 S1 Y-240 ; coarse home Y G1 X4 Y4 F600 ; move away from the endstops G1 S1 X-10 ; fine home X G1 S1 Y-10 ; fine home Y ''' Z homing section follows'''
OK, thanks. I'll look into it.
Brgds /Thom
For completeness, I have a macro called by config.g on its last line to make fine tuning of some parameters. The reason for putting them there is to change and run them separately conviniently without the need for rebooting the Duet. It adjusts the Z trigger height by a few hundreths of mm.
; Extra Configuration file for minor adjustments
; without the need to reboot.
; executed by config.g on start-up
;
; Probe and mesh
G31 P500 X0 Y15 Z2.68 ; Set Z probe trigger value, X/Y offset and trigger height
M557 X0:285 Y6:291 P7:7 ; Define mesh grid
; Motor params
M92 X160 Y160 Z800 E855 ; Set steps per mm
M566 X200 Y200 Z100 E300 ; Set maximum instantaneous speed changes (mm/min)
; M203 X9000 Y9000 Z700 E6000 ; Set maximum speeds (mm/min)
; M201 X2000 Y2000 Z150 E2000 ; Set accelerations (mm/s^2)
M906 X1000 Y1000 Z650 E1200 I30 ; Set motor currents (mA) and motor idle factor in per cent
M99 ; Jump back to caller
; end
Sure thing. Her it is.
; homeall.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Thu Dec 14 2017 23:00:02 GMT+0100 (Västeuropa, normaltid)
G91 ; relative positioning
; X/Y -axes
G1 S2 Z3 F8000 ; lift Z relative to current position
G1 S1 X-340 Y-340 F1800 ; move quickly to X or Y endstop and stop there (first pass)
G1 S1 X-340 ; home X axis
G1 S1 Y-340 ; home Y axis
G1 S2 X5 Y0 F3000 ; go back a few mm X5 Y5
G1 S1 X-340 F360 ; move slowly to X axis endstop once more (second pass)
G1 S1 Y-340 ; then move slowly to Y axis endstop
G1 S2 X10 Y10 F3000 ; Move inside bed - X only moves to X=10
G1 S2 X20 Y-20 F3000 ; Move inside bed - Y only moves to Y=11
; Z-axis
G1 S1 Z-400 F2000 ; Move fast towards sensor and stop when hit
G1 S2 Z2 F2000 ; Back up a bit
G90 ; back to absolute mode
G30 ; lower head, stop when probe triggered and set Z to trigger height (z set to 0)
; Set home position and park hotend
G92 X0 Y0 ; set new X, Y zero position
G1 Z1 F400 ; Park the hotend a mm above bed
Hi,
I have two printers powered by DuetWifi. One is a custom made Kossel (delta) and the other is a big core-xy. I've been running 2.02 on both for a long time period, more than a year. I recently updated the delta to 2.05. It worked like a charm. I liked the new web interface so decided after a week or so that I also will update the Core-xy to the same FW package.
After the update the Core-xy would not home the Z-axis correctly. I'm using the Escher IR-sensor and the Z-plane is driven by two separate motors to accomodate leadscrew adjustment. The Z-homing procedure gives an error message that the sensor was not triggered and the Z-plane ends up 3-4 mm away from the nozzle. I didnt't investigate as i were short of time. I just downgraded to 2.03 and the Core-xy was now behaving correct again.
Has the homing G-codes or their parameters behaviour changed in between versions?
Here are the relevant code from config.g that relates to the homing/sensor part:
; Mode and axis travel
M667 S1 ; Select CoreXY mode
M208 X0 Y-10 Z-0.6 S1 ; Set axis minima
M208 X325 Y325 Z380 S0 ; Set axis maxima
; Endstops, Z-probe and bed mesh grid
M574 X1 Y1 S0 ; Set active low endstop switches on X and Y
M574 Z1 S2 ; Set active high Z-probe as endstop Z
M591 D0 P2 C3 S1 ; Filament sensor enable Extruder 0 - E0 endst. input, normal low OK
M558 P1 H2.5 A2 R0.35 S0.02 F140 T8000 ; Set Z probe type to IR sensor, dive height, recov time, tolerance, dive speed, and # of probings/point
G31 P500 X0 Y15 Z2.77 ; Set Z probe trigger value, X/Y offset and trigger height
Best regards /Thom
Hello,
I'm in the progress of installing a filament out senor to my Duet Wifi.
What is the standard behaviour of the Duet2 WiFi when configured with a filament sensor using M591?
Does the printer just freeze or do more elaborate things?
TIA /Thom
OK, Great! In the mean time I'll just filter the output from S3D through a AutoIt serial editor filter that will perform the conversion.
Thanks /Thom
Hello,
I posted this question under Hardware and Wiring and that might have been a little off topic, so I'm trying here in the general part instead.
Is it possible to set up a custom output on the Duet Wifi that will generate a servo signal (1-2 mS) that follow/is proportional to the value of FAN0?
f ex
0% = 1.0mS
100% = 2.0 mS
If that's not possible, tweaking the FAN0 PWM output itself to produce a 22mS period pulse train with 1-2 mS duty cycle would yield a valid servo signal between 5...9 % in its entire span. Not much to play around with.
I could solve this in the Slicer (S3D) if math in the G-code was possible with a REPLACE macro that would produce something like this.
; Before
.
.
M106 S127
.
; After
.
.
M280 P1 S(([fan_speed_pwm]/255)*1000 +1000) ; S127 "Imaginary" expression
Any thoughts ? Did I miss something?
Regards /Thom
It's an old thread but exactly what I'm after.
Any plan on implementing conditional gcode?
Hi,
I'm experimenting with an uncommon build plate material - PMMA. It has good adhesion properties with PLA, almost too good. The plate is 3 mm thick and is heated to about 45°C which is more than enough to make PLA stick. I get inconsistent readings from the IR sensor at various places. The surface it rests on is painted matte black but I'm wondering if it would have been better to paint the rear side of the PMMA plate itself.
Now, is it the black surface under the PMMA plate that reflects the IR signal or is it the top surface of the PMMA?
Hi guys,
I have a Tronxy X5S which I have fitted a Duet Wifi and a custom made extruder. The Duet is using independent drives for the two Z-motors and I have setup a macro for the leadscrews compensation using the Escher IR-probe that works nicely. The old Z-home sensor is used as before connected to the Z-endstop sensor input.
Now, the question is, what of these determines the actual Z-zero position? Is it the Z-endstop homing sensor or is it the leadscrew compensation bed probe operation?
@AS-3D:
Quick Question on this point.
What exactly will change if you're done with Version 2.0?Is it just more compact or can it operate faster?
Is it a performance jump like from Windows Vista to Windows 7?
Sry but i don't get it.
In short: More efficient use of the microcontrollers and development resources.
Which means that you can do more things with the resources you have at your disposal without sacrificing performance. In plain english that means that you can add more features, speed up certain parts and shorten development times.
For the developer a lot of things becomes easier as the abstraction level is significantly raised. Code becomes more robust as you don't have to twiddle around with low-level error prone code that often incurs limitations that makes the entire code base hard to maintain. Hunting for bugs becomes somewhat easier too.
Exiting!
I'll be following this closely. We had an earlier discussion about G code look-ahead to enable rising/lowering of extruder temperature according to the current extrusion speed. I hope this is on the list somewhere.
Another thing I have been pondering is a "predictive" and self-adjusting start time for the heating up of the hotend in relation to the timeline of the heating of the bed in order to save some time when starting a print. With the PID parameters resulting from the auto-tune of the heated bed, one should be able to estimate the time when the bed reaches the target temperature. The same goes for the hotend. With these estimated predictions, one should be able to start the heating of the hotend at a certain time during the heating of the bed so that both the bed and hotend reaches the target temperature at the same time.
Small adjustment to this factors can be made by measuring the actual time each print. Over time, the prediction factors will "home in" on the correct value as the printer is being used.
Let's see if I got this right.
If Z in the above example is moving along at 100mm/min or less a direction change could be immediate. If Z moves at higher speeds the controller must wait until it comes down to 100 mm/min before direction change. Is that correct?
In Marlin for example, jerk seems to have a much lower value (around or below 10). Does that mean that Marlin uses another unit-of-measure?