I have made homing and sent 2 times the G32 command. I don't know the meaning of the answer. I attach what Repetier Host reads. Please explain better: shall I disable the Autolevel option or shall I avoid to do G29 ?
09:25:28.911 : N31 G32*42
09:25:36.181 : Z-probe:20.345 X:40.00 Y:170.00
09:25:47.973 : Z-probe:20.077 X:290.00 Y:170.00
09:25:58.727 : Z-probe:20.295 X:140.00 Y:210.00
09:25:58.727 : plane: a = -0.0011 b = 0.0014 c = 20.1455
Hello, I have made 2 tests according to your advices. 1st test type I have printed 2 objects with extruder 1 and 17, I have repeated the test with 2 objects and extruders 1 and 25 with the extruder cleaning commands at each tool change. Result: same behaviour as printing the whole 6 objects. 2nd test type I have repeated the test with 2 objects and extruders 1 and 25 with the extruder cleaning commands limited to the following:
; tool change
T[next_extruder]
M401; store current position in memory
G1 X0 Y45 Z5 F2000
M402 Z F2000; resume Z stored position
M402 F2000; resume stored position
M114; read current position (X,Y,Z,E)
M117 offset at layer [layer_num] and [layer_z]mm;
No more Z error !!
Apparently G1 Z only movements between M401 and M402 Z cause the problem ..
First G29 is not autoleveling. That just measures average height of 3 points and uses average as Z. Also does not activate autoleveling while G32 does measure rotation and activates autoleveling. plane: a = -0.0011 b = 0.0014 c = 20.1455 Transformation matrix: 0.999999 0.000000 0.001070 0.000002 0.999999 -0.001427 -0.001070 0.001427 0.999998
Plane equation is Z = a * x + b * y + c So b = 0.0014 means every 100mm you move y it changes z by 0.14mm. So a 200mm bed has an error of 0.28mm over complete y axis. That is much compared with a layer width so correcting it a bit physical would be good.
Reduced test is a good way. Also that reducing commands between M401/M402 solved it. But I do not think a single Z move causes the problem. Single or combined should not matter. I'd first remove only the Z0 moves - these are the most likely source. In general add back moves now that it works until it stops working and post the new combo not working with the last added line. That is the one causing the problem.
Also a small warning: your Z5 moves might also go down if objects are higher! Better is to switch to relative mode and definitively go up as a final solution.
Hello ! Finally I have identified "the new combo not working" after very long testing !! Here is the result:
; tool change GCode
T[next_extruder]
M401; store current position in memory
G91; Use relative coordinates
{if layer_z < 24}G1 Z+5{endif}; level "up" to bucket after XY Homing to avoid interference
G90; Use absolute coordinates
G1 X0 Y45 Z5 F2000
G11; un-retract
G1 Z0; level down to bucket rubber
G1 E20 F100; extrude 20mm of filament at 1,7mm/sec
G1 Z5 F800; raise the nozzle to avoid damage to the purge bucket
M402 Z F2000; resume Z stored position
M402 F2000; resume stored position
M114; read current position (X,Y,Z,E)
M117 offset at layer [layer_num] and [layer_z]mm;
If I delete the commands: G11; un-retract G1 E20 F100; extrude 20mm of filament at 1,7mm/sec
the problem does not appear.
Adding those commands in the positions inside the above GCode sequence instead generates the problem. In practice the problem consists in adding some positive Z offset at every change of tool (in other words every time the tool change GCode is executed).
I would add the photos where the problem does not appear and those where the problem is evident but at every image file It says "file too large"....
Note: I have not sent initial autoleveling command G32: only Homing + G29 to keep the same conditions of the preceding tests.
O bet on the G11 since you are missing G10. They must always be like a pair inside M401/M402. If you have RETRACTION_Z_LIFT different then 0 they will move z (your problem) by changing the z offset. So only with matching calls the offsets get reset.
Setting RETRACTION_Z_LIFT 0 makes this effect at least disappear so you can use G11 without G10.
Hope I'm right with that, but reading the code I see that this is a possibility to get a z move.
With G92 E0 you do not need G10/G11 at all as you can add any extrusion you like. But pairing them or removing them would both solve the problem I think.
I need retraction because I return exactly at the last point of my previous color print with a different color and this way the extruder leaves a spot of the changed color on the previous print. I modified the code this way:
G92 E0; reset extruder position
G1 E30 F300; extrude 30mm of filament at 5mm/sec
G92 E0; reset extruder position
G10; retract
M402 Z F2000; resume Z stored position
M402 F2000; resume stored position
G11; unretract
M114; read current position (X,Y,Z,E)
M117 offset at layer [layer_num] and [layer_z]mm;
Do you know a better way to avoid the spot ? It would be to return 1 mm up wrt the stored position:
Instead of G10 you can always use G92 E0 G1 E-1 F1800 ... M402 T F2000 G92 E0 M402 X0 Y0 F12000 G1 E1 F1800 M402 F2000
You need to unretract before last M402 that sets E to last value. Or you will start with wrong E value, also slicer might add a G92 E0 after extruder switch anyway so fix it as well.
Question: should it be possible to manage the 2 Diamond Extruders as 2 different hotends but as mixing extruders of max 16 virtual extruders each ? If the answer is yes what are the modifications in firmware ? Thank you for your time.
In V1 this will not happen. For V2 that is what I want, but did not have started mixing extruders in V2, mainly because I do not have such a printer. What board do you use for your printer and which motion type (cartesian/core xy). Maybe you could become a tester for V2 so I can write the mixing code and you do testing if it works. I guess it will also be more flexible so not required 16 per mixing but any number you can store. Or even only one and you just switch mixing ratios.
I use Arduino Mega and Ramps 1.4 plus additional board for signal expansion, Cartesian printer 500 x 500 x 500 mm dimensions self built from scratch. I would like to use Panucatt RE-ARM as it is fully RAMPS 1.4 compatible... or any similar solution that keeps backward compatibility. The reason for using Arduino Mega and Ramps 1.4 is that I have found it as the most open hardware solution with the widest firmware compatibility and support. Every firmware can run on it and I don't like proprietary solutions. Yes, I would like to be a tester for V2 and I thank you for the proposal but does it mean to restart building the whole printer from scratch ?
Using V2 means building firmware from scratch, not the printer. But RAMPS is currently not supported in V2. Currently only Arduino Due based boards like RADDS work. Need to write the HAL layer for AVR or better adjust it. Planned but not done yet.
Therefore to run V2 I need to replace RAMPS with RADDS but it cannot drive 6 extruder motors, only 3, so I have to add other electronics for it and I have to use Arduino 2. To do so I have to remap the connections of all the devices ... I have also Nema 32 motor drivers for XYZ axes .. A lot of work...
OK. Meantime I have a little question just arosen: Is it possible to use M600 (change filament) in a mixing extruder configuration but moving one only wire instead of all togheter ? The reason why is to be able to remove or change a single wire of the diamond extruder. Thank you for the answer and your time.
Does it move all same amount or according mixing ratio? In latter case you would need to select a virtual extruder with one extruder having 100% of steps. Then it might be possible. Don't have one so not 100% sure what firmware does here, but think it uses mixing ratios.
Even if I set the 100% ratios (and 0% the others) selecting the corresponding virtual extruder and moving with repetier host I move the selected virtual extruder only so one only wire. At the same time if I issue the M600 cmd all the 6 wires (double Diamond) move together of 1/6 amount. Just tested.
You see the special case for mixing extruder to retract all filaments. Reason is a problem you otherwise have. That function is used by G10/G11 which should be used mixing extruders instead of slicer retraction. If you do not retract all the same amount you can not really remove pressure correctly when doing a mixing print. If you only use one color it would of course be no problem. So G10/G11 were modified to retract all and as you might guess M600 uses also that function for retraction. So if you remove the special cases with #if MIXING_EXTRUDER M600 will do what you think but G10/G11 not do what needed.
New revised Question: would it be possible to manage the 2 Diamond Extruders as not 2 but 1 only mixing extruder driving 2 different heaters one for each diamond ? Driving means that I can issue a gcode command to power on and off independently each one of the 2 extruder heaters. At the same time I will not move in the mixing ratio (obviously) the filaments of the diamond extruder whose heater is powered off... This way I emulate 2 mixing extruders (with some limitations being intelligent driving with some risk of errors but it is woth doing...) If the answer is yes what are the modifications in firmware ? Thank you again for your time.
Each extruder can only have one heater and temp sensor. So with current datastructures I don't see 2 heaters for 1 extruder. You also need then 2 output temperatures for one extruder and that will no host understand.
In other words: 2 extruders but only 1 mixing of 6 filaments. What is very useful is to power on and off separately each diamond extruder. The only one 6 filament mixing can be managed.
I have done such configuration by assigning the first 3 extruders (0 to 2) to the heater 0 thermistor 0 and the last 3 extruders (3 to 5) to heater 2 and thermistor 2 normally used for extruder 2 then I have selected the mixing extruder option to actually do the mixing among 6 filaments/extruders.
The setup options are allowed inside the FW config tool.
Ok, if it compiles you have at leats a chance to do it with not too much changes. Main question is where temperatures get assigned to - with mixing extruder all get mapped to extruder 0. So you need to modify that I think. Also the heat control loop might skip all extruders except 1, you need to modify it to use 0 and 3 instead.
Output of temperature will be a paint I guess. Hosts assume one temperature for mixing etxruder only. If you say you have no mixing etxruder you get 16 temperatures. At least in repetier-server you can say which extruder is taking the real temperature so you can use that and only output T0: and T16: if first 16 are are mapped to first the next 16 to second extruder. But it will look a but awkward to have 32 extruders in lists.
Comments
Please explain better: shall I disable the Autolevel option or shall I avoid to do G29 ?
09:25:28.911 : N31 G32*42
Thanks of your work, I understand that it is difficult.
Walter
I have made 2 tests according to your advices.
1st test type
I have printed 2 objects with extruder 1 and 17, I have repeated the test with 2 objects and extruders 1 and 25 with the extruder cleaning commands at each tool change. Result: same behaviour as printing the whole 6 objects.
2nd test type
I have repeated the test with 2 objects and extruders 1 and 25 with the extruder cleaning commands limited to the following:
No more Z error !!
Apparently G1 Z only movements between M401 and M402 Z cause the problem ..
What do you think ?
Walter
plane: a = -0.0011 b = 0.0014 c = 20.1455
Transformation matrix: 0.999999 0.000000 0.001070 0.000002 0.999999 -0.001427 -0.001070 0.001427 0.999998
Plane equation is Z = a * x + b * y + c
So b = 0.0014 means every 100mm you move y it changes z by 0.14mm. So a 200mm bed has an error of 0.28mm over complete y axis. That is much compared with a layer width so correcting it a bit physical would be good.
Reduced test is a good way. Also that reducing commands between M401/M402 solved it. But I do not think a single Z move causes the problem. Single or combined should not matter. I'd first remove only the Z0 moves - these are the most likely source. In general add back moves now that it works until it stops working and post the new combo not working with the last added line. That is the one causing the problem.
Also a small warning: your Z5 moves might also go down if objects are higher! Better is to switch to relative mode and definitively go up as a final solution.
Finally I have identified "the new combo not working" after very long testing !!
Here is the result:
If I delete the commands:
G11; un-retract
G1 E20 F100; extrude 20mm of filament at 1,7mm/sec
the problem does not appear.
Adding those commands in the positions inside the above GCode sequence instead generates the problem.
In practice the problem consists in adding some positive Z offset at every change of tool (in other words every time the tool change GCode is executed).
I would add the photos where the problem does not appear and those where the problem is evident but at every image file It says "file too large"....
Note:
I have not sent initial autoleveling command G32:
only Homing + G29 to keep the same conditions of the preceding tests.
I wait for your answer.
Thanks.
Walter
If you have RETRACTION_Z_LIFT different then 0 they will move z (your problem) by changing the z offset. So only with matching calls the offsets get reset.
Setting RETRACTION_Z_LIFT 0 makes this effect at least disappear so you can use G11 without G10.
Hope I'm right with that, but reading the code I see that this is a possibility to get a z move.
Before you were writing I had already imagined the solution:
Yes it consists of both pairing G10 and G11 but not only !
A reset extruder position before and after extrusion did the trick !
I added also an initial G32 instead of G29 aaaand ...
everything works !!!
Thank you very much !
Please confirm also that I am right.
Walter
I modified the code this way:
G92 E0; reset extruder position
Do you know a better way to avoid the spot ? It would be to return 1 mm up wrt the stored position:
e.g. M402 X Y Z+1 would it be a valid command ?
Walter
G92 E0
G1 E-1 F1800
...
M402 T F2000
G92 E0
M402 X0 Y0 F12000
G1 E1 F1800
M402 F2000
You need to unretract before last M402 that sets E to last value. Or you will start with wrong E value, also slicer might add a G92 E0 after extruder switch anyway so fix it as well.
Do not us e+ in Gcode. Omit it simply.
Thanks.
Walter
If the answer is yes what are the modifications in firmware ?
Thank you for your time.
Walter
I would like to use Panucatt RE-ARM as it is fully RAMPS 1.4 compatible... or any similar solution that keeps backward compatibility.
The reason for using Arduino Mega and Ramps 1.4 is that I have found it as the most open hardware solution with the widest firmware compatibility and support. Every firmware can run on it and I don't like proprietary solutions.
Yes, I would like to be a tester for V2 and I thank you for the proposal but does it mean to restart building the whole printer from scratch ?
Walter
To do so I have to remap the connections of all the devices ... I have also Nema 32 motor drivers for XYZ axes .. A lot of work...
Why not to keep backward compatibility ?
The reason why is to be able to remove or change a single wire of the diamond extruder.
Thank you for the answer and your time.
Walter
Just tested.
Walter
You see the special case for mixing extruder to retract all filaments.
Reason is a problem you otherwise have. That function is used by G10/G11 which should be used mixing extruders instead of slicer retraction. If you do not retract all the same amount you can not really remove pressure correctly when doing a mixing print. If you only use one color it would of course be no problem. So G10/G11 were modified to retract all and as you might guess M600 uses also that function for retraction. So if you remove the special cases with #if MIXING_EXTRUDER M600 will do what you think but G10/G11 not do what needed.
This way I emulate 2 mixing extruders (with some limitations being intelligent driving with some risk of errors but it is woth doing...)
If the answer is yes what are the modifications in firmware ?
Thank you again for your time.
Walter
Thanks.
Walter
The setup options are allowed inside the FW config tool.
Also the heat control loop might skip all extruders except 1, you need to modify it to use 0 and 3 instead.
Output of temperature will be a paint I guess. Hosts assume one temperature for mixing etxruder only. If you say you have no mixing etxruder you get 16 temperatures. At least in repetier-server you can say which extruder is taking the real temperature so you can use that and only output T0: and T16: if first 16 are are mapped to first the next 16 to second extruder. But it will look a but awkward to have 32 extruders in lists.