RepRapFirmware 3.6.0-alpha.4+3 available for testing

o_lampe

@edsped Maybe you could disable IS during toolchanges?
The acceleration on short tracks is different now and moving on the edge to make the toolchange as fast as possible might have flaws now and then...

dc42

@edsped another thing that may help is to use M400 between critical moves of a tool change, for example between the pull-in move and the locking motor move when picking a tool up. Using IS in 3.6 will overlap adjacent moves to some extent. So in this example, the lock motor will start to move before the pull-in has completed. This may or may not matter, depending on the speeds of the moves and the type and frequency of IS in use.

edsped

@o_lampe I've lowered tool change speeds to see if that helped and it didn't. Initially my rationale for high speeds was to minimize ooze in an effort to eliminate the need for a wipe tower. It didn't work and I never lowered them but have more than halved them the past few days...

edsped

@dc42 One thing that is consistent when there's a tool drop is that the locking pin isn't fully rotated to the lock or unlock position which initially had me thinking there was mechanical binding. I'll stick an M400 before the call to the tool lock/unlock macro to see if that helps. I've reduced my tool change speeds by about 60% to see if that helped and it made no difference, but I'll leave them low until I figure out why I'm not getting proper tool engagement.

edsped

@dc42 I added M400 prior to macro calls for lock and unlock and stuck one in the macro as well... Following are the macros if that helps and a couple of pictures showing the pin when a failure occurs.. Pin should be horizontal when unlocked and stop should be at the limit switch, when there's a tool drop the stepper never reaches the limit switch...

tool_lock.g

; Engage the toolchanger lock. RepRap Firmware V2.0.1 version.
G91                 ; Set relative mode
G1 U10 F5000 H0      ; Back off the limit switch with a small move
M400
G1 U200 F5000 H1    ; Perform up to one rotation looking for the torque limit switch
;G1 U200 Y0.5 F5000 H1    ; Perform up to one rotation looking for the torque limit switch
G90                 ; Set absolute mode

tool_unlock.g

; Disengage the toolchanger lock
G91                 ; Set relative movements
G1 U-4 F9000 H2     ; Back off the limit switch with a small move
M400
G1 U-360 F9000 H1   ; Perform up to one rotation looking for the home limit switch
G90                 ; Restore absolute movements

edsped

Will try the M400 commands and if they don't help, I'll disable IS at start of tool change and re-enable it after tool is picked up.

Thanks for the assistance

edsped

A quickie follow up, several prints, maybe 50'ish tool changes and no issues. It appears as if the M400 is helping.

Kiolia

I want to chime in and report that the 3.6.0 5+1 alpha has been working well for me. I have not run any long prints, and I don't probe or tool change, but I changed over from 3.5.1 because I was hitting suspicious layer shifts at well below expected accelerations for printing moves only (not for travels) in speedboat testing. I have run 25 prints since changing over Sept 3rd, along with various non-printing tuning and tests, at accelerations from 50-200k and in-print speeds up to 900mm/s, on a 6WD delta at 400 steps/mm (6HC with a 3HC running a 2WD extruder), as I've been working into the three-minute range on regulation boats. (Yes, it's not a particularly useful pastime, but my machine is finally finished and I've gotta do it once -- plus I'm hoping it's a useful stress test of the new motion stuff in 3.6.0.) The new IS melts down print crispness at these accels, but after some deep breathing I've concluded that's not a bad thing -- if you want crispy prints, the answer is to print in the accel range that's sane for your machine, anyway.

Part of my testing has been aimed at stress testing the delta segmentation change -- I've tested from 100 to 400 seg/s with 0.1 to 0.2mm segment length, as well as accidentally 0.1seg/sec and 400mm min length, and apart from the latter booboo there is little observable difference in quality at high speeds and no difference I've yet found in terms of speed ceiling. I have found that high speeds with high-poly models are causing reports of underruns in the first array slot and, sometimes, very small numbers of LaErrors -- e.g., a 67-layer test vase print with a portion that is a 200-segment, 10mm-diameter circle, sliced at 350 x 100k x 20 jerk consistently reports back underruns [800+,0,0] -- but I don't have comparison data from before I updated, so I don't know if this has anything to do with the alpha. I do know that the circle in that stress test print shows evidence of slowdowns starting at about the same segment count as the move queue length, and that extending the queue length with M595 causes proportionately more reported underruns. (I changed SD cards, just to see if the originally-supplied card with its 4kb clusters was an issue, but a new 32GB card with 32kb clusters did not change anything.) For my foolishly-fast speedboat runs, I've dodged the issue by enabling Arc Welder, which seems to work just fine.

