@Phaedrux
Sorry for the delay, don't come to this machine unless is failing (again!)...

So just a couple of things; the z-probe issue in the end was bad wiring - the cable chains where the cables pass thru have apparently ended up wearing out the cable, as I had finally noticed that the issue was mostly present in the same (approx) area of the Y axis... I tried a new cable running outside the cable chain and problem is gone, probe runs perfectly now.. put the new cable inside the cable chain and all continues to work fine now!

And, about the delta requiering home before probe, how does RRF do that which I would like to do on cartisian?

@hector que tal va eso? Algún avance?
How is this going? Any news?

@Phaedrux said in Occasional hotend crashes into bed during mesh calibration:

auto is likely running G32, which is bed.g, which you should check to see how it's written. It probably has a G28 to home followed by G29 to run mesh compensation. Where as "run mesh grid" is just calling G29.

OK! yes, my bed.g is G28 followed by G29

It may be a good idea to update your firmware to 2.05.1 and DWC 2.0.7 so that you have the benefit of any of the many bug fixes since then. It will make troubleshooting any remaining issues easier.

I will update now...

When doing a homing routine or a mesh grid routine etc it is a good idea to reduce the motor current so that in case of a crash, the motor will stall before any real damage can occur. This would remove the need for a backup endstop, which is possible, but you would have to configure it as an emergency stop.

I am running all NEMA 23 from the external driver board, via their own drivers, so cannot reduce current via software... at the moment the dual Z motors are at 1.9A - I have just done a test reducing to 1.0A, but the right motor then cannot raise the weight of the bed - at 1.5A the bed seems to move fine, but also seems to have enough power to do damage...
Ideally I would like the z-endstop as a backup endstop, I don't mind that it is an emergency stop, it would be better like that than the damage it is making now - perfect situation (if the only option is as an emergency stop) would be to be able to use the z-endstop to do a normal home, then use as emergency endstop if the bed passes -1mm during the z-probe... right now I have the z-endstop at +3mm, so absolutely no contact with the bed even if the heated chamber causes the bed surface to bow up (but am presently changing for an aluminium bed anyway)

Is the Duet inside the heater enclosure? It would be preferable to have the Duet outside if that's the case.

it is in a space "in between" the heated area and the outside of the machine, so it gets heat from the inner surface.. but I have just installed a permanent fan in the access door, so it is always getting cold air from outside - MCU is running at 36ºC now, when without the fan it was at about 55ºC

@andymidtf said in Occasional hotend crashes into bed during mesh calibration:

either that or that the machine respects the axis min of Z-1 that is in my config when doing a Z probe...

It can't respect that during a homing move because it's in the process of trying to identify where Z0 is. If the probe doesn't trigger, it can't know that it's pushing into the bed. We must solve the problem of the probe not triggering.

I was hoping that, as a normal home had been done just before, the G29 or G30 would be aware of Z0, and therefore could be able to respect Z-1 as its limit to search for the bed... but totally agree that have to solve the problem with the probe...

Please post your config.g

had posted at the end of first post

No, for the reason stated above. G30 is a seeking move. It will travel until it triggers. If it doesn't trigger, it will keep traveling. The issue of the probe must be resolved.

nor G29? some way of not resetting zero before making the probe?

...

A question that may help find the max current for the z-motors that would push the bed but do least damage: I think I can use RRF3 on a Duet2 ethernet? would the M574 Z1 S4 P"zstop" work with the external driver boardand RRF3? At the moment I am using 1.5A as 1.0A won't push the bed up...(and the external drivers don't have anything in between) In theory I could use the Z-motors direct from the Duet (2.4A = 1.2A per motor..?), if the bed can move with this current then I could possibly take advantage of motor stalling instead of/ as well as the z-probe, or as the emergency stop (even better! as could use normal home as well)

thanks!

I realise that with the z-probe I was not using the z-endstop - I have now changed back this behaviour and home now does x,y & z, but I have also moved the z-endstop up to about +3mm, so z-home sets Z to +3mm, to avoid the hotend hitting the bed even when there is any change in height with the machine heated up...

So another quick question: Now that Z0 is known after homing to endstop, will the machine respect my axis min of -1mm when doing Z-probe?
Obviously I am pretty nervous about testing this on the machine... !

Hi,
So, slightly similar to https://forum.duet3d.com/topic/7365/hotend-crashing-into-bed-during-auto-calibration, but I have P1 already set, and it is not always this issue happens..

