Max number of virtual extruders

walbux · May 2019

Hello,
I am very satisfied of the Repetier FW and I am experimenting new things like a mixing extruder with more than 3 pla filaments.
To test it I would need to exceed the max number of virtual extruders in M163 and M164 gcode commands.
Unfortunately when I exceed the 15 the mixing alghorithm does not work any more. Example:

This sequence works

; Cyan

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P0
M163 S5 P0

M164 S0

while this doesn't work

; Cyan2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P0

M163 S5 P0

M164 S16

Thanks for your answer.

Walter

Repetier · May 2019

The number of virtual extruders is fixed at 16 with numbers 0-15, so any other virtual extruder will not work. Reason is limited space in eeprom for extruders and 16 is already a lot. I guess in V2 it will be more flexible, but currently it does not even have virtual extruders.

walbux · May 2019

I currently do not use the eprom storing (EPROM MODE DISABLED) and to change a configuration parameter I prefer to reflash the FW. The reason is to be sure every time of what is the booting configuration.

In this condition is there a way to modify the max number of virtual extruders to 32 for example ?

The alternative would be to reload one of 2 Virtual Extruders config in the middle of a print..

The reason is to foresee preset shades of colour (for example mixing white and black or red and white)
Thanks.

Walter

Repetier · May 2019

Firmware is not prepared for flexible virtual extruders. If you find the arrays and check if there are range checks in c++ code you can modify it of course.

The other thing is how many colors/extruders do host and slicer softwares support. I know we support 16. Don't think you can use more there.

walbux · May 2019

Apparently Slic3r supports more than 16 extruders. I have tried to config them and it accepts such setup.

Can you please indicate which files to modify to increase the virtual extruders to 32 while in EPROM MODE DISABLED ?
Thanks.

Walter

Repetier · May 2019

Actually only in extruder.h the line

#define VIRTUAL_EXTRUDER \

16 // don't change this to more then 16 without modifying the eeprom positions

needs to be changed. As said eeprom will not work - it will still try to write the extra extruders but that will overwrite other settings since eeprom.h defines

#define EEPROM_EXTRUDER_LENGTH 100
for all extruder variables. You will need to increase that but then you overwrite variables stored after extruder which you then also must move. Or disable eeprom that it's all you need to do.

walbux · May 2019

Thanks a lot !
I will keep EPROM MODE DISABLED.

Walter

walbux · September 2019

Hello,
I have made some testing configuring 32 virtual extruders like this:
in extruder.h the line

#define VIRTUAL_EXTRUDER 32 // don't change this to more then 16 without modifying the eeprom positions
and in configuration.h
#define EEPROM_MODE 0

Then I have sent the script:

; Cyan

M163 S0 P1

M163 S1 P0

M163 S2 P0

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S0

; Ocean

M163 S0 P5

M163 S1 P1

M163 S2 P0

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S1

; Blue

M163 S0 P1

M163 S1 P1

M163 S2 P0

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S2

; Violet

M163 S0 P1

M163 S1 P5

M163 S2 P0

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S3

; Magenta

M163 S0 P0

M163 S1 P1

M163 S2 P0

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S4

; Raspberry

M163 S0 P0

M163 S1 P5

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S5

; Red

M163 S0 P0

M163 S1 P5

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S6

; Orange

M163 S0 P0

M163 S1 P1

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S7

; Yellow

M163 S0 P0

M163 S1 P0

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S8

; Spring Green

M163 S0 P1

M163 S1 P0

M163 S2 P5

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S9

; Green

M163 S0 P1

M163 S1 P0

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S10

; Turquoise

M163 S0 P5

M163 S1 P0

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S11

; Cyan-Brown

M163 S0 P2

M163 S1 P1

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S12

; Magenta-Brown

M163 S0 P1

M163 S1 P2

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S13

; Yellow-Brown

M163 S0 P1

M163 S1 P1

M163 S2 P2

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S14

; Brown

M163 S0 P1

M163 S1 P1

M163 S2 P1

M163 S3 P0

M163 S4 P0

M163 S5 P0

M164 S15

; Cyan2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P0

M163 S5 P0

M164 S16

; Ocean2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P5

M163 S4 P1

M163 S5 P0

M164 S17

; Blue2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P1

M163 S5 P0

M164 S18

