First homing attempts failing.
-
also I would say that you DO have a problem with your switches you state above that you have a switch at both ends of the travel and that they are wired as normally closed and in series with each other. This is not normal in a 3D Printer.
-
If you understand electrical you would understand the presence of 2 switches only enhances the chances for stopping an axis. Your covered physically at both ends. Normal means nothing. 3d printers are not normal. they by design and the codes they use are contarty to every success that main stream cnc has had for 30 years now. Are you people going to tell me that a $300.000,00 haas mill is built wrong? Or that the gcode used by that machine, that never allows an end stop to be struck is also wrong. Series wired switching mean 2 switches 1 trip signal. Doesn't matter where it gets hit. This board doesn't know where it is. Couldn't find it's way to either end without changing this terrible code it's asked to run. This is gcode that is a slapped together purely designed version of someone else success.
and as for you deckingman my rank wasn't directed toward you. It was at the person asking the same questions ignoring all the times I have already answered. Do you like being ignored? The things you pointed out effect nothing because that proof reading happened before your post. You point out things That have nothing to do with the elephant in the room. You also shouldn't ware your feeling on your sleeves, like we are on the play ground!
This is an example of real Gcode for homing. Axes coordinates are programed by controller learning it position by tripping a switch, not by stopping at a switch and written G92 into homing file to tell firmware where we are. The controller doesn't rely on us to provide that info, we already did that by giving it a "pair" of eyes "the 2 switches." It zeros the low end and registers the high for axis length. A measuring method not user input. The G28.1 is used there after just to check we didn't lose steps. Running G28 should only Happen 1 time ever. G28.1 happening at program start. Printers rely on user data to feel there way around. than stupid statements like printer should be built so it can't damage itself. Really? How about not letting that happen in the first place. You guys drive car build fairly safe than ignore safety when you drive, because you rely on the car? These are machines that need proper instruction. you can't measure as well as the printer. let it do that for you.
G28 & G30 Return to Home
A home position is defined (by parameters 5161-5166). The parameter values are in terms of the absolute coordinate system, but are in unspecified length units.
To return to home position by way of the programmed position, program
G28 X~ Y~ Z~ A~ B~ C~ (or use G30). All axis words are optional. The path is made by a traverse move from the current position to the programmed position, followed by a traverse move to the home position. If no axis words are programmed, the intermediate point is the current point, so only one move is made.G28.1 Reference Axis
Program G28.1 X~ Y~ Z~ A~ B~ C~ to reference the given axes. The axes will move at the current feed rate towards the home switch(es), as defined by the Configuration. When the absolute machine coordinate reaches the value given by an axis word then the feed rate is set to that defined by Configure>Config Referencing. Provided the current absolute position is approximately correct, then this will give a soft stop onto the reference switch(es
-
Hi Jason,
Having two NC switches wires in series, one at each end, is unusual but should work most of the time. It won't work if you are trying to home to the low end of the axis, and the head is already at the high end (or vice versa), because the high end switch will be triggered so the circuit will be open.
Ian (deckingman) has correctly pointed out that one of your homing file lines has a colon before the comment instead of a semicolon, and this needs to be corrected.
I think I have worked out the problem. In the config.g file that you posted on page 1, you are using a very high steps/mm (800) which is because you have specified x128 microstepping. If you set the XY microstepping to the default x16 with interpolation enabled (I1 in the M350 command), and the XY steps/mm to 100, I think it will work.
Currently, if you wish to home using high microstepping, you have to use a low homing speed. This is because the need to check endstop switches on every step adds a large overhead to the step pulse generation.
PS - I've just been reminded that some of the time, you have been using external drivers. If you are using external drivers at present, reducing microstepping in config.g won't work unless you reduce the microstep setting on your external drivers too. What you can do instead is reduce the homing speed, i.e. use a lower F parameter in the G1 S1 command.
HTH David
-
I had some similar strange things happening when setting up my Duet also, swore up and down it wasn't a switch problem because they appeared to be working correctly, but it was a switch problem ultimately.
My axis were set to NO (normally open) using an end switch similar to this http://www.dx.com/p/getech-mechanical-endstop-switch-module-v1-2-mechanical-limit-switch-for-3d-printer-switch-ramps-1-4-300266.
In the "Machine Properties" panel of the duet, the switch appeared to be working correctly, when triggered it would change its state to open/close. In my mind not a switch problem…
So for a test I took one of the switches and modified it to be just a normal 2 wire open/close switch in the NC (normally closed) position, fixed all my problems.
ampapa,
-
This is the current none working config.g as far as homing and S1 checking is concerned.
; Configuration file for Duet Ethernet (firmware version 1.17 to 1.19)
; executed by the firmware on start-up
;
; generated by RepRapFirmware Configuration Tool on Sat Nov 25 2017 12:15:39 GMT-0500 (Eastern Standard Time); General preferences
M111 S0 ; Debugging off
G21 ; Work in millimetres
G90 ; Send absolute coordinates…
M83 ; ...but relative extruder moves
M555 P1 ; Set firmware compatibility to look like RepRapFirmare
G31 X-40 Y25 Z1.5 P25
M208 X0 Y0 Z0 S1 ; Set axis minima
M208 X295 Y295 Z207 ; Set axis maxima; Endstops
M574 X1 Y1 S1 ; Set active low endstops
M574 Z1
M558 P5 X0 Y0 Z1 H5 F100 T2000 ; Set Z probe type to switch, the axes for which it is used and the dive height + speeds
G31 P600 X0 Y0 Z2.5 ; Set Z probe trigger value, offset and trigger height
M557 X40:210 Y40:240 S20 ; Define mesh grid; Drives
M569 P5 S1 R1 T2 ; Drive 0 goes forwards
M569 P6 S2 R1 T2 ; Drive 1 goes forwards
M569 P7 S1 R1 T2 ; Drive 2 goes forwards
M569 P8 S1 R0 T2 ; Drive 3 goes forwards
M569 P9 S1 R0 T2 ; Drive 4 goes forwards
M569 P10 S1 R0 T2 ; Drive 5 goes forwards
M584 X5 Y6 Z7 E8:9:10 ; Apply custom drive mapping
M350 X16 Y16 Z16 E16:16:16 I0 ; Configure microstepping without interpolation
M92 X80 Y100 Z4800 E80:80:80 ; Set steps per mm
M566 X300 Y300 Z12 E120:120:120 ; Set maximum instantaneous speed changes (mm/min)
M203 X10000 Y10000 Z280 E1200:1200:1200 ; Set maximum speeds (mm/min)
M201 X400 Y400 Z150 E150:150:150 ; Set accelerations (mm/s^2)
M906 X2000 Y2000 Z2000 2000:2000:2000 ; Set motor currents (mA)
M84 S0 ; Disable motor idle current reduction; Heaters
M307 H7 A-1 C-1 D-1 ;disable heater 7 to free up for servo signal
M305 P0 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 0
M143 H0 S80 ; Set temperature limit for heater 0 to 80C
M305 P1 T100000 B4138 C0 R4700 ; Set thermistor + ADC parameters for heater 1
M143 H1 S260 ; Set temperature limit for heater 1 to 260C; Tools
M563 P0 D0 H1 F0:1:2 ; Define tool 0 FAN 0,1,2 FOR EXTRUDER 0
M563 P1 D1 H1 F0:1:2 ; DEFINE TOOL 1 FAN 0,1,2 FOR EXTRUDER 1
M563 P2 D2 H1 F0:1:2 ; DEFINE TOOL 2 FAN 0,1,2 FOR EXTRUDER 2
G10 P0 X0 Y0 Z0 ; Set tool 0 axis offsets
G10 P0 R0 S0 ; Set initial tool 0 active and standby temperatures to 0C
M568 P0 D0:1:2 S1 ; Enable mixing for tool 0,1,2
M567 P0 E0.33:0.33:0.34 ; Set mixing ratios for tool 0; Network
M550 Pkathy's printer ; Set machine name
M540 PBE:EF:DE:AD:FE:ED ; Set MAC address
M552 P192.168.2.9 S1 ; Enable network and set IP address
M553 P255.255.255.0 ; Set netmask
M554 P192.168.1.254 ; Set gateway
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet; Fans
M106 P0 S1 I0 F255 H1 T45 ; Set fan 0 value, PWM signal inversion and frequency. Thermostatic control is turned on
M106 P1 S1 I0 F255 H1 T45 ; Set fan 1 value, PWM signal inversion and frequency. Thermostatic control is turned ON
M106 P2 S1 I0 F255 H-1 ; Set fan 2 value, PWM signal inversion and frequency. Thermostatic control is turned on; Custom settings are not configured
; Miscellaneous
T0:1:2 ; Select first toolMy x homing
; homex.g
; called to home the X axis
;
; generated by RepRapFirmware Configuration Tool on Sat Nov 25 2017 12:15:39 GMT-0500 (Eastern Standard Time)G91 ;relative moves
G1 z5 F3000 ; move head up
G1 X-295 F1500 S1 ;move -310 mm stop at switch
G1 X5 F1000 ; move back slowly
G1 X-295 F360 S1 ;Move -310 stop at switch
G92 X0 ;tell firmware where we are
G90 ;absolute move
G0 X0 Z2.5 F1500 ; move to X to center z upWhy don't we try to explain why these 2 files fail if the board and current Ethernet firmware are all correct.
Machine pauses re-assigns a need axis concordant value than travel which ever way it wants and ignores the switch.
I'm using a scope between the end stop and switch and clear see 0.002 volts when switch is closed and 3.312 when open! My switch are fully holding the connector voltage to zero!I can't make the correction that was suggested early about micro setting, because I did that 3 days ago. Just plain old 16 time no interpolate. Same setting on drive. Next I whole step the thing, but that will fail too.
-
Thanks for posting your current config.g file.
You are using M584 to select drivers 5 and 6 as the X and Y drivers. M584 does not remap the endstop switch connections that are used, only the drivers. Therefore you still need to connect your X and Y endstop switches to the X and Y endstop connectors on the Duet. Is that where you have them connected? Or have you connected them to endstop connectors on the DueX5 instead?
-
The j33 and j32 connectors are the standard end stop connector that are normally used, center area of main duet board. I only have the simple expansion header board. Instruction state that that end stops are handled the same regardless of external drive config.
-
M569 command line has to be written with actual drive numbers used. So x is drive 5 and y is drive 6 z drive 7 same as M584. Other wise there is no motion. I think there may be an issue with end stop and drives not matching as they should in firmware. Something just isn't right. Do you know of anyone who has actually succeeded at configuring all external drives, or at least x and y? If so, seeing the config and homing files would probably help. I'm pretty sure Mine are according to documentation. There really need to be more info produced about what firmware is actually doing. If it can't perform an operation there needs to be a report as to what element is wrong, missing or at least point us in the right direction. repetier host provide much more internal data. I emailed an entire report from a failed homing attempt. It provided alot of motion data I'm not able to understand, but someone should. There was a reason provided for the failure as well, which I can't understand either. Have you seen that?
This example from Duet site below doesn't help much when it displays the original assignment for all on board motion drives.
We need an example of an actual external drive assignment using a drive number that you can actually use.
X can't remain 0, and Y can't be 1 Z can't be 2 or 3 these are not available for connection as external unless they come off lcd or 50 pin header.
This makes them only available as 5,6,7,8,9,10,11"Example
M584 X0 Y1 Z2:3 E4:5:6 ; Driver 0 controls the X motor, 1 controls Y, 2 and 3 control Z motors, 4 and 5 control E motorsAssigning a drive using M584 does not remove its old assignment. Therefore, if you assign a drive that defaults to being an extruder drive, you should also assign the extruder drives explicitly as in the above example. Failure to do so may result in unexpected behaviour."
Than how do I remove the old assignment? This might be the end stop S1 hang up. Firmware probably can't find the connection between these 2 events. I think firmware needs to see x drive 0 and x end stop for 0. This is contrary to the ability to externally drive a printer with this board. Support needs to be built into firmware to enable end stops that are externally driven for x y z based on M584 reassigned drive numbers. I understand M584 only reassigns the drive portion, but it leave a disconnect as to the usage of an end stop that normally configures to an axis that was originally assigned to 0 or 1. The end stop portion also needs to be reassigned to new drive number. M569 should work, but it doesn't pan out that way because M584 doesn't remove old assignment. This explains why I don't produce motion with S1. Firmware is either trying to drive S1 related motion command from drive number that no long exists or I can't clear axis motion because it can't related x end stop to a non 0 drive number.
-
The endstops are independent of the drive mapping.
I'll put your config.g and homex.g on my bench test system and test it.
-
I've replicated your system as best I can, but I am using a DueX5 to drive three Nema 23 motors because I don't have any external drivers. Here is a video showing X homing behaviour. I have connected a NC push button to the X endstop input, and I press it to simulate the endstop switch being triggered. When I press it, the X endstop LED goes out and the homing move stops as it should.
https://www.dropbox.com/s/otl3gkwt8pkx249/2017-12-11%2011.44.25.mp4?dl=0
I tested with both 1.19.2 and 1.20RC1 firmware versions.
Are you quite certain that you have the X and Y endstop switches plugged into the correct connectors, and not swapped? The order of the endstop connectors is Z Y X E0 E1. In the Machine properties page of DWC, the first row (which starts "Drive 0") shows the X endstop state. Under "Endstop hit" is shows "No" when the endstop switch is connected but not pressed, and "Yes" when I hold the button down.
-
OK now my turn. I'm going to make my own video and show exactly to the best of my ability a visual inspection and demonstration of the behavior. Hope I can figure out how to upload video here in proper resolution.
-
https://www.dropbox.com/s/0e4zo5gx2p2cdnz/00009.MTS?dl=0
Here's my video
-
As you can see I demonstrated switches working. Than I showed a failed S1 attempt. Next you see the x carriage moves under S2. Last you see the x homing behavior. Notice that there is a tiny move in the beginning. Less than a mm. The digital distance readout changes twice. From 70 to -220, than to zero all without moving, or using a homing switch. This clearly displays a board with an ability to run a file in an inappropriate manner. This board is assigning a coordinate without activating a switch. The failure to produce motion is 1 issue, how about confirming a homing run without feed back from it's switch. And what's with the busy sign that takes 30 plus seconds to clear. Something has to be wrong more than user error. If need be I will hook up a meter to show full voltage rise and fall for my switches. Anything else you wanna see let me know, otherwise I got mail this board back. I really would like to sort this out first, because I don't want to get stuck with a refusal to except the return in the long run if it's config related. But firmware bugs are not my fault.
-
Thanks for the video. I will study it in more detail tomorrow. Meanwhile, I think the issue must be to do with the different timings that happen during homing moves because of the extra homing switch checks. Please can you try a fee more things:
1. Does the Y axis behave the same way, i.e. after G91 you can do G1 S2 Y moves, but G1 S1 Y moves don't work, even though the endstop is showing as not triggered?
2. In your M569 commands for the external drivers, change T2 to T5 to lengthen the minimum step pulse width and interval.
3. Try firmware 1.20RC1.
Also please provide a link to the data for the stepper drivers you are using.
The problems you are having are really bugging me too, and I hope we can get them sorted soon.
-
PS - if those tests don't resolve the issue, I thought of another useful test. Let's eliminate the endstop switches from the equation, by disconnecting them from the Duet and changing S1 to S0 in the M574 command, to make the endstops read as not triggered all the time. Then see whether G1 S1 movement commands move the head the distance commanded, just as G1 S2 commands do.
-
The new firmware 1.20RC1 allows x and y to complete homing with nothing changed in any of my files.! Now
i am on left with the bl touch smart 3.3v logic sensor to work and I'll be printing. I wanted to thank Dave, Tony, and the other members for there help with this issue. They say cleanliness is next to Godliness, I now say patients is. Forgive me for some of the comments i made in response to so answers. More patients is in the works.Now I could probably get probing done quit if I could receive a review of all the files pertaining to z homing and whatever feature allows for leveling. My bed is machine cast aluminum plate further flattened using lapping plate diamond slurry. You'd think at 50/1000000's of the inch over the longest distance, That I wouldn't need it. I didn't realize the bed heat and glass cover would ruin my perfectly flat level running bed, but they are terrible in comparison.
Ok so I got M280 P7 S10 to deploy the probe. M280 P7 S90 retracts well also. Solid red light changes blue on deploy. Probe indicator on web interface reads 1000 . This value doesn't change. Sensor doesn't report contact with bed surface.
Probe is wired to the z probe in and gnd pins not the special probe pin. no z homing swith either. I must has missed something in instruction on this thing. Documentation doesn't support rep rap firmware from bl touch's end. What I find from Duet side of things is a case of catch up due to the release of many version of this probe and firmware. This things config setup has changed so many times I'm clueless.
An help will be great, Thank all!
; homez.g
; called to home the Z axisG91 ;relative moves
G1 z5 F200 ;raise head 5mm to ensure it above trigger height
G90 ;back to absolute moves this might be wrong G91
G1 X140 Y140 F2000 ;put probe at bed center
G91 ; relative moves
G1 Z-210 S1 F100 ; move down until triggered height
G90 ;back to absolute
G92 Z0.3; homeX,Y.g
; called to home all axes
;
; generated by RepRapFirmware Configuration Tool on Sat Nov 25 2017 12:15:39 GMT-0500 (Eastern Standard Time); Relative positioning
G91
G1 Z5 F3000 ;lift Z 5mm
G1 X-295 y-295 F1500 S1 ;relative move to x,y -310mm neg dir stop at switch
G1 X5 Y5 F1000 ;relative back off switch 5mm pos dir
G1 X-10 Y-10 F360 S1 ;relative move x,y -310mm alliance neg stop at switch slowly
G90 ;absolute moves
G1 X140 Y140 F4000 ; put probe center of bed
G30 ;lower probe set height
G0 X140 Y140 Z2.5 F1500 ; absolute move to bed center first probe position; bed.g
; called to perform automatic bed compensation via G32
;
; generated by RepRapFirmware Configuration Tool on Sat Nov 25 2017 12:15:39 GMT-0500 (Eastern Standard Time); Clear any bed transform
M561; Home all axes
G28; Deploy the mechanical Z probe
M98 Pdeployprobe.g; Probe the bed at 4 points
G30 P0 X40 Y40 H1 Z-99999
G30 P1 X40 Y260 H1 Z-99999
G30 P2 X210 Y260 H1 Z-99999
G30 P3 X210 Y40 H1 Z-99999 S
; Retract the mechanical Z probe
M98 Pretractprobe.g -
I'm puzzled - I can't think what I changed in 1.20 series firmware that could be making the difference! But I'm glad it's working. I'm sorry it has taken so long to resolve what was evidently a firmware issue.
Regarding your bltouch, there are at least 2 issues here:
1. Your Z probe is not working with the firmware. The Z probe reading should be 0 when the probe is deployed but not triggered. it should go to 1000 (possibly too briefly to see) when the probe is triggered.
To test a Z probe, with the head well above the bed, deploy the probe and send G30. The head should move towards the bed (or vice versa). Trigger the probe by holding something under it. That should stop the movement. If it doesn't, cut the power to prevent the head crashing into the bed.
However if you are getting a Z probe reading of 1000 all the time, that isn't going to work because the G30 command will provoke the message "Error: Z probe already triggered at start of probing move".
Please post a photo showing how you have connected the bltouch to the Z probe connector. Also post the lines you have added to config.g to support the Z probe - you should have at least a M558 command and a G31 command.
2. Your Z homing file is set up to use a microswitch, not a Z probe. To home Z using a Z probe you need to use a G30 command, not a G1 S1 command. See https://duet3d.com/wiki/Configuring_RepRapFirmware_for_a_Cartesian_printer#Homing_Z_using_a_Z_probe. Your homeall.g file is already set up to home Z using a G30 command.
-
Questions,
(1) For homez.g I'm no use M280 P7 S10 to deploy G30 to trigger height M280 P7 S90 to retract G92 Z0 to set height. That's working well. Thanks!
(2) Second I see option for M98, G32 G31 for probing multi location. I want a bed.g file that will measure and compensate for rolling variation of flatness with a total of .7 mm of adjustment over 87,000 Sq mm's.
I think the 16 point version might work. However after using the Escher3d cal. I see M or Gcode telling firmware what probing feature it's running. G28 to home x,y M98,M98 will be changed to M280's M98 doesn't work. Than G30 for every measured point line by line or isn't G32 0r G31?
And how do I tell firmware to store and run height values every time only running bed.g every so often to check stored values are still correct?(3) My bed is mounted on thk 15mm rails attached solid cold drawn steel bars 65mm high 20mm wide. Bed is constructed with 12.7 mm thing aluminum plate bolts direct to linear guide way carriage blocks, 3 on each side 50mm long each. machine frame is just as stiff. My bed leveled state will never change outside of thermal variation. So I need a good 1 shot probing run and a repeated use file of the recorded deviation in flat/level.
This is what calulator produced for bed.g
; bed.g file for RepRapFirmware, generated by Escher3D calculator
; 16 points, 6 factors, probing radius: 120, probe offset (40, 16)
G28
M98 Pdeployprobe.g
G30 P0 X0.00 Y101.58 Z-99999 H0
G30 P1 X58.11 Y69.26 Z-99999 H0
G30 P2 X87.32 Y15.40 Z-99999 H0
G30 P3 X82.86 Y-47.84 Z-99999 H0
G30 P4 X39.02 Y-107.21 Z-99999 H0
G30 P5 X-41.04 Y-112.76 Z-99999 H0
G30 P6 X-103.92 Y-60.00 Z-99999 H0
G30 P7 X-118.18 Y20.84 Z-99999 H0
G30 P8 X-77.13 Y91.93 Z-99999 H0
G30 P9 X0.00 Y41.92 Z-99999 H0
G30 P10 X30.32 Y17.51 Z-99999 H0
G30 P11 X33.52 Y-19.35 Z-99999 H0
G30 P12 X0.00 Y-60.00 Z-99999 H0
G30 P13 X-51.96 Y-30.00 Z-99999 H0
G30 P14 X-51.96 Y30.00 Z-99999 H0
G30 P15 X0 Y0 Z-99999 S6
M98 Pretractprobe.g -
For general bed compensation, you should use G29 mesh probing. See https://duet3d.com/wiki/Using_mesh_bed_compensation. If you are using multiple independently-driven Z leadscrews, you can use G32 and bed.g to adjust them if you wish, see https://duet3d.com/wiki/Bed_levelling_using_multiple_independent_Z_motors. Or you can use G31 and bed.g to tell you the corrections you need to make to your bed levelling screws, see https://duet3d.com/wiki/Using_the_manual_bed_levelling_assistant.
The calculator is for generating probe points for calibrating delta printers.
Normal practice for deploying and retracting the Z probe is to use M401 and M402, not to invoke the deployprobe.g and retractprobe.g files directly with M98. The probe will automatically be deployed before probing and retracted after probing if necessary; however in a bed.g file you may want to use M401 and M402 explicitly so that it only deploys and retracts the probe once, instead of once per probe point.
-
M401 isn't working M280 P7 S10 is what bl touch instructions say to use on deploy and M280 P7 s90 retract. I've seen this written in many examples, but also some users need to ad a T0 in the deploy.g and retract.g but it doesn't work for many of us either. Seem like plain M280 Your P# and S10/90 is what working with this thing. It's providing trigger now. I start at 0 and triggered 1000. So if I run G29 will these result be used to alter the performance of print begining to actual simulate a level surface? Or do these options just for measuring purposes, still requiring manual leveling?