I have Duet 2 ethernet, v2.02 fw, Cartisian 1m3 printer, with IR sensor (with SMDs) near hotend... occasionally when doing mesh calibration the sensor does not trigger on the Duet, whilst the LED does light up on the IR board - I have revised also https://miscsolutions.wordpress.com/mini-height-sensor-board/, "Troubleshooting, LED turns on/off to indicate triggering, but the printer firmware does not recognise whether or not it is triggered", but it is not clear how I may correct pullup resister values if they would be too high, as I am getting the expected 4 flashes on power up, and am using a Duet anyway...

To add complication, although this has been a very occasion issue with PLA (no heated chamber), curiously, when pressing "Auto Bed Compensation" it generally failed at the same point, if it failed (probing stops as no trigger detected, head rams against bed to -4, when my axis limit is -1!), but when using "Run Mesh Grid Compensation" it fails less often, and generally at a different point! As far as I can observe, "Auto" runs a Home first, whilst "Run mesh" does not, it just starts (as long as machine was already homed).. both give a height map once/when finished.

I would also like to learn how to configure a "backup" endstop - the Z-endstop works fine, is magnetic, so when the probe fails to trigger no damage is done to the endstop, but I would like that, if the probe fails, the Z-endstop trigger stops any further Z move, as, this morning, when doing a G30 in the center of the bed, a one-off probe that up until now has always worked first time, today did fail, and went a lot more than -4mm, bending the heatbreak a lot... either that or that the machine respects the axis min of Z-1 that is in my config when doing a Z probe...

And now to make things worse (but possibly can id the issue as well?)! :
This printer is (supposedly) ready for ABS, being contained in a metal box all the motors and rails, however when set to only 60ºC the heated chamber, the bed height now varies just over 2mm higher, and the bed surface itself suffers some bending, to the extent that it is now necessary to do a new grid compensation, however now the issue is much more repetitive, so much that cannot finish a complete probe - until I remember that troubleshooting, and also that resisters increase resistance with heat, and that the Duet is in a place where it is also heating up (not so much, somewhat) - and placing a fan directed at Duet now permits finishing the Bed Compensation - but does not get rid of completely the issue as still occasionally fails - with todays spectacular fail of the G30!

So.. if this issue is from a pullup resister on the Duet being borderline slightly too high (?), I remember that for Duet 0.6/0.85 there was a way of indicating the thermistor resister value - any way this can be indicated in the config? Or any idea what else could be the issue here?
And how can I enforce axis min so that they are not exceeded? Or perform a stop when the Z-endstop is triggered to avoid such exaggerated bed movements in negative..?

Any opinions would be appreciated!

Thanks!
config.g

@mawildoer said in Advice on adding plasma torch height control:

EMI Testing

Just a quick update on this one. I've done some testing very specifically on the EMI induced in a shielded wire taped adjacent and in very close proximity to the plasma cable. This test cable is a CAT 6 Ethernet cable, where each pair is foil shielded and the whole cable is braid shielded.

Also note that I didn't actually conduct everything in the following order, but I thought it made more sense to present it this way.

Test Setup

I got some interesting results (and way, way more noise than anticipated).

FWIW, I've been investigating making a plasma CNC as well, and have noticed

1. VERY important not to use a HighFrequency arc starting machine, these DEFINITELY will fry CNC electronics, pilot arc start are the one to use
2. Many cheaper Chinese plasmas have a s*** load of EMI noise, even one page goes directly to prohibit the use of certain plasmas (including the make of the one you are testing) with their CNC frame: http://www.langmuirsystems.com/plasma-cutters
   by the way, their FAQ has a load of interesting info too

For my part, I'm also investigating an inductive probe to do the z-correction, instead of Torch Height Control, because I would prefer to completely isolate the CNC from the plasma (that said, would still need to attach the torch on/off M3....), but am also worried about EMI, but directly from the arc - if the inductive sensor is to be close enough to be useful to change height at the nozzle... if the sensor gets affected, it will incorrectly change the z-height... not convinced yet that it would work, probably THC would be better as is "spot-on" the nozzle...

Cheers!
Andy

@dc42 No, there is no chamber heater configured... there IS a chamber heater, but it is completely independent (at the moment, I was thinking of later including control in the Duet), and is run by its own heater control.
I have M140 H-1 in config.g, so no instruction should be sent for bed/chamber anyway?

cheers!
andy

Hi David,

So I have tried all FW from 1.19.2 up to 2.0RC2, all behave the same...
I have redone a few simple tests:

1. all drivers from onboard Duet drivers - issue still arises
2. connecting both external z-motor drivers to 1 Duet external port, basically for the Duet there is now NO U motor, and both z-motors are controlled as one - pain for levelling, have to manually twist right leadscrew, but with this set up issue DISAPPEARS!
3. went back to 2 external independent z-motors, U added, issue comes back.

