Welcome! Log In Create A New Profile

Advanced

RADDS work now stable with RepRap Firmware

Posted by angelo 
Re: RADDS work now stable with RepRap Firmware
February 27, 2016 10:45PM
And thanks to everyone for helping to diagnose this! Everyone's patience and willingness to help is appreciated.
Re: RADDS work now stable with RepRap Firmware
February 27, 2016 10:55PM
I fix my problem. That was the line "G10 P0 S0 R0" , Without a thermistor hook up it fail but as soon as you hook your thermistor its all good, probably a failsafe for broken thermistor I guess

You should put a note for that in your doc radds.md something like: Testing without thermistor can cause issue.

Thanks Dan and DC42, Its was nice to you guys to help me out, many Dev simply dont care if one user out of many have problem.

Keep the good work guys!
Re: RADDS work now stable with RepRap Firmware
February 28, 2016 02:52AM
Ok thx!
Re: RADDS work now stable with RepRap Firmware
February 28, 2016 03:49AM
Quote
GroupB
I fix my problem. That was the line "G10 P0 S0 R0" , Without a thermistor hook up it fail but as soon as you hook your thermistor its all good, probably a failsafe for broken thermistor I guess

That will have been caused by the firmware trying to send an error message to all interface including the web interface. So should be fixed in Dan's latest release.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
February 28, 2016 03:55AM
Quote
dnewman
I found and fixed the issue with config.g causing a hang when it generates error responses (or any response which isn't an Ok response). The fix is checked in to the RADDS port. A new build (with 1.5.8beta) is at

https://github.com/dcnewman/RepRapFirmware/blob/dev/Release/RepRapFirmware-1.09r-dc42-radds-b.bin

The issue was specific to the RADDS port. It related to there not being network-based reporting paths. I had missed #ifdef'ing out a section. Was easy enough to #ifdef out a couple of enumerations and then let the compiler tell me where all they occurred. (That will also prevent that exact issue from biting again in the future should new code be added using those enum members.)

I'm glad you solved it.

I had to do a build without the web and telnet interfaces recently. I left the calls into the webserver module in place, but I stubbed the webserver I/O functions like this:

bool Webserver::GCodeAvailable(const WebSource source) const
{
	return false;
}

char Webserver::ReadGCode(const WebSource source)
	return 0;
}

void Webserver::HandleGCodeReply(const WebSource source, OutputBuffer *reply)
{
	OutputBuffer::ReleaseAll(reply);
}

void Webserver::HandleGCodeReply(const WebSource source, const char *reply)
{
}



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
February 28, 2016 10:25AM
Got a little hardware question for the radds, Im about to wire the fan on the head , gonna have 2 fan, the hotend and the pla cooling fan, im wondering can I bring only one 12V and share it since the mosfet is a NPN and switch the GND ? If I do what will happen at the diode of the fan where the 12V is not going through there ? Are the fan really require that diode or its more for the heater ?


Re: RADDS work now stable with RepRap Firmware
February 29, 2016 10:27AM
I just try the new firmware its good Dan! , I was still on the last B you sent me , doing some testing before doing my first calibration and the Extruder wont extrude and reset the controller, so I went ahead and flash your new one, and its nice this time instead of a reset a got a nice " Hey dumbass you cant cold extrude without M302 ! " Its help a lot for noob like me to have proper error msg instead of a disconnect right away smiling smiley
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 11:28AM
I have a speed problem , Im wondering if other users of this firmware on Due/Radds have the same problem:

If I ask the printer to move at 5500 mm/Min + its doing weird thing like the X axis going only midway ( whatever if I change the driver OR if I hook the X driver to the Z axis its always the same, or ramp up the A on the driver) Under 5500 all is great and movement are OK

Due/Radds 1.09r firmware, dvr8825 1/32

for more detail see my thread on delta :

My thread

im loss , I tried everything, changing driver, changing motor, ramp up A on driver,change from octoprint to prontoface... im out of idea
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 12:43PM
What's the step rate? That is, what are the steps/mm for that axis?

Now, I've been told by some Marlin developers that DRV8825s actually require slightly different step pulse timing but that they mostly work okay until you push the step rate too high. I do not know if that is valid or not; I've pretty much ignored DRV8825s since they are not well suited to 3DP anyway. They are meant for low speed applications such as scanners and ink jet printers. (They have too long of a min. rise time.) As such, I don't myself know if there is indeed a need for slightly different step pulse timing than RRF provides.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 12:59PM
Im using 160 step/mm

So im the first one on radds using dvr8825 or what ?

Edited 1 time(s). Last edit at 03/04/2016 01:05PM by GroupB.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 01:26PM
So that's a step rate of 14.7 KHz.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 01:29PM
So you see any problem having that step rate with reprap firmware ?
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 01:44PM
I myself don't know. dc42 would have an informed opinion on that subject. I don't as regards either DRV8825 or RRF.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 01:57PM
I gonna try repetier I guess and see if this problem is only with reprapfirmware,

so there a good chance those rasp 128 or tcsomething wont work too right ?
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 02:07PM
RAP128s work fine for me. However, I stick to resolutions in X & Y below 100 steps/mm. And further, I'm not a Delta user and do not know how much additional load that is imposing. Again, you might ping dc42 for comment.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 02:24PM
DC already check my other post and so far, got no solution

its chinese for me but here I found someone with a RADDS having the same problem on repetier but in repetier look like there a setting to fix that :

maybe a hint

they talk about the firmware is too fast for the dvr8825 and to add stepper high delay 1 or 2 us... do that sound like this can be my problem ? is there such setting in reprapfirmware ?

edit : more research repetier say dvr8825 need 1.8us delay

