Max number of virtual extruders

walbux

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

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

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

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

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

Actually only in extruder.h the line

#define VIRTUAL_EXTRUDER </div>

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

Thanks a lot !
I will keep EPROM MODE DISABLED.

Walter

walbux

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

G92 E0

G1 E100 F120

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

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

walbux

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

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

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

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

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

Ok, but that seems to be your extruder switch code
M401; store current position in memory;G10; retractG1 Z5; level "up" to bucket after XY Homing to avoid interferenceG1 X0.142857 Y45 F2000; move to rear X=0 Y=30 (Homing and purge bucket location)G11; un-retractG1 Z0; level down to bucket rubberG1 E20 F100; extrude 20mm of filament at 1,7mm/secG1 Y75 F800; move slowly forward past the rubber stripG1 Z5; raise the nozzle to avoid damage to the purge bucketG1 Y149; go past first rubber stripG1 Z0; continue purging on bedG1 Y165; move slowly forward past the rubber stripG1 X20; and 20mm to the rightG1 Y185; move slowly 20mm forwardG1 X0; and 20mm to the leftM402 Z F2000; resume Z stored positionM402 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

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

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

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

Any news ? Do you need further testing ?

Walter

Repetier

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.