the issue I am very sure has to do with Duet on board problems, however I still have the strong feeling that external EMI is causing these onboard problems, however I am still at a lose as to how to test this... there are many cables that run parallel, including 220v ac, 24v dc, and stepper motor cables, all together, and also the cables for the extruder motor, 2 always on fan, print fan, z-probe, heater and thermister, that run together for over 3m, via 2 cable chains on X and Y axis... this as well as the noted difference in voltages on the drivers, and the additional observation of distinct voltages when inverting the tester probes (only when the original ena,dir,pul voltages start out negative!! if they are +ve, like when dir is +ve, then there is NO difference inverting the probes, apart from the +/- sign itself!)

My next plan will be trying to re-cable the machine, cable by cable, outside of the chassis, until either all cables are hanging outside of the machine, and separated between them selves, or I find the pair that is affecting the machine!

Any other (better!) ideas are appreciated

cheers!
Andy

I tried downgrading, but the board complains is missing Duet2Combined... even when I use a new micro SD with FW 1.19.2 loaded on the card!

@dc42 this board came with 1.21... the last board came with 1.19, and I upgraded to 1.21...
Me tinks maybe should downgrade? to 1.20? see what happens? this can be down I assume... not like iPhone where once gone up, cannot come down!

Andy

@dc42 a multimeter.... I am measuring across each pair of cables, as indicated on the wiring diagram of the wiki of the expansion board, and the stepper has the connectors marked; enable, direction and pulse, first on the 6 wire connector on the expansion board, then touching the screw terminals of the connector of the same pair on the stepper driver.. first I was making sure I respect orientation of the multimeter (red probe to +ve, black to -ve), and then found that swapping these gave distinct results (instead of just a reversed value).

FWIW, I just tried something new, and issue still shows - I disconnected completely the external steppers on Z & U, and connected them straight to the Duet onboard drivers, on Z & E0, corrected config.g as needed, checked directions - machine works fine, except for when issue shows again...

Also, FWIW, as am not sure if now the issue seems slightly more intermittent than a few days ago (I think I mention that further up), now, instead of trying +/- 5mm (++++++, then -------, then ++++++, etc), as this seems to take longer for the issue to show, I am doing +/- 0.05mm, until I get a rough sound & rapid move (like the first videos), and then straight after do +5mm, and the U goes -5 whilst Z still goes +5...

I am ever more sure that there is an issue with negative or earthing on the machine, just don't know how to locate... FWIW (again!), I am actually changing to Duet, as on the original Chinese board the Z2 (U on Duet) connector on the logic board stopped working correctly, but to the point where it would not give any signal at all (tried swapping Z1 and Z2 connectors and which ever motor was connected to Z2 output did not move) - I had to end up piggybacking the Z2 connector on the Z1 connector just to be able to use the machine, but levelling was manually turning the Z2 motor leadscrew!: as this was not acceptable in the long run, I opted to change main board to Duet... that and the fact I have much more control over the machine, have added a piezo z-probe, will be able to add more extruders, the laser filament extruder, etc...

Andy

@andymidtf @dc42

Opps! looks like the comment about the machine stopping responding on unplugging the ethernet was premature - on removing the ethernet cable I also managed to press the microSD card without realising it, and it was not correctly inserted - on inserting fully the machine now responds correctly (duet and expansion board still hanging), but still has the issue

Neither the chipsets on the expansion board or the driver chipsets on the Duet are heating up at all, even after 10 mins holding position with motors energised.

F*** this is getting annoying...

Additionally, measuring again the voltages on just the X axis, getting (about) 4v (ena), 4.6(dir) and 4.6(pul) on the expansion board, and 4.85, 6.15 and 6.20 on the driver! Even more than before... there is no difference with or without ethernet plugged in

AND, even more strange stuff that makes me think it is a problem of negative or earthing: just for fun (!) I tried reversing the tester probes, +ve to -ve and -ve to +ve - there is a small difference, sometimes a reasonable one, between most -ve voltages - in theory (and in the practice measuring, for example, the Duet power input connections) reversing the tester probes should just give a -ve reading of what was being read, but...:

After moving the X axis AWAY from endstops (dir is +ve voltage now)
Voltage on expansion board connector, and on the driver connections:
With tester normal ... (R)eversed:
X ena -4.06 .... R 4.25 Driver -4.96 .... R 5.76
X dir 3.22 .... R -3.22 Driver 3.22 .... R -3.22
X pul -4.75 .... R 4.81 Driver -6.30 .... R 6.35