Edited 1 time(s). Last edit at 03/04/2016 02:27PM by GroupB.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 03:54PM
Quote
GroupB

they talk about the firmware is too fast for the dvr8825 and to add stepper high delay 1 or 2 us... do that sound like this can be my problem ? is there such setting in reprapfirmware ?
edit : more research repetier say dvr8825 need 1.8us delay

That's basically what I was referring to earlier as heresay from some Marlin developers: different step pulse timing is needed for DRV8825s. And if that is truly the root problem, then use RAPS-128s or Panucatt SD6128's would be a hardware "fix".
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 04:13PM
I've looked at the code. It effectively creates a 1.07uS step pulse. (More like 1.1 uS if you toss in time to handle the loop and function call, assuming the compiler hasn't unrolled the loop or inlined the function.) I'll see about sending you a build which takes double that. Not quite the 1.8uS but good enough to see if this is indeed the root cause.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 04:57PM
You may also need to increase the minimum pulse interval, in the case where multiple pulses for a motor are generated in one call to the ISR.



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 05:24PM
Ok dan I try the firmware you sent me, and its the same problem nothing change, I dont know what the delay you add but they speak or 2us on repetier
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 05:44PM
Well, I went with your

Quote

edit : more research repetier say dvr8825 need 1.8us delay

We can try 2.0 uS but as dc42 wrote, the delay between successive pulses may also need to be increased.
Re: RADDS work now stable with RepRap Firmware
March 04, 2016 06:02PM
probably, that will explain why its move kinda to 150 when ask 300... half the pulse are missed
Re: RADDS work now stable with RepRap Firmware
March 05, 2016 03:08AM
I just checked the datasheet again. The DRV8825 needs 1.9us step pulse high time, 1.9us step pulse low time, 650ns setup time and 650ns hold time for DIR before the rising edge of the step pulse. The corresponding figures for the A4982 are 1us, 1us, 200ns and 200ns.

RepRapFirmware will switch to double stepping when the pulse frequency to the motor rises above 14.3kHz. At 160 microsteps/second that equates to a Z movement speed of about 90 mm/sec, or 5400mm/min. So that would explain why the problem occurs at 10000mm/min but not at 5000. Looks like the width of the step pulse isn't causing a problem, but the interval between step pulses is.

Dan, you could try adding a delayMicroseconds(2) call after these lines in DDA.cpp, around line 882:

	reprap.GetPlatform()->StepLow(drive);
	dm = firstDM;



Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod

Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Re: RADDS work now stable with RepRap Firmware
March 05, 2016 01:23PM
When you figure this out Dan , send me the file , I will be happy to test it for you... since I cant print because of extruder problem that all I can do "test"
Re: RADDS work now stable with RepRap Firmware
March 05, 2016 02:27PM
I may have time this evening.
Re: RADDS work now stable with RepRap Firmware
March 05, 2016 03:37PM
no hurry , still have more problem to fix other than dvr8825
Re: RADDS work now stable with RepRap Firmware
March 05, 2016 08:10PM
Quote
dc42

Dan, you could try adding a delayMicroseconds(2) call after these lines in DDA.cpp, around line 882:

	reprap.GetPlatform()->StepLow(drive);
	dm = firstDM;

Done and e-mailed. The idea here is that the instructions between setting the step pin HIGH and then LOW again will take more than 168 clock cycles (2 uS) and thus no additional action there is needed?
Re: RADDS work now stable with RepRap Firmware
March 05, 2016 09:31PM
Tested 1.09-e, its work I went up to 400 mm/sec (24000 mm/min) without problem, not missing a beat, on my 300 mark all the time.

No more reason for dvr8825 user to not give a try to RRF now.

You guys planing to add a M command to select the driver in the futur? instead of keeping 2 different .bin ...
Is the dvr8825 the only one with different timing or the raps 128 or tc something too ?

I did not test the direction, I dont know if fast change of direction is affected too, I saw in repetier they have a setting for that too, a delay on direction

How I test that ? simply make a macro with example : G1 S1 X-300 F12800 (next line) G1 S1 X100 F12800 (next line) G1 S1 X-100 F12800 ( repeat)
will that work or there a faster way to test that ?

Edited 1 time(s). Last edit at 03/05/2016 09:34PM by GroupB.
Re: RADDS work now stable with RepRap Firmware
March 06, 2016 12:06AM
Quote
GroupB
Tested 1.09-e, its work I went up to 400 mm/sec (24000 mm/min) without problem, not missing a beat, on my 300 mark all the time.

Thanks for testing. The change here is that there's sufficient delay after the STEP pulse and before the next STEP pulse. I had merely been focusing on ensuring that the STEP pulse itself was asserted long enough. (And in my defense, I did write that that alone may not be sufficient.)

Quote
GroupB
No more reason for dvr8825 user to not give a try to RRF now.

Well, you're the only person other than myself with that code hack. Now, we need to decide how to cleanly make this available to others. If people are using other stepper drivers, they won't need that added delay. So, ideally, it should only be when the end user configures it to be used. Possibly even on a per drive basis. dc42 may have an opinion on what gcode to leverage for enabling/disabling it.

Quote
GroupB
I saw in repetier they have a setting for that too, a delay on direction

Yes, that may be needed as well.
Re: RADDS work now stable with RepRap Firmware
March 14, 2016 11:19PM
Hello, guys.

Where do I connect a inductive Z probe on RADDS?.. Probe model is LJ18A3-8-Z/BX. I wired it up through a voltage divider so it outputs a 3.2 V when triggered. A perfect replacement for normally-open Z min switch, but a manual for Duet says I need to connect it to E0 endstop. There is also a reference in code to E0_AXIS, but it is not in Pins.h for RADDS.
Sorry, only registered users may post in this forum.

Click here to login