; Violet2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P5

M163 S5 P0

M164 S19

; Magenta2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P0

M163 S4 P1

M163 S5 P0

M164 S20

; Raspberry2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P0

M163 S4 P5

M163 S5 P1

M164 S21

; Red2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P0

M163 S4 P5

M163 S5 P1

M164 S22

; Orange2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P0

M163 S4 P1

M163 S5 P1

M164 S23

; Yellow2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P0

M163 S4 P0

M163 S5 P1

M164 S24

; Spring Green2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P0

M163 S5 P5

M164 S25

; Green2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P0

M163 S5 P1

M164 S26

; Turquoise2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P5

M163 S4 P0

M163 S5 P1

M164 S27

; Cyan-Brown2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P2

M163 S4 P1

M163 S5 P1

M164 S28

; Magenta-Brown2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P2

M163 S5 P1

M164 S29

; Yellow-Brown2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P1

M163 S5 P2

M164 S30

; Brown2

M163 S0 P0

M163 S1 P0

M163 S2 P0

M163 S3 P1

M163 S4 P1

M163 S5 P1

M164 S31

to configure 32 virtual extruders followed by the script

T0

G92 E0

G1 E100 F120

T4

G92 E0

G1 E100 F120

T8

G92 E0

G1 E100 F120

T16

G92 E0

G1 E100 F120

T20

G92 E0

G1 E100 F120

T24

G92 E0

G1 E100 F120

to test the behaviour of the SW in a simple condition.

Repetier · September 2019

So now only ram is the limit. Great:-)

walbux · September 2019

One more question:

I experience problems in the management of the Repetier M codes:

If inside the Tool Change Custom G-Code of PrusaSlicer-2.1.0+win64-201909160915 I use the following commands:

M401 - Store x, y and z position
...
G1 Z0
G1 Z5
...
M402 - Go to stored position.

for more than 3 times inside the first layer I obtain that from the 4th switch on the M402 - Go to stored position goes to the wrong layer.

In practice I am printing 6 cubes of different colors with 6 different extruders.

When I change color I prime the next extruder in a side area of the hotbed.

From the 4th to the 6th time that i do this when I come back to the first layer printing with the M402 It seems that I am printing the upper layer because the extruder push out material flying on the hotbed at about 1 mm height.
If I repeat the same print without these Tool Change Custom G-Codes everything works perfectly.

Do you think that it is a firmware issue due to M401 - Store x, y and z position ? May it be a lack of memory space ?
Many thanks for your help.

Walter

Repetier · September 2019

V1 has only one memory socket, so position M402 should return to is last M401 being send. Pause will also use that to store position so make no pause in that case.

If I understand it correctly you are printing 6 objects one by one and at the top you memory position go to purge position and then move back and then you need to go down to z=0.2 for next layer.

So M402 should go to a higher position right? If it does then it is ok. If you do not come down to z=0 it might be z min or z probe triggering and preventing the move. Here you see what M402 execute sin the end:

void Printer::GoToMemoryPosition(bool x, bool y, bool z, bool e, float feed) {

if (memoryF < 0)

return; // Not stored before call, so we ignore it

bool all = !(x || y || z);

moveToReal((all || x ? (lastCmdPos[X_AXIS] = memoryX) : IGNORE_COORDINATE), (all || y ? (lastCmdPos[Y_AXIS] = memoryY) : IGNORE_COORDINATE), (all || z ? (lastCmdPos[Z_AXIS] = memoryZ) : IGNORE_COORDINATE), (e ? memoryE : IGNORE_COORDINATE),

feed);

feedrate = memoryF;

updateCurrentPosition(false);

}

so it is just a plain move like any other G1 moves. Only the target comes from M401 and not from g code.

walbux · September 2019

I confirm that no pause has been done. What I really don't understand is why this issue appears only at the third tool change or after T0, T4 and T8 changes have been managed correctly. The tool change gcode is the same for every tool change. I don't think the z probe is triggered because it should be triggered in the same way during the previous tool changes...

I would send you both the Prusaslicer project file .3mf and the produced Gcode files but I don't know how to attach these type of files so I send hereafter the Gcode where the issue appears.

; tool change

T16

M401; store current position in memory

;G10; retract

G1 Z5; level "up" to bucket after XY Homing to avoid interference