Especially on the Enable, and more on the driver, there is a difference of 0.8v when I think there should not be! Again, when measuring a +ve voltage on the expansion board (dir), there is no difference on the driver, NOR if I reverse the tester probes (how it should be, and how it is also on the Duet power in).

Any ideas on how I can test this? Either disconnecting stuff or reading voltages between other parts? Or the chassis..? I have the feeling something is not right and maybe it is this which is causing the issue... not sure what else to try about the issue right now!

thanks!
Andy

@dc42 I’m afraid I am no longer at the machine... by differential line driver chips you mean the chipset that is on the expansion board itself, or the driver chips on the duet board? I have not checked if they heat up... I will be back monday midday...

The drivers are sannoon sn2405a, I don’t have a datasheet, and most of the web is in chinese! FWIW, i had on hand some different drivers today and tried installing on the z-axis; the issue is still present... i did not however make new measurements of the voltages.

I did make a couple more tests, thinking maybe something to do with the correct earthing of the machine - i happen to have installed the expansion board on a different surface than where the duet is installed - all surfaces are painted steel, so I had assumed the whole machine would be earthed, but, to check, I tried unfixing 1st the expansion board, then the duet, letting both hang by the cables - this did not seem to have any effect either, but during all these tests I had had the ethernet cable plugged in - on unplugging it the machine now stopped responding via the paneldue!
I have yet to mount again the duet and expansion board to see if the machine now responds without the ethernet cable plugged in - on Monday I will continue!
Not sure what this means yet

Cheers!
Andy

Still unresolved! Anyone have an other ideas...?

So I have done some more experiments (!)... I decided to measure voltages between enable (+ & -), direction & pulse, both on the expansion board and on the driver connector - I have seen some strange (?) behaviour, but I am not an electronics guy, so am not sure..

1. when the issue produces, the direction voltage changes on the expansion board ONLY on the affected motor, so it seems the reversed signal is still coming form there...?
2. when I measure positive voltages (when the bed has just been ordered to raise (z -ve)), the voltage is exactly the same on expansion board and driver - when I measure negative voltages, there is a difference, sometimes quite a lot... I put the voltages measured, maybe they mean something to someone better qualified than myself:

After homing, last X & Y move was towards endstop, last Z move was away from endstop (2mm z +ve)
expansion board ... driver ... difference
X ena -4.05 ... -4.43 ... 0.38
X dir -4.65 ... -5.95 ... 1.3
X pul -4.69 ... -5.91 ... 1.22
Y ena -4.02 ... -4.04 ... 0.02
Y dir -4.85 ... -5.27 ... 0.42
Y pul -5.04 ... -5.32 ... 0.28
Z ena -4.01 ... -4.50 ... 0.49
Z dir -4.68 ... -5.09 ... 0.41
Z pul -4.59 ... -5.28 ... 0.69
U ena -3.98 ... -4.15 ... 0.17
U dir -4.75 ... -5.32 ... 0.57
U pul -4.72 ... -5.42 ... 0.7

swapped Z & U again, same, after homing...
U ena -3.89 ... -4.10 ... 0.21
U dir -4.58 ... -5.17 ... 0.59
U pul -4.58 ... -5.06 ... 0.48
Z ena -3.91 ... -4.24 ... 0.33
Z dir -4.55 ... -4.87 ... 0.22
Z pul -4.51 ... -5.26 ... 0.75

after homing, lowered bed, then RAISED as last move (z -ve)
Z ena -4.05 ... -4.72
Z dir 3.25 ... 3.25 +ve voltage exactly the same on board and driver
Z pul -4.72 ... -5.65
U ena -3.9 ... -4.32
U dir 3.25 ... 3.25 +ve voltage exactly the same
U pul -4.5 ... -5.45

I have no idea why when -ve voltages they are so different, when +ve voltage they are exactly the same any ideas?
thanks!
Andy

Still unresolved! Anyone have an other ideas...?

@dc42 Now just replaced Duet and expansion board, I did it straight out, all at once, all 3 parts (expansion board + cable + duet), just to try and eliminate anything to do with previous electronics - the issue continues!

Before swapping out everything, I took down M122 output at 4 stages, just for comparison purposes: power on, homed, after lowering bed once strange sound is noted, and after the issue itself reproduces (U is reversed - ALWAYS happens on next move after strange sound). I attach the M122 outputs - I could not tell if there was anything wrong, at least there did not seem to be any errors...:

0_1524920202918_M122_power on.txt
0_1524920208252_M122_homed.txt
0_1524920214324_M122_lowering bed, sound distinct.txt
0_1524920220025_M122_U motor moved reversed.txt

