Skip to content

Commit

Permalink
New atomic operation through RIAA (prevent due hang?), cold extrusion…
Browse files Browse the repository at this point in the history 
… command, bug fixes
  • Loading branch information
@repetier
repetier committed Sep 28, 2014
1 parent 91bd2e1 commit 794df83
Show file tree
Hide file tree
Showing 33 changed files with 1,817 additions and 264 deletions.
47 changes: 26 additions & 21 deletions src/ArduinoAVR/Repetier/Commands.cpp
View file
Expand Up @@ -916,18 +916,18 @@ void Commands::processGCode(GCode *com)
}
break;
case 134: // G134
Com::printF(PSTR("CompDelta:"),Printer::currentDeltaPositionSteps[A_TOWER]);
Com::printF(Com::tComma,Printer::currentDeltaPositionSteps[B_TOWER]);
Com::printFLN(Com::tComma,Printer::currentDeltaPositionSteps[C_TOWER]);
#ifdef DEBUG_REAL_POSITION
Com::printF(PSTR("RealDelta:"),Printer::realDeltaPositionSteps[A_TOWER]);
Com::printF(Com::tComma,Printer::realDeltaPositionSteps[B_TOWER]);
Com::printFLN(Com::tComma,Printer::realDeltaPositionSteps[C_TOWER]);
#endif
Printer::updateCurrentPosition();
Com::printF(PSTR("PosFromSteps:"));
printCurrentPosition(PSTR("G134 "));
break;
Com::printF(PSTR("CompDelta:"),Printer::currentDeltaPositionSteps[A_TOWER]);
Com::printF(Com::tComma,Printer::currentDeltaPositionSteps[B_TOWER]);
Com::printFLN(Com::tComma,Printer::currentDeltaPositionSteps[C_TOWER]);
#ifdef DEBUG_REAL_POSITION
Com::printF(PSTR("RealDelta:"),Printer::realDeltaPositionSteps[A_TOWER]);
Com::printF(Com::tComma,Printer::realDeltaPositionSteps[B_TOWER]);
Com::printFLN(Com::tComma,Printer::realDeltaPositionSteps[C_TOWER]);
#endif
Printer::updateCurrentPosition();
Com::printF(PSTR("PosFromSteps:"));
printCurrentPosition(PSTR("G134 "));
break;