G1 X0.142857 Y45 F2000; move to rear X=0 Y=30 (Homing and purge bucket location)

G11; un-retract

G1 Z0; level down to bucket rubber

G1 E20 F100; extrude 20mm of filament at 1,7mm/sec

G1 Y75 F800; move slowly forward past the rubber strip

G1 Z5; raise the nozzle to avoid damage to the purge bucket

G1 Y149; go past first rubber strip

G1 Z0; continue purging on bed

G1 Y165; move slowly forward past the rubber strip

G1 X20; and 20mm to the right

G1 Y185; move slowly 20mm forward

G1 X0; and 20mm to the left

M402 Z F2000; resume Z stored position

M402 F2000; resume stored position

;M114; read current position (X,Y,Z,E)

M104 S210 ; set temperature

; Filament gcode

G1 X138.808 Y225.019 F3600.000 ; move to first perimeter point

G11 ; unretract

G1 F2400

G1 X120.886 Y225.019 E0.60663 ; perimeter

G1 X120.886 Y207.098 E0.60663 ; perimeter

G1 X138.808 Y207.098 E0.60663 ; perimeter

G1 X138.808 Y224.959 E0.60460 ; perimeter

G1 X139.215 Y225.427 F3600.000 ; move to first perimeter point

G1 F2400

G1 X120.479 Y225.427 E0.63419 ; perimeter

G1 X120.479 Y206.691 E0.63419 ; perimeter

G1 X139.215 Y206.691 E0.63419 ; perimeter

G1 X139.215 Y225.367 E0.63216 ; perimeter

G1 X139.622 Y225.834 F3600.000 ; move to first perimeter point

G1 F1200

G1 X120.072 Y225.834 E0.66174 ; perimeter

G1 X120.072 Y206.284 E0.66174 ; perimeter

G1 X139.622 Y206.284 E0.66174 ; perimeter

G1 X139.622 Y225.774 E0.65971 ; perimeter

G1 X139.236 Y225.730 F3600.000 ; move inwards before travel

...

Many thanks for your support.

Walter

Repetier · October 2019

I can not test that code anyway.
" It seems that I am printing the upper layer because the extruder push out material flying on the hotbed at about 1 mm height."
sounds more like something triggered z min I guess. Do you have #define ALWAYS_CHECK_ENDSTOPS 1? Try with 0 so z down moves are not disturbed by z min endstop triggering. Just to rule out that part. From description I hear M402 goes to top layer first only move down then is stopping too early. You go down several times so there are several times to trigger it. Only thing I can think of at the moment.

walbux · October 2019

A clarification: I don't print

1 object 1 color ciano, purge extruder...
2 object 2 color magenta, purge extruder...
3 object 3 color yellow, purge extruder...
4 object 4 color red, purge extruder...
5 object 5 color black, purge extruder...
6 object 6 color white, purge extruder... .

I print

first layer of all the objects (6 tool changes)
1 first layer of object 1 , purge extruder...
2 first layer of object 2 , purge extruder...
3 first layer of object 3 , purge extruder...
from here on the problem occurs
4 first layer of object 4 , purge extruder...
5 first layer of object 5 , purge extruder...
6 first layer of object 6 , purge extruder...

second layer of all the objects (6 tool changes)
7 second layer of object 1 , purge extruder...
8 second layer of object 2 , purge extruder...
9 second layer of object 3 , purge extruder...
hereafter the layer printing height wrt z=0 (hotbed level) seems correct
10 second layer of object 4 , purge extruder...
11 second layer of object 5 , purge extruder...
12 second layer of object 6 , purge extruder...

Repetier · October 2019

Ok, but that seems to be your extruder switch code

M401; store current position in memory

;G10; retract

G1 Z5; level "up" to bucket after XY Homing to avoid interference

G1 X0.142857 Y45 F2000; move to rear X=0 Y=30 (Homing and purge bucket location)

G11; un-retract

G1 Z0; level down to bucket rubber

G1 E20 F100; extrude 20mm of filament at 1,7mm/sec

G1 Y75 F800; move slowly forward past the rubber strip

G1 Z5; raise the nozzle to avoid damage to the purge bucket

G1 Y149; go past first rubber strip

G1 Z0; continue purging on bed

G1 Y165; move slowly forward past the rubber strip

