3.3 Final destroys my CoreXYUV (but RC3 is OK)

dc42

@deckingman I suspect it is the same fault as these:

https://forum.duet3d.com/topic/24553/rrf-3-3-does-not-respect-max-accel-in-first-moves-after-tc/8
https://forum.duet3d.com/topic/24660/issues-after-prime/71

In which case, what triggers the fault is the combination of G4 P500 (which waits for the move queue to empty), G1 Z5 (which AFAIR in your configuration involves only motors connected to expansion boards), and G1 X165 U165 A165 Y300 V300 B300 F9000 (which involves motors connected to the main board).

If that's the case, then it will not occur using 3.4beta3. A workaround for RRF 3.3 would be to use a M400 or G4 Pxxx command before the G1 X165... command.

deckingman

@dc42 That sounds reasonable. Now I have to make some decisions. Do I try M400 or G4 in RRF 3.3? In which case there are probably numerous other instances of similar sequences in other macros that I'll need to look at. On the other hand, do I try 3.4 beta3 which, because it is a beta, might cause me other issues? Whichever route I choose, do I disconnect all the tubes and wires that connect the two gantries together (which is a lot of work) or do leave them as is and try with one hand on the emergency stop in the hope that I can hit it before too much damage occurs?

On balance, maybe I'll just stick with 3.3 RC3 and get on with the rest of my life. I'll test 3.4 when it progresses to a release candidate status.

resam

@deckingman can you turn down your motor currents to reduce potential havoc? something just above "barely moving" and below "a single finger can stop the carriage".

Phaedrux

@deckingman said in 3.3 Final destroys my CoreXYUV (but RC3 is OK):

On the other hand, do I try 3.4 beta3 which, because it is a beta, might cause me other issues?

On the plus side, you may be able to catch any other issues present before it's too late to make the final release.

deckingman

@resam said in 3.3 Final destroys my CoreXYUV (but RC3 is OK):

@deckingman can you turn down your motor currents to reduce potential havoc? something just above "barely moving" and below "a single finger can stop the carriage".

Possibly. The trouble is that my XY gantry has a moving mass of about 1.5 Kgs and the UV gantry is about 3 Kgs. So it takes a fair bit of motor current to accelerate that mass, and I can't reduce it too much. Also, once the gantries are in motion, there is a fair bit of kinetic energy which might still cause some damage when those gantries are travelling in opposing directions. For sure reducing the motor current will help - in fact it's something I do as a matter or course in my homing files in case an end stop were to develop a fault. But it won't eliminate the potential havoc.

deckingman

@phaedrux said in 3.3 Final destroys my CoreXYUV (but RC3 is OK):

On the plus side, you may be able to catch any other issues present before it's too late to make the final release.

Moral blackmail again? If the final release has issues it'll be because I didn't test the beta versions. Is it really my job to beta test every firmware version? If so, can I get paid for doing so because it takes up an awful lot of my time.

I've been keeping an eye on things and note a number of threads highlighting issues that have thus far arisen with 3.4 betas. On the basis that I've done more than my fair share of testing over the years in the past, and spent far too many hours evaluating problems and potential solutions, I think I'll wait a while and let others do their bit. I did say that I'll try 3.4 when it gets to release candidate status.

As an aside, I tend to create a sub folder for every firmware that I download before I upload it to my machine. It makes it easier to roll back if I need to. So I have a record of all the firmware versions that I've tried and I see that I have sub folders for (among others) 3.3beta1, 3.3beta1a, 3.3beta2, 3.3RC2, 3.3RC3 and 3.3Final. So I tested 3 betas and 2 release candidates but still ended up with problems when "upgrading" to the stable version.

Phaedrux

@deckingman said in 3.3 Final destroys my CoreXYUV (but RC3 is OK):

Moral blackmail again?

How about we just forget I said anything then. Have a good day Ian.

o_lampe

@deckingman To protect your installation once and for all you could connect the gantries with a steel cable. The cable(s) would be a bit shorter than the bowden tubes or wiring.

deckingman

@o_lampe said in 3.3 Final destroys my CoreXYUV (but RC3 is OK):

@deckingman To protect your installation once and for all you could connect the gantries with a steel cable. The cable(s) would be a bit shorter than the bowden tubes or wiring.

Hmmm, it's a thought... But I like having a certain degree of freedom of movement. Currently I can move the XY gantry about 15mm in all directions relative to the UV gantry. This allows me to use a script which generates UV moves for the extruder gantry (UV) such that it follows the hot end gantry but doesn't replicate every small move. For example the extruder gantry will "park" in the centre of a hole or cylinder while the hot end gantry prints the circles. So I'd need to set the length of the steel wires fairy accurately such that they allow (say) 12mm of movement.

But then what would happen if a firmware bug meant that one gantry tried to do something wildly different to the other? I suspect that I'd likely end up with bent rails or broken gantry parts. The problem with having relatively high moving mass is that one needs to use relatively powerful motors which are capable of doing damage if they are constrained from doing what they want to do.

o_lampe

@deckingman
...that's how I destroyed my CNC.

Another crazy idea would be to add a strain gauge or some other emergency switch to the steel cable, but using bullet proof Firmware would be best.
Better have and don't need, than need and don't have they say in Germany

deckingman

@o_lampe said in 3.3 Final destroys my CoreXYUV (but RC3 is OK):

@deckingman
...that's how I destroyed my CNC.

Another crazy idea would be to add a strain gauge or some other emergency switch to the steel cable, but using bullet proof Firmware would be best.
Better have and don't need, than need and don't have they say in Germany

Before I converted to a driven gantry for the extruders (UV), I used a passive gantry. That is to say, there were no motors on the UV gantry and it was connected to the hot end gantry with two strings (not steel wires). So the hot end kind of dragged the extruders around. But when I did long fast moves, once the 3Kg or so of 6 extruders got up to speed, it didn't want to stop and change direction so the strings used to snap often, and/or they would jerk the hot end causing it to lift off the print