To date I have yet to see a single reported hiccup, regardless of LaError or underrun counts.

I hope the above is useful!

dc42

@Kiolia thanks for your report. It's good to hear when things are working well, not just when there are problems.

Kiolia

@dc42 Cheers! And if there's anything in particular I can look out for and/or try while I'm breaking in my delta, please let me know.

dc42

@Kiolia not really, just watch out for changes in behaviour. The only bug I am aware of in 3.6 that is not in 3.5.3-rc.1 relates to expansion boards and homing moves.

edsped

Day 3 without any tool drops so I'm going to say inserting M400 prior to tool lock/unlock macros is working. Out of curiosity, will this be addressed in the final release or will the M400 always be required? It won't matter much for me as I'll likely forget to remove it when the 3.6 is released but I am curious.

dc42

@edsped I haven't decided yet. We'd need to either disable IS throughout tool change files, or implicitly wait for motion to stop between certain pairs of moves - but what pairs, exactly? I'm not sure that either of those would be appropriate in all circumstances. We could add a means of specifying that a certain axis is used as a tool locking mechanism, but would that be any better than advising users where to use M400?

oliof

If people don't want to sprinkle M400s, they could also disable and re enable IS at the beginning and end of the macros.

dc42

@oliof yes. I am considering extending M593 to allow IS to be turned off and then turned on again without needing to specify the parameters.

Kiolia

Okay, I'm back with a problem report with my delta. I noticed during extrusion "blob" testing tonight that it was making a light clunking noise during each blob extrude. At first I assumed it was the extruder, but it was happening on all the blobs, and doing it the most on the lowest cubic (slowest) ones. To judge from finger-on-arms, it may only be the Z axis (AWD, so this is two steppers). IS on/off does not affect it. It is reproducible without extrusion, too, using a very slow move with Z component like G1 X3 Y1 Z20.5 F16.84 starting from X0 Y0 Z1. There is no discernible interval to the clunking; it sounds random, and it happened at least once on most of the blobs, which were done across the bulk of the bed area. M122 shows nothing amiss to my eyes. I can confirm that this wasn't happening with nigh-identical GCode in 3.5.1. I think I've seen this or something similar reported already, but I thought that was connected somehow to IS, and this doesn't seem to be.

droftarts

@Kiolia Hi, thanks for your report. I think this may be related to this issue: https://github.com/Duet3D/RepRapFirmware/issues/1015. I don't think this has been fixed in 3.6.0 yet, so one for @dc42.

Ian

droftarts created this issue in Duet3D/RepRapFirmware

open Input shaping on linear delta causes Z motor clunking at specific bed locations #1015

Kiolia

@droftarts Some additional test results. At least for me, it is new for 3.6.0 and specific to very slow moves, not IS or bed location-related. I executed the following sequence of moves this morning, starting from X0 Y0 Z1, and heard the noise (which sounds like a light motor skip) multiple times on all 6. With the exception of move number 4, which had many skip/clunk noises throughout, the starts of the moves did NOT make noises at first -- I would estimate at least the first 10-15 seconds of the other 5 were all noise-free.

dc42

@Kiolia thanks, I'll test this on my own delta next week. @droftarts can you test this too?

Kiolia

@dc42 If it's needed for repro, I'm running x32 on 0.9s / 16Ts for 400 steps / mm and set segmentation to 400/sec 0.2mm min length. (if you need the rest of my config let me know.) I haven't tested to see if there's a specific speed threshold for the behavior, but the way that the noises often don't start for some seconds makes me wonder if the duration of the move is a factor, rather than just the speed.