G1 X20; and 20mm to the right

G1 Y185; move slowly 20mm forward

G1 X0; and 20mm to the left

M402 Z F2000; resume Z stored position

M402 F2000; resume stored position

I see z moves to z=5 and to z=0 so it goes away from bed and goes back. So z triggers might have an influence and the question remains if ALWAYS_CHECK_ENDSTOPS 0 would prevent the error.

walbux · October 2019

Yes I have #define ALWAYS_CHECK_ENDSTOPS = 1.

I follow your advice and repeat the test setting it to 0 then I give you the result.

See you soon.

Walter

walbux · October 2019

OK test just done.
Result: nothing changes, the problem still appears as before.
I have done both the print with "my extruder switch code" and with no tool cleaning code at all as before.
in the first case the problem appears after the third tool switch, in the second case no problem at all also after the 6th switch.

Special note: apparently the extruder height wrt the hotbed lightly increases at every tool switch from 4th to 6th so that the last printed coloured object is the worse

but at the end of the first layer there is the command:

G1 Z0.0600 F3600.000 ; move to next layer (1)

then the height of the extruder returns correct !!

Thank you for your help.

Walter

walbux · October 2019

I have deeply analyzed the gcode and the only commands implying z movements are the layer 0 change of 0,4 mm at the beginning and the second layer at 0,6 mm (after all the 6 colors have been switched within the first layer).

Every other Z movement is between the M401 and M402 commands within the tool change code:

M401 - Store x, y and z position
...
G1 Z0
G1 Z5
...
M402 Z
M402 - Go to stored position.

So in conclusion no Z movement should disturb the print of the first layer despite the number of color changes.
See you soon.

Walter

walbux · October 2019

Any news ? Do you need further testing ?

Walter

Repetier · October 2019

Currently I have no idea what is going wrong. The endstop test was all I could think of. Just as you said it makes no sense to work 3 times and then get wrong.

Do you have autoleveling active? With autoleveling there could be lost position if coordinate systems used switch. But I do not see that this is happening.

Can you make a simple test without printing. Just moving and the switch code for different places. Is it happening also when you have only one per y row? Also maybe add a M114 after the M402 to output current position to see if firmware thinks it is where it should be.

The only way to solve this is to break it down to the smallest solution causing the error and identifying under which condition it happens. Especially with problems that happen always but not every time there must by a condition that causes the error to happen. One might be going outside allowed area so a move gets not executed.

walbux · October 2019

Yes, I have Autoleveling active and I do autolevel just after homing and before every print.
Should I disable it ?
What is strange is why autolevel should affect only the prints after the third tool switch...

In my mind the problem is linked to the virtual extruders from 17 to 32. Infact it happens when 3 of these extruders are used and apparently the higher the number of the extruder, the higher the height wrt bed. This anyway is linked to the M401 M402 sequence. I will do some test and then send you results.

The first test I will do is to cancel the print of the first 3 objects and see the behaviour of the FW printing only the other 3 objects with the virtual extruders from 17 to 32

Walter

walbux · October 2019

OK test done, I have canceled the print of the first 3 objects and see the behaviour of the FW printing only the other 3 objects with the virtual extruders from 17 to 32, those behaving uncorrectly in the 6 objects print.

Result:

print ok, no noticeable misbehaviour of the FW.

Now ?

Walter

walbux · October 2019

OK 2nd test done:
the test consists of:

homing
autoleveling
setup 32 Virtual Extruders

now Z=20

set T0
execute the tool cleaning sequence followed by M114
(Z=20 again)

set T4
execute the tool cleaning sequence followed by M114
(Z=20 again)

set T8
execute the tool cleaning sequence followed by M114
(Z=20 again)

set T16
execute the tool cleaning sequence followed by M114
(Z=20 again)

set T20
execute the tool cleaning sequence followed by M114
(Z=20 again)

set T24
execute the tool cleaning sequence followed by M114
(Z=20 again)

The test has been done without heating the extruders.

Test result:
despite most of the movement of the failing print have been done no error appeared.

Any advice ?

Walter

walbux · October 2019

Question,
how can I go outside allowed area ?
Setup:

Xrange is 0 - 355
Yrange is 0 - 330
Zrange is 0 - 280

The printing head cannot go out of the above ranges.

