v092: "use_advance" in combination with "drive_system 2"

andin

Following observations were made with the latest version of RepFW 092.2:

Following setups cause erratic motor movements of X&Y which do not coincide with required coordinate movements (i.e. something wrong with X/Y positioning):

DRIVE_SYSTEM 2

USE_ADVANCE 1

EXT0_ADVANCE_K 40 <-- set using EEPROM

Following setups work without problems:

DRIVE_SYSTEM 2

USE_ADVANCE 1

EXT0_ADVANCE_K 0 <-- set using EEPROM

DRIVE_SYSTEM 1

USE_ADVANCE 1

EXT0_ADVANCE_K 40 <-- set using EEPROM

Summary:

The problem is caused by combined usage of DRIVE_SYSTEM 2 and the advance algorithm.

andin

Correct:

In my previous post, I made a mistake:

It should say EXT0_ADVANCE_L, not EXT0_ADVANCE_K obviously.

Repetier

Advance has no direct connection with movement in xyz. Moreover it is completely independent of the drive system. So I guess it is not really software related. What I think is that it is an other instance of crosstalk. Maybe to endstops causing moves to stop early (disable always checking endstops to validate) or even influencing of xy somehow, also I haven't seen this happen so far. Normally it is a endstop triggering from stepper signals. Activating advance causes faster stepper rates inducting more current. Something like that.

andin

I was confused as well - there should be no relation between both. always checking endstops is disabled.

However, there is no such problem with version 0.91.7.

There must be something in 0.92 which creates such problems.

Configurations I used for testing both firmware versions were absolutely identical with new features of 0.92 disabled.

Repetier

0.92 now has PDM instead of PWM enabled by default. That gives different frequencies on the extruder heater line (more frequent). Yesterday I had a user where this made the difference between crrosstalking and not crosstalking.

On the other side, if endstop checking was disabled it should not be crosstalk to endstops creating the problem. But without knowing your printer and knowing how and where all the cables are it is hard to say what is influencing what.

andin

Thanks for your quick responses, repetier!

<div>
</div>The heater was disabled during the test. I also take specific cautions to EMI-related issues by making sure that cables do not radiate and the signals are robust. Crosstalk is minimal on all lines - checked with my oscilloscope...

There is this interesting phenomena which seems like a bug in the firmware (or maybe I am missing something):

This settings works good:

#define DRIVE_SYSTEM 2

#define USE_ADVANCE 1

#define EXT0_ADVANCE_L 0 <--- set using EEPROM

Causes erratic movements of X-Y and high motor noise:

#define DRIVE_SYSTEM 2

#define USE_ADVANCE 0

<div>#define EXT0_ADVANCE_L 0 <--- not available in EEPROM

Ceteris paribus, all other settings remain equal.

</div>

What other differences there are 0.91.7 vs. 0.92.2 that could cause these issue?

andin

Ok, problem found:

Repetier Host does not load the EXT0_ADVANCE_L to EEPROM correctly. I assume the parameter is loaded as int and not as float as it is supposed to be, but not sure...

Anyway, I have tested saving EXT0_ADVANCE_L 40 to EEPROM using my LCD controller and it works without any problems in X-Y movement thereafter. The act of saving was verified by checking the EEPROM settings from the host.

On the other hand, saving EXT0_ADVANCE_L 40 to EEPROM from the Repetier Host causes problems.

:-)

andin

Follow-up:

The problem persists and is definitely a bug in the firmware:

The issues with X-Y movements appear with DRIVE_SYSTEM 2 and after the function setAdvanceActivated() is called.

Hardware related problems are out of the question: everything works wonderfully if DRIVE_SYSTEM is set to 1 and/or EXT0_ADVANCE_L=0. Crosstalk problems were excluded after checking with an oscilloscope - besides my hardware setup is very EMI-robust.

It would be great if you could verify the firmware. Many thanks!

Repetier

I rechecked the firmware. Drive system 1 and 2 are nearly identical and only differ in 2 routines: startXStep and startYStep. See here startXStep for axample

#if DRIVE_SYSTEM == XY_GANTRY DRIVE_SYSTEM == XZ_GANTRY

if(isXPositiveMove())

{

Printer::motorX++;

Printer::motorYorZ++;

}

else

{

Printer::motorX--;

Printer::motorYorZ--;

}

#endif

#if DRIVE_SYSTEM == YX_GANTRY || DRIVE_SYSTEM == ZX_GANTRY

if(isXPositiveMove())

{

Printer::motorX++;

Printer::motorYorZ--;

}

else

{

Printer::motorX--;

Printer::motorYorZ++;

}

#endif

As you see there is really no difference that could explain it. Only difference is direction of motors.

Also does it happen with L = 30 or only with 40? You might be right that you have no crosstalk but I have seen strange things like power units switching of at special extruder PWM frequencies, Y axis loosing some steps for no apparent reason on Rumba boards and more. Also it is very unlikely that a software problem like this appears only for some very special extruder speed settings. So I still think it is a electronic issue. Maybe you should switch XY with extruder 0/1 sockets and see if it goes away.