#endif // DRIVE_SYSTEM
default:
Expand Down Expand Up @@ -1256,7 +1256,7 @@ void Commands::processMCode(GCode *com)
{
Extruder::setTemperatureForExtruder(0,0);
#if NUM_EXTRUDER>1
for(uint8_t i=0;i<NUM_EXTRUDER;i++)
for(uint8_t i=0; i<NUM_EXTRUDER; i++)
Extruder::setTemperatureForExtruder(0,i);
#else
Extruder::setTemperatureForExtruder(0,0);
Expand Down Expand Up @@ -1320,7 +1320,8 @@ void Commands::processMCode(GCode *com)
break;
case 164: /// M164 S<virtNum> P<0 = dont store eeprom,1 = store to eeprom> - Store weights as virtual extruder S
if(!com->hasS() || com->S < 0 || com->S >= VIRTUAL_EXTRUDER) break; // ignore illigal values
for(uint8_t i = 0;i < NUM_EXTRUDER; i++) {
for(uint8_t i = 0; i < NUM_EXTRUDER; i++)
{
extruder[i].virtualWeights[com->S] = extruder[i].mixingW;
}
#if EEPROM_MODE != 0
Expand Down Expand Up @@ -1406,9 +1407,8 @@ void Commands::processMCode(GCode *com)
case 223: // M223 Extruder interrupt test
if(com->hasS())
{
BEGIN_INTERRUPT_PROTECTED
InterruptProtectedBlock noInts;
Printer::extruderStepsNeeded += com->S;
END_INTERRUPT_PROTECTED
}
break;
case 232: // M232
Expand Down Expand Up @@ -1465,15 +1465,17 @@ void Commands::processMCode(GCode *com)
#endif
case 281: // Trigger watchdog
#if FEATURE_WATCHDOG
{
Com::printInfoFLN(PSTR("Triggering watchdog. If activated, the printer will reset."));
Printer::kill(false);
HAL::delayMilliseconds(200); // write output, make sure heaters are off for safety
HAL::forbidInterrupts();
InterruptProtectedBlock noInts;
while(1) {} // Endless loop
}
#else
Com::printInfoFLN(PSTR("Watchdog feature was not compiled into this version!"));
Com::printInfoFLN(PSTR("Watchdog feature was not compiled into this version!"));
#endif
break;
break;
#if defined(BEEPER_PIN) && BEEPER_PIN>=0
case 300: // M300
{
Expand All @@ -1487,6 +1489,9 @@ void Commands::processMCode(GCode *com)
}
break;
#endif
case 302: // M302 S<0 or 1> - allow cold extrusion. Without S parameter it will allow. S1 will disallow.
Printer::setColdExtrusionAllowed(!com->hasS() || (com->hasS() && com->S != 0));
break;
case 303: // M303
{
#if defined(TEMP_PID) && NUM_TEMPERATURE_LOOPS>0
Expand Down Expand Up @@ -1706,7 +1711,6 @@ void Commands::emergencyStop()
#if defined(KILL_METHOD) && KILL_METHOD==1
HAL::resetHardware();
#else
BEGIN_INTERRUPT_PROTECTED
//HAL::forbidInterrupts(); // Don't allow interrupts to do their work
Printer::kill(false);
Extruder::manageTemperatures();
Expand Down Expand Up @@ -1737,8 +1741,9 @@ void Commands::emergencyStop()
#if HEATED_BED_HEATER_PIN>-1
WRITE(HEATED_BED_HEATER_PIN,HEATER_PINS_INVERTED);
#endif
HAL::delayMilliseconds(200);
InterruptProtectedBlock noInts;
while(1) {}
END_INTERRUPT_PROTECTED
#endif
}

Expand Down
2 changes: 1 addition & 1 deletion src/ArduinoAVR/Repetier/Communication.cpp
View file
Expand Up @@ -30,7 +30,7 @@ FSTRINGVALUE(Com::tFirmware,"FIRMWARE_NAME:Repetier_" REPETIER_VERSION " FIRMWAR
FSTRINGVALUE(Com::tFirmware,"FIRMWARE_NAME:Repetier_" REPETIER_VERSION " FIRMWARE_URL:https://github.com/repetier/Repetier-Firmware/ PROTOCOL_VERSION:1.0 MACHINE_TYPE:Core_XY EXTRUDER_COUNT:" XSTR(NUM_EXTRUDER) " REPETIER_PROTOCOL:2")
#endif
#endif
FSTRINGVALUE(Com::tDebug,"Debug:");
FSTRINGVALUE(Com::tDebug,"Debug:")
FSTRINGVALUE(Com::tOk,"ok")
FSTRINGVALUE(Com::tNewline,"\r\n")
FSTRINGVALUE(Com::tNAN,"NAN")
Expand Down
6 changes: 3 additions & 3 deletions src/ArduinoAVR/Repetier/Communication.h
View file
Expand Up @@ -79,9 +79,9 @@ FSTRINGVAR(tSpaceRaw)
FSTRINGVAR(tSpaceAt)
FSTRINGVAR(tSpaceBAtColon)
FSTRINGVAR(tColon)
FSTRINGVAR(tSpeedMultiply);
FSTRINGVAR(tFlowMultiply);
FSTRINGVAR(tFanspeed);
FSTRINGVAR(tSpeedMultiply)
FSTRINGVAR(tFlowMultiply)
FSTRINGVAR(tFanspeed)
FSTRINGVAR(tPrintedFilament)
FSTRINGVAR(tPrintingTime)
FSTRINGVAR(tSpacem)
Expand Down

33 comments on commit 794df83

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Due (RepRap Duet) hangs anyway..the worse thing is that it hangs randomly
Where can be the cause? (Even with Serial object it hangs)
Is it possible to trace with JTAG?
Really waiting for your reply

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you have a board with jtag interface that could help. I don't have it, so I make guesses and try again. Which is difficult since it seems not possible to force the hang with some simple commands. So a good print is no guarantee. Strangest thing of all is that it is the same code as for avr which seems to run with no problem. So it must be something arm specific (guess).

@kyrreaa
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have a Due and am wiring it up to use a set of loose stepper-boards I have.
I also have a jlink adapter so I can try and see what's going on later.
I'll see if I have time to check the usb stuff too as I expect it is possible to handle this by using a soft timeout. The usb subsystem will never take more than a set ammount of time to be ready to transfer a packet so we can handle the missing connection.

@kyrreaa
Copy link
Contributor

@kyrreaa kyrreaa commented on 794df83 Sep 30, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried to remove USBSerial at all from Arduino core...
It didnt help! So the problem isnt USB as it seems.
Also i tried to just put leds and turn it on when Due is in interrupt.
When it hangs it isnt in any interrupt (as i see,but not clearly).

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kyrreaa ,try to catch address or function in where it hangs

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also have ordered a jtag interface now. Hope the error occurs also with a naked due and does not take too long. On etester needed 40h to get it the first time. Long debug run!

@kyrreaa
Copy link
Contributor

@kyrreaa kyrreaa commented on 794df83 Oct 1, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So..

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's now running for 3 days without any errors inside the debugger. And I only removed one one overflow bug if pdm was enabled in HAL.cpp

static uint8_t pwm_cooler_pos_set[NUM_EXTRUDER + 3];

the +3 was missing. I think the hang was already before. Anyway I'm testing with fixed line without hang. Anyone else who could cause the hang with a naked board?

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try to run& debug too...
Big thanks for info about this bug!

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you compiling with Arduino 1.5.x or with Makefile+arm-gcc...?

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

With atmel studio using a very home brew configuration which includes the files of arduino as sources as well, so i can debug them as well. That was the easiest solution since the jtag works great within Atmel Studio. If you want I can send you the project also you would need to update the path settings to the gcc libraries. Just drop me a real mail so I can mail you the link.

Maybe that reorderd the data in a bad way, meaning removing the problem since the overwrite (if it is one) doe snot happen where it causes a damage.

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will try it(both master & 092 branch)
You can also try just to compile via Arduino IDE

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But how can I debug it then, if I compile with Arduino IDE? Compilation result must match my debug informations or I have still no clue what happens.

@kyrreaa
Copy link
Contributor

@kyrreaa kyrreaa commented on 794df83 Oct 7, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can send Atmel project to me
mail: (mynickname)@gmail.com
Thanks!

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mushketer888 Mail is on its way

@kyrreaa Don't understand what you mean. When I press debug in Atmel Studio it always starts the current project, compiles it and uploads it. How can I tell to use a external binary instead?

@hexa6six
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi,
just wanted to let you know that the hangs also occur if the DUE is not connected to any host via USB. In my case I'm using DUE+RADDS+RADDS-LCD and I always print from SD-Card. It randomly hangs as described above. Strange enough, the very same gcode might print ok another time.
Are we sure, that the DUE just ain't picky about electromagnetic influences?

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Regarding this special error nothing is sure:-) We had it with host or sd print, with h-belta nd delta printers, but I lost a bit track of the other combinations that already had that error. Especially since it is hard to see if it is always the same error. Only the fact, that is is already very rare lets us asume it is one error. Checking the interrupt handlers I even saw that the default interrupt handler is an infinite loop, so any normally unused interrupt would also cause a hang. Also I think the NMI interrupt is the most likely if it is a interrupt.

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I compiled from Atmel Studio...
No hangs yet at all!!
Testing..

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, just found some more bugs in the HAL.cpp cooler handling which I fixed with latest update. Now there is no buffer overflow any more.

@mushketer888 Your version still contains the bug but no overflow.

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks
I updated latest changes

Running

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From USB it prints normally (as far as i go)
But with Due Software SPI it hangs randomly
Looks like something with software spi+interrupts (maybe interrupts damage spi bits etc)

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope it hangs anyway...strange (with or without software spi) usb<->spi

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So which version did hang? The one from Atmel Studio? Did it stop in debugger or just uploaded from studio?

@mushketer888
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From Atmel with latest changes
I didnt connect debugger yet (cause i will use OpenOCD)..
I just uploaded .bin from studio
Now i disabled software spi,sd at all and testing..

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why are you using software SPI?

Anyhow you seem to get more errors with my Atmel version then I get, so if you send me your Config I can test that instead. Does not look like my settings are going to crash for me.

Did you test naked board or real printing? I'm only testing naked because I need to disable watchdog to see hang and that is dangerous as we know.

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, I got a hang while in debugger after a week of running. Hang occured in this function:

void HAL::microsecondsWait(uint32_t us)
{
uint32_t usStart, goal;

// get the current count
usStart =  TC_ReadCV(DELAY_TIMER, DELAY_TIMER_CHANNEL);

// funny math here to give good accuracy with no overflow 
goal = usStart + 10*us-5; //((F_CPU_TRUE / (DELAY_TIMER_PRESCALE * 100000)) * us) / 10;

// goal may have wrapped, if so wait for counter to catch up
if(goal < usStart) {
    while(goal < TC_ReadCV(DELAY_TIMER, DELAY_TIMER_CHANNEL));
}   
// wait for counter to reach requested value
while(goal > TC_ReadCV(DELAY_TIMER, DELAY_TIMER_CHANNEL));

}

more precisely in

while(goal > TC_ReadCV(DELAY_TIMER, DELAY_TIMER_CHANNEL));

with goal = 0xffffffff

As everyone can see the likelyhood that read time is larger is extremely low. Also I think the function is not very accurate. Now I switched to the arduino version and hope it works as expected. This version is slightly faster whcih caused my lcd to not initalize correctly - I added some more delay there.

That also means that eventually your STEPPER_HIGH_DELAY may be to low now if you needed them.

@kyrreaa
Copy link
Contributor

@kyrreaa kyrreaa commented on 794df83 Oct 10, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nophead
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The way I do timer delays is much simpler and bug free.

start = read_timer();
while(read_timer() - start < delay)
   ;

It handles wrap around implicitly as long as start is the same size as the timer.

@kyrreaa
Copy link
Contributor

@kyrreaa kyrreaa commented on 794df83 Oct 10, 2014 via email

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@repetier
Copy link
Owner Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I think the Arduino solution I now use is most accurate

static inline void delayMicroseconds(uint32_t usec)
{
    uint32_t n = usec * (F_CPU_TRUE / 3000000);
    asm volatile(
        "L2_%=_delayMicroseconds:"       "\n\t"
        "subs   %0, #1"                 "\n\t"
        "bge    L2_%=_delayMicroseconds" "\n"
        : "+r" (n) :  
    );
}

A simple loop knowing a cycle take 3 ticks. So overhead is a multiplication and that bge takes a tick longer when it leaves the loop. It is blocking but thats ok. We normally call it from interrupt for a 1us or 2us wait and that is not enough for writing a multithreaded firmware.

@nophead Your solution also works perfect, but a function call may be more overhead so timing would be correct time + [0..function call + sub + compare]. In case of the due it is not much and also would work well, just a little bit less inaccurate (< 1us I think).

Please sign in to comment.