The 2 diamond extruders are configured as one only mixing extruder with 6 wire mixing instead of 3.
The heaters are connected in parallel whilst the Thermistor is one of the 2.
In the slicer the second extruder has an offset of 77 mm in the Y direction wrt the first.
This means that the outside allowed area can only be that the extruder 2 Y range is -7,7 - 322,3 or in other words the area between 322,3 and 330 cannot be printed by the second extruder.

Anyway during the print of the failing file no endstop seems triggered.

Walter

Repetier · October 2019

Ok, I see you come with new ideas.
First news to me you have 2 diamond extruders? I never wrote support for more then one. Is it 1-16 is the first one and 17-32 the second one? When switching extruders we use per extruder xyz offsets that must be set correct. If you have a z offset on the other it will add a z move that is not reflected in any coordinates. Switching back to first one would undo that change. That is also why you never set a xyz offset in slicer for the extruders. They are handled in firmware already and only then the homing is done so everything fits.

What happens in a print with only one extruder being used? If that works it is likely that the switching code adds the coordinate change as that was not included in the original code and there might be that something gets wrong.

walbux · October 2019

First answer yes 2 diamond extruders: 1-16 the first, 17-32 the second. This was the reason to extend from 16 to 32 the number of virtual extruders what else. Every per extruder XYZ offset has been set to 0. The only coordinate change is Y from 17 to 32 and is managed inside the slicer.
Apparently everything works ok except the z leveling of the first layer but only in the cases described.

walbux · October 2019

I know that you support only one mixing extruder and infact the twin diamond is configured as only one mixing extruder but with 6 wires instead of 3, one more of the Diamond Fullcolor Mixing extruder.

walbux · October 2019

So summarizing the tests done:

setup #define ALWAYS_CHECK_ENDSTOPS = 0, Autolevel enabled; no pause done

1 - I print 6 different colors cubes and the Z offset problem appears in the first layer last 3 colors
2 - I print 6 different colors cubes but I cancel the cleaning code (M401 ... Z movements ... M402 Z M402) at every tool (color) change and the problem disappears
3 - I print the same file but with only the last 3 cubes (colors - extruders 17 to 32) and no problem appears
4 - I simulate the movements by the following sequence:
set TN (extruder number N)
execute the tool cleaning sequence followed by M114
(monitor Z errors)
Result: no Z error appears.

What to do now.

Autolevel was always on. Shall i disable autolevel ? What exactly does autolevel wrt bed leveling ?

More generally is there a place where I can read in detail what each parameter does in addition to the code comments and the description inside the Configuration Tool because inside this last there is only described enable disable automatic bed leveling.

Thanks.

Walter

walbux · October 2019

One additional clarification, in the previous point 3 I print the same file (plate) of the point 1 cancelling the objects with the first 3 colors (extruders from 1 to 16) but I leave the cleaning code (M401 ... Z movements ... M402 Z M402) at every tool (color) change.

walbux · October 2019

I have an inductive sensor for probing and I have selected 3 points Bed Measuring Method and Bed Correction Method = Software correction of rotation.

I am waiting for your advices. Thanks.

Walter

Repetier · October 2019

Autoleveling controls z so distance bed-nozzle stays same for all xy positions. In this context there is a problem with second extruder. Here you move it slicer wise but firmware will still correct z for the first extruder position. So if bed has a rotation along y axis (z moves for y moves) you will be on a wrong z height by the 7cm correction between the nozzles. Hopefully not much so it might not really matter.

Autoleveling enabled means it will do this z correction while xy moves. Otherwise z distance will not be corrected.
Alternative is physically leveling the bed so G32 reports no correction for xy movements (b,c values I think it is in output).

My main problem is that your operation is much too complex to oversee it and there is a lot of text written here. And I do not see the error. Even for simple errors it is already hard to follow what happen in firmware code. Following a few hundret unknown lines not seeing the moves does not make it easier.

Shouln't the problem also happen when you have 2 objects with extruder 1 and 17? This is my attempt to make the problem as easy as possible. So first only 2 objects and then start removing commands between until only the error remains and you can say at that command it does that move wrong.
Also what happens if you remove parts inside M401/M402? Does it still get confused. I guess one of the commands gets the M402 in trouble by changing something it did not see.

Max number of virtual extruders

Comments