Firmware 1.19RC1 released - please help us with testing!
-
DJDemonD, thanks for your report. The diagnostic info that indicates that the Move module was trying to print some debug info to USB but you didn't have a USB connection to a PC. The Move module only prints debug into when you send a M111 S1 command to enable debugging. Is it possible that you did that?
If you don't think you did, please connect a USB cable and attach to the Duet using pronterface or similar, and see what it is trying to print.
It produced this output just after a homeall
ERROR] Traceback (most recent call last): File "printrun\printcore.pyc", line 241, in _readline File "printrun\pronterface.pyc", line 1713, in recvcb File "printrun\pronterface.pyc", line 1669, in update_pos ValueError: could not convert string to float:But didn't crash this time, (i just reflashed rc1 and reset prior to doing this) this is the m122:
=== Diagnostics === Used output buffers: 3 of 32 (12 max) === Platform === RepRapFirmware for Duet WiFi version 1.19RC1 running on Duet WiFi 1.0 Board ID: 08DDM-9FAM2-LW4SD-6J9FL-3S46P-K0X3W Static ram used: 21144 Dynamic ram used: 96336 Recycled dynamic ram: 1304 Stack ram used: 1304 current, 5148 maximum Never used ram: 7140 Last reset 00:04:55 ago, cause: software Last software reset reason: User, spinning module GCodes, available RAM 7440 bytes (slot 1) Software reset code 0x0003, HFSR 0x00000000, CFSR 0x00000000, ICSR 0x00400000, BFAR 0xe000ed38, SP 0xffffffff Error status: 0 Free file entries: 10 SD card 0 detected, interface speed: 20.0MBytes/sec SD card longest block write time: 0.0ms MCU temperature: min -269.8, current 29.9, max 30.3 Supply voltage: min 11.8, current 12.2, max 12.4, under voltage events: 0, over voltage events: 0 Driver 0: stalled standstill Driver 1: stalled standstill Driver 2: stalled standstill Driver 3: standstill Driver 4: standstill Date/time: 2017-08-04 18:54:12 Slowest main loop (seconds): 0.004898; fastest: 0.000033 === Move === MaxReps: 3, StepErrors: 0, FreeDm: 240, MinFreeDm 228, MaxWait: 82567ms, Underruns: 0, 0 Scheduled moves: 56, completed moves: 56 Bed compensation in use: none Bed probe heights: 0.000 0.000 0.000 0.000 0.000 === Heat === Bed heater = 0, chamber heater = -1 Heater 1 is on, I-accum = 0.0 === GCodes === Segments left: 0 Stack records: 2 allocated, 0 in use Movement lock held by null http is idle in state(s) 0 telnet is idle in state(s) 0 file is idle in state(s) 0 serial is idle in state(s) 0 aux is idle in state(s) 0 daemon is idle in state(s) 0 queue is idle in state(s) 0 autopause is idle in state(s) 0 Code queue is empty. Network state is running WiFi module is connected to access point WiFi firmware version 1.19beta10 WiFi MAC address 5c:cf:7f:ee:63:48 WiFi Vcc 3.10, reset reason Turned on by main processor WiFi flash size 4194304, free heap 39760 WiFi IP address 192.168.0.127 WiFi signal strength -42dBm HTTP sessions: 1 of 8 Socket states: 2 0 0 0 0 0 0 0 Responder states: HTTP(1) HTTP(0) HTTP(0) HTTP(0) FTP(0) Telnet(0) -
Also and it may be entirely unrelated to RC1 my grid compensation setup is:
M557 X0:260 Y0:190 S50 ;define mesh
M376 H10 ;taper off after 10mm
But it only moves 20mm between probing points (same on beta11) are 20x20 the largest grid squares it will probe? -
20mm is the default, but it can use more, and I have just tested it. I suspect that your M557 command isn't working for some reason, e.g. because you have subsequently used G29 S1 to load a previous height map that used 20mm spacing.
You can run M557 with no parameters to see what the current grid is.
-
Thanks David, I'll try not loading the grid in config.g but load it in start gcode instead.
-
I've just released 1.19RC2:
- Changed the way we handle tool offsets during a tool change to (I hope) better meet the needs of both IDEX and conventional dual-nozzle printers
- Fixed spurious error message when G92 E0 is processed (this affected users who used absolute extrusion coordinates when slicing)
- Fixed Duet3D filament sensor data receive code
-
CoreXYU still broken in RC2. This time I tried first X than U with no problem. Then changed to second tool and did a X-1 in the interface. This crashed the second tool into the rail at max X/U…
Edit: I did not dare try a home all
-
Hi Lars, thanks for trying RC2. However, as I have neither an IDEX machine nor a CoreXY machine to test on, I need more data:
1. When you changed to a second tool, where on the X/U axis were the two carriages?
2. Please publish your homing files so that I can simulate them as best I can.
3. Please run some more tests. You can help protect the mechanics of your machine by reducing motors currents, as well as having a hand on the power switch.
Try homing X, Y, U and Z individually. When you have found one that doesn't work, run the commands in that homing file individually, then you can tell me which command is giving the problem.
Thanks - David
-
Lars, I think it might be something peculiar with CoreXYU and tools on RC2 as well. I have tested tool changing on a Cartesian IDEX and it appears to work correctly. Can you also publish your tool change macros pls.
-
Hi Lars, I think I just found the problem with homing Core kinematics, so no need for those tests now.
-
IDEX still dont work.
The z offset is still not used on the printheads, while it is still displayed correctly in the interface. - in the video, the purple toolhead should have been printing 10mm over the bed.
Worse, the heads craches on second toolchange.Config files:
www.kulitorum.com/download.zipVideo:
https://www.youtube.com/watch?v=7ePx8PGa_MgKulitorum
-
Thanks Kulitorum, that's helpful. Which tool is printing which colour? I'm guessing that T0 is black and T1 is purple so that the second tool change is T1->T0, but maybe you have it the other way round?
-
Hmm, I just realized that after the second toolchange, as the heads craches, it is actually printing at z10….
But the z offset of 10mm is defined for tool 1 (left tool) and is used for tool 0 (right tool) but only on the second usage of that tool.
-
You are right - tool 0 is the right tool, black filament, tool 1 is the left tool, purple filament.
-
And here's the gcode for the print - for reference:
-
Thanks. I think the Z offset is working correctly. You have specified a Z offset of +10mm for tool 1, which means that tool 1 nozzle is 10mm higher than the reference point. So it should be trying to print 10mm below the bed surface; but you probably have a limit set at 0mm. If you want the tool to print 10mm above the bed, you need to specify a tool Z offset of -10mm in your G10 command.
Using your configuration, I have replicated the problem of the U axis moving when you re-select tool 0 and move the head in X, and I am investigating it.
-
Ok, cool. If this is correct, then why is tool 0 printing at z10 for the last 5 secs if my video?
-
That would because when tool 1 was selected, moving to Z offset 0+first layer height was prohibited, so it moved to 10mm + first layer height. Then when you reselected tool 0, Z was at 10 + layer heights and now G1 Z command has been read in the gcode file yet.
-
Just tested with head 0 offset of -10 and G1 Z commands after tool change, that everything seems to be working, apart from the head crash. Cool.
-
Kulitorum, thanks.
Lars and Kulitorum, I've just released RC3 with fixes for (I hope) CoreXY homing and IDEX tool change. Please try it (carefully - I suggest you reduce motor currents at first).
-
Thanks. Just tried it, and on the first change to T1, this happens:
T0 is moved away correctly.
T1 should move to R2, (R1?) but it tries to move the wrong direction, and just slams the head left.I let T1 print (outside the printbed) and when it was done it slammed left again. Then T0 did its thing correctly.
Then T0 parked, and T1 printed correctly. (although offset 2mm left because of the headcrashes)