so it looks like there is nothing wrong with the electronics, so in theory no longer should keep asking for help on the forum...

FWIW, I have again, with new electronics, after verifying issue is still present, swapped ONLY Z & U motor connections to expansion board, (and also their endstops) - issue transfers to the other motor (was in right motor, now is in left motor) - this is what has me most stumped, as simple diagnostic practice should indicate that there is nothing wrong with anything after the board, if only swapping connectors on the board makes the issue change place...
The only other thing is now maybe is not so frequent... hard to tell
I took new board, it already had 1.21 on board, and adjusted config.g on SD card to my setup, and substituted my homing, pause, resume, trigger and bed files, and macros.

Any ideas from anyone else would be greatly appreciated!
PS header added so that phrase comes up on forum thread list

thanks!
Andy

PPS the only other thing I can think of is electrical noise, but have no idea how to test that idea...

@dc42 Hi David,

If that was the case, why does the issue go from one side to the other when I swap connectors on the expansion board? And why does the issue show so suddenly and randomly... and also, in the last video, why does the U motor go backwards in 2 of the 7 movements.. ?
By the way, did you appreciate the change in tone of the movement just before the reversed move? Any idea what that could mean?

I will certainly try reducing speed and acceleration, but I have seen the issue also when doing a bed compensation with the piezo probe, at F150, as well as normal moves at F600.

I will not be able to get back to the machine until thursday, so then I will try various M112 whilst and after the problem has occurred. I’ll get back to you then.

Thanks a lot for taking the time to attend this forum, i know you have a lot of work too, I for one (and many others I’m sure!) appreciate your help resolving our problems
Just thought you need to hear that once in a while!

Cheers!
Andy

@dc42 I have tried swapping drivers, the issue stays with the same motor, so the driver is not the issue...
I managed to make another video:
https://youtu.be/_L0VyhTQw8k

homed Z, then sent z+ (bed down on this machine) 5mm various times; the 1st and 2nd moves are OK, 3rd move OK but sounds distinct, then 4th move goes wrong (Z-right, U, moves UP instead of down!), then 5th move is OK, 6th move is OK but sounds strange, and again 7th move is wrong - it seems, on the longer moves at least (where I have time to appreciate it?), that the move just BEFORE the one that goes wrong, one can hear a difference in the sound of the z-motors: this may just be that the U z-motor is already having an issue in this movement, even thou it does go in the right direction still, but it is the movement just after that is in the wrong direction

Also just to note, when the movement is 5mm, it seems to be just in opposite direction, but at same speed and amount, where as the shorter movements (0.5 or 0.05mm from Panel, or 0.1 or 1mm from DWC) seem to also have an increased jump in speed and amount moved, as well as in the opposite direction!

don't know what to try, strangely everything seems to indicate issue with what ever motor is assigned as U, irrelevant what side of the machine it is! For me this can only be an issue on board the Duet, where somehow the software is going crazy!

I am about to order a new Duet Ethernet and Expansion board, if you think this will help, to diagnose this issue better... if on replacing the Duet or Expansion board the issue clears up, then I'll get back to you about how to resolve that... does that sound OK to you?

Cheers!
Andy

PD I would replace first the ribbon cable between the boards, test, then replace the Expansion board, test, then finally replace the Duet. If have to replace the Duet, would then double check re-replacing the cable and expansion board with the present ones, just to make sure

@dc42 no, haven't tried exchanging stepper drivers, I had ruled out issues with the stepper drivers, as swapping ONLY the connectors (Z to U and U to Z) on the expansion board transferred the issue to the other motor: the actual stepper drivers stayed connected to their respective motors, so the left hand z-motor (originally Z) kept the left hand driver, and the right hand z-motor (originally U) kept the right hand driver - when swapped on the expansion board, U to now use the left, and Z to the right; if the right hand driver itself was having issues, then the same right hand motor (now Z) would still show the issue, regardless of whether it was connected/assigned as Z or as U... at least that is how I understand it!

It seemed (until swapped Z & U, and also X and Y) that maybe the E8 port was maybe having issues, but the issue follows what ever motor is assigned as U, regardless of where U is connected, and regardless of whether U is the left or right motor... strange to say the least!

That said I will revise this suggestion next time I am at the machine...

cheers!
Andy

@dc42
ok, I'll try that monday... I generally use a fingernail, but when have to use the screen more, as seen, I use a piece of filament with the tip melted into a rounded blob

cheers!
Andy

@dc42 the file is a "notebook" where I copy all changes from the DWC, once I make any changes there...
0_1524343174660_